My 15 years in Building Products…

Photo by Yianni Mathioudakis on Unsplash

Today my role in Product Directorship involves many roles starting from being requirements analyst, being business analyst, developing business strategy, developing/building a product, marketing & selling it, and primarily making this happen through a team of PMs. My day-to-day activities kick in lots-lots of communication, guiding my PMs, guiding cross functional teams and helping their leaders to be aligned to Product goals as well as business vision, analyzing success metrics and failure root causes, cultivating and maintaining healthy and fruitful culture, and learning & developing myself. But these all are today, and to make this happen, I have come a long path with lots of failures, successes and learnings. No, I am not gonna tell you my story of 15+ years of experience. I will give you my learnings being in the journey of building many products. Let’s get started:

Know your customer but don’t listen to your customer.
I know you got strange face reading this. But let’s understand knowing a customer first. Why is it important to know your customer? Everything you are doing, is to add value to your customer so that, you can capitalize on your value add. If you don’t know the audience whom you are serving, then you definitely don’t know what to serve them. Not knowing a customer is like, serving the non-vegetarian food to a vegetarian customer. What happens is, a customer never asked for that food and you keep trying selling, which eventually lose shape and die. What does knowing a customer mean? Well, it is,

And why I say don’t listen to your customer? Simply put, if you listen to them, you will end up building something which they too are in least need of. You are a Product Manager; you are not a personal assistant who takes notes, instructions and then just perform them. If so, you can join as a PA to them 😁

“Customers can only tell you what they FEEL or how they feel or how are they doing it currently. They can never tell you what is the problem or what solution they need.”

It’s you as a Product Manager, bring both the right (most burning) Problem as well as the right solution to the table. My talks above might confuse you. I am not saying deny your customer’s any requests or talks. What I am saying is, the listening of the feeling should be covered in the knowing part. One such experience I can talk to corelate here; one of my work involved a customer who has issues with managing the battery acid levels. The device was IOT enabled and was regularly pushing the levels information into the hub. Well, I never put it on individual names or roles, so let’s say the product team, built 53 days; 40 odd APIs, an easy interface, but, what’s needed was only 5 APIs, which customer wanted to consume, to read the levels and trigger action via service. What customer spoke was all that what they have, what they need and also what they don’t need; listening to which resulted in disaster. What the product team built was already there with them. So, once again, Know your customer but don’t listen to them.

Track your competition but never follow them.
Again strange advice from me? Yes, I am strange too 😊. Knowing, what your competitors doing is not your job. Don’t get stuck with them. If you keep following your competition, then you will solve their problem in your product, which we definitely don’t need.

Firstly, my experience has taught me, there is no competition in this world. You are not competing with anybody. You have solved something in someway which your customers need and that’s exactly the reason they are your customers and not the customers of businesses which you feel are your competitors. You have stood for your customers in someway, supported them in someway, which your customers like much and that’s exactly the reason they are your customers.

Secondly, following your competition will make you fall in loop of their growth which eventually will saturate you product growth. You will see the problems your competition has solved and eventually make them as your problems and end up solving something which nobody or a very few needs. Let me share an experience; once I was doing a design review of one of my team member. The PM working with the design team was ready with the prototype and started presenting. I was constantly feeling that I have seen this already, but, that was the first prototype review I was doing. Sooner, I realized, our neighbor has something similar. We felt our neighbor has solved it already and got inspired by them, but that’s not true — my customer problem was similar but needed a different solution. This is what happens, when you follow your competition.

So, does it mean, don’t look at your competitors? No, keep track of them. Just don’t follow them.

It is a great, great, great information that your competition gives you as they are in the same field/industry/domain as yours (hence I use the word — neighbors).

Being in same domain serving different customers (bit of overlap), neighbors bring in a great quality of information that can help you better serve your customers. Something your neighbors have solved for their customer which resembles your customer feelings too, you should be inspired by (once again, I definitely don’t mean follow here). So, don’t follow your customers on what they are doing, but know what problems they have solved, how they have dealt with certain issues. Keep tracking them.

Study your metrics but don’t only depend on them.
We all want our product to succeed. And I being the Director/Head of Product, I want my clan to succeed (my business to sustain and grow). Hence, we as product manager(s) have great math to do i.e. metrics. Either it is usage metrics, revenue metrics, retention metrics, and what not (these depend on the kind of product and its revenue model too), we Product Managers tend to put every metrics and create a huge dashboard and keep presenting for every what’s next meetings. I have seen PMs taking pride in their dashboard (why not, its beautiful and insightful to the level of decision making) to the extent that they deny any strategies/decisions that fall before/beyond the scope of the numbers, ranges, or trends they have come up with.

Common, you are a product manager and not intraday trader. Technical Charts are not for you. You are not deciding anything for a day (there are other leaders at execution level to do so). Your product doesn’t start today and end today. It has a Life Cycle which can span years. You have to understand this —

Metrics you draw/derive shouldn’t become impediment in your decision making. Rather, metrics should be ensuring you the decision you made is right.

So, don’t use metrics for everything. I prefer metrics should be used to cross-check the decisions made. It implies don’t use metrics to make decisions, instead use them for validating your decision. Apart from this, anyways metrics has its primary use (which I don’t deny) — Showing how product is performing. Keep showing it (that’s important).

Hence, study metrics, use them in KPIs reviews (Product Performance), don’t bother them much. Your decisions should solely depend on the customer insight you have gained directly from customer itself, the roadmap you have drawn, the resources you have currently with you, and the market information (which side the market/your industry moving on). Metrics are and should be, another just a supportive piece of information.

Don’t take any feature/product personally.
Wow!! this is tough. Not sure, how many times in my career, I had to convince PMs to stop thinking product and start thinking business. The feature/product which was solely built by, is so much personal, knowingly or unknowingly, such that you defend it up/down, right/left, till the moon for everything. One of the experience I would like to share, where we had a feature built which we had to put down as market changed and no buyers, and I was no where interested in bearing any cost of it. But my PM, who built it, was so strong towards keeping it live, maintaining it, and to the level adamant that he couldn’t see the reasons why we have to retire that feature.

We all love our product. It takes so much of hard work, to build, to nourish, to market, to sell, to make it successful, and sustain. I understand, during this journey we tend to feel it as our baby and start protecting it. But business has simple rule:

Any cost worth the revenue, keep it and grow… Any cost doesn’t stand anywhere, scrap it immediately…

A Software product/feature incurs many costs — infra, marketing, development, support, etc. I cannot simply agree to my PM to keep it because he was emotional about that feature. As a product manager, one should know the Product Life Cycle. Every product/feature has to retire a day. We all know how many products Microsoft, Apple had, and retired. Even Facebook today is not the same product what it was a decade ago.

So PMs, love your product. I too do. In fact, a lot. I remember here, one saying which someone said to me:

You see a plant with flower; if you like that flower, you will pluck it. But if you love that flower, you will water the plant to breed more flowers.

That’s true. Love your product so that you nourish it and grow it to its full potential. But don’t get emotional. Don’t attach to it. At the end, its a business, its for a business and its by a business. That’s it.

Work on revenue/outcome before design/development.
This is something which I have experienced not much with older PMs, but mostly younger ones or new ones. The approach you should remember is:

Think Business Model before thinking Product Model

Think business first. Knowing the problem and knowing your solution around it is fine. But the product modelling should be done only after you know the business around the solution you gonna provide. If the gain is not worth contributing towards the vision and growth of your business then you are not solving the problem.

I understand value addition, making a difference, innovation, jargons, etc. But in reality, these hold good only when — the solution you provided can grow your business and contribute attaining your vision.

“You are not only solving your customers problem. You also have to solve your business problem too (revenue, sustenance, growth)”. Inventing a toothpaste sucker from tube and calling it an innovation doesn’t make any sense. Nobody needs it. Everyone around is ok having some, at the end toothpaste gets wasted in tube. You cannot build sustainable business around it.

So, don’t rush to get your product to market. First see whether the market really exists. First see whether you can build a business around your product. “A product can change company’s fortune”; correct, but as a Product Manager you should remember it is in both ways, grow or bankrupt. Never design your product first. Let business evolve for the product and only then product can create a business.

Boss might be right, but you own the product, and you are responsible for its success.
I don’t know whether my boss will like this. Anyways, Product Management is a serious business; Boss cannot be ruining my product. Certain times, it happens that (has happened to me too), you conflict with your boss but not willing to let him/her down or oppose. And agree upon (compromise is right word) saying at the end boss is right. Your boss, would get you all the why’s answered to do it, but doesn’t fully convince you. Still you go ahead and see it happening, what you had foreseen already.

Executives might know business better than you, but you know your product better than anybody. If not, then you actually don’t own that product. Remember, there is this phrase floating in internet —

Product Manager is the CEO of the product.

Implies, your decision on a product will mostly be right than your boss (again, provided you own the product). Its nothing wrong in denying and standing for what you feel is right. But just don’t stand straight saying we will only do this. A good Product Manager will always support his/her decision with enough artifacts and evidences, which will convince the stakeholders.

One such experience I would share, where, I was been to customer premises and saw a problem which is recurring and can be automated. I came back, talked to few of other customers we had and found them facing same/similar problem. I was so convinced that the automation around the recurrences will bring good revenue to the company. I needed to convince my boss that, I want to get this product live and I need all the resources I listed. We both couldn’t settle for a long. As it is a new launch, every data was considered hypothesis, except the customer talks I did. And that was enough for me to finally get a buy in. I was right, the product contributed 1.3m to the revenue same FY.

So, your analysis holds strong, then don’t be on wrong side. Stand and put your argument straight. Don’t bother whom you are reporting to.

There are many experiences, many mistakes, many learnings, and it will continue. I will stop here with the thinking that, I have given our major lessons from my journey.

Signing off…

Thank You!

Do you like my writing? Does it add any value to your life or profession? If so, Follow me on medium and subscribe to get notification as soon as my new writing is published.

Your support is worth millions. You can support me by Buying me a coffee

--

--

I write my experience in Product, Engineering, Technology, Management and Entrepreneurship. Also, I share my experiences and life lessons too.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Praveenkumar Revankar

I write my experience in Product, Engineering, Technology, Management and Entrepreneurship. Also, I share my experiences and life lessons too.