When I moved from software engineering into product management, I expected product discovery to be about learning new frameworks and techniques. Looking back, the frameworks were the easy part. What really shaped my approach was learning how to make decisions when there was never enough information to be completely certain.
One thing that made the transition feel natural was that I had always enjoyed challenging solutions. Even as a software engineer, I was rarely the person who simply implemented what landed in my backlog. I wanted to understand why we were building something before thinking about how to build it. That curiosity was one of the reasons I moved into product management.
What surprised me was how different it feels when the problem belongs to your users instead of your colleagues.
As an engineer, most of my stakeholders were internal. Even when I worked on the XING Design System, our users were developers across the company who shared similar context and whose needs were easier to validate.
Product discovery felt different.
Users don't always describe their problems clearly. What they say doesn't always match what they do, and unlike software engineering, there isn't a compiler waiting to tell you whether your thinking is correct.
The frameworks were the easy part.
The difficult part was deciding what to believe when every piece of evidence seemed to tell a slightly different story.
While working on XING's Salary Transparency initiative, this mindset was really tested.
We were building a feature that displayed salary information on job postings to help job seekers make better informed decisions.
The goal sounded simple.
The questions weren't.
Should we show a predicted salary range?
Should we communicate how confident the prediction was?
Would users trust an estimate?
Was an estimated range better than showing nothing at all?
There were no obvious answers.
So we started learning.
We interviewed job seekers. We worked closely with our Data Scientists to understand the reliability of our salary predictions. We analyzed user behavior, looked at competitors, and challenged different ideas across the team.
I found myself constantly moving between customer interviews and dashboards.
When users told us salary transparency mattered, I wanted to know whether their behavior reflected what they were saying. When the analytics showed a pattern, I wanted to understand the story behind it.
For a while, my engineering instinct took over.
If the answer wasn't obvious, maybe the evidence wasn't good enough.
Maybe we needed better interviews.
Better analytics.
Better questions.
Looking back, I don't think that instinct was wrong. Better evidence leads to better conversations, better insights, and ultimately better decisions.
Learning how to collect reliable evidence is one of the most important parts of product discovery.
What changed wasn't my focus on evidence.
It was my expectation of what that evidence could do.
I had been treating research as a way to uncover the right answer.
Then I realized what I was really searching for.
I wasn't looking for better evidence.
I was looking for certainty.
That shift completely changed how I approached discovery.
Instead of asking whether we had found the right solution, I started asking what uncertainty we were actually trying to reduce.
Sometimes the uncertainty was about whether users really had the problem.
Sometimes it was about whether our data was reliable enough.
Sometimes it was about understanding the trade-offs between different solutions.
Once we had reduced the biggest uncertainty, the next step wasn't more research. It was making a decision and continuing to learn after shipping.
Looking back, I don't think my software engineering background made product discovery harder.
In many ways, it gave me the curiosity to challenge solutions and the discipline to think critically about evidence.
What had to change was my expectation that good evidence would eventually remove uncertainty altogether.
It doesn't.
Today, I still care deeply about collecting good evidence. The difference is that I no longer expect it to eliminate uncertainty. I expect it to help me make a better decision.
The goal of product discovery isn't to eliminate uncertainty.
It's to reduce it enough to make a thoughtful decision.