At RedBit, our mission is to stop you from building unusable software or software lacking a business case. Too many times, we've seen product owners plough forward building technology that was unsatisfying for their target audience because of weak or unclear requirements. Our goal is to build products that meet user and business goals while always bringing value. One of the ways that we've been able to do this is through product discovery.
Product discovery is the current buzzword for something that got lost in translation in the jump from waterfall to agile methodologies, called a feasibility study. Feasibility studies consisted of analysis and evaluation of a proposed project to determine if it:
- was technically feasible
- was technically feasible within the estimated cost, and
- was profitable.
Feasibility studies were often the last phase of a project before you considered building out a product, especially if it involved a large sum. In other words, it was usually the point where the business folks asked IT if their cool project idea was worth building out.
As such, product discovery is a learning process where you gain knowledge about a business and its users. It usually involves gathering and processing information, exploring solutions and focusing on a particular direction.
Product discovery is not the same as Eric Reis' Lean Start-Up or Steve Blanks' Customer Discovery or the Business Model Canvas. Discovery does not and should not replace those. It should happen after you've done your lightbulb thinking, after your assumption and hypothesis planning, and after you've fleshed out your value proposition. The product discovery happens in the sweet spot before you start a project. It brings together the final parts of the puzzle to help you validate the product you want to develop.
The key to any product discovery is that it is a shared activity for any product team. This product team should not only include the management or executive team but any and everyone who'll be responsible for creating the product. Without everyone on the team having a clear understanding of the project goals and user needs, you can't expect them to build a product that'll make you or your customers happy.
The final piece of the puzzle is determining the technical requirements, obstacles, and the cost to build. The more your tech partners know the more realistic they can be with budgets and timelines.
The success of a product discovery comes from having the information you need to make an informed decision on whether to continue with a project. You should never consider it a failure if you don't choose to move forward. In fact, you should consider it a success that you didn't waste money developing a product with little value. Think of the saying, "Every failure is the breeding ground for future success." Even if you don't build the product you wanted, you now have a wealth of knowledge to find new ways to deliver the value you want.
.png){kind=small}
