I recently made transition from Engineering to PM world and with much naivety all I thought I needed was to learn how to write a great PRD, learning JIRA, learning customer research interviews and have the gut to be attentive in countless zoom meetings would be enough for me to become a PM! Well I was proven pretty wrong pretty quick and I thank the universe for that!
Here are some of the significant changes I observed and implemented, some of them were smooth and some I still struggle with but actively pursue to learn and lean back on mentors / peers / books / school to help me with.
TLDR: For me personally transition into Product management required more shift in my mindset than a skill set acquirement!
Before I go on with these things I have learned, let me elaborate on Things i still actively struggle with so that there is not an iota of doubt that I am anywhere close to knowing everything about product management!
- Writing PRDs that require a certain amount of focus, great level of details that makes most stakeholders happy from engineer to Customer success
- Running a Scrum
- Sticking to the roadmap
- Trying to balance between serving the customer and keeping the number of context switches for engineer manageable
- Feeling confident on a feature request inherited from other PM (s) because I always feel hesitant towards reaching out for more when the knowledge transfer has already been done.
Shift in Mindset on who my Stakeholders are:
I used to think delivering best product experience to the Consumer in terms of quality and quickness. I would assume that as a PM my biggest stakeholders are customers.
I now know the job of a good PM is to balance between the two most critical stakeholders: Customer and engineers. Everybody and everything comes later! If delivering a delightful product experience to end user is one then minimizing context switches for the engineers is equally if not more important. My end users are not technically challenged to not call on my bulls ** t if I try to sell a mediocre feature and engineers I work with are not “resources” to be expected to give up on their need to innovate / make mistakes and bandwidth to iterate!
Shift in mindset when executing
As an Engineer, I felt that none of my task was complete until there are 2 solutions on the table – One that could be done right now and one that is the most optimized (I wasn’t one of the “10x engineers” whose solutions were both instant and best.)
But As a PM, My job is to make sure problem statement is defined as comprehensively as possible with little to no room for ambiguity. The job is not to produce PRD / Product brief that are 10 pages long but does not define problem for the majority of the end users and is not useful for folks from customer success to design to engineering. And most importantly PRD is never to be created in vacuum. After learning this the hard way I now make sure to recognize the most important stakeholders of the feature I am working on. If some of them cannot commit to providing feedback while the PRD Develops I will at least try to understand their perspective on problem statement and what is it they want the product to cater to. The teams i reach out to Sales, customer success, marketing, education / training, Support / SRE team and the most important engineers.
Shift in mindset when planning
As an engineer, catering to present while frequently optimizing for future used to be enough for me to get my job done.
But as a PM, it is more granular than present versus future needs. I categorize my projects under
- Existing Product features driving the NPS / Customer sentiment down
- Existing Product features driving the NPS / Customer sentiment up
- Product gaps leading to customer churn
- Product gaps which are customer deal blockers
- Product gaps which are customer expansion / renewal blockers
- Feature parity with Competitive landscape in conjunction with Org priorities at present (it could be to cater to bigger customers than small businesses or
Shift in mindset when communicating
Identifying your stakeholders and seeking Consensus from correct stakeholders by delivering just the right amount of information and making sure there is a plan B in case of a deadlock!
I try to strategize for Plan B and having an alternative strategy in my back pocket. There is absolutely no need to distract the team with it until there is a need for the same. (I have made the mistake of sharing my plan A / B and C and distracting everybody quite unnecessarily and nobody wants to see your face with deadline approaching and a messed up chaos of 3 plans)
Also, shield your engineering team from infrequent and massive context switches because of the questions that PM failed to envision or ask in time.
Shift in mindset when present in a meeting
The meetings are no more places where I can speak when spoken to and yet speak just enough so that the conversation remains exploratory between the stakeholders of the meeting / problem statement / impact for understanding the problem but leaves scope for action items by the end of it.
The onus of understanding and exploring the problem and getting a consensus on problem statement falls in PM’s responsibilities.
Tools that help me
- Excel, Notepad and a pen, Cloud zoom recordings
- Figma
- Miro
Skills that have helped me so far
- Learning how to conduct user interviews (It is so much more nuanced than I ever estimated it)
- Data analysis
- If technical PM, skill set to be able to understand if not contribute to the design specs engineers write for the feature.
Books that may help
Some questions that I have been asked and here is my personal opinion to those –
For someone with software engineering + client facing consulting experience, how difficult would it be to land PM job interviews? What are some things that you would advise to improve my chances?
I am currently pursuing an MBA and studying with some super talented individuals who want to transition to product management.
Path 1 —Move from engineering into Product management in a growth startup
In my opinion, the transition without a business degree in startup is much easier but the job may not teach you the skill set or opportunities to become a good PM. It is imperative to keep in mind the difference between a program manager and product manager. While the title should not matter in a startup but one must not lose the sight of what they want to learn to create the value they want out of their role.
Path 2 – Move from engineering into Product management in a post growth phase company
In my experience I have seen this move much harder and takes lot more time. Also, this move most of the times brings the foundational skill sets because of a larger team in place and bandwidth to get a mentor.
Advice I would give (I have only cleared 1 PM interview in last 1 year and that was for a growth startup so the questions looked very different from the standard questions I have read about)
- Focus on breaking a problem statement better
- Even if you have not done it so far in your career, learn about GTM strategy, basic pricing
- Try to understand the underlying business models of some of your favorite apps and what is it that consumers of each of those apps would care about
- Be able to articulate your working ethos with different stakeholders specially sales and engineering
- KPIs. Never leave a product feature idea without KPIs to measure the engagement or success.
- If technical PM, learn about observability and as a PM push for building a stack that alerts the team of customer pain before customer.
What do you personally like and dislike about being a PM?
What I love – With the product management I feel I have hit the sweet spot I want to develop my career in. My current role requires technical knowledge I have gathered in the past to communicate effectively with engineers. Understand the solution, push back the business when needed to and find alternatives amongst engineering teams when needed to. But I want to develop my career understanding and making an impact directly on the business. I want to understand the businesses of users we impact with our products, want to understand how and when to implement different GTM / Pricing / Product marketing / Roadmap strategies at different stage of the company I am working for – startup Vs growth stage vs post growth stage.
What I am not a big fan of – Learning how to influence without authority. As a PM you get a team of engineers to work with. When transitioning from engineering background it can be hard to avoid being too involved into solution part of the project and stay in the “PM” lane and yet make sure that the timelines are met.