Pre-discovery. How to prepare for product discovery

Product discovery is all about uncovering user problems and validating solutions to those problems quickly. When teams start discovery without preparation this can lead to wasted time, wasted effort and bad solutions. This post explores my thoughts on how best to help teams prepare for product discovery (aka pre-discovery).

1. Explain the big picture

Want to minimise the risk that the discovery team sets off in the right direction? Here are a few questions to consider before the team gets started:

• Why has this discovery been prioritised? Why now?
• What problems need to be solved?
• What business objectives or results are the team expected to achieve?
• Are there any constraints, risks or deadlines the team need to be mindful of?
• And most controversially, what solutions do senior leaders already have in mind (if any) and why? Discovery teams rarely like to be told what solution to build (for good reason). However, if senior leaders do have expectations, it is good to at least understand what they are and why they exist, and it is better to know sooner rather than later. Teams should have the licence to challenge these assumptions and come up with alternative ideas. Kuba Bartwicki’s post In defence of sometimes starting with solutions is well worth a read on this topic.

2. Prepare a cross-functional team

Cross-functional teams bring diverse perspectives and expertise to the product discovery process. Doing discovery together leads to better solutions, faster decisions and a more aligned team. Discovery is about reducing risk. Cross-functional teams identify risks earlier and identify better solutions to those risks faster.

Which roles need to be in the cross-functional team? It depends on the problem and context. Some of the discovery teams I have worked on in Government have included product management, delivery management, user research, content design, service design, analysts, data scientists, engineers, operations, procurement, legal, marketing, sales and SMEs. I have also seen discovery teams of two very T-shaped individuals who wear many of these hats at once. My personal preference is usually for smaller teams as they can move faster and have lower costs. The key thing is that there are people on the team who can understand and mitigate the four key product risk areas: business value, user value, usability and technical feasibility.

It isn’t necessary (and it usually isn’t practical) for all team members to be full-time on the discovery. That said, small teams of people who focus on one problem at a time can usually deliver results better and faster.

If working with part-time team members on a discovery, starting and finishing discovery are the two most important activities for the team to do together.

3. Start together

It can be tempting for individuals to get started with discovery before the wider team is ready. This can be problematic for multiple reasons:

• Loss of tacit knowledge. When small teams go through the discovery process together, they gain knowledge from synchronous collaborative interactions that is difficult to replicate in documentation. When teams miss out on this, they risk missing out on the nuanced understanding and context that comes from collaborative discovery.
• Inefficient use of time. Work done alone is at higher risk of needing to be repeated or significantly revised
• Lack of buy-in from team members. Team members often feel less invested if they are not involved from the beginning, leading to an increased risk of disengagement
• Premature solutionisation. Individuals getting started ahead of others can lead to confirmation bias and narrow thinking, leading to substandard solutions.

If some team members are available to start ahead of others, they should limit their discovery work to conducting secondary research to gather pre-existing information. Or removing potential blockers like the ones listed in the section below. Primary research should generally wait until the discovery team is ready to start together.

4. Remove potential blockers

Slow discoveries are expensive. Here is a short list of things that often slow down discoveries, along with some tips for how you can reduce the risk of them slowing you down.

• Stakeholder buy-in or availability. Internal stakeholders include roles like legal, sales & operations. External stakeholders include partner organisations who you are developing the product with. Discovery usually can’t get very far without all the right people available, so getting their buy-in and getting conversations scheduled with busy stakeholders in advance can reduce the risk that this blocks the team.
• Access to users. There is always a lag between identifying users and being able to speak to them. Line up relevant users to speak to in advance so that round 1 of user research can start in week 1 of discovery.
• Access to data. This includes performance analytics for existing solutions, customer support data, existing insights about user needs/problems and results of any previous discovery work done in the space. Ask on your company’s equivalent of Slack to see if anyone else at the company has worked on similar problems before and ask them to point you towards the documentation
• Tools and facilities. Make sure everyone has access to the tools the team need to use in the discovery. Tools for note-taking, action tracking, video conferencing, instant messaging and virtual whiteboarding will all be essential from day one.

5. Plan ahead for delivery

The goal should be to move swiftly into delivery once discovery is complete (or complete enough for the team to have enough confidence that they are not about to start building the wrong thing).

Why does leaving gaps between stages lead to waste?

• Loss of momentum & context. Insights generated during discovery fade with time, especially tacit knowledge which is difficult to write down. The longer the gap, the higher the cost of delivery, and the higher the risk of a lower-quality solution.
• Outdated knowledge leads to wasted effort. We work in a fast-moving industry working with fast-moving technologies. Gaps between stages increase the risk that insights are outdated by the time work begins and then need to be re-done
• Disconnect between discovery and delivery. Long gaps increase the risk of having to change team members between discovery and delivery. These handoffs between knowledge workers come at a cost

When preparing a team for discovery, leadership should try to make some educated guesses about how long the discovery will last, and what shape of team will be needed to deliver on the discovery findings. They won’t always get it right. But it is easier to find valuable work for an engineering team at short notice than it is to find an engineering team at short notice to do valuable work.

This can get very difficult when suppliers or partners are involved, but it is not impossible. If contracting with a supplier or partner for a discovery, think in advance about how you might move fast into delivery once the discovery is complete, and provision for this from the beginning.

Winning new business – an important exception

In the real world, design work or prototypes are often needed to win new business, develop a partnership or secure funding. I am not suggesting that we need to put in place a discovery team to do these types of pre-sales activities. Instead, a small team should put together some high-level concepts which show the type of solution that will be possible. The goal should be to persuade the client/partner/executives that the work is worth committing to. More often than not I have seen discoveries come up with different and better solutions than what was initially assumed, so it is important to educate all involved that some discovery work will need to take place before delivery starts.

Thanks for reading

The phrase “strong opinions loosely held” is especially true for this post! Please do get in touch if you have any feedback.