Moving From Engineering To Product Management
In the last article I talked about the role of architects and engineers in the product discovery process. I explained that great products come from the collaboration of the product manager, user experience designer and architect/engineer.
I often get approached by current engineers asking what’s involved in moving to product management.
Sometimes this happens when the engineer gets to truly participate in the discovery process, and he gets a taste of actually influencing what the product is and not just helping to build it. And sometimes this desire to move to product management comes from the frustration of realizing that it doesn’t matter how good the engineering team is if they’re not given something worthwhile to build.
In any case, many of the very best product managers I have ever known have come from engineering, and in this article I’d like to call out what I’ve found to be the main challenges for engineers as they make this move.
Realize that engineers have a big advantage in that they generally have a deep understanding of what’s just now possible. If they can now combine this with a deep knowledge of the user, and develop some new skills, you’ve got the makings of a great product manager and great products can result.
First, and most important, you have to realize that you are nothing like your target user. If you spend the time you need to with real users you’ll
quickly learn this, but you need to disabuse yourself of any notion that if you like the product and can figure out how to use it, then your users will like the product and figure out how to use it.
Second, and related to the above, you need to develop an empathy for your end-users and customers. You need to realize that they’re not clueless, but that they have their own jobs and own areas of expertise, and they are as busy as you are but with their own lives, which are typically very different from yours. The easiest way to achieve this is to spend actual face time with your users and customers. Note that this doesn’t mean that they have any idea what they want from your product or what the real product requirements are; it’s your job to figure that out.
Third, there is an important mind-set change that needs to happen. In an engineering organization, especially if you’re a lead or manager of engineers, you are always working hard to optimize your developer’s productivity. This is important, but as product manager you must now realize that your job is not to optimize the developer’s productivity, but rather to optimize the end-user experience. It is no longer about coming up with the fastest way to build something, but rather coming up with a product and user experience that users actually value and can figure out how to use. While this might sound easy, I promise you that when you’re faced with hard decisions and time versus user experience trade-offs, you’ll have to fight your natural tendency hard.
Fourth, you’ll need to develop a humility that comes from showing your ideas to users and customers and finding that in many cases users don’t respond the way you hope. But you will learn that if you listen and watch closely, you’ll improve your understanding and if you keep trying, you’ll likely get better fast. But this only happens if you’re open to learning and can handle the rejection.
Fifth, there is a culture among engineers that values active debate and sometimes loud and passionate arguments, but in many cases the decisions are
fairly clear as one solution is objectively better – runs faster, scales better, more fault tolerant, more extensible, etc. The point is that technical decisions often have a clarity and closure about them that doesn’t always exist in decisions around product definition and user experience. You may find that you need to modify your style of persuasion and argument, and work harder to build support for your opinions and decisions.
Finally, your relationship with your old engineering team can be a difficult one. They may soon come to challenge you in ways they may not have before. They will doubt your ability to stay on top of the technology, and they’ll be sensitive to you speaking for them or especially committing to things on their behalf. You will need to learn to bite your tongue and let the engineering team do their job and participate with you in discovery. But you should have enough to worry about with the overall product responsibility that you shouldn’t mind letting go of the technical decisions.
I strongly encourage companies to facilitate this type of career move. You can often end up with some truly outstanding product managers. At the least, even if the engineer decides to go back to engineering, he’ll have gained a level of customer insight that will help him do his job even better.
A special thanks to Steve McClelland for his insights into this transition. Steve is a terrific example of a talented and valuable architect becoming an even more valuable product manager.