Product Discovery is an essential activity for the success of a Product organization. It helps ensuring that customer needs are met, and, more generally, to minimize the risks associated with a product launch. However, its importance in product strategy can be underestimated, and it is not always well anchored in product processes. In this article, Alexandre Irrmann-Tézé, Thiga Managing Director, gives us the keys to effective Product Discovery, and the methods to facilitate its implementation and adoption throughout the organization.
The activities of Product Discovery consist in identifying user needs, studying Product solution opportunities. It also means ensuring that these are relevant to both the user and the company. As a CPO or Lead Product Manager, I feel that these activities are carried out too sporadically and unstructured.
My teams conduct user tests from time to time. We've also done an initial exercise in building personae.
However, Product Discovery activities are crucial to the success of a product. Indeed, they enable us to limit risks and design as closely as possible to user needs. I'd like to be able to industrialize them; that is, perform them on a recurring basis and at scale within the company, to feed several squads in parallel.
We propose the creation of a team dedicated to Product Discovery activities. It draws on the various Product squads to help them de-risks long-term topics.
This team uses a number of methods inspired by the Design Thinking or Lean Startup movements. Ideally, it should minimize risks in the shortest possible time. However, it must not encroach on the autonomy of individual squads.
The Product Management field can broadly be broken down into 3 main activities:
- Discovering: identifying an opportunity and defining the vision of the product or functionality responding to it
- Building: building and developing the product and associated user experience
- Growing: preparing the organization to market the product and grow the user base via acquisition and retention mechanisms
These 3 activities are all crucial to the success of a digital product. They are also cyclical and apply to all levels of the product; i.e. every feature or release normally goes through these 3 successive phases.
However, we observe that most organizations focus extremely on Building, sometimes at the expense of Growing and especially Discovering activities. Product Discovery is indeed less covered by existing literature and complex to scale up; as we'll see later in this chapter.
A Toolbox Inspired by Design Thinking and Lean Startup
Product Discovery is a set of activities that involves identifying user needs or market opportunities. It defines hypotheses concerning either the need or the solution, then tests them, upstream of development.
Example Case Study Product Discovery
For example, in the case of a dating site product dedicated to athletes. There may be several Need Hypotheses:
- A 1st Need Hypothesis might be: practicing a sport is an important criterion in friendly or romantic relationships
- Need Hypothesis 2: existing solutions on the market are insufficient in relation to this given use case
- Hypothesis Need 3: athletes are especially fond of digital solutions
And several Solution Hypotheses:
- Hypothesis Solution 1: sports practiced should be highlighted on each user's personal data sheet
- Hypothesis Solution 2: the MVP can focus on running as it is the most commonly practiced sport .
- etc...
In general, you need to start by defining a use case, an idea expressed in the form of a user need. Sometimes the idea relates directly to a solution. In which case it's important to ask the question "why does this product make sense?"
What is the need behind the proposed solution?
Create a canvas associated with the use case, users
To materialize this use case, and still with a view to industrializing the Discover approach, we suggest you create a canvas to fill in. Like a Lean Canvas, this brief will evolve throughout your design process. It will be progressively enriched and amended to arrive at the final result. It's also a very useful internal communication tool, enabling you to see what everyone's working on, and to quickly get an overview of the company's medium-term projects.
The canvas we propose consists of several parts. Nevertheless, feel free to adjust this sheet according to the needs and specificities of your Product and organization.
- Target users: in general, the persona or personae concerned by the use case; or the discriminating criteria that make it possible to identify the users impacted by this use case.
- Problems encountered: the description of the user problem. Initially, you can fill in this section by putting yourself in the end-user's shoes, in a theoretical way; you can then challenge and complete this description after meeting real users.
- User feedback: verbatims (qualitative) or metrics (quantitative) that justify and prove the user problem.
- Hypotheses to test: a list of the main assumptions you made when filling in the canvas. This list will define the tasks to be carried out for the Discover process. You'll need to prioritize them, choosing the riskiest ones first; the ones that can collapse your idea if they turn out to be wrong.
- Expected value: for both company and customer. Fill it in as objectively as possible; this will allow you to prioritize topics among themselves, and quickly set aside subjects with low added value.
- Competitive advantage: why it's YOU and you alone who can successfully solve this user problem (materialize this use case).
- Adherence & dependencies: other in-house projects that may impact this use case, or teams working on similar topics.
- Competition: who are your main competitors on this user need.
- De-risking effort: the effort made to de-risk this topic (time allocated, resources assigned...).
Now that you have a formalized use case, the next step is to validate or invalidate each of the established hypotheses. The first action (and often the most important) is to check that the users are indeed in line with the idea you have of them, and that the need you believe to be certain really is.
Kanban for the Product Discovery Process
To do this, you'll probably need to mix qualitative and quantitative research. Going out to meet users, even immersing yourself in their environment; peeling back user feedback, studying analytics.
You'll need to use this material to dig deeper into user need; and so update your personae and Jobs to Be Done, depending on which approach you prefer.
Once you've validated (and no doubt gone considerably deeper in the process) the user need, it's time to turn your attention to the Solutions part. Organize a brainstorming session, inviting as many different profiles as possible: market experts, sales forces, POs or PMs, developers. If you already had some solutions in mind at the outset, make the effort to put them aside and start again from a blank page; this frees up more time for reflection. It's also likely that, once you've worked out the need, the initial solution will turn out not to quite meet it.
.The proposed solutions can be written in epic form; for example if you're organized in SAFe, or in Feature Teams. Not all of these epics will develop in the end. In an MVP logic, you'll have to prioritize the ideas that bring the most value. They must nevertheless remain achievable in a short timeframe.
After prioritizing an idea that meets the user need, is ambitious but feasible, and builds on the strengths of your company or organization, we advise you to take some time to think about the business model for this Product or feature. Many companies, especially startups, put this off until later, preferring to launch as quickly as possible; however, we don't think you need to invest weeks of effort in a detailed business plan to get a first idea. A quick opportunity study
(starting with a check that the target market is large enough for the product to survive) can often be enough, and will help to win over management. Anticipating business model issues also helps to make the right design choices from the outset.
The final step is to test this solution idea with users. Build a prototype, interactive if possible, and test it. If the results are excellent, congratulations, there's a good chance the Product will do well. If they're average, take into account the various user feedbacks. Then review your copy: fine-tune the solution. If necessary, dig into the need again to see if you've missed something. If the prototype tests poorly, or you don't manage to win over users after several tries, forget it and move on to another idea. Archive the prototype, which you may be able to use again later (if the market develops or user needs evolve).
Examples abound on the various app stores, in the columns of tech magazines or on Startup Graveyard. Too many Products turn out to be solutions to problems that don't exist (remember Google Glass), or target the wrong users, or never find their business model. Of course, no methodology, no matter how sophisticated, will protect you 100% against failure; but many problems can often be anticipated and solved in a few weeks of well-structured work.
Who Takes Charge of the Product Discovery Process in the Company?
In general, most companies do Product Discovery to some extent. The difficulty lies in industrializing this approach at company level. Applying the methodologies described above is within the reach of any organization; managing to do it systematically, to good effect, at the right level, and across all Product topics is a more complex task.
In practice, companies often adopt 2 organizational options that are, in our view, equally counterproductive.
The Non-Choice: the Absence of Real Product Discovery
In some cases, no one in the organization really gets to grips with the subject, for fear of failure or cultural resistance; in general, we find ourselves in a top-down logic where a few people (often the founder, or the CPO) impose their law and are content to follow their intuition. Some people take the initiative and carry out user tests and prototypes. However, this approach clashes with the urgencies and priorities set from above. The result is often incoherent and doesn't allow for the construction of a true de-risking pull flow.
The Multitasking Product Owner
Other companies are aware of the importance of de-risking a subject before launching it into design. They entrust this task to the Product Owner of a Scrum team. This can work to a certain extent, especially if the Product Owner has an appetite for user experience and "Design Thinking". But it's not optimal, and often leads to Discovering activities falling by the wayside. Indeed, the Product Owner of a Scrum team juggles urgent and contradictory demands. They can also find themselves with their noses to the grindstone, having to prepare their next sprints and deliver user value on a regular basis; it's not uncommon for them to find it difficult to reconcile the 2 temporalities, short term and long term. As a result, the flow of derisory use cases is no longer sufficient to feed the Scrum teams.
.In addition, the Product Owner and his team are by nature very focused on the Build. They then have a "solution" orientation and a propensity to build and then test after the fact.
When a Scrum approach is used, it's important to be aware of this.
When a design or Product Discovery approach is well implemented, it's usually a trial run at the start of the project, to build the Minimum Viable Product. After that, we often switch back to a steering approach mixing intuition and emergency management.
The Solution: a Dedicated Product Discovery Team
The most relevant solution, if we want these Product Design and Product Discovery activities to be executed appropriately, at scale, and sustainable over time, is in our view to build a dedicated team.
This team is made up of Product Managers, often organized into different functional areas (tribes, in the case of Feature Teams). The idea is to draw on the expertise of the Product Owners, developers or Product Designers present in each squad; the Product Discovery team does not impose ideas "from above" on the development teams. It does, however, help them by working on long-term topics that will eventually make it into their backlog. It will therefore gladly solicit members of the squads concerned by the subject under study; whether for a brainstorm, a feasibility study, or a sketching workshop.
.Example of Product Discovery Organization
The Product Discovery team doesn't have a monopoly on the Discovering methodology either. It doesn't cut the various squads off from their relationship with users. They all draw from a common toolbox, used by the Product Owners and Product Designers in their squad to test and design their short-term functionalities or evolutions (horizon: a few sprints), and by the Product Discovery team to prepare what will happen in the future.
.Also, what's being set up looks like a double sprint logic, with a Product Discovery process (over a longer time) and squads working over a shorter time; but the 2 cycles must be interconnected and participative, to avoid falling back into V-cycle in disguise.
Example of a Product Discovery Process in Sprint Mode
We suggest, however, including Product Designers profiles directly within the Product Discovery team; the user research and prototyping aspect are indeed very important activities. The Product Designers of the various squads are often too unavailable to be called upon for long-term projects. On the other hand, the Product Discovery team may be working on subjects that do not (for the moment) fall within the scope of any of the squads: having a Product Designer directly dedicated to them helps prepare the ground.
.A third cycle can be added to this scheme: the Growth approach (see the Product Academy volume 2 for more information). It aims to experiment at high frequency to gradually improve the Product. This approach can be carried out by the squad and its Product Owner, as part of the delivery cycle; but we can also create a third cycle of high-frequency experimentation, even faster than the Scrum cycle and carried out by a Growth Marketer or a dedicated Growth team.
How Long Does the Product Discovery Process take?
By their very nature, the activities we describe above are sometimes quite time-consuming, and are never technically "finished": we can always dig a little deeper into the need, do an extra iteration on a prototype or re-run a user testing session.
However, a Product Discovery team can't afford to dwell for months on one or two use cases. While it's difficult to determine in advance how much time to invest in a given topic, we still suggest you measure out the effort. To do this, 3 criteria can be considered:
- The level of risk: the risk is essentially linked to the impact of this subject on your business. An experiment that's fairly easy to develop, on a subject that's ancillary to your business but potentially interesting will present little risk. Redesigning your underwriting process or launching a brand new Product on which you have high hopes will be a riskier project.
- The level of urgency: when do you expect to be able to start developing the envisaged use case? 1 month? 3? 6?
- The existing level of knowledge on the subject: if you're reasonably certain of your assumptions, have several market studies or large quantities of user feedback readily available, you can afford to move faster towards conclusions and solutions.
We suggest you define 3 "typologies" of use cases, and size the effort accordingly:
- Very risky and exploratory use cases; you'll tend to invest time and energy in Product Discovery on these projects
- Moderately risky use cases, about which you have doubts; set a deadline in the near future to make an initial assessment of the discover phase
- Use cases that are urgent or very low-risk; plan a faster process (a few weeks)
The easiest way is to pace your Product Discovery team in sprints, like a Scrum team. It's also to allocate a certain number of design sprints to each type of project. It's sometimes difficult to assess the level of risk upstream. So don't hesitate to plan an initial week of exploration for each project. Then, if necessary, refine the level of urgency or priority.
In fact, it can be interesting to run subjects that are fairly simple to de-risks but have a high impact in parallel with more long-term strategic subjects.
In all cases, Product Discovery should not go into too much detail. The danger is to limit the effectiveness and involvement of the squads that will follow. The idea is to de-risk an few important hypotheses, if necessary by means of prototypes. It's not about dictating a ready-to-develop solution to teams who are focused on delivery.
Don't forget that building the solution yourself is only one possibility among many, and not always the best one. If the subject is risky, complex, or potentially costly to develop, the Product Discovery phase can also be used to identify potential technical partners, or even takeover targets. If it turns out that a third-party player perfectly meets the need you've identified, or that a player offers an appropriate SaaS solution, partnership can be a cost-effective solution, at least for the time it takes to validate your market's interest.
.Do's and Don'ts of Product Discovery
If you haven't already, we encourage you to recruit Product Managers and create a Product Discovery team within your company. Your product will be all the better for it. Here are a few points to help you implement this process in your organization.
| Do's | Don'ts |
|
|
To transform and improve your organization, read our book on Product oriented organizations
