This is an ongoing collection of lessons I have learned the hard way building digital products which has scaled millions of users. These pointers can be learned only through experience and not from a book.

1. User Interview >> Surveys.
2. Building an MVP on a no-code tool is far better than explaining the idea to stakeholders with a wireframe.
3. Pivoting based on user feedback is paramount for product success. Your assumptions as a Product Manager must alter based on the feedback received from customers. Do not hold your assumptions tightly.
4. Differences of opinion from team members will arise, it is important to make everyone feel heard. Everyone must be encouraged to speak their mind however only ones backing up with solid reasoning must be encouraged.
5. Proactive stakeholder communication is important. If a request has been delayed from the development team then communicate the same with the stakeholder citing the reason for the delay. Failure to do so will result in a feeling of let down and exclusion for the stakeholder. You need their support to make the feature and the change a success.
6. Great product managers weave a story when communicating to the team or the higher ups. Do not jump into explaining the problem right away. Start with a story. The story should include users, the pain point the users are facing and the loss faced by the product because of user dissatisfaction. Then conclude with the solutions you have in mind.
7. Sometimes it’s not the product, it’s the process that’s the problem. Operational issues must be scrutinized before moving to technical discussions.
8. A developer’s time is valuable and if something can be resolved with an instant message instead of a full fledged meeting then that’s the way to go.
9. Every story you create should have the “Why?” in it.
10. Backing up your argument with data is important but when communicating it to end-users or non-technical folks you are better off using emotion and storytelling. Humans are swayed by emotions, not numbers.
11. It’s truly fascinating to see how much you can achieve when you block your calendar to focus on tasks that matter.
12. Every meeting should have 3 items sorted before it ends – Future action items, Takeaways from the meeting and most importantly a hard stop.
13. Operational tasks can inadvertently consume more time than necessary. It is also not possible to completely eliminate them. You should block an hour per day for such items.
14. Every discomfort that the user faces is not a pain point that should be solved. Do not pick every battel that comes your way.
15. Every ticket you create should have the following sections outlined in detail – Story, Context, Requirement, Acceptance criteria.
16. If any team member comes up with a counter argument which breaks your logic, then you should swallow your ego and allow their argument to take center stage.
17. Logical reasoning & decision making are the super-powers of a product manager. If you don’t use it everyday, it will soon loose its shine.
18. Product Managers don’t have authority over other teams. The antidote to this problem is to build respect and charisma. Your team members have to like you so much even after repeatedly saying no to their face. People pleasing won’t work here.
19. You cannot win as a Product Manager without basic technical knowledge. The definition of basic changes with time.
20. If a change/feature has been delivered then it is the responsibility of the Product Manager to increase it’s awareness and increase adoption.
21. What user’s want and what user’s need are two different needs. Add a new button might not be the solution, removing the whole page might be.
22. It is equally important to remove redundant features as it is to add newer ones.
23. Product metrics must be at the tip of the tongue of every PM.
24. When you start your workday – follow these three actions > Check email, check calendar, check product metrics. And then go about your day.
25. Do not unnecessarily ask engineers to complete a task by the end of the day if it’s a non-urgent item.
26. Before approving a complicated design make sure you consult the engineer who will build it. This will save a lot of time later. Downgrade the design if necessary.
27. A useful skill to practice is to break down a complex problem into pithy business use cases.
28. A monetizable feature will always be preferred over convenience on priority. As it should be.
29. Before setting out to build a new program experiment it yourself with a set of users and if it genuinely solved a problem then go ahead with the technical implementation.
30. Spend time pondering over Build Vs Buy. Many a times it is better to buy a ready made solution than to build it from scratch internally. Cost, team bandwidth, expertise are factors that should be considered.
31. Often the simplest solution is the most effective one.
32. Product Management comes with the overthinking curse. You will see edge cases that other won’t. Solve them before release.
33. Bad news must travel faster than good news to upper management.
34. When promising a delivery timeline, promise with a 2 week extension. Production issues are real. You might have to revert back and add the bug in the next sprint.
35. Measuring developer productivity by tools which count lines of code per day and similar stats is a waste of time and futile. Delivery of tickets is a better metric.
36. When using the RICE method to determine priority of items, Reach and Impact must be estimated by the Product Manager while Confidence and effort must be estimated by the engineering manager.
37. It is better to ship smaller items than to wait for the whole module to be complete.
38. Always release a bare skeleton solution first and see how users use it. Build on top of it. You will see more possibilities here.
39. Your best friend in the engineering team is the QA, followed by the developer. Not the other way around.
40. You will face stakeholders who are difficult to deal with. Do not close yourself to them. Ability to handle different personalities and getting work done from them is part of being a true professional.
41. The calm man is always the bigger man. Not the one who has the loudest mouth.
42. Every week pick a slot to talk to your manager about the tasks you are handling & to discuss the bigger picture – where you are headed.
43. Self starters are always rewarded. Ability to lead and deliver without being told to so is key to being a leader.
44. Product Managers should know sales and marketing as good as they know technology. This is the reason why the Head of Product becomes the CEO over the CTO. Time and again this has been proved.
45. As a Product Manager you have access to all data within an organization, leverage it to gain critical insights about the industry.
46. It is widely known that communication is de facto skill that every Product Manager should have, what is not widely known is your written communication should be on point and precise. The best product managers I know I do not use circumnavigation but come to the point immediately.
47. Users use your product in ways unprecedented by the PM. Understand their use cases and observe how they use it.
48. You will be bombarded with noise in your office. The vast majority of which is low impact items. It is difficult to escape them. Hence find a place which is quiet where you can focus. Only the product team must know where you are. Sometimes difficult to reach is a good place to be. P.S. I am not a fan of the open door policy.
49. One effective trick I have learned is this – While jotting down points during a conversation or just brainstorming, instead of using a blank document or the notepad, pull up a google/excel sheet instead. You will be able to structure your thoughts and as a bonus you can calculate things on the go.
50. As opposed to popular opinion, you are not the CEO of the product. You are a facilitator.
51. Great ideas will strike in an unexpected moment. In the shower, in the midst of a conversation or on the way to work. Scribble it immediately or leave a voice note. Its hard to remember them.
52. Your immediate reporting manager will have a strong influence on you. Their mannerism and the way they think will alter your thinking, while choosing your manager is not upto you, you must be cautious to learn only the good parts.
53. The Engineering team will always have the upper hand when it comes to the technical understanding of the product, but as a Product Manager you should have a strong hold on the business and user base.
54. Do not rely on assumptions and intuition, rely on data.
55. Do not be afraid to pivot from your roadmap if business calls for it.
56. While documenting a change, you should also document why you decided to make the change. Your future self will thank you for it.
57. One high value skill in product management is to explain a complex business case in a one liner. It is sign of clear thinking and intelligence. Brevity is a hard earned skill.
58. Never overpromise your stakeholders.
59. AI can take care of operational work while you can work on tasks that require critical thinking. Brainstorm ideas and find flaws in your logic by talking directly to an AI on voice mode.
60. Always keep an eye on what your competition is up to. Every time they release something valuable question what made them work on that feature/change. Pivot your roadmap in that direction if it seems valuable.
61. Attending customer success calls and digging through customer queries is a great way to gauge what sort of problems users are facing on a day-to-day basis. Prioritize these, else you risk a high churn rate.
62. The most valuable player in the team is the one who genuinely cares about the end user.
63. Once a new update has been released, make users aware about the update through all channels available. Use other departments like marketing and branding to spread the word.
64. The best way to spot a bullshitter is to transcribe what they say and real it out aloud. You will be surprised how most arguments are hollow and just fillers sprinkled with jargons.
65. On your browser three tabs must be pinned. Your calendar, you mail and an AI service. Disable notifications as much as possible.
66. Product Management is not about being an expert in Jira, Asana or Airtable, just like how being a good developer is not about being good at JavaScript, Python or Java. Adapt your tool to your job not the other way around.
67. Show and tell >> imagine and tell
68. Unpopular opinion – if you have a small team of less than 20, you are better off working in a waterfall model shipping features quickly than working in a scrum/agile fashion.
69. You can teach a PM every skill other than communicating clearly. It is hard for PMs to be an introvert. Its a hard pill to swallow for many aspiring PMs.
70. Never feel shy, embarrassed or obligated to sit through a meeting which does not provide value. Encourage team members to leave them asap.
71. Realize the difference between decisions which needs to be made quickly and decision which can be mulled over.
72. When you talk to your stakeholders/colleagues about their day, find ways to automate repetitive tasks for them.
73. If any stakeholder comes up with a problem they want to solve, ask them 5 instances from the past where they have encountered it. If they are unable to answer, its either not a problem that users are facing or its a problem not worth solving.
74. Effort to reward ratio should be weighed with engineering when it comes to prioritizing tasks.
75. Never assume, always ask.