Product Discovery: Build what matters

Getting your Trinity Audio player ready...

From Quality to Curiosity — My Journey into Product

Before stepping into the world of product management, I spent a few years as a Quality Engineer. I loved breaking things, poking at edge cases, and making sure everything worked as expected. But over time, I found myself asking a different kind of question:
“Where did this requirement even come from?”, “Why are they even asking for this feature?”, “How is this going to solve the problem for the client?”

I was curious not just about how something worked, but why we were building it in the first place. That curiosity eventually pulled me upstream — into user stories, product decisions, and conversations that happened before the first line of code was written.

Now that I’m working in product, I’ve started to see patterns, mistakes, and opportunities more clearly. And one of the most important lessons I’ve learned is brought to you as a blog.

Let me start with something simple : Product discovery is how we figure out what’s worth building.

Sounds obvious, right? But in practice, it’s easy to get it wrong — especially when deadlines loom, roadmaps fill up, and pressure to ship is high.

Why Product Discovery Even Matters

The reality is, building products is expensive. Every line of code takes time, money, and attention away from something else. So before we invest in building anything, we need to be confident it’s the right thing — something our users actually need and will value.

That’s where discovery comes in. It’s how we learn. It’s how we stay close to our users. And it’s how we avoid the trap of building beautiful solutions to the wrong problems.

The Common Trap: Starting with Solutions

One of the most common mistakes I see (and have made myself) is this: We start with the solution.

Someone has an idea. It sounds great. We scope it, design it, build it, test it, and launch it. And then… crickets. Adoption is low. Engagement is flat. And we wonder what went wrong.

What happened is that we skipped the problem. We didn’t take the time to really understand why this feature mattered or what specific pain it was solving. We focused on delivery, not discovery.

Problem First, Always

Real product discovery starts in the problem space, which ideally is the opportunity space. What are our users struggling with? What’s holding them back? What do they actually need?

To get those answers, we need to go out and talk to them. Not once. Not occasionally. But continuously.

That means:

• Customer interviews
• Observing behavior
• Running usability tests
• A/B experiments
• Tracking how users actually use the product
• Asking, listening, watching

All of this helps us see the product through their eyes — not ours.

Why It’s Hard to See Like a User

Let’s be honest: we’re much closer to our products than to our users.

We know the workflows. We know what comes next on each screen. We’ve been living and breathing it for months. But our users? They just want to get a job done. They’re not thinking about feature X or button Y. They’re just trying to solve their problem — quickly and easily.

I saw this clearly during a cross-team demo. A feature team ran through a new feature at lightning speed. They knew exactly what to do and where to click. But the rest of the room was lost. They needed every step explained — it was all new to them.

And that’s exactly how our users feel. Except we won’t be in the room to guide them. So our product has to make sense on its own. If it takes too much effort to figure out, they’ll just move on.

Pro tip: The best products require the least amount of thinking to use.

Mind the Knowledge Gap

Here’s another big blind spot: We assume users know more than they do.

Because we built the product, we understand it deeply. But our users don’t share that context. They don’t have our mental models. So when we design from our own perspective, we risk creating things that make sense to us — but not to them.

Bridging that gap means putting in the work to understand how they see the product. What confuses them? What do they expect? What feels intuitive to them?

That’s why user input isn’t just a nice-to-have — it’s essential. Without it, we’re just guessing.

Continuous Discovery = Continuous Value

If we want to build products that matter, we have to keep discovering. Not just before a big launch. Not just during planning. But all the time.

That shift — from one-off research to continuous discovery — changes everything. It helps you think clearly about the value your feature is delivering. If it’s not performing as well as you expected, your continuous discovery habit gives you the insight to make improvements. You can then tweak your product to deliver more value to your customer. So instead of just shipping a feature and moving on (that’s output), you’ve actually created value for the client — a credible outcome.

And that’s the goal: outcome over output.

Start with the Outcome

Every good discovery process starts with a clear outcome. Not a feature. Not a roadmap item. An outcome.

Business leaders care about outcomes — growth, retention, revenue, strategic progress. Our job as product teams is to take those high-level outcomes and translate them into product outcomes: measurable user behaviors we can influence through the product.

Think of it this way:

• Business outcome: Increase customer retention
• Product outcome: More users successfully completing on-boarding within 3 days

Once we have a product outcome in mind, our next job is to discover the right opportunities — the unmet needs, the pain points, the desires that, if solved, could move that outcome.

Only after we’ve explored those opportunities do we move into solution mode. And even then, we keep validating, testing, learning.

The Structure of Great Discovery

At the heart of it, good discovery follows a simple rhythm:

1. Start with an outcome
2. Discover opportunities
3. Explore and validate solutions

That’s it. That’s the backbone of a strong product discovery process.

In my next post, I’ll dive into Opportunity Solution Trees — a great framework to help teams map this journey from outcome to opportunity to solution. It’s a practical way to stay focused, make better decisions, and build with confidence.

Until then, just remember: Product discovery isn’t a phase. It’s a mindset.

Reference: https://learn.producttalk.org/