PO 101 : 5 easy techniques to an amazing product discovery
I believe a core Agile principle: that people come before processes. However, I found it’s common people in the Agile community mistake the idea of people over processes for enabling chaos. The truth is quite the contrary: to deal with people and obtain the most from them, the ability to organize and apply method is paramount, as long as you keep your focus on the people.
A lot is said about the process of building and validating an MVP, but it is hard to start from scratch. Product discoveries are a very useful tool for Product Owners whenever we are trying to assess a need and still haven’t got a minimal product in the market to validate our assumptions. However, when building a product discovery, a PO has a very challenging decision to make: what methodologies will be applied in order to extract the most value and knowledge from the stakeholders?
I have seen all kinds of product discoveries, and many didn’t focus on what the people involved with the product could bring to the table. Shallow and biased interviews, the lack of enabling consensus among team members and stakeholders and listening for solutions instead of problems will take your hard work down the drain.
So I put a short list of valuable techniques that have proven immensely useful time and again. Note that none are mandatory. You should always taylor the techniques to your need. However, this list can be seen as a menu, and you can pick the choicest dishes from it.
1- Certainties, Assumptions and Doubts
This will help you level your team and your stakeholders ideas on the product. By taking the notions from people’s heads and placing them on the wall for everyone to see, you will be able to answer many questions that, otherwise, would spend months haunting your product and causing mayhem.
How-to: draw 3 columns on the board (Certainties, Assumptions and Doubts), distribute post-its and markers all around and ask the participants to write down at least two of each. Give them 5–10 minutes and ask them to place their post-its on the board as soon as they are finished. While they are filling the board, try clustering similar post-its. As they finish, read all clusters and single post-its aloud, starting from Certainties and ending with Doubts. Invite the participants, to re-write or move the post-its from one column to another, as necessary.
2- Is, Isn’t, Does, Doesn’t
The goal for this practice is to build your product vision in a collaborative way.
How-to: draw a cross on a board and name each of the resulting spaces: Is, Isn’t, Does, Doesn’t. Give each participant some post-its and markers and ask them to write down at least two for each quadrant, in order to complete these sentences:
The product is…
The product isn’t…
The product does…
The product doesn’t…
Give them 10 minutes and ask them to place their post-its on the board as soon as they are finished. While they are filling the board, try clustering similar AND antagonistic items. After all post-its fill the board, read all clusters and single post-its aloud, trying to find consensus about the product’s scope, asking participants to re-write the items as needed.
If you’re striving to make the borders of your MVP clearer, this exercise must focus on what the MVP should look like. Nice-to-have features must be left aside, no hard feelings.
Personas are a way of ensuring you and your team will be able to keep a user-oriented view of the product. However, unless you have extensive time for research, you will probably start with proto-personas — those that are hypothetical people you build by using your imagination — and will validate your assumptions, turning them into personas later on.
How-to: have a proto-persona form ready beforehand. Ask the participants to form teams of 2–3, and hand the forms, saying they must think of users for your product and collaboratively fill all the information on the form thinking od that user. Emphasize the closer to reality, the better. Give them 30 minutes for this activity and, as they finish, ask them to place the personas on the wall. Each group must introduce their persona to the other participants, and explain why they believe this persona would use the product.
4- Objectives and Key Results
After building personas, all the participants will have an underlying, subconscient awareness of the needs they are trying to attend with this product. That’s the perfect moment for you to tap in their collective mind to define the product’s OKRs.
How-to: draw two columns on a board, one for Objectives and the other for Key Results. Ask the participants to write what they believe are the product’s objectives in post-its, giving them 5–10 minutes for this activity. As they fill the board, group similar objectives. After they are done, distribute two stickers per participant and explain each sticker counts as a vote. They will have 5 minutes to cast their votes on the most important objectives. You will then count the votes, and the 3 top objectives will be considered for KRs.
Now ask the participants to gather in 3 groups, giving one objective to each. Give them 10 minutes to think of metrics that should prove that objective was achieved. When they are finished, ask them to come forward, read their objective and the key results they established for it. Collect the other participants’ feedback and refine as needed.
5- Story prioritization
After you have Personas + OKRs, you can start building stories to form your MVP backlog, each focusing on attending to the demands of at least one persona and trying to achieve one objective/key result.
You can choose to create your own stories or do a specific dynamics for story creation with the stakeholders. However, if we assume you have a list of stories, the toughest part in my experience is prioritizing and grouping them in a release plan that makes sense.
How-to: Write each story in a post-it and place them on the wall. Explain to the participants each story will be read aloud and then they’ll have to vote using one hand, showing numbers from 1 to 5. For each story, there are 3 criteria that need voting:
Relevance — how this item relates to the product vision
Urgency — how this item is affected by timing, considering the MVP launch T0
Tendency — how this item is affected by testing and collecting user feedback
To make sure the participants understand the criteria they are voting of, you can hand them this:
Relevance: how important is this item for the product vision?
1 = it’s not important. It would be nice to have, but we’ll be fine without it.
2 = desirable, nice to have
3 = important
4 = very important
5 = it’s vital and highly valuable
Urgency: how immediate must the implementation be considering the MVP launching?
1 = launching after the MVP makes no difference. We can wait.
2 = it’s not comfortable, but we can wait after launching the MVP.
3 = it’s very uncomfortable, we should have it in the MVP.
4 = it’s urgent. Not having it in the MVP will jeopardize the product.
5 = there is no MVP without it.
Tendency: How much user feedback do you need?
1 = we don’t need feedback to iterate on this item, so it can wait.
2 = we need some feedback to validate the use of this item before launching.
3 = we need feedback to tweak the feature before launching.
4 = feedback is very important, it could change the way we build this feature.
5 = We rely solely on feedback to understand what we need to assess this need. We need short, iterating cycles from the get-go.
The participants must vote for each aspect of each story, and much like a planning poker, find consensus in a final grade. This is the perfect opportunity to align the understanding of priority, so you don’t have to deal with stakeholder war over what features get developed later on.
You will multiply Relevance x Urgency x Tendency and backlog should look somewhat like this:
With this, you’ll have a pretty good idea of order, and that will be based on the participants’ common knowledge, and not on political pressure.
Now you can ask the participants to study the ordered backlog and, checking the OKRs, identify at least one objective and one metric to group stories on, considering the order in which it’s necessary to build the product.
Draw 3–4 blocks representing each release, and ask the participants to gather in 3–4 groups (1 per release) in order to place at least one objetive and metrics per release, and what stories will compose it. Give them 20 minutes for that activity, and make sure they can negotiate among themselves.
Congratulations! You have your first release plan!
If you like this post, don’t forget to recommend & share it and then check out more great Code Like A Girl stories.