We keep hearing "customer is the king", and listen to him. While building products, we always tend to keep hearing from the customer. It’s very important to hear the customers all the time. However, it's even more important to understand the real “pain point” of the customer. Just hearing the customer and doing what they ask, is a very bad way of solutioning and serving the customer. Product designers must probe deep underlying pain points of customers and come up with the most optimal solutions for a common pain point.

In a service-led model, the customer is the one who is creating and financing the product. The service provider is more into execution with little interest to innovate or productize. It’s more of a made to order kind of a model which works well for the client-service method. The good part is unlike yesterday, the companies are trying to productize such service led projects helping both the client to monetize and service providers to innovate. The LTV of such productized service projects is much better.

In a product methodology, there is no client to begin with. You are the creator, early user and financier of the product. Hence, it’s very important to follow a very strict, disciplined and diligent approach to product development. If you fail and stick to the plan well, you'll plan to fail. There are various models for product feature planning like RICE, KANO, MoSCoW, etc. Irrespective of the model you follow, one needs to absolutely ensure that the sequence is as below. Any error in the sequence can lead to feature bloat, features with poor benefits and very wrong outcomes in the long term. At Empuls, we have learnt over time and iterated with various methodologies, but this golden rule has worked very well for us. It is also important who are the stakeholders and who are the final decision makers in each step. A democratic decision-making leads to delays, poor ownership and directionless product design.

1.Start with WhY

Every feature in the product is costly in terms of time and opportunity cost. Whenever taking one feature for production, there is some other feature which gets delayed. Hence, very thoughtful planning on feature prioritization is very important. The fundamental for any model starts with Why. For every feature picked for development, do a 5 Why Analysis (can be 2/3/4 Why too, depending upon problem) to reach a conclusion.

Many times, features which look very important, are dropped once they go through this Why analysis approach. Let me take you through an example with our product.

Feature requested: We should have rich text formatting in the Empuls collaboration module.

1st question: Why should we do it?

Answer: Some customers would like it.

2nd question: Why can’t customers do the required without rich text?

Answer: Not sure, they might be able to do it. But it would be nice if we can do rich text.

3rd question: Why are other communication products not doing this feature yet?

Answer: Maybe they don’t find it so important today.

4th question: what %age of customers can’t use the product without this feature?

Answer: Not sure, maybe less than 1%.

And by continuing such discussion, you generally can conclude on feature prioritization with a good data-driven process. “Why” a feature is required is the most crucial step in product development and it should be based on user voice, impact, data etc. This process should be handled by senior sales, product and tech teams only as the cost of error here is the highest.

This is a very crucial step, as most of the customers generally ask What they want, they hardly say Why they want it. Humans have an obvious tendency to provide solutions rather than talking about the deep underlying problem. It’s important for product teams to understand deeply from customers and convert their “What” into “Why” because the customer themselves don’t understand why they want some features. Customers are generally asking What because of some experience, comparison with some other product or just out of desire. Many times, the What is just a far-fetched desire, and not really a need. If these questions around “desired features” are not handled properly, it can lead to a product which has too many bells and whistles, but not useful for the real need at all. This is the toughest phase of product development, often unpleasant, which sets the future of any product success. Let me try to explain this with an example from Empuls.

Customer requirement: Every action on the platform should have a mail. (What statement)

Now if the product team gives this solution, it'll satisfy this customer without really solving the real problem. The product designers need to ask the right questions to this customer like “Why do you need mail for every action?”

Customer answers: Because the previous product I was using did so.

Product team answer: Hmm...But this can be solved in a much better way through notifications. This ll keep the stakeholders informed without cluttering their inboxes.

Now, this solution works well for both the client and the product team and a good overall long- term feature for the product. Had the product designer started solutioning the way the customer asked initially by giving a mail for every action, this would have led to a very sub-optimal product feature.

2. Plan the What

Once the Why is established, the planning for What is easier. In this step, the product and design teams should collaborate to define the nuts and bolts of the feature. It's important to define the problem statement very clearly. A problem well stated is a problem well solved. It's always important that the problem is directly heard from the source rather than through various layers of people leading to Chinese whispers and distorted problem statements.

3. Plan the How

This step is about executing the What. In this step, the technology teams should plan the execution of the features as defined in process 2. The How decisions should lie with the product and engineering teams together.

4. Identify the Who

Once the problem statement and the approach to a solution are stated, its time to identify the right person or team to execute it. The right combination of the team with the right skills for the problem and solution is important for optimal results. The Who decisions should lie with the engineering teams.

5. Plan the When

The deadlines are easy to predict when the first four steps are clear. Most of the times, project timelines are wrongly estimated due to lack of clarity in the first four steps. One should never jump to this step unless there is proper detailing of each of the other four steps. The When decisions should lie with the engineering teams.

This article is most relevant for software products. However, these learnings can be relevant to other industries too.