Vidyut Salaria
Problems never stop appearing, and neither does my drive to solve them.
So I build them myself. Six problems, six unrelated domains, all driven by the same instinct.
How I think
Six problems. Six domains.
Same instinct every time.
The principle
I build for myself first.
“If something bothers me enough to fix, statistically it bothers thousands of others. I build for myself. The population follows.”
The story so far
None of this was planned. I finished my MSc without a clear sense of what came next, and chose my dissertation topic hoping it would pass. When the results came back, something shifted: I had designed an experiment from nothing, built the platform to run it, and the data held up. That was the first proof I had that I could take an idea and make it work through resourceful problem-solving, not just theory.
Then came the part nobody puts on a portfolio: months of applying to roles that either did not fit what I wanted or asked for experience I did not have yet. Rather than wait for that loop to break on its own, I started building. Not because every idea was significant, but because each one taught me a new tool, a new problem, a new way of thinking. Six domains later, this page is the result.
Where I'm strong
Compulsive curiosity
I do not pick domains because they are relevant. I pick them because something in them bothers me enough to understand. Psychology, retail, finance, cryptography, strategy, knowledge systems: the through-line is not the subject, it is the need to figure it out.
Finding what's underneath
Every project here started as something else on the surface. The expiry feature existed on every shop till. Nobody asked why nobody used it. The forecast line existed on every stock app. Nobody asked what it could not see. The work is always one layer deeper than the obvious problem.
Shipping past the user story
Most product thinking stops at the user. I think end to end: from identifying the opportunity, to positioning the solution, to how it reaches the customer, to how it generates value. A feature is not done when the user is happy. It is done when the business case closes.
Learning and teaching
I absorb fast and explain clearly. The same instinct that pulls me into a new domain pushes me to make it legible to someone else. I do not hoard what I learn.
Adaptable by default
Solo when the problem needs deep focus. Collaborative when it needs range. Given liberty I will find a better way. Given constraints I will still deliver. Same person, different modes, depending on what the work actually needs.
Right now: actively looking for a role that suits my profile. I ask why before I ask how. Currently based in the UK, open to relocation.
The work
Six self-initiated builds, six domains.
Each one starts with the problem I noticed, not the title.
I had no formal background in most of these domains.
That distance is what let me see what insiders had stopped noticing.
"Everyone was studying AI performance. Nobody asked what happens to the human when they find out their teammate isn't one."
AI was entering the workplace as a collaborator. Nobody had empirically tested what actually happens to a human working alongside one: emotionally, cognitively, in terms of raw performance. And nobody had asked the specific question: does it matter whether the human knows their teammate is AI?
Survey-based studies measuring what people think they feel. Human-to-human teaming experiments with established methodology. Both were safe, low-risk, and already answered. Neither touched the question of human-AI collaboration in real time.
Built a full web application from scratch to run the experiment. It needed to reach participants internationally and track real-time performance metrics across three controlled conditions. 66 participants. ANOVA with Tukey HSD post-hoc. AI-aware participants scored ~87% higher than AI-unaware. p<.001. Effect size η²=.34. Awarded Distinction. Examiners described it as publication-level work. Three domains navigated simultaneously: psychology research, full-stack development, and Russell Group academic standards.
The easy version was a survey study: hand out questionnaires, analyse responses. Fast, low-risk, acceptable for a dissertation. Cut it because surveys measure what people think they feel, not what they actually do under pressure. Cut human-to-human teaming as the comparison because that question had already been answered. Chose the harder question specifically because it was harder, and because it was interesting enough to actually work on.
The findings have direct implications for AI deployment strategy in organisations. The next step is translating the academic findings into a practical framework for HR and product teams: when to disclose AI involvement, how transparency affects team dynamics, and what the performance data means for AI product design.
The Toolkit
Everything I've picked up.
Across projects, domains, and years of curiosity.
Certifications
Proof of range.
Formal credentials across product, cloud, data, and strategy.
Featured
Certified Scrum Product Owner (CSPO)
Scrum Alliance
McKinsey Forward Program
McKinsey & Company
Google Project Management Certificate
Coursera · Google
EA Product Management Job Simulation
Forage · Electronic Arts
Siemens Mobility PM Job Simulation
Forage · Siemens
AWS Academy Cloud Foundations
Amazon Web Services
Also completed
Architecting with Google Compute Engine Specialisation
Coursera · Google Cloud
Oct 2020
Six Sigma Yellow Belt
Coursera
Lean Six Sigma White Belt
Management and Strategy Institute
Oct 2021
SQL (Intermediate)
HackerRank
Apr 2025
What's next
Let's find a problem
worth solving together.
Currently based in the UK. Open to relocation. Looking for a role built around problems worth that level of focus.