👤 Manoj Agarwal
10th January 2022
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 developing solutions 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 in innovation or productizing. It’s more of a made-to-order kind of 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 learned 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. Democratic decision-making leads to delays, poor ownership, and directionless product design.
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 that 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 that look very important, are dropped once they go through this Why analysis approach. Let me take you through an example of 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 are 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 talk 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 that has too many bells and whistles but is 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.