How much time do you spend talking about features?
How much time do you spend understanding end users’ problems?
If you asked me these questions several years ago, I’d say I spent at least 90 percent of my time talking about features. As embarrassing as it can be, I barely understood end user problems.
Teams receive pressure from all layers of the organization. Everyone has a brilliant idea that they’re sure will change the business forever. Others have urgent and important issues to solve. And you’re in the middle of this mess, trying to figure out how to create value.
It’s easy to do what others want. It’s hard to do what they need.
Without a meaningful balance between discovery and delivery, you’re more likely to create crap than value. Sadly, many teams invest too much time delivering and too little time discovering what matters.
Let me elaborate on some discovery and delivery strategies that I’ve seen to be sustainable for product teams to create value steadily.
Although the difference might be obvious, what I observe in the corporate world confuses me.
I see too many teams putting their energy into delivery without knowing which problem they’re ultimately solving. Meanwhile, I see too few teams striving for problem understanding before coming up with solutions.
The Agile Product Manifesto espouses “understanding the problem over thinking of solutions.” Here’s my simplified explanation of this tenet when it comes to discovery and delivery:
Now, I must clarify some aspects of this before we continue:
Our current challenge is dealing with pressure for more output.
Delivering more features doesn’t mean creating more value; you’ve got to find out what creates value.
As Albert Einstein once said, “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.”
This quote has variations — sometimes it’s 50 minutes thinking, or 59 — but you get the point 🙂
Curiously, in the digital product world, the balance between discovery and delivery seems to be inverted. I generally find teams investing no more than 10 percent of their time and effort in discovery. I wonder how they can create value without precisely understanding problems. This puzzles me.
A more sustainable balance would be 75 percent discovery and 25 percent delivery. Do you think I’m exaggerating? Not really. I’m just afraid of creating bullshit. I want to increase the odds of thriving.
Discovery is continuous. The magic of discovery lies in uncovering what you don’t know.
You’ll inevitably realize that most of your ideas won’t work. And that’s fine, because it helps you avoid creating something nobody needs.
Given that most of your ideas won’t work, you need to invest time continuously in understanding your users and testing different ideas. That’s why it’s critical to put proper attention to discovery.
“The hard reality is that product strategy doesn’t happen in the solution space.”
To create outstanding products, you need to master both discovery and delivery. I won’t go deep into how you do each of them, but I’ll share what great results look like for each phase.
Many people think that product discovery is about validating ideas. I’d disagree with that. Product discovery is all about understanding end users’ problems, then uncovering opportunities to create business outcomes.
It’s fundamental to understand that product discovery happens in the problem space. Yet, it’s easy to slide into the solution space and mess around.
A problem can be solved in multiple ways. If you’re talking about something you can only solve in one way, that’s a solution, not a problem. Step back, and go to the problem space.
So, what happens during product discovery?
Strive to understand your users’ scenario, what matters to them, what jobs they want to get done, their pains, and their wishes. It’s all about understanding what your users care about and identifying opportunities to improve their lives.
The more you understand your users, the clearer their problem becomes.
For example, you know how users care about it, how many users are impacted, how often they face this issue, and how that can enable business value.
Good problem framing makes it easy to decide which problems are worth solving.
Run product experiments to understand what works and what doesn’t.
Experiments are fast and short. You’re talking about hours or days, not weeks. Experiments have expected results, and you decide upon them whether to scale up, pivot, or drop it.
Good product discovery won’t confirm your assumptions, but it’ll uncover the unknown.
A falsification mindset is powerful in creating knowledge. Instead of striving to validate assumptions, you aim to prove yourself wrong. With such openness, you can avoid confirmation bias and commitment escalation.
Product discovery isn’t just an input to product delivery. They overlap and happen in parallel.
Treating delivery as a phase after discovery will create a waterfall effect and trap the team.
It’s not about receiving requirements and implementing solutions. It’s about building to learn and scaling up based on evidence.
After a successful discovery, you may get excited about the solution you uncovered. Be careful: just because it worked with a smaller user group doesn’t mean it’ll work with a bigger cohort.
Keep a learning mindset throughout the journey.
To make product discovery endeavors successful, you should:
The shorter your release cycle is, the faster you learn. Outstanding product companies do several releases per day. Of course, you need to understand your scenario. You cannot move from three months’ release to daily. But you can move to monthly, bi-weekly, weekly, and daily.
Never assume impact. Measure the result. It’s not about measuring how long you took to get a solution live but understanding how it creates value. Build to learn.
In the past, teams used to invest months implementing solutions, then releasing them to the whole audience at once. This approach is dangerous. If something goes wrong, it’ll impact your entire audience. A better approach is starting with a smaller audience and scaling gradually based on evidence.
“Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.”
The digital product world is challenging because of its complexity. Curiosity and humility are vital traits to enable you to succeed.
You should be curious to discover untraveled roads and humble enough to drop your ideas when you learn they make no sense to your audience.
Great product teams work relentlessly to solve problems. They create state-of-the-art solutions, though that is a means to an end. Solutions are only valuable when people can use them to make their lives better. Otherwise, they are worthless.
You’ve got to pick which problems are worth solving carefully. The way to do that is to master product discovery. Without effective discovery, you’ll fall into endless traps and end up frustrated.
Do what’s right, not what’s easy
Delivering solutions is easy. Creating valuable solutions is hard.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
The stronger the habit, the more often users want to use your product and the lower the chance of them churning.
LogRocket’s Galileo AI watches every user session in your app to surface the most impactful areas of user struggle and key behavior patterns.
By understanding what your competitive landscape is doing, you can figure out what unique wedge you can leverage to capture your market.
Josh Schoonmaker shares his approach to balancing two key leadership traits — assertiveness and kindness — and knowing when to apply each.
Learn more →
