The PM Journal | Log 14

May 26th, Happy World Product Day and a reflection on Product Discovery 😃

Naiana Bezerra
8 min readMay 26, 2021
(Photo by Alexas Fotos from Pexels)

If you have been following my articles you know how amazed I am about discovery and how I truly believe it is the justification of every successful product.

Product Discovery is simple: discover opportunities, validate assumptions, mitigate risks, empower others, build, measure, learn, and repeat.

Recently I gave a short talk about Product Discovery to recap how easy and important accomplishing discovery continuously is for product development.

I used these two simple slides below to describe the risks, the value, and the process of product and continuous discovery.

Discovery Risks & Value

I’m sure there are tons of other risks and values to add, but I decided to highlight the most relevant ones in my opinion. You will see that they overlap because one leads to the other. It is a combo of bad habits and a better mindset!

Risks:

  1. Lack of focus: Discovery is extremely important for product strategy. It helps fill the gaps from unknown questions giving more focus to where to go. That said, without focus, the product goes in every direction increasing the chance of creating something meaningless for users.
  2. Sales-led: A company that has a sales-led mindset doesn’t usually believe in experimenting. It is driven by the volume it makes/sells. The common scenario is the sales team and/or senior stakeholders driving the feature requests and making decisions.
  3. Output-oriented: Being oriented by the number of features a team delivers impacts the company’s success directly. The team is not encouraged to solve a user problem, driving users to turn down the product. Then the company needs to rely on promotions and manipulations to keep customers interested, but it is a never-ending cycle and extremely costly.
  4. Fail wrongly: It is normal to fail and we should, but failing wrongly means the validation is happening at an ineffectual time getting users’ feedback too late. Or even the team doesn’t have clear objectives, hypotheses, or has an inaccurate target audience.
  5. Costly: The famous ROI, return of investment. A company is investing in building a product/feature/functionality expecting it to be a success and generate leads. Based on a very well-structured five years business plan. Without discovering if this product/feature/functionality has any value to customers, what are the chances to succeed as wished?
  6. Factory process: A common project management process. The team would simply receive a list of requirements to build an entire product, release it after months of work, and be ready for the next batch.
  7. Feature team: Completely unempowered team, working with a roadmap of features delivering what they are told. The team is not doing proper or any discovery to uncover unknowns.
  8. Lack of sense of purpose: Why are you doing what you’re doing? This goes beyond the discovery process, a team that doesn’t know the value and the reason for what they are developing has no motivation of improving and innovating the product. Worst has no empathy for users. The product and/or legacy becomes a Frankstein.
  9. Top-down decisions: Trust. I mean, lack of trust from leaders in believing the people they hired won’t do good work. So they just dictate whatever the teams will do. There is no encouragement from these leaders to empower teams in building value from their own discoveries.

Value:

  1. User-centric: Independent of the methodology, tools you chose for the discovery process it should always have users as a reason for everything you’re doing. You are building something to move the needle, for that to happen, user behavior will change. It is up to you to make that the best experience for them by marking value.
  2. Product-led: Every action of a company that has a product-led mindset will drive product improvement and innovation based on what customers need. That way the company creates loyal customers and creates a belief in its mission.
  3. Outcome-oriented: Product teams driven by results are inspired to find the most effective solution led by what users truly want, accomplishing the desired outcome.
  4. Fail fast, learn fast: A good continuous discovery process has constant validations of assumptions. Failing fast means, instead of building an entire feature to get feedback after, the team validates hypotheses with users before by fast prototypes, experiments, interviews, researches… learning quicker what does work and what doesn’t work.
  5. Prioritize opportunities not solutions: Humans tend to think of solutions immediately. That’s natural. But when you prioritize problems/opportunities and discover the right answers, solutions will have a rational foundation.
  6. Iterative process: Works really well with a discovery process. It is when the team develops gradually features and functionalities that are independently releasable and not complete, where the team can test quickly something or from a previous validation (A/B test for example), based on new learnings and insights, the team iterates the product. Instead of incrementally building fully working parts.
  7. Product team: An empowered team focuses on building the right thing for users and the company through continuous discovery uncovering what works best to achieve desired outcomes.
  8. Collaboration and motivation: Product, design, and engineering should always work collaboratively in shaping a product mitigating viability, usability, feasibility risks, ethical risks, and finding together what brings value to users. A sense of ownership in ideating and brainstorming together increases motivation.
  9. Bottom-up decisions: The best scenario is when leaders (top-down) share the company’s strategy and goals with product teams (bottom-up) that will commit to these opportunities or problems and discover the best action to tackle building a product/feature/functionality that works for everyone.

Discovery Process

As Teresa Torres says, there is no right way to do discovery. You can use different methodologies, techniques, tools… what’s important is to crack the problem.

The following process contains the best practices to effectively perform a strong product and continuous discovery. You might do some steps differently or in another order. After all these years of iterating and trying several things, this is what works for me now. And depending on the product and which stage of its lifecycle I adapt the approaches I want to apply.

I will repeat myself a little below on descriptions, but with repetition comes fluency.

  1. Work collaboratively: Product, design, and engineering should be involved in the day-to-day process. As well as key stakeholders. Participating in researches, interviews, ideating and prototyping, mitigating risks together.
  2. Identify the desired outcome: The outcome is the metrics you’re trying to move. The behavior you need to change. Always align with the product strategy.
  3. Discover product opportunities: Work on the right problem to solve. In consultancy, the client might say they know the problem to address. But always explore more what users really desire and need, with new insights you will validate if the initial problem is the right direction, or another problem might be found. This suits stakeholders on product companies too. Product opportunities are customer needs, pain points, desires.
  4. Structure and prioritize opportunities: Prioritize opportunities using strategic decision — what's the most important problem we need to solve, what is the outcome, what will move the needle, what are the goals, how do we mitigate risks. As Teresa Torres says explore if the opportunity is really customer-centric. When writing product opportunities frame them as customer needs, pain points, etc., I want, I need, I try, I hope… to express them as customers' point of view.
  5. Opportunity analysis: Learn about the market and the segment. Who’s the target audience. Who’s in the competitive landscape. What new trends or new technologies are out there that can evolve the product.
  6. Discuss solutions for the prioritized opportunity: As solutions I mean assumptions. What — as a team — do we think might solve the problem? Ideate considering and analyzing every aspect of a product (business (viability), engineer (feasibility), design (usability), ethical and value). Map as many ideas as come. Are there new technologies? What will change users' behavior? Would we have any dependency? How about accessibility? How about translations? Devices? You will not build an entire product at once, you might not consider accessibility for example on a prototype, but you need to keep in mind relevant functionalities to validate what is required. Also, remember that less is always more. The product will evolve with new learnings.
  7. Create and prioritize hypotheses: There are several frameworks, toolings, canvas, to organize hypotheses. Again, prioritize using strategic decisions — what's more important? Which hypotheses are more uncertain of? What do we believe offers more value? Sometimes product managers need to use their gut feeling based on experiences and knowledge to help to prioritize and to make decisions. But remember, this is a collaborative discussion.
  8. Strategize and plan validations: What are we validating? How will we experiment? Is A/B testing the best approach? How many interviews we will perform? Strategize what will work better to achieve your objective.
  9. Talk to users: Time to start measuring and figuring out your assumptions. Do whatever is in your power to get in contact with users. I don’t mean sending a survey or measuring in A/B experiments tools. You need qualitative data, you need user insights. And the best & only way to obtain awareness of their desires, pains, needs, is listening empathetically to what they have to say. These interviews are about them, your customers. It is not about the product. So don’t go with a Q&A format. Use a story-based interview format: Tell me about your life, to share your story with me. And be actively listening for the pain points and needs.
  10. Analyze metrics: Never stop measuring. If it is a new product, look for KPIs or any other company metric available that can help understanding more the business, goals, where the company is, etc. Also, look for data online, researches on the topic, what competitors are sharing. For an ongoing product, analytics is your best friend. Whatever change you make, check the reports and find any difference in behavior. Or for new features/functionalities, be specific on the objectives and create reports that will help your questions.
  11. Synthesize qualitative and quantitative acumens: Qualitative and quantitative data ALWAYS hold hands. They are key for product decisions. One evidence supports the other. Now synthesize your learnings. What’s new? What was validated? Generate a document containing everything you discovered. Separate learnings, new insights and opportunities, review and create hypotheses, etc.
  12. Transparency on the progress: Keep relevant people in the loop during every step of product development, they are holding you accountable. Be transparent about what’s going on. Manage expectations, be honest. That way you build relationships with trust. Also, take each chance to get their inputs too, involving them in the making. Your stakeholders may know a lot about the market, learn from them too.
  13. Make product decisions: What’s the value of the product? How will the team solve the problem? What’s next? Pivot or persevere? Review assumptions and opportunities. Modify. Create new. Start over.
  14. Iterative process: Gradually make changes to the product. Or iterate prototypes, PoCs, interview scripts, tests. Create an MVP. Whatever is the next phase of your discovery&delivery process.
  15. REPEAT!

As Product people, we lead teams to build worthy, relevant, and valuable products.

To that, the team has to be: empowered, united, involved, and owners to solve unknown problems.

(Please notice that I’m not native in English and I apologize for mistakes)

--

--

Naiana Bezerra

The PM Journal is a space to share daily routine experiences as Product Manager plus articles related to the product and agile world. Enjoy 😊