Deep Product Discovery

To successfully create or build a working feature, a team must take the time to understand the feature from multiple perspectives and understand the risks, impacts and trade-offs associated with building the product. This practice provides a guide for discovering the key pieces of information required to successfully build each working tested feature.

Pain Points

  • The team doesn’t understand the business value of a requested feature
  • Users receive a feature for testing that doesn’t meet their needs
  • Product teams themselves are frustrated by what they are building
  • Trust between the development team and users erodes due to the quality of the work delivered

Benefits

The primary benefit of this practice is reduced time to market for a given feature, less waste and significantly reduced opportunity cost.1

By performing a deep product discovery, you allow the team to think about issues and discover information. The team needs time to adequately process this information; you want to learn as much as possible during discovery well before you have to start working on a feature or capability.

Our brains solve problems when we present them with information and allow time for that information to “marinate”.2

This mode of work harnesses those background processes and allows the teams to understand the work they will be undertaking much more completely.

Assessment

  • Product Discovery is routinely completed in a manner that yields meaningful insights on the needs of the business as well as the pros and cons of relevant options and risks associated with the product (100pts)
  • Product Discovery is routinely completed, and sometimes provides something valuable (10pts)
  • Product Discovery is not routinely completed (-25pts)
  • Product Discovery is never held (-100pts)
  • Product Discovery is scheduled but consistently canceled due to higher priorities (-150pts)

Application

✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this practice:

Setup

  1. Pick an item that you would intend to start working on within the next week.
  2. Select available Subject Matter Experts (SMEs) and/or users who are relevant to this item.
  3. If available, capture information from a feature already completed that is similar in complexity and scope as the selected item.

Trial

  1. Assemble the team to discuss the identified work item
  2. Share all the relevant and collected information for the team to discuss
  3. Meet with SMEs, explain your current understanding and ask them questions
  4. Ensure the team discusses trade offs relative to features, quality and time/cost aspects of the item as well as associated risks and unknowns

Evaluate Feedback

  1. After the item has been built, tested and demonstrated to those users/SMEs, evaluate the feedback received
  2. Compare the results with any similar items and evaluate the relative performance of this effort
  3. Discuss the results with the team. See if the extra effort payed off in a better feature/function (it should)
  4. Take the time to thank the stakeholders and users/SMEs that took time to assist with this discovery, and ensure they understand the value of the activity

What Does it Look like?

This practice allows you and your team an opportunity to learn and better understand subtle nuances of the products they build before they begin the development process. In these sessions, details are debated, discussed, sometimes argued, but understood. The team familiarizes themselves with the information and solutions to thorny problems are shuffled off to our subconscious to work on.

Naturally, no team will learn everything in the first meeting or set of meetings. Learning is ongoing as the product develops and evolves, and discovery is an ongoing process—not a “one and done.”

Warning Signs

  • One person or a small number of people are determining what feature functions are needed
  • Teams aren’t taking the practice seriously and don’t ask users difficult questions
  • The team never pushes back on unrealistic work demands
  • Risks and trade-offs are brushed off and all discussion focuses solely on feature/function
  • A big meeting with users is held once at the beginning of the project and then never again until final delivery

How To Fail Spectacularly

  1. A person in a marketing role dictates all aspects of a feature, and has no interest in discussing anything other than exactly what they want and when it has to be done by
  2. Holding a discovery session without relevant users/SMEs and research data, leaving all details up to the development team
  3. Allowing group-think to override behavior and keep individuals from speaking up with concerns and questions
  4. Not holding deep dive sessions and expecting to get meaningful results

  (ScheduleImprovement.txt) Next→

  1. When the development team is tied up on a feature longer than needed, they are not available to deliver other value. ↩

  2. See Pragmatic Thinking & Learning (Hunt, 2008) for details. ↩

Find Out More...

Follow @growsmethod in the Fediverse, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method®. We will not use your email for any other purpose.