The Transition from Engineering Manager to Product Manager

Published in

Product Leadership Journal

9 min readMar 28, 2022

I used to be a developer, a tech lead and an Engineering Manager before I embraced Product Management full time. I’ve been talking to many people lately who are curious about how I made that shift — and made it stick. So this week, I decided to pull together my notes, prompts, stickies and thoughts into something that is hopefully cohesive and helpful to others making (or considering) the transition. As always, I’ll talk about skillset and mindset.

1. From Outcomes to Output

Generally speaking, Engineering is organized around productivity (output) and Product around value (outcomes). Engineering is structured, discrete, & measurable, while product is ambiguous, messy & often depends on Engineering for measurements (data, analytics, insights). You have to get comfortable saying “I don’t know” and “let me get back to you on that.” It’s humbling and instructive. “Agile” gets amplified 10x in every context. It can be overwhelming at first, but plow on — the rewards will follow.

Outcomes vs Output demonstrated by the Penguins of Madagascar

You will find that your #1 job now is communication and alignment. #2 is learning. And #3 is staying ahead of the curve. You will have little time for anything else. Lower your expectations (Literally, get used to achieving only three things on a good day 😅).

2. From Code to Words

Sadly you’ll have to part with some of that admirable technical vocabulary you’ve built up over the years, like “stateless service” and “runtime reconfiguration.” People buy benefits, not features. As more and more platforms, toolkits and SDKs come into the market, the gap between engineering language and customer language is growing. You will have to constantly adapt & align (I wrote about this in an earlier post).

“People don’t buy products, they buy benefits.”
— Zig Ziglar

The ultimate test is the Feynman Technique (a.k.a. ELI5 or Explain Like I’m Five) [1]. If you can explain it to a five-year-old, you understand it well enough to explain it to anyone else. Here’s an example of getting there iteratively:

Note that we’re not “dumbing down” the concept, but explaining it in relatable words and analogies.

3. From Technical Knowledge to Product Knowledge

In his book “Inspired,” Marty Cagan[2] advises that good PMs need to build a deep knowledge of:

a) The user

b) The data

c) The business

d) The industry/market

This is where your technical experience can really set you apart. You’ve likely spent a lot of time learning programming languages, paradigms and platforms. The best practices of learning are 100% transferrable here.

For example, I successfully applied some of the same methods as I used for learning new programming languages: learning by doing, pairing with experts, picking up idioms and seeking out best practices.

4. From Problem to Solution

It’s cliched but understated: “fall in love with the problem, not the solution.” The Engineering mindset defaults to finding creative solutions to hard problems. As PM it is your responsibility to provide — indeed obsess over — the bigger context. Fortunately, there is no shortage of frameworks in the Product community readily available to help you & your team. The most basic one is (courtesy of Marty Cagan again) the four questions to ask yourself before building something[3]:

a) Is it valuable?

b) Is it usable?

c) Is it feasible?

d) Is it viable?

On a related note, Frameworks are your friend — you will find one to explore, prioritize, organize and communicate just about everything you can imagine.

5. From Knowing the Path to Walking the Path

Do you feel like you have a lot on your plate already? Well, good news, you are now also responsible for fostering a healthy team culture 😃. There’s a famous saying in Product Management circles:

“When a product succeeds, it’s because of the team, and when it fails, it’s because of the PM”

Your pace becomes the team’s pace. Your standard becomes the team’s standard[4]. Your obsession becomes the team’s direction.

You will get scrutinized a lot: by your team, peers, customers, bosses, competitors and partners. What will help you:

Building resilience: mental, emotional, physical and spiritual
Building strong relationships (and networks): literally with everyone you meet
Walking the talk: if you believe in something, be the first one to demonstrate it
Building (often workshopping) a shared vision, measurable goals and an agreed set of values or principles

6. From Authority to Influence

“Influencing without authority” can be a tough pill to swallow, but it is the most effective tool in a PM’s toolbox when mastered. A big part of your job is convincing people that what you’re asking of them is worth their time and effort. Some tricks I’ve learned:

Use data: Use it yourself, coach others in using it and make it standard practice in your team for any idea or argument — presented by anyone — to be backed up by data and/or metrics
Validate everything: “Trust, but verify.”
Read Crucial Conversations[5]. Twice.
Set realistic expectations. That doesn’t necessarily mean being less ambitious, rather being candid about risks.
Get good at building consensus, negotiating deals and forging alliances. I’ve resolved many a crisis by calling up a fellow PM and essentially bartering support (i.e. “I’m in a soup; if you can give me X now and I can help you out with Y later”).
Use people’s strengths instead of fighting their weaknesses: For example, technical folks can especially be opinionated and idealistic. The PM’s job is not to change the way people think but to make everyone believe in the same thing. Once you are able to get your point across, you will have the strength of all of that technical passion behind your mission. There’s a subtle but powerful difference, and it requires the use of models like Situational Leadership[6] to adapt your communication style constantly.
Finally, don’t fall into the trap of getting influenced by authority yourself 🙂. Sometimes you will have to stand your ground against all odds, so make sure you have 100% conviction (refer to all the points above). Often a difficult conversation like this is an opportunity to coach up.

7. From the Team to the Customer (and Back)

Your reputation precedes you. As an Engineering Manager, I had become known for fighting for my team (In fact, I became a Manager because I was fighting for my team so much 😁). But as a PM, you have to balance the customer’s needs and the business’ aspirations against the team’s needs, such as fulfilling work, the best tools, career progression & hearing their feature/product ideas. Especially in your early days, be prepared to doubt yourself a lot.

Three things that can help you with your team:

Keep your eyes on the big picture: As PM, you instantly get exposed to a much bigger context. Instead of feeling overwhelmed by it, use it to your advantage. Abstract, translate and share it in all of your conversations with the team.
The relationships you built earlier: Because you are already known as an effective leader, the people you’ve worked with will not change their opinion of you overnight. Take them along for the journey, show them what you see now and reason with them about decisions & tradeoffs going forward.
Listening doesn’t mean committing: Often, creative people just need to be heard in order to feel engaged. Every idea should be heard — that is literally the definition of “thinking out of the box”. But not every idea needs to be committed to. And you should be able to have these conversations with your team. Hint: Use a voting system to bubble up the best ideas to the top.

On the other hand, when you are speaking as the voice of the customer:

Your goal is to find the cheapest and fastest way to make the highest number of customers happy
Most ideas don’t really need to get built: if there isn’t already a solution out there, you have to be solving a very specific problem in a very unique way. And even then, you can often experiment with integrating/mocking a “close enough” solution before committing resources to build it yourself.
Product demos, feedback and constant communication are non-negotiable job responsibilities
Not all customers are equal, and just like with the team, not every piece of feedback needs to be committed to

Think of it more as a balancing act than juggling.

8. From Managing to Coaching

Even though now you’re managing the product and not the team, don’t stop having your one-on-ones with them. People who work on product development daily are still the best source of ideas, challenges and insights. However, my biggest mistake was staying involved in passionate and heated technical debates. It wasn’t until our Scrum Master pointed out to me that I might be influencing the team’s decisions that I realized this. The same applies to UX, QA, Program Management, Marketing and other disciplines you’ll work with. Your job is not to be the best at any of them, but to bring out the best in people who are already good at what they do.

So my advice to the new PM here is:

Get out of the weeds, lean on experts such as Technical Leads
Use the Scrum Master to keep yourself honest

By all means, you can bring your experience and intuition to the table, as should any member of the team, but don’t drop any of the things you’re primarily accountable for. And one of the most important is to build a healthy (and humble) culture of product thinking in the team.

9. From Many to One

Conflict is not always overt. Sometimes, people remain silent even if they are not in agreement. Some of the concepts I swear by:

Single Source of Truth: Maintaining a relevant, prioritized, refined Product Backlog — with useful metadata such as tags, components and links — takes a lot of time and energy, a lot of late nights and early mornings. But trust me, every other alternative will cost you more in the long run.
Management by Powerpoint: Putting it on a slide doesn’t make it true. As much as possible, try to use some of the fantastic tools out there to roll up data from JIRA into actionable insights. Sometimes this means being able to provide different views of the same data to different audiences.
Meaningful Meetings: This is a massive topic in itself, so I won’t go into it here. But the productivity multiplier here is to document meeting highlights, key decisions and action items. Meetric changed my life (as did OneNote before it) and I’m currently experimenting with AI assistants such as Sonero.ai which I’m convinced are the future.

10. From the World to You

Finally, don’t forget about the most important person in this conversation: You.

Ensure you’re getting frequent feedback from the people you’re working with
Ensure you clearly understand how your success is measured. This was a challenge for me because initially, I felt like I was expected to do everything.
Balance the amount of time you spend on product discovery vs product delivery
Establish clear Rules of Engagement with others (e.g. what’s acceptable and what’s not) and revisit/adjust them as needed[7]
Timebox everything
Have checks and balances in place to ensure that you don’t feel overwhelmed or start burning out
Use your two superpowers: Saying No and Delegating

I hope you find this worth your time. Please follow The Product Leadership Journal if you did. If you have any questions, thoughts or comments, please leave them below or hit me up on Twitter or LinkedIn. And remember, there is an amazing, loving, supportive community of Product Managers out there who are always happy to help, learn and grow together: r/ProductManagement, ProductSchool and MindTheProduct to name a few.