Product Development Part 1: Product Discovery Fundamentals

Build products your customers love.

There's nothing like building a product and realizing your users have no need for it. With product discovery, you can ensure you're building products your users actually need and love.

There is nothing quite so useless as doing with great efficiency something that should not be done at all

Peter Drucker

What is Product Discovery?

Product discovery is about understanding customers' pain points, identifying potential ways you could solve them, and validating whether the product you're going to build will solve those barriers efficiently. This process helps refine team ideas by deeply understanding real user challenges and then arriving at the best way to solve them.

Product discovery begins not with how, but why. Products can only be successful when they solve a burning user problem. Discovery demands that you start with deeply understanding the underlying challenges and frustrations your users encounter and only then can you clearly outline the central user pain that needs to be solved. When a clear outline has been established, in its simplest form, you’ll collect feedback to validate your hypothesis, and each time you receive feedback you're reiterating and re-framing the hypothesis further. You’ll uncover more information about the problems users face each time you test your assumptions, and with that, you refine and narrow down which problems are worth solving before moving on to creative solutions. Here’s a good example from Productboard:

1. Uncover challenge

2. Re-framed & narrowed challenge

3. Creative solution

Ultimately, it helps you lower the risks around deciding what to build. When skipping the discovery phase, you can expect to have a disconnect between your user needs and the product that you ship. Not to mention lower satisfaction rates, product success, ROI, etc.

Why do you need to do Product Discovery?

In short: If you skip discovery, you end up building products for problems no one has.

Teams who don't take the time to understand the problem they're solving risk biasing their work towards internal perspectives and solving the problems of the company over true customer needs or they lean towards well-understood solutions that still may not be usable or useful.

Product Discovery is about the data-informed reduction of uncertainty in regard to problems worth solving and solutions worth building through a series of nonlinear activities, conducted as a cross-functional team.

Tim Herbig

A good example of a bad product discovery: Smalt is an interactive centerpiece that allows you to dispense salt with a shake of your smartphone screen, measure the amount of salt you consume, play music, and change the light on the device depending on the mood. Overall sounds pretty cool. Once the product was on the market, the Smalt team realized that users had no need for a high tech gadget that needed to be connected to WIFI to salt their food, and even though the other features the product had might've been persuasive, it was not enough for Smalt to be profitable.

Who is involved in Product Discovery?

The best product discovery doesn't happen in a vacuum. The entire product team should be involved. Your team is either working in the problem space (discovery) or the solution space (delivery) with continuous activity focused on matching solutions. But outlining the problem space should be a top prioritization and truly understanding the definition of what is being solved.

A truly customer-centric organization has a continuous pipeline of gathering user feedback and new insights to better understand their user needs. In Dual-Track Scrum you simultaneously apply Agile principles like cross-functional collaboration among product, design, and engineering to the discovery and delivery tracks continuously. This ensures that both tracks heavily influence feedback for development. Although the process starts with the entire team at discovery, you will arrive at the moment where the team branches, and some continue their investment in discovery, while others are focused on creating solutions for the problems identified.

Tim Herbig recommends breaking the discovery team into three groups:

• Permanent collaborators - Product managers, UX , researchers, and engineering leads
• Temporary collaborators - Developers, leadership, customer support, sales
• Supporters - Executives, other product teams, infrastructure teams

Involving the right people across the organization in product discovery helps unlock insights that might've been overlooked and empowers the core product team to validate their ideas.

4 W's of Discovery

There are many questions you can ask during product development but you should emphasize de-escalating risk as a driving force with your team’s Discovery.

According to Tim Herbig, teams that lack a starting point for Product Discovery are often due to the lack of strategic context. This is connected to a clear understanding of Product Strategy. A simple outline of the cornerstone questions for Product Strategy should be built on:

• What is the one overall problem your product is solving?
• Which alternatives could your users draw on to solve that problem (i.e., direct and indirect competitors)?
• What are the core value propositions that define your product?
• What makes your product unique compared to direct and indirect competitors?

Having a “SWOT” (Strengths, Weaknesses, Opportunities, and Threats) style chart answering these questions in Idea, Value, Capability, and Market format will help guide the Product Discovery visibility and make it easy for the team to turn to when making trade-off decisions while navigating through the problem space.

Marty Cagan identifies four big considerations:

1. Value risk (whether customers will buy it or users will choose to use it)
2. Usability risk (whether users can figure out how to use it)
3. Feasibility risk (whether our engineers can build what we need with the time, skills, and technology we have)
4. Business viability risk (whether this solution also works for the various aspects of our business)

When should you do Product Discovery?

Constantly.

At Spark Equation, we continuously incorporate product discovery into our clients' projects to reduce the risks around feature development and ensure their product not only meets users' pains but supports the overall business vision. Product Discovery should never be a one-off process or something you swap Delivery with, it’s most effective when both Discovery and Delivery are overlapping and intertwined with each other for constant feedback and developing a right fit solution.

Create real impact with your products quickly and effectively, in less time by starting with Product Discovery and continuously applying the process in development. We assist teams like yours in aligning business and product strategy with Continuous Discovery, chat us online or assess your alignment now.

Check out the next part of our series on Effective Continuous Discovery.

‍