What Engineers-turned-PMs struggle with

+ Advice on how to tackle those challenges

Engineers that turn towards Product Management certainly have a few advantages.

Their technical know-how helps them as:

• they are able to actively participate in dev-heavy meetings.

• they can quickly assess idea feasibility without always having to “circle back” from the tech team.

• they understand what tech debt means & make way for it.

• their knowledge of the underlying architecture helps them design practical solutions.

For these reasons and more, several product-based organizations still prefer candidates that have a technical background. However, that doesn’t mean the transition for engineers to the product role is easy.

My developer friends often tell me 5 things they struggle with after they take on the PM hat:

1. 𝗡𝗮𝘃𝗶𝗴𝗮𝘁𝗶𝗻𝗴 𝗮𝗺𝗯𝗶𝗴𝘂𝗶𝘁𝘆

As engineers, they are used to tackling uncertainty in the solution space when they are out exploring an apt approach to solve a problem.

However, identifying what problem to solve in the first place can be disconcerting for them. When there are so many problems to solve & all need attention, selecting the right one for the time & selecting a defined scope that will lead to maximal impact is a tricky proposition.

Advice:

Uncertainty is uncomfortable & there are no right or wrong answers, so it’s ok to feel that way. Get better at asking a lot of relevant, meaningful questions. Try to find answers to these questions in customers, stakeholders, domain experts, primary research & product data.

Also, sometimes you won't have the answers. It’ll happen. Make an educated guess, test & iterate. Keep falling forward.

𝟮. 𝗪𝗿𝗶𝘁𝗶𝗻𝗴 𝗹𝗼𝗻𝗴-𝗳𝗼𝗿𝗺 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻.

Verbose emails, specs & PRDs can be taxing. for them. The don’t like spending hours on a document, especially one that keeps changing as they collaborate or find something new. It's a stark departure from writing code which usually is more concise, testable & can be put into action.

Advice:

Writing can be as rewarding as code. If you think about it, code is just a structured expression of what you want a system to do. Similarly, specs are an open canvas for you to instruct a team on what to do (along with “the why").

Moreover, there is no single way to develop specs. Review how other people go about specs & communication. Tailor it to something that suits you and the team. Experiment! And remember: more isn't necessarily better.

𝟯. Dealing with 𝗗𝗶𝘀𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻𝘀

Product management rarely affords them space to think “deep”. They get pulled into too many meetings & often get Slack pings as soon as their train of thought gains momentum. They tell me how they miss the times when they could pop in some earphones & go into code nirvana.

Advice:

As a Product Manager, you'll have to learn to protect your time by pushing back. When people need you to respond to something or invite you to a meeting, qualify the need. Why is it needed? Do they already have access to the data? Is it urgent? Can it be delegated? And are you the best person to solve this?

Know that, as a PM, while you are required to orchestrate the show, that doesn’t mean your time is owned by others. Feel free to delegate, postpone or cancel if you need to (but do it with a valid reason).

𝟰. Holding back on getting involved in tech.

Engineers also find it’s too tempting to not get into the implementation specifics, especially when drafting a spec or JIRA ticket. They find their specs often turn into a functional specification doc that carry implementation details (to a database level). Moreover, they find themselves gravitating to technical discussions with the engineering team & actively debate solution approahces.

Advice:

If you're aware of the codebase & underlying architecture, leaving implementation tips on a spec is acceptable. Your point of view can be valuable. However, you need to try to refocus that energy by remembering that you’re the voice of the customer and the customer doesn't see your code. They just use what they get. You can remain suggestive by sharing your 2 cents, but avoid becoming prescriptive.

𝟱. There’s 𝗡𝗼 𝗦𝘁𝗮𝗰𝗸 𝗢𝘃𝗲𝗿𝗳𝗹𝗼𝘄.

This might seem like a humorous point but it alludes to the fact that there is a lack of "personalized" help in the discipline. There are very few mentors. PM books are great in general but remain fairly high-level. Online articles can be non-specific. Podcasts rarely discuss about implementation specifics of a product.

Advice:

Since every product is unique, you'll seldom have people facing the exact same issue you are. Thus, abstraction is key. Focus on patterns, not on specifics.

Also, seek help from PMs in your industry on LinkedIn. Join Slack Communities like Product School and Product Folks. Post your doubts on these Slack groups along with Quora & Reddit and you’ll be surprised how many people are willing to help.

Product can be pretty lonely within the confines of a company, but over the years, the PM support community has scaled up.

Final Word

If you’re an engineer that’s just started in product management, I'd advise you to give yourself time to ease in. PM follows a different pace than tech. The latter is all about execution while the former is about balance. It starts by understanding the customer & problem thoroughly before a line of code is written. Embrace the problem space and wander freely in it.

Engineers take pride on their problem-solving skills. A Product Manager additionally needs to be great at problem-seeking & sculpting.

Hang in there.