

Discover more from Behind Product Lines
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.