Product Discovery – a collaborative effort

Sometime back I attended a session on Product Management by an industry expert and had some good take-aways. Ill focus on the area of “Product Discovery” in this post. It takes a very collaborative approach in the whole Product Discovery process.

The Product Discovery process looks to evaluate your product idea and provides a framework to validate whether it is worth investing time and resources on building it. The starting point of this process is a Product Idea and the end goal is a “Build” or “Not build” decision for that idea.

The idea is to form a Core Product Team comprising the Product Manager, the Technical Architect and the User Experience Designer who work together to validate the idea from the perspective of “Valuable, Feasible and Usable”. As you have probably guessed, each of the team member approaches the idea and validates it from that perspective.

The PM is largely responsible for deciding if its Valuable – Is it a real customer pain point and does the product that you intend to put out solve the problem effectively.

The Technical Architect is responsible to decide if its Feasible – Is it possible to build a product based on the limitations that exist within the ecosystem and the organization – within the given time and the organization’s technology capability.

The User Experience Designer validates the Usable angle – Is the product envisioned Usable enough from the customer angle. Is it too complicated for anyone to use.

Again the entire process is very collaborative and iterative. Based on these, you come up with prototypes which you will run through potential customers. It is recommended that you have about 6 potential customers that you work with to validate this prototype. The thought being that anything much less than this will end up being a “customer specific solution” as against a product that delivers value to a customer segment. The good part is not a single line of code has been written by Engg until this point – QA or Ops hasnt yet been involved.

The idea of this process is not necessarily to sign off with a “Build” decision, but to help you rapidly validate your product ideas in an inexpensive manner. It also enables you to quickly drop ideas that wont work and focus your energies on other one. While this is not a fail proof way of building products, it sure gives you a better shot at rolling out something that will meet customers’ needs

 

NWritings

5 Replies to “Product Discovery – a collaborative effort”

  1. This is a nice post that highlights the three important factors to consider before deciding whether to venture into a project or not.

    But,I have a minor comment. The blog states:”The good part is not a single line of code has been written by Engg until this point ā€“ QA or Ops hasnt yet been involved.”. I do not completely agree with this point.
    First of all, there are different types/stages of prototypes – dummy prototypes (static HTML pages),
    then beta, gamma prototypes etc. Code changes and QA testing definitely happens for betas/gammas that go on production.

    1. I am referring to the “dummy prototypes” and not the beta, gamma where work has gone into it already. The idea is to take something minimalistic to validate the idea. If you have already built something and QAed it etc, the cost has already gone up. You may not be able to do this all the time, but use this option wherever relevant.

Leave a Reply

Your email address will not be published.