Main takeaways:
- Insight and Experiences
- On deciding and navigating the transition
- Differences in mindset, skillset, and the nature of work
- How (and when) engineering thinking can be beneficial to Product Managers
7. Key topics
1. Guideposts
○ ..for plotting a path towards a product role
2. Advantages and hurdles
○ ..for PM’s coming from engineering to be aware of
3. Reflections
○ ..on differences in the nature of the work and responsibilities
8. Who this talk is for
1. Engineers
○ ..considering or actively moving into Product Management
2. Product and Engineering Managers
○ ...with engineers on their teams who are interested in making the transition
3. Other roles
○ ..that are looking to make a lateral career move into product
Anyone interested in an engineer’s perspective on product management.
9. A little about me
● Digital art and graphic design in high school led me to web development
and software engineering
● Studied C.S and Economics at a liberal arts college
● Considered the PM route as a new grad. Ultimately chose to start in
engineering
● Built and launched B2B products as a full-stack engineer and tech lead
● Transitioned into PM while taking a product from zero to one
10. If you’re an engineer and think you might want to be a PM, first...
12. ● Technical partner in the product development process
● Execute on engineering with pragmatic focus on business impact and ROI
● Deep knowledge of the product and genuine user empathy
● Strong communication skills and cross-functional collaboration ability
The Product Engineer
13. ● Intuition on what makes a product great that can inform decision making
● Start by understanding the goals of your product, business, and users
● Think critically about every feature you build - don’t be a “code monkey”
○ Analyze how features solve specific problems for the user
○ Explore and evaluate other options
● Constantly be asking questions, especially “why”
○ Don’t be satisfied with just the “how” and the “what”
○ Exercise: Whenever you realize “that’s a product question”, go through the exercise of
answering it yourself first
● Study the results and impact of what you build
○ How do users react? What caused confusion? What drove business impact?
Develop your product sense
14. ● Build user empathy - it will make you a better engineer and future PM
● Develop a genuine interest in the users your product serves
● Participate in any opportunities to learn about them
○ e.g User research
○ Answering and reading support tickets
● Use your own product! (if practical)
● Deeply understanding your product and users gives you a foundation
to build on top of
Know your users and your product domain
15. ● Understand where engineering fits in the product development lifecycle
● Reflect on your engagement with PM’s as an engineer
○ What as an engineer do you like/dislike and value in a PM?
○ What is the process and interaction between engineering and product?
○ How do PM’s inspire and motivate engineers?
● Strive to be a strong technical partner to product - learn what makes a good
relationship
Master eng <> product collaboration
16. Study and do your product homework
1. Research and learn about the work of a PM
○ Plenty of books, courses, online resources available
○ Specifically research: what would the PM role at your company look like
2. Talk to your PM and other PM’s in your company/industry
○ Learn through second-hand experience
3. Volunteer to help your current PM
○ Begin getting first-hand experience of what the role entails
17. Build relevant skills through your eng role
1. Leadership
○ Become accountable for more than your own work. Rally a team around an initiative.
2. Project management
○ Organize and manage tasks and milestones for projects with multiple stakeholders.
3. Cross-team alignment
○ Seek opportunities to collaborate with other teams (e.g platforms, cross-functions)
4. Written and oral communication
○ Produce technical docs and presentations
18. Find and develop in the right environment
● Look for companies/teams with growing products and expanding scope
○ Roles and opportunities grow with the business
○ Typically you’ll transition within the same company and team
○ Transitioning in-place lets you leverage existing domain knowledge and expertise
● Build a track record of competence and execution ability
○ Your role transition is a “risk” investment - show that you’re a good bet
○ Prove you’re able to “get stuff done”
○ Gain support and advocates from teammates that know your work
20. State your “why”
● Clearly state your reasons and goals for making this transition
● For yourself
○ Knowing your “why” will help push you through the challenge ahead
○ Documenting your thought process will be invaluable when reflecting down the line
● For others
○ Being able to clearly communicate your goals and motivations helps others in being able
to support you
21. Gather support and find the right opportunity
● Discuss with your manager, product lead, and supporting team
○ Your success in both transitioning and being a PM depends heavily on the support of those
around you
● Identify the right opportunities for you
○ Leverage your domain expertise and experience
○ Scope will likely be in proportion to the credibility you’ve built
● Clearly define the parameters and process
○ Projects and responsibilities you will take on and/or give up during the transition
○ Timeframe and objectives
22. Separate your engineer and product responsibilities
● Don’t be both the PM and engineer
responsible for building a project
○ You’ll be negotiating with yourself on scope
○ Being the “builder” introduces too strong of a bias
● Not representative of the actual role and
dynamic of PM
○ You won’t get an accurate sampling of the job
● If juggling both responsibilities, at least
separate role by project
23. On Mindset
● Step up, do the work, embrace the learning required
○ There’s no substitute for doing the work
● Be ready to put in the effort required to grow into this new role
● Any transition is going to be challenging - be prepared to not be good at
things, but willing to adapt quickly
○ Humility and beginner’s mind
25. Advantage: Technical “Perks”
1. “Technical” sense
○ Intuition on scope and technical feasibility of potential
projects/features
○ Ability to communicate technical concepts
2. Ability to answer your own questions
○ Get answers from data, check systems/tools/dashboards, debug
issues quicker
○ Keep your teammates working on their primary tasks
3. Efficiencies in automations
○ Ability to fill in gaps operationally to assist different roles/functions
without spending engineering resources
26. Advantage: Engineering respect and trust
● First-hand eng experience builds true empathy and trust
○ You understand technical debt, trade-offs, outages
● Ability to lead a well-aligned product and engineering machine
○ Ability to communicate and understand engineering trade-offs
○ Allows you to scope releases more flexibly, and move with a more agile team
● You should know how to unblock this function better than any other
○ You know what slows engineering down and can pre-empt it
■ Dependencies, unclear requirements, missing content or designs
27. 1. Technical pragmatism can limit your ability to think creatively
○ Great product/engineering development requires both side to push effectively
Hurdle: Your technical thinking can limit you
28. 2. Risk of over-emphasize engineering concerns and discounting other
important functions
29. Hurdle: Overly solutions focused
● The engineering instinct is to immediately go through solutions
● PM’s need to first make sure they’re solving the right and most
important problems
○ Remember: PROBLEMS over SOLUTIONS
30. Advantage: Systems thinking
1. Breaking down problems and managing
complexity
○ Identifying key components of a problem
○ ex: Actors and interactions, user flows, customer
segments
31. 2. Managing the system of you and your team’s ability to build the best product
32. Hurdle: Expanding your communication style
● In engineering, a majority of communication is with other engineers
○ Style is direct, practical, and assumes understanding of technical complexity
● Engineers turned PM’s need to learn how to communicate with each
function
○ Each function and role has their own culture and terminology
○ Requires ability to frame things in terms they understand
● Internal vs. external communication
○ Talking with customers and partners
○ Talking with your team, organization, and leadership
34. Nature of Work
1. Importance of organizational metaskills
○ Communication and decision making - email, calendar, docs, task management
2. Day-to-day work schedule
○ Learn to effectively run and select the right meetings
3. Actively engaged with many more threads
○ Eng are usually deeply focused on a few tasks; PM’s can be engaged on dozens at a time
○ Requires:
■ Ability to quickly get back to speed on a multiple projects
■ Deliberate prioritization and time-blocking of the most important work
35. Working with ambiguity
● Engineers work in a world of precision
○ Ex: Code runs deterministically, task estimates require accuracy
● Product managers have to think a lot more in unknowns and bets
○ You never know with certainty how users or the market will react, what risks are issues will
come up in development and integrations
● Requires a different decision making process
○ Make the best decision you can, with the information and time available
○ Learning to be comfortable with a degree of uncertainty is a key challenge for engineers
36. Relationships and communication
● Your ability to enact change is highly tied to the relationships
you build with your team and other functions
● Building these relationships requires you to see your
communications as part of your craft
○ Recording decisions to drive alignment
○ Establish who needs to be informed of what information when
37. You lead through assists, not points
1. You’re unblocking and aligning teammates to do their best work
2. You’re no longer an “expert”
○ Engineers code, designers design, sales sell..
○ Your job is to assist, support, and enable others toward a shared vision
3. If you’re an expert in anything, it’s understanding the customer, market, and
your team’s ability to serve it
38. Sources of satisfaction
● Engineering satisfaction is direct and tangible
○ E.g shipping a feature, finding a bug
● Satisfaction for PM’s is much less so
○ The results of your work are not as obviously and immediately felt
○ Find small wins - areas where you feel you’re moving the team forward
● Satisfaction for PM’s typically comes on a longer timescale
○ Seeing the impact your decisions and work have on users and the business
39. Tip: Record and reflect your journey
1. Write down milestones, decisions, lessons
○ Externalizing these will help in your learning and decision process
2. Write down and reflect on the activities and results that you resonate with
○ Reflect and figure out what you enjoy and what you find tedious
For myself - the experience and feeling of a team building momentum
40. Takeaways
● Develop product skills in your role as an engineer
● Build trust and a track record
● Find and develop in the right environment/team
● Understand the role and your own goals
● State your “why”
● Recognize your eng background will give unique advantages and hurdles
● Be ready to put in the work to learn, unlearn, and grow