A recent post about a week-long fire drill, and how the Dude’s teammates got their shit together (or didn’t) caused the Dude to consider writing a series on the personas of various product managers, and how they approach the position.
The Dude is a grizzled veteran, who has worked closely with probably 50 different product managers throughout his career, and – naturally – has thoughts about how to categorize them into buckets. By no means will the Dude be able to articulate the entire spectrum of product managers, but he can do some sketching.
First up, the starry-eyed engineer
The Starry Eyed Engineer
This is the persona of an engineer who wishes to or has transitioned into a product management role. How they decided to make the shift is irrelevant, but the fact that they bridged the chasm is. That said, more and more product managers are rising from the engineering ranks.
Partly driven by programs at the major tech companies (Google and Facebook in particular) that are focused on product managers with serious engineering chops, and that can’t find what they want when they do an open market search for product managers.
Regardless, a product manager who spent time as an engineer will have some specific traits:
- They are detail oriented. They can focus on perfection, and will put in an amazing effort to get “it” just right, whether that is a gate review deck, a product proposal, or a presentation to sales/customers/conference attendees. As such, they struggle to step back and look at the big picture, constantly refining their work until it is just right.
- They side with technology over business. Their background and education are weighted to solving technical problems. Give them the lay, the constraints, and they will noodle possible solutions, even before putting pen to paper. But to effectively manage one of these product managers, their leader will need to pull them back, walk them off the brink, get them out of the tool chain. When the Dude wrote the linked post above, he had never seen a successful engineer->product manager transition. He has now, and he works with one, and he strategizes with his boss to pull this individual back from the weeds. It doesn’t always work, and next week is a whole new exercise. But, this product manager does great work.
- Data Driven. They have this in spades. They are great at slicing and dicing metrics, looking for ways to embed, collect, and analyze analytics to get to insight. Sure, product managers that come from a marketing background are analytical as well, but they tend to view the product as a black box, and nibble at the edges. A former engineer is curious, and willing to go very deep. This can be a curse, because it leads to the next trait…
- Paralysis by Analysis. Engineers want absolutes. They want to have no (or very little) uncertainty. That means that long past “good enough” they will continue to research and refine their proposals, products, and put off making a decision until the probability of there being an error is so low that it is less likely than Jessica Alba showing up at the Dude’s house for a weekend fling. This is one of the attributes that frustrates the Dude with these engineers turned product people. They just can’t make a decision. As a product leader over one of these product managers, a major responsibility you have is to break through this, and force the decision. Do not let the perfect be the enemy of the good.
- Soft on business knowledge. Most (not all) engineering programs in universities have little focus on the business of innovation, and bringing a product to market. Notable exceptions are out there, schools like Stanford, ASU, and the like have a lot of support for engineers to give them the skills needed to build a business. But the reality is that most engineers are coming from hard engineering programs, and gaining that vision and aptitude to build a business is not core to their education. Most product managers that the Dude has worked with that went to a strong engineering program without the entrepreneurial cant augment that with an MBA. It doesn’t need to be a high dollar Biz School (HBS, Wharton, Sloan) as they aren’t necessarily looking for the “network” but instead the business acumen. How to read a balance sheet. Do an NPV/IRR analysis. Calculate free cash flow. In reality, one of those $30K three week “Executive MBA” programs is fine. Engineers know mathematics, and can pick up the accounting savvy they will need, but some of the basic business metrics is handy to not have to reverse engineer.
How to be successful as a Engineer -> Product Manager
First, you can do the job. Just recognize that your world is going to be very different. Before you make this transition, you ought to seek out some product managers, hopefully in the same industry you are in, or close to it, and preferably outside your current company. The life is different, your job role will be very different, and instead of fiddling with technology, tool chains, and stacks, you will be more likely to interface with marketing, sales, leadership, all from a position where you have influence, but not direct power.
Second, regardless of how much you want to roll up your sleeves, and help with the solution, you mustn’t. You are no longer responsible for daily builds, pull requests, check-ins, and code reviews. Sure, your knowledge of these things will help with your interactions with the development team, but your value to the organization is no longer in the code you write, but instead it is the framing of the problem. You have made the first step from “solution space” into “problem space”. If you fail at this first step, you really should return to engineering.
Third, find some mentors. If you are in a large enough of a company, there are probably several seasoned product managers. Reach out to them, ask for guidance. Buy them coffee and chat. Ask about their backgrounds, their path to product, and what their days are like. Twitter is a good place to find some thought leaders, search on the hashtag #prodmgmt and read. As a product manager a large part of your time should be spent on free ranging and undirected research. Spend some of that time on yourself. As an engineer you probably that that was a waste of time.
Fourth, learn to ask for help. Truth is product management is a loosely defined role in many (most) organizations. It has responsibilities that shift depending on maturity of the organization, and having frank discussions that feel uncomfortable with your leadership is important to learning. Learn to embrace criticisms. Behaviors that got you high rankings as an engineer will be frowned upon in product management. Getting a perfect gate review counts the same as barely clearing the bar.
Fifth, triage. No other way to describe it, but the first thing you will encounter is the deluge of demands. Your first email of the day may lead to an escalation, and a shit storm that derails everything else you have done. Or, as an engineer, you might have received a handful of emails a day that you needed to read and respond to. Not so in product management. Biz Dev, Sales, Marketing, support, operations, finance, and others in the org will come to you from all angles demanding your response, and it can be overwhelming. Figure out how to quickly prioritize, and to handle the multiple inflows. If you don’t, you will fail. Note: The Dude has tried all the “Getting Things Done” variants, and none of them work in his world. Try if you must, but a “system” that works for others seems to fold in on itself in the reality of product management.
Summary
As opposed to the Dude’s earlier writing, it is becoming more common for engineers to make it into product management and thrive. It is not easy, comfortable, or a sure thing. But it can be far more rewarding than the other path into engineering management.
If you make the transition, you will have to consciously work on not falling back into your comfort zone. You are no longer an engineer, responsible for part of a product. You are responsible for all of it.
