Too many teams miss out on unlocking product value (plus fun & learning as bonus) either by not focusing on discovery, or obsessing about the process. Worst is when leaders track efficiency metrics to manage it. Having learned discovery the hard way myself (credits at the end), I think I understand why. But more importantly, I want to share 3 areas leaders can manage instead, so teams are empowered to do their job.

I’d like to start by reflecting on two quotes that explain discovery best.

“Discovery, by definition, means you don’t know the answer when you start.”

Ed Catmull’s (Co-founder, Pixar) spirit¹ in Marty Cagan’s words². Either way, two great influencers on building lovable products.

The most magnificent thing takes a while to build.

Moral of Ashley Spires’ story, The Most Magnificent Thing, for pre-schoolers captures the ups & downs of the creative process perfectly.

There are two unknowns in there: scope (resources) & time — presuming everyone likes high quality. And Management 101 teaches leaders to fear & control both. Rightly so, because they have opportunity costs associated, making leaders and teams anxious about discovery. Instead of trying to observe what works and what to fix, they resort to a shinier process for a false sense of control. 🤦🏽

Don’t get me wrong about process; I love process as a guard-rail but not as the only rail.

Instead if leaders just observed these 3 areas from a distance, they would know exactly where to coach, while empowering teams to have a fulfilling time doing discovery.

1. Origin of discovery work

Understand 🔍

• How do teams explain ‘discovery’ and their current process? Particularly useful when starting in a new role, and helps understand the mindset, frameworks and approach of the team.
• What triggers discovery and where does it begin? Answers would most likely range between ticket, feature, idea, problem and mission. Great teams (with a well-defined purpose) are at the right-end of that scale — both literally and metaphorically.

Improve 💡

• Democratise access to data – both quantitative and qualitative. Data Analysts should be reserved for higher-order analysis that modern-day product analytics and data visualisation tools are still not ready for. User research findings should also be in an easy to search system⁴. Same goes for customer service tickets and feature requests.

Data accessibility ensures product teams know just as much as anyone else in the company about what their customers need and don’t need to be thrown ideas at.

• Educate the team on core discovery concepts: dual-track Agile, design thinking, customer journeys, jobs-to-be-done, design sprints. Instead of adopting one as-is, retrospect and restore the missing pieces in your process. Don’t be shy to repeat.
• Guide teams to clear missions which help them understand which problems to own, and which ones to solve with other mission teams. Assuming good team topology exists. Connect to company mission.
• Challenge teams on their opportunity(-solution) trees and discuss how those bets fit within the portfolio of bets you manage in your product area. Connect to north star metric through KPIs these opportunities impact.
• Reflect on discovery content you discover — frameworks, blogs, podcasts, etc — to draw parallels to your process and control the FOMO. Trust me, they all rinse-and-repackage the same core principles.

2. Learning goals for each planning cycle

Understand 🔍

• What’s the trend of initiatives (#) and time allocated to learn about new problems? Quality and consistency matters more than quantity or win-rate.

Running 6 experiments each quarter, half of which remain non-conclusive due to interfering experiences or data issues, is just as bad as not running one for 2 straight quarters.

• How often is discovery compromised for delivery work? Especially for UI revamps, refactors and “customer wishlist” features creeping in – else go back to 1. The only exceptions I’d allow is doubling-down/scaling a previous test with proven impact, or fixing blocker/critical issues in production.
• What is stopping the teams from dedicating more time to discovery? This is important in case you going through a strategic refactor, preparing to open-source/inner-source/retire, then teams shouldn’t feel guilty about it. Don’t take time for an answer.

Improve💡

• Share clear goals to be achieved every cycle. This can include themes, principles or even high-level problems to tackle, but it must be based on strategy, evidence and insights from data.
• Give feedback on the team’s prioritisation. As a leader, you must ensure the selected problems and their sequence accelerate delivering product strategy. Guidance based on insights & evidence should do half the job.
• Challenge discovery briefs that answer why, who, what, how, when. Make sure they pick the most impactful problems that have positive impact a sizeable segment, or have a sizeable impact on a metric.
• Acknowledge the discovery plan. Show you care as much as delivery. 👏🏼

3. Quality of generated insights

Understand 🔍

• Can teams validate their ideas autonomously? Between Designers, PMs and Product Marketeers when available, they should be able to recruit/target users, setup usability tests, craft surveys and even generate insights for further iteration. A floating/shared UX researcher is OK unless it blocks the team. Having to wait on a “Research ticket” is the absolute worst.
• Do the validation techniques allow learning quickly and cheaply? If everything results in a A/B test in code, that’s a red flag.
• Do the insights generated enable decision-making with confidence? Setting up a good hierarchy of hypotheses is key. This means you can validate or invalidate clusters of hypotheses at once, without having to test every single variation.
• Do the insights increase confidence by an order of magnitude? If a team’s confidence in a hypotheses increases from 25% to 30% after an experiment running 3 weeks, it’s probably wasn’t worth it.

Improve💡

• Democratise access to the customer. There is nothing better a leader can do for customer-centricity. 👑
• Challenge teams to pick lean validation methods suited for the why & who combination sufficient to validate their belief.
• Invest to enlarge their validation toolkit and encourage using new methods. If you’re validating what your users would like to share with friends, start validating on the platform they’ll share before building anything on yours. Testing Business Ideas⁵ by Bland & Osterwalder should give you a headstart.

There’s lots to worry about being customer-centric and data-driven. But it all starts here with good discovery. And if you see room for improvement in any of the areas above, please tackle those before proposing the newest discovery process on the market. Don’t attach FOMO to enablers (tools and processes) but to actions and results (value generation).

Remember, the risk of not doing good or enough discovery compounds in delivery — on the spectrum of unsatisfying work ranging from dry backlogs to rework.

Credits

To the many that have shaped my thinking in this area:

• Marty Cagan’s 2-day training on “Building products that customers love” totally changed my mind. Always grateful!
• My teams and peer leaders at Babbel for helping me understand a lot of the above, and giving me opportunity to push for change. PMs, Designers, Researchers, Engineers — thanks for raising your concerns, pushing back on stuff that didn’t matter and approaching this with an open mind – Really proud of what we’ve achieved!
• Big thanks to Petra Wille & Shaun Russel who coached me and the teams on this topic.

References

1. How Pixar fosters collective creativity – Ed Catmull
2. Product Discovery Anti-patterns – Marty Cagan
3. The Most Magnificient Thing – Ashley Spires
4. UX Research System – UXStudioTeam.com
5. Testing Business Ideas – Bland & Osterwalder