- Your “things to do” list would be overflowing ALL the time. Even if you take no more things to do and just work on the current task list, it may take you a month to just wrap up those. This would lead to a constant prioritization loop. You would always be prioritizing on whats important for you to do right now, today and this week.
- No “Right” / “Correct” way of doing things. You will need to figure out what works in your role, your product and your organization with your customers, your engineering team etc. This is very different from Engineering where you need to usually solve a mathematical looking problem and come up with the best suitable solution. Incase of Engineering generally the influencing factors (for your choice of solution) would be well understood so you can make a “well-informed” judgements. This is very hard in a Product Mgmt role, the ‘influencing factors’ in your decision-making would be generally fuzzy. Many pieces of information would not be available. Many data points would be un-verified. Many data points can be made available, but it would take a huge effort to gather those, and you would not have all the time for that investment.
- Poor understanding / standardization of the role. Different organizations, different teams have very different understanding of what the Product Manager should do. This leads to a lot of confusion, mis-understanding and the going gets tough. For example, I have seen orgs where PM defines what problems we need to solve, the use cases, business scenarios, HTML mocks ( if they are relevant), then leaves it to the engg team to build a system which can accomplish those goals. I have also seen teams, where the Product Manager provides a requirements document which already defines an engineering approach for the problems to be solved and the engineering team is responsible for building that engineering approach( and does not care about the business use cases, scenarios). 2 extremes. Be careful about this clarity before you sign up as a Product Manager for a particular org (be it an org within the same company or a different company).
- Limited learning re-sources. There are a LOT of senior engineers to learn from. The knowledge and the wisdom has been gathering in this area for a long time and thus getting induced into this role and growing in terms of learing and executing best practices is rather easier because of the abundance of patterns. Product Management being a new role, has limited resources to learn from.
- You own the engineering re-sources now. You are the major influence on what engineering team should focus on. So be very careful in keeping your “hidden geek / developer” instincts under control. Hint: Don’t keep re-writing / cleaning up your software .
- Your tasks may run into several weeks / months (not days / hours) . Learn to live with that, don’t set or commit to aggressive timelines.
- There is no real boss now (like there was in the engineering days). You are the CEO of your product and your engineering team. Which translates to the need of a lot of self-motivation, self-confidence and drive. There may be times when you need a bit of appreciation for what you did or how you accomplished a task, but there would be no one appreciating you or watching you so closely (as would be the case in the engineering role).
- Learn to live with un-finished tasks.
- Learn to live with ambiguity, un-certainty.
- Develop a strong decision-making framework – work hard on your guiding principles and clarity on your long-term vision. Write your decision-making framework down – get guidance from your senior peers / bosses and make it concrete.
- Develop a habit to retrospect often, gather learnings and document them , share them. Add these to your decision-making framework as notes / some other form. So that you don’t ever make those mistakes again.
Just my initial set of thoughts on this transition, would love to hear your comments. Please share your thoughts in the comments section.