When helping teams and companies shift towards the product model, one of the key concepts introduced is practicing product discovery. Prior to this shift, a typical scenario starts with a stakeholder—someone up top—sharing detailed requirements on what to build. This approach leaves the so-called “feature team” with very limited opportunity to influence the solution.
Now, contrary to the old way of working, you are empowered to solve “problems” rather than just developing “solutions”. Instead of merely taking requirements from stakeholders and executing their ideas, you have to come up with your own ideas and ensure those ideas solve fundamental business and customer problems. You are accountable for producing results.
The playing field is completely different: more rewarding and engaging but also harder. You have to learn and unlearn certain skills and behaviors. And, I have seen, many times firsthand, what this opportunity does to a team—you see the spark in their eyes from working on something meaningful: “Oh, I get it. I know what the customers want.”
But, there are also plenty of traps to fall into.
In this article, I’ll surface a common anti-pattern that teams stumble upon when having the opportunity to work more with product discovery: the Discovery Illness.
The Discovery Illness refers to the – inertia – that might happen as a consequence.
Essentially, Discovery is about the collaboration between the Product Manager, the Product Designer, and the Tech Lead to discover the right solution to build before writing any scalable code. Typically, this involves talking to end-users, customers, and stakeholders to gauge their needs and then ideating, prototyping, and validating solutions—quickly. The last word is key here. As a rule of thumb, a team should spend no more than a typical sprint, two weeks, on Discovery.
To be more concrete, during this time, the team should have uncovered business and customer value, identified key product risks, aligned on multiple different potential directions in the form of prototypes, tested those prototypes with real users/customers, or conducted multivariate tests. By the end of these steps, the team should be comfortable slicing the prototypes into smaller pieces to bring them into Delivery. That is what good looks like in our book. From idea to potential solution in two weeks.
If it takes longer, something is wrong. There are clear signs of the Discovery Illness.
In order to make this more tangible, let me share a few symptoms.
Symptom 1: Everyone in the team needs to be included in the decision-making process.
The product model is all about being inclusive and turning the dial up on collaboration. The downside is that people feel they need to be involved in every meeting, slowing down the pace of product development.
Try this instead:
- Facilitate a role expectation mapping workshop to surface what you expect from one another and define guiding principles for how you would like to collaborate moving forward.
- Assess what meetings/ceremonies you have as a team, and discuss A) if you can merge, B) cancel, or C) create new, more focused collaborative sessions.
Symptom 2: There are arguments when it comes to what solutions to prototype (hidden agendas).
We’ve all been in situations where there has been friction on what to build. Some team members have pet ideas, ideas they have explored on their own, to push forward. This indicates clear signs of misalignment in what the future direction should be. If you are not rowing in the same direction, you slow down.
Try this instead:
- Review existing materials around the direction of the product, and presentations from senior leaders to understand how the course is charted.
- Invite a leader to a fireside chat to share the strategic context, the fundamental problems to solve for the product, and why they are important
- If the direction is fundamentally unclear from leadership, try to form your own direction by facilitating a product vision sprint for your product.
Symptom 3: Stakeholders are dipping their noses in your work.
Stakeholders are important. They have key insights into the various parts surrounding your product and are experts in their domains. However, they are not experts in your product and your context.
When transitioning to the product model, stakeholders might start to feel a lack of control, fearing they are missing out. Hence, they begin to dip their noses in, asking to be involved in decision-making and asking tough questions about what you are prioritizing—ultimately slowing you down.
Acknowledge that you share the same goal: you all are employed to make the business more successful. The difference is that they only see their part of the equation, not the way you holistically see it.
Try this instead:
- The fundamental recommendation is to be “proactive” rather than “reactive” when dealing with stakeholders—try always to be one step ahead and to anticipate stakeholders’ needs.
- Include stakeholders in your sprint demos to show progress.
- Invite stakeholders to your monthly or quarterly reviews of your product to discuss, debate, and learn about the progress you have made.
- Leverage stakeholders for 1-on-1 ad-hoc feedback on prototypes you are creating in discovery.
Symptom 4: Ballooning scope.
The whole point of Product Discovery is to spend as little time as possible figuring out the – right – solution to build. Teams with the Discovery Illness tend to increase the scope of the solution for every Discovery activity they do, meaning they talk to one customer who mentions a need for a particular solution, and then the team incorporates that solution into the prototype. The team lacks certain critical thinking skills on what insights to value and, more importantly, what not to value.
Try this instead:
- Have the mantra of “code in production.” Acknowledge that you will never be 100% certain in Discovery if you’re right or wrong: you have to put things to the test. The more you practice experimenting, the better judgment your team will have on what to value and what not to value.
- Practice slicing on all levels: A) slicing the problem to be solved, B) slicing the solution you intend to build, and C) slicing what to deliver.
Symptom 5: Nobody wants to make the “call.”
I’ve worked with product teams where the team had a tough time making decisions on what to build. There was uncomfortable silence in team meetings when bigger decisions needed to be made. This likely stems from a few reasons: A) The team has made decisions in the past that caused a stir from stakeholders, and they got burned B) There are unclear expectations on team members’ responsibilities, C) There are conflicts in the team underneath the surface.
Try this instead:
- Measure the psychological safety of the team, discuss the results, and take action.
- “Manage up” by being transparent about early progress to important stakeholders to avoid friction down-stream
Summary
I hope this article resonates with you, especially if you’ve encountered similar challenges during the transition to the product model. The key takeaway is to ensure what you are working on as a team is linked to the direction of the product, and that you have a bias to test, learn, and to put “code in production”. You have to build the muscle to slice items into smaller pieces. This is not something that happens overnight, these are skills that you need to collectively train every day, every week, and every sprint – as a team. Always, ask yourself: “Can we make it smaller? How can we test it?”.
Learn more
Martin Christensen and I have written the book Holistic Product Discovery that goes way deeper into the topics discussed in this article.
