This is the third post of a 4-Part series that will take you on a journey of Successful Digital Product Development.

Start reading from the first part here.

“A product that’s built for everyone, gets used by no one.“

It’s a long journey from the time the idea of a product emerges in someone’s head till the time it is built and deployed. Multiple stakeholders are involved during this sojourn. For the heck of giving this journey a fancy name, let’s call it the D-4 process. 

The Product D4 process – 

1. Discovery – Define the persona of the targeted users, and their use – cases. 
2. Design – Create user flow wireframes and UI templates 
3. Development – Build scalable and stable databases and tech for the product
4. Deployment – Launch the product and provide version upgrades

In this and the next article, we will go deeper into the first 2 stages – Discovery and Design. These 2 stages are the foundation of a Product and should ideally take at least 60% of the total time of the entire product journey.

Product Discovery

This is the first stage of the product journey, where we start by sharpening the idea and defining it as narrowly as possible.

Let’s take an example here – suppose someone says that they want to solve the problem of receiving too many emails in the inbox by building an email productivity tool using AI. 

Now that’s a very broad statement. So first we need to narrow that down to something more workable. One way of doing that is to get the business stakeholders to jointly agree on answers to 3 fundamental questions. 

• What are we building?
• Who are we building this for?
• Why will they use this?

Again, to sound fancy, let’s call these the 3-Ws of Product.

a. The WHAT

In the above example, we need to get more specific than ‘building an email productivity tool’. This statement could be interpreted in different ways. E.g. Are we saying we want to see only emails that are relevant, or of interest, to me? Or are we saying I want to see short summaries of all emails? Or are we saying we want to be able to extract and act on actions from emails? Are we planning to build productivity features within the inbox of the existing email account or do we want to build a separate app? Is the envisaged usage primarily going to be mobile app based or web based? … and so on. 

The design and features required to build a product for each of the above interpretations are different. 

b. The WHO

Going deeper into the above example, are we solving the problem for personal use email or for business use email? If it’s for business use, are we targeting Sales function or customer support function or some other function? Are we building for a small business operation or for a large organization?  

This is important because a Sales function would need categorization of email information in context of sales Pipeline and leads conversions, while a Customer Support function would need categorization of issues based on other criteria, The actionables to be extracted would depend on the context of the use case. Similarly if we are building for a large organization, then there is additional complexity required for hierarchy based reporting, user license management and billing etc.

c. The WHY

A user has many options to choose from. So what is that one big reason for the user to choose our product? Let’s call it the ‘hero feature’ of the product. It’s important to define this upfront so that right from the design stage onwards, this ‘hero feature’ gets its due importance in the Product. 

It’s equally important to define the hygiene features. Hygiene features are those that are taken for granted by the user – a user does not buy the product because it has the hygiene features, but a user will NOT buy the product if the hygiene feature is missing. 

For Instance, let us take the case of our email productivity example, if we are building the product for sales teams of a mid to large organization, then the hero feature could be AI generated action items from emails (e.g. Remind Anna about the sales proposal next week), or it could be automatic sales pipeline creation (e.g. ABC Corp added to the Negotiation stage in your Pipeline for USD 50k) . 

Now, if our go-to-market strategy is B2B sales, rather than a B2C (or B2C2B, as in the case of many new age Prosumerized products), then Management reporting would be a Hygiene factor.

It is the responsibility of the Product Manager to coax the business managers to get them down to these specifics of What, Who and Why, before proceeding to the Design stage. 

The guiding principle here is that – 

The sharper the product definition, the smoother the user experience.

This is the third part of our 4 part series. Read the other parts here – 

1. Paypal Mafia and Evolution of Techno Product Management
2. The Art of Product Management – The Human Element 
3. The Process of Product Management – Discovery 
4. The Process of Product Management – Design