Skip Product Discovery at your peril

Photo by Markus Winkler on Unsplash

The all-important product discovery phase — don't skip it. It's a critical phase before you jump in and build the next great feature. A common mistake while building products is not making an explicit distinction between what you know (empirical) vs. what's an assumption. As you can imagine, assumptions bite back. Sometimes, irrecoverably.

The product discovery phase, somehow, isn't that popular in the fast pace of the daily circus. Whichever way you look at it, discovery time is an excellent investment to understand jobs-to-be-done. You want to make sure you're solving the real problem and need. For that, first, fall in love with the problem space.

User research has huge ROI

Researching user and customer problems (needs and wants) will go a long way in arriving at a value proposition for your product. Especially important if you're an early stage product, finding the product-market fit is key to your survival. Along the lines, I'm a fan of empathy interviewing in Design Thinking. However, a note of caution: on the execution front, Design Thinking framework isn't that strong.

There are several user groups and organizations that can find individuals across industries and segments. With a little investment, you can exchange ideas and gather their feedback. Talk to a diverse audience, and rest assured you have enough nuggets to extract.

Prototypes are your savior

So, with all that said, you want to test your concept as early as possible. Regardless of agile jargon, it's better not to jump and build the solution right away (yes, there are exceptions). Build a quick prototype. For that, there are many options in the market (for UI: Figma, Adobe XD, etc.).

Your aim here is to see if you can validate your hypothesis and answer any unknowns.

Solve for these three broad parameters

You want to have answers to these three questions before you jump in and build:

Firstly, is there a customer desirability for this product/feature?

Secondly, if yes, for the above question, is there a business viability?

Finally, often, you need to answer whether the solution is technically feasible? Nicely put by Marty Cagan in his book Inspired:

• Do we know how to build this?

• Do we have the skills on the team to build this?

• Do we have enough time to build this?

• Do we need any architectural changes to build this?

• Do we have on hand all the components we need to build this?

• Do we understand the dependencies involved in building this?

• Will the performance be acceptable?

• Will it scale to the levels we need?

• Do we have the infrastructure necessary to test and run this?

• Can we afford the cost to provision this?