Once Upon a Time In the East — A Product Manager's Storyby@thatproductguy
1,427 reads
1,427 reads

Once Upon a Time In the East — A Product Manager's Story

by Kumar ShubhamAugust 5th, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Shubham is a Product Manager at He was a young product manager in Mumbai, India. He had just got into the role and was ignorant about various nuances of Product management. He wasn’t a product manager by training, if there is such a thing. This is a story of his mistakes and his learnings. He has learnt to stop multitasking and focus on being productive instead of busy. He also learned to say ‘not now’ when an idea is not being prioritised.

Coin Mentioned

Mention Thumbnail
featured image - Once Upon a Time In the East — A Product Manager's Story
Kumar Shubham HackerNoon profile picture

Disclaimer: All characters and events depicted in this article are entirely real (and represents the protagonist i.e. the author himself). Any similarity to actual events or persons, living or dead, is strictly intentional.

A long, long time ago (not that long, just 5 years ago) in a land far away (a land in the East, Mumbai, India) there was a young Product Manager named Shubham. He had just got into this role and was ignorant about various nuances of Product management. He wasn’t a product manager by training, if there is such a thing. This is a story of his mistakes and his learnings.

Mistake I:

Doing everything at the same time — Being a PM, Shubham had to play a lot of roles and thus, it required multitasking which split his attention to these tasks. This sometimes affects the quality of work.


Stop multitasking. Getting a number of things off your to-do list is good but it does not mean you have to do it all at the same time. Concentrating on one task gives you more time to think (and act) as compared to doing it with several other activities on the side. Multitasking requires you to split your attention complicating your thought process.

If you want to get things done, choose to do it, and do it one thing at a time. Don’t attempt to do many things, because you’ll end up accomplishing nothing. Dale Carnegie said that you should do the hard jobs first, for the easier ones have a way to taking care of themselves.

Focus on being productive instead of busy. ~ Tim Ferriss

Mistake II:

Not saying “NO” — There are so many great ideas coming up all the time and ideally he had like to do all of them. Ideas, requirements, requests keep pouring up from internal stakeholders. Marketing, operations or business development, everyone want their stuff to be heard first and made first. And that led to a heap of tasks requests, and pressure to deliver all of them.


Saying ‘no’ is one of the most challenging parts of being a Product Manager. But as a Product Manager, you need to keep focus on the vision, the user needs and the value this ideas can bring. ‎You will only be a good Product Manager when you learn to say NO effectively.

This is to be done with reasons and making the other party understand why it’s being declined. Instead of just saying no, don’t hesitate to point out the impact on costs and risks. Whenever you can, say ‘not now’ especially if the idea is valuable but not yet to be prioritised. Also, don’t neglect it completely, if its a valuable one do add it to the backlog so you can always pick it up at the right time. In addition, try not to say ‘I’ while saying no. Use data and complete transparency in prioritisation and show the value for the product and for the business versus a personal opinion.

Mistake III:

Being only a solution guy — Being a PM he loved to solve problems — it’s in his blood. But it was problematic to think only in terms of potential solutions. It closed him off from thinking about the problem itself. And even after a solution was provided since problems were not optimally solved, it didn’t provide the optimum ROI for the effort and cost which were put in.


There is inherent danger in just thinking about the solution because you end up constraining your thinking to a certain subset of solutions. Instead, really think about what the problem you are trying to solve for the user is — make sure you understand not only their pain, but what causes it, to deliver the optimal solution. A look at below picture sums it up. Exploring and thinking on problem gives a broader view and helps in finding the optimum solution. It is also important to ask the right questions about the product to pinpoint and drill down to the core of the problem.

Mistake IV:

Being perfectionist — He had thought so much about it, there are so many additional tweaks that could exponentially increase the value of it. And for him, it’d be unfair to himself, the developers, and the user to release it? This not only keep its release on hold but also gets the team to work on a feature/product which hasn’t yet proved if it would be successful or not. Often he found that the feature/product was a fail or didn’t provide a better push to user experience or revenue from what was there already.


This is the single biggest mistake you can make as a product manager. None of those additional features can replace the value of getting your feature or product in the hands of real users. In many cases, worse is actually better. Be relentlessly aggressive to onboard your first user. There are no perfect products! Give it to user testing, they will find a new bug every time. Something will need to be changed or rethought. And that’s normal. There is nothing to worry about. Just release it, collect feedback, then improve it. Early in a product’s lifecycle, that has to be one of your milestones.

According to the Pareto Principle or the 80/20 rule, states that 80% of results in a system come from 20% of the causes.A trivial change can lift up revenue or experience providing the optimum ROI.

Mistake V:

Product Manager or Project Manager — He not only handled the product but also handled the project, micromanaging and getting status through stand ups. This was a complete waste of his quality time and skill set on tasks which wasn’t his job.


Product management is still a relatively new discipline in the world. Across different companies the responsibilities of the role can range from those of a project manager to product owner or even being the boss of the team. Some common commands which goes out from PM’s, ‘I know what the team has to do and how to do it’. Another one, ‘I told them to do this exactly, why isn’t it done?’. This approach is very far from my view of what a Product Manager should be. A good Product Manager leads through vision, communication and influence, not commands and micromanagement. They focus on bringing together the best people to drive the product forward and make sure every team member is heard and enabled to speak up and share their best ideas. Skill set of a Product manager is to be fully utilised when they work over the Product than to micromanage project and team. That is what they’re meant to do — better the product for the user and better the KPI’s set for the company and its product.

Mistake VI:

Not being Data centric pre/post feature launch— He did proper research pre-launch for a fantastic product feature. But after the feature was launched, he didn’t give attention to what was happening to those numbers. Whether the NPS was going up/down or there was a massive fall at one step of the funnel. Thus, if the feature actually made an impact and kept it sustained throughout or the spike was just for a short term and a major issue with user experience just brought it back down even below the previous state? He missed to gauge it and when he came to know about it, it had done the damage.


It’s because we are sometimes so obsessed with measuring pre-launch data that we forget to take a look at the post-launch numbers. But product management is not only about successful shipping. Did you ship? Be ready to iterate, to change, to improve it. How are you going to improve something if you have not asked the users/customers about it?

Gathering user feedback and analyzing it are two really important things a product manager should focus on. As a beginner product manager, you often overlook Cohort analysis, Net Promoter Score analysis, Funnel and Heatmaps/Clickmaps/Scrollmaps. The first one measures the retention. Retention itself shows how valuable a feature is to your users. Cohort analysis is a behavioral analysis tool that helps observe how groups of people/cohorts experience something, usually over time.

The Net Promoter Score is a measure of your customer’s overall loyalty to your product. The score is calculated by taking the percentage of respondents who are promoters and subtracting the percentage of respondents that are detractors. This will bring a score ranging from -100 to 100, which is your Net Promoter Score. But it’s a good idea not to focus on the numbers a lot. Instead, focus on user feedback and try to improve the NPS over time.

Funnel is a mean to look at the steps it takes for a user to do what you want them to do. It can be as granular or high level as you’d like. It gives a good indication at which step a user is dropping of and which step is actually working for you, so that you just tweak the step where drop offs are happening rather than modifying the complete flow.

Heatmap/Scrollmap/Clickmap gives a pretty clear view on how an user is interacting with the elements on the product/feature. Thus providing you ample information on which element is placed at the wrong place, if any element needed to be pushed or made more clear for the user to find it easily.

Data is the biggest asset of a Product Manager, it is the only source of truth and the only proof of a product success or failure.

Mistake VII:

Lack of hypothesis driven approach and validating the same — he had an amazing idea to better the user experience and also increase the conversion rate by doing so. It was an intuition call and also more of a “I know how my user will react to this feature”- kind of call. So, he went ahead to get this feature developed and release to the users. Less did he know, that not only it brought the conversion rate down but also lowered the user experience. Only after few weeks of the feature launch he realised the mistake and then rolled back to earlier step.


As a product person often when taking product development decisions, there is usually a decision making process that one has to face with two extremes and lots of equilibriums in between.

It all starts with the realisation that even if you think you know what your users want, the reality is that you don’t, unless you go observe and speak to them! Even if you believe you have a strong market understanding, build a product based on your gut feelings and you risk launching something that only a few people will use, blaming the rest for not getting it. The best way to gauge it, is to develop an hypothesis and then run an A/B test for that feature to validate your hypothesis.

Now after running the test you just learned that the result was positive and you’re excited to roll out the feature. That’s great! If the hypothesis failed, don’t worry — you’ll be able to gain some insights from that experiment. Now you have some new evidence that you can use to run your next experiment. In each experiment, you’ll learn something new about your product and your customers. Hypothesis-driven approach gives you valuable insights on what you should do next.


So, Shubham had made all these mistakes after becoming a Product manager. But he doesn’t regret them. It’s important that you know what the takeaways are. Just make sure you learn from them! Be brave and humble enough to acknowledge when a feature isn’t working. Your user doesn’t care that it was an incredible technical challenge implement. Your user doesn’t care that it took 4 weeks and 6 full-time engineers to build. And they certainly don’t care that you may lose some respect among your team for admitting defeat.

What your user cares about is that their experience using your product is degraded because a feature isn’t what they need it to be. Solve for your user. If a feature isn’t working and you’re talking to users early and often, you’ll know when something isn’t working. Further, you should be able to measure everything that goes on in your product, so you’ll have data to back up your assessment that a feature isn’t cutting it. It is the failures and mistakes from which we learn and those experiences are what makes, who we are now.

Anyone who has never made a mistake has never tried anything new — Albert Einstein

If you found this article useful share with others so that they can enjoy it, too.

Thanks for your time! Connect with me on LinkedIn and Medium.

Stay tuned for more UX and cognitive psychology posts till then Happy Reading!