Last month I completed a year at Homesfy. This also marks my 1 year anniversary transitioning from Software Engineering to Product Management. Transitioning into the role was hard enough but the learnings and experiences that came out of it, made it all worthwhile. I have complied top 15 lessons I have learned below so that new PMs wouldn’t have to reinvent the wheel and learn it the hard way. Each lesson has a story to it and have come out of experience and observation.

1. What you pick to work on is probably the most important decision you will make as a PM.

• This one decision will change the trajectory of what you will build for your organization. If your product does not align with your organization’s business goals then you have quite literally wasted engineering efforts, time and money. You need to know why you are building what you are building.

2. You cannot please every stakeholder, but you have to keep them happy 🙂

• As a PM you work with various departments in an organization. Everyone has ideas and needs that are well intentioned, but you as a PM have to decide which ones to pick up and which ones to discard. PMs need to have high EQ and empathy to make the opposite person understand why something cannot be done now.

3. “You are the CEO of the product” – is complete BS

• Hard to digest fact for many PMs. Although you have a bigger say in many aspects of a product, you are not the only decision maker. The success of a product/feature will definitely rest on your shoulder but thinking that you are the only one in control and things will happen according to your whims would be grave mistake.

4. For trying out an idea, you don’t need to get engineering involved all the time

• If you can use no-code and build an MVP/MVF and prove that your idea works (with data), that’s when you should debate and get it in the roadmap.

5. If someone has a valid point, you must put your ego aside and listen. Like truly listen.

• You are not the “know it all” guy/gal. Different stakeholders from Marketing, Engineering, CS, Finance might have a whole different take or perspective about a problem. And sometimes the solutions that they propose might top the ones you are thinking. Set aside room for opinions and choose what’s best for your product.

6. Debate often but don’t mistake being a contrarian with being an a**hole

• Debating and discussing out things is a good thing and should be encouraged in every organization. But it should never be a You Vs Me situation. Choosing whats best for the product has to be based on sound data, research and user interviews and not hunches and loud mouthing.

7. Deploying a feature is just half the job

• Initially I used to wash my hands after I roll out a feature and got busy with the next big thing. I never looked back and checked if my users are actually using it and what the numbers are. This is a rookie mistake. PMs have to know what sort of impact their decisions have made. Something I am still working on.

8. Document everything

• You never know when something will come in handy 3 months down the line. Having a record of policies, rules and user flows will help not just you but other stakeholders.

9. Genuinely care about your Users

• Product starts and ends with the user. Talk to your users often and know what bothers them. Every user will have a different user experience. One other exercise I do is I simply observe how users are interacting with the product. You will find it amusing.

10. Proactively communicate with stakeholders and provide closure

• Something I have started recently is sending out information to various stakeholders on what was deployed in the last sprint. You might release features regularly but if users are unaware of it, the team’s hard work goes in vain. Also respond to stakeholders if you are the point of contact, don’t keep them hanging and waiting for an answer.

11. Like it or not – You will spend time firefighting

• Murphy’s law can set into motion anytime. Production fails, deployments are delayed, live bugs are reported. Things might fall apart and you become answerable for the shortcomings. You will spend 5%-10% of a week dealing with this chaos, allocate time for these but don’t let it consume your work day.

12. Carve time out for deep work

• My phone keeps buzzing with calls almost all the time. Deep work is essential for researching and documentation. Except for a few contacts I rarely pick up calls in the morning. Keep a polite “I will get back to you” SMS template handy.

13. Don’t waste time of developers with unnecessary meetings

• As a PM you define the what. Communicate it with developers while grooming them for the sprint. Let them have the freedom to figure out the ‘how’. Whole day discussions with developers seems unproductive and can hamper sprint scope significantly.

14. Technology does not drive business

• Strategies, plans, models and people drive businesses. Technology is a mere accelerator for convenience, speed and scale.

15. Be good with numbers and data – guesstimations

• My product caters to sales and salesmen are pretty darn good at crunching numbers in their head. Having good mental arithmetic skills can help in making quick decisions.

More to come in the coming months.