A 4-step guide for day-to-day product discovery
Building successful digital products requires two things: building the right product, and building the product right.
The former is ‘product discovery’ and the latter is ‘product delivery’, according to product guru Marty Cagan.
Product discovery is about defining what to build to solve a customer problem and generate a positive business outcome. Done well, it mitigates the risk of developing the wrong thing. Product delivery is then the process of building the thing as fast as possible and to a high standard. A winning product team needs to master and balance both discovery and delivery.
While this is nothing new, in my experience delivery still gets much more attention from product teams and senior management.
Product teams are often solely measured on their speed — how fast they are at popping out new features — and not on their effectiveness to validate new ideas. Delivery work is optimized down to the last detail, while discovery work is poorly defined and rushed.
The result? Technically beautiful and well-implemented features, delivered at lightning speed, which no customer ever uses.
Having previously written about more general leadership and management topics like self-management, people development, onboarding, and recruiting, I’m turning my attention to product discovery. While a lot has been said and written about specific discovery techniques, I have seen many teams struggling with how to really put these techniques into practice and embed discovery work into their day to day life. Hence, I have put together the four main aspects that have helped me in the past into a practical guide to champion continuous product discovery.
It’s a guide based on my six years of experience working in product and CX — currently being put to use as a Head of Product at Babbel. The guide is targeted at teams or product leaders who are looking for some inspiration on how to get started with a more balanced, outcome-driven way of product development.
But first: why is product discovery so hard to implement?
My hypothesis is that product delivery gets far more attention than discovery because it’s comparatively easier to set-up delivery structures. Just look at the number of branded frameworks like SCRUM or Kanban which exist.
The world is totally different for product discovery. I’ve yet to find a comprehensive framework for day-to-day product discovery (if you have one please comment below).
The reason they don’t exist is probably because of the exploratory nature of discovery work. How to best discover problems worth solving — and the most promising solutions to those problems — is highly dependent on your industry, the type of product you’re working on, and your product’s stage.
However, while it’s near-impossible to define a discovery framework similar to the delivery ones, I believe there are four industry and product-agnostic steps that every team needs to work through. Below is my guide to implementing these four steps into your daily work.
A 4-step guide to successful product discovery
Step One: Outline your discovery toolbox
There are two stages to product discovery:
- Identifying an opportunity for a product improvement (and therefore understanding the problem ‘space’)
- Identifying the most promising solution for the given opportunity (narrowing down the solution ‘space’).
(Product development teams are just like NASA astronauts… Both deal with lots and lots of space!)
To move through these two stages you need to ask yourself different questions and use different techniques which will vary between different situations. The best teams I know have a large toolbox of techniques ready to go. Techniques such as exploratory user interviews, data analytics, story mapping, and sacrificial prototyping.
It’s vital everyone on your team is aware of these different techniques and when to best apply which of those. Otherwise, it’s easy to tap into the fallacy of always using the same method independent of the question at hand.
Do you have this knowledge in place? If not, start the conversation. Run a (or multiple) team workshop(s) to collect and review different discovery methods. Collectively create a written library of techniques that you can regularly revisit during your retrospectives to ensure you’re using your full repertoire. To get started, don’t reinvent the wheel. Build upon existing toolboxes (my personal go-tos are Jeff Patton’s Discovery Recipes and ideo.org’s Design Kit).
Outlining your discovery toolbox helps you avoid getting stale as a team and company, and allows new starters to get a detailed and fast understanding of how you do discovery ‘around here’.
Step Two: Plan how every team member can contribute
In my opinion, product discovery requires active participation from everyone in the team. It’s a collective responsibility, not a task for selected members.
In modern product organizations, product managers and designers spend the majority of their time on discovery work. Their discovery involvement is rarely questioned.
It’s a different story when it comes to engineering. If you have five engineers should all of them get involved with considerable time invested in every single discovery initiative you’re running? Probably not. It would be inefficient and costly. But how then do you make sure that engineering is represented?
Two methods worked well for my teams in the past:
- Have a lead engineer, or engineering manager, take up an active role with notable time invested in your discovery work.
- Identify those engineers in your team who are interested in taking an active role in discovery. They can then get involved in your discovery work either on a rotating basis or split up by initiatives.
What does an active role mean? Well, it’s certainly not coming in at the end of a discovery cycle to discuss feasibility when a solution has already been sketched out. It’s about being there from the start. Participating in user interviews to identify problems, taking part in ideation sessions, helping with developing functional prototypes, and contributing ideas for new opportunities based on technical advancements.
In the two methods above, the rest of your engineering team is still involved in many of the discovery discussions I outline in step four of this guide. Their involvement is just more light touch. What’s essential is that, when you do involve engineers, you encourage questions, feedback, and ideas. This is often not common and so engineers may feel uncomfortable providing game-changing suggestions.
For example, in a refinement session I was once running, a newly onboarded backend engineer raised a very valid concern over a GDPR-related implementation. After the session, he reached out to me and apologized for having spoken up (believing it ‘wasn’t his place to get involved’). I was shocked. His input was just what we wanted and, more importantly, needed. At the next meeting, I made an effort to underline just how valuable this input had been and how everyone was encouraged to contribute.
No matter the topic or discipline, everyone should actively contribute to your discovery work. The key question to ask is: how can they best contribute? For me, it’s worth assigning people to one or two of four ‘perspectives’: value, usability, feasibility, or viability?
For ‘standard’ roles — like product management, product design, and engineering — the area of expertise (and therefore ‘perspective’) is usually clearly defined (see image below). For more specialized roles — like a service designer or a subject matter expert — things aren’t always clear and have to be defined case by case. While everyone can contribute to all four perspectives, I believe it’s helpful to know people’s main mission and focus.
Step Three: Consider how to continually involve customers
Product discovery is about identifying the gap between what a customer would consider a great product, and what your product currently does. This requires customer involvement.
The more frequently you learn from your customers, the easier it is to make daily product decisions that favor them. As Teresa Torres describes in this super insightful podcast, customer involvement should be set up in a continuous rather than project-based manner to ensure at least one customer interaction per week.
To do this you need to regularly recruit customers that you can listen to, talk with, or observe. Recruiting can easily turn into a time-consuming task. To combat this, you can create a somewhat automated recruitment process.
For B2C products: think about recruiting from your product (i.e. a pop-up that asks for customer feedback in return for a certain reward), social media, or with the help of your support team.
For B2B products: ask your customer success team for support, or consider setting up a lead user pool where customers sign up to frequently participate in return for a reward. A lead user pool is something we built up at my former company NavVis. Many customers were surprisingly eager to join and hence, finding someone for an interview or shadowing session was not a problem any longer.
Of course, picking the right reward plays a big role in how effective your recruiting efforts will be. Money might not always be the right approach. For enterprise customers, a sneak peek of your product roadmap is sometimes more valuable than a decreased subscription fee.
Don’t have the budget for a dedicated user research tool that supports recruiting and scheduling? Think about which software tools might help, such as calendly for scheduling customer interviews without (almost) any manual interactions.
Step Four: Set your ways of working
Product discovery requires alignment, good decision making, and joined-up problem-solving. How can you best facilitate these three?
Let’s start with ceremonies…
Consider embedding your discovery discussions into existing delivery ceremonies, rather than creating new sets of recurring meetings to do collaborative discovery work. If you’re working in Scrum, this is what that could look like (I say ‘could’ as in an agile world no two teams have the same ceremony structure so the below will need to be personalized):
- Run reviews and retros on both discovery and delivery work:
When doing so, it’s important to get comfortable with failure. Discovery is all about learning and there is no learning without failure. Get people to celebrate and talk about hypotheses that could not be validated, ‘failed’ experiments, and things they have stopped exploring.
Make sure everyone understands that this ‘failure acceptance’ is in contrast to delivery work where you would never release a failing feature. By failing in discovery we avoid failing in delivery. This is something to shout about, so SHOUT ABOUT IT! - Give discovery updates in your daily
While this may add five minutes to each daily, it gives your discovery work the attention it deserves. It also allows everyone in the team to contribute with questions and ideas (don’t forget the lessons I outlined in step two of this guide). - Announce upcoming discovery work during sprint planning
You’ll want to keep this meeting short and efficient. So, instead of doing the discovery planning in it, have a plan ready and announce it to the team before you get to the detailed delivery planning. Knowing what is coming up, and where certain engineers might be required to help, will put delivery work in perspective.
Of course, none of these ceremonies give you enough space to draw conclusions from an experiment or to creatively ideate solutions. Decision making, detailed planning, and creative work will need to take place elsewhere.
Besides the multiple non-regular discovery activities that take place during the week, there’s one thing that has really worked for many of my teams: scheduling one weekly session where everyone actively involved in discovery work can make decisions, and discuss and plan next steps. It’s a fixed meeting slot which is used differently depending on the team’s needs. Nothing urgent or important to discuss? Cancel the meeting.
One final point on this step… Keep track of your discovery work.
When it comes to delivery work every action item is usually tracked in a board on Jira, Trello, or similar. How can you establish similar tracking for your discovery work?
It’s easy to get lost in all your different hypotheses, experiments, and user stories that are getting ready. By keeping track of them in one place your team will have visibility over what everyone is focusing on and where you’re at with discovery. For me, a very simple Kanban-style board does the job (you don’t want to over-engineer the board and give every discovery step a dedicated column).
If you wanna dive deeper into ‘ways of working’, check this article where I share templates for product development artifacts like the discovery board mentioned above.
That’s your lot (for now)
There is no standardized way of doing continuous product discovery. However, the above four steps are ones I think every team should go through. Start with them, set something up, then stay agile and constantly improve your discovery workflows and structures.
Have I missed something? What’s worked for you in the past? I’ll be writing about this further in the coming months so would love your examples and battle stories. Just comment below…
