Mar 2008
Moving From Engineering To Product Management
03.27.08 Filed in: SVPG Blog
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.
Email to a friend
Sign up for the free newsletter here.
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.
Email to a friend
Sign up for the free newsletter here.
The Architect Role
03.17.08 Filed in: SVPG Blog
The job of the product manager is first and foremost to discover a product that is valuable, usable and feasible. You’re wasting the rest of your team’s time, and your company’s money, if you can’t do this. But this doesn’t mean that you have to discover this product yourself.
There are, in general, two other key roles besides yours. In other articles I have written about the critical role that a user experience designer (aka interaction designer) plays. In this article, I’d like to talk more about how and why you need to include the engineering organization in this discovery process.
First a terminology note. When I refer to “architect” in this article, I am referring to an engineering or systems architect. I’m not referring to an information architect (which is similar to an interaction designer and is part of the user experience team). Also, I use engineer and developer interchangeably.
There are actually two topics when discussing the architect role. The first is to discuss why and how to have architects participate in the discovery process. The second is to elaborate on this relatively new role within product development that has several benefits to the product organization.
Participating in Product Discovery
One of the most common mistakes that product managers make is to not include engineering early enough to make a difference. By the time engineering is often brought in, you are so far down a path that time is running out and there’s little that can be done. Sometimes this happens because the product manager believes it’s his job to define the product, and it’s engineering’s job to build it. Sometimes this happens because engineering is so busy building that they can’t free up any resources to participate earlier.
There are really two main reasons you need strong representation and active participation by the engineering organization during the product discovery process:
- First, the engineers and architects know best what is possible. They can help identify new solutions to user’s problems. They can contribute ideas, evaluate ideas, and improve on ideas. They are an absolutely essential ingredient to the product discovery process.
- Second, the engineers and architects can evaluate the cost and complexity of the different ideas and features. They can review prototypes, and help flesh out what is involved with each idea. It is essential that these time and cost estimates are provided early, during the discovery process, as this is key information for the product manager to decide whether or not a feature or capability is worth including in the resulting product definition.
The idea is to avoid the common problem where the product manager comes up with a great product, and then hands it off to engineering where they estimate the cost, and of course it turns out to be far too long to build, so the horse trading begins when it is too late to come up with good alternatives and test them with users; and more generally the problem of the product manager coming up with great ideas that are simply not feasible.
In terms of the engineering time required for this participation during product discovery, I typically tell engineering and architects that they need to plan for a few hours a week to review the latest ideas and prototypes and provide the necessary feedback. As product ideas progress, they’ll be asked to give more than just preliminary advice on cost and scoping, and at that point they’ll need to dig in more and provide estimates that the team can count on as they make the critical trade-offs.
The Architect Role in Product Development
As products and teams get larger, especially for large consumer internet sites or consumer electronics devices, the product development organization needs people that have a holistic view of the complete product. These people know not just one or two areas, but they are responsible for knowing, at least at a high level, how the whole product works including architecture, site operations considerations (including scale, performance, and provisioning) and topics such as test automation and release management. Increasingly I am seeing companies establish a centralized architecture team to develop these people, and I think this is an important trend, for several reasons:
- The architecture of large systems needs constant attention to ensure the system can continue to meet the needs of the business. This includes worrying about site availability, scalability, performance, maintainability and internationalization, as a few examples. The architecture team is always looking for bottlenecks and inefficiencies in the system, and they typically provide prioritization, guidance and assistance on the different areas needing attention.
- The architecture organization is an additional contributor to the overall Portfolio Roadmap. They are the owner of Technology Sponsored Initiatives, and often will debate with other parts of the business for precious engineering resources. The architecture and systems engineering activities need to be prioritized against other business initiatives, as it's not always sufficient to use the small, dedicated group of system engineers and architects to do everything that must be done.
- It is important that your top engineers not feel that they have to move into management to progress in their career financially or professionally. The dual track serves this need well, and the architects are typically the top of the engineering ladder as an architect job is valued by the organization at all levels.
- The truth is that most product engineering teams today don’t maintain internal system documentation. They may have something written down but it’s probably old and nobody trusts that it’s accurate. So when new engineers start, they generally learn by talking to other engineers. The architects represent the institutional knowledge (living documentation) of the system, and they are responsible for helping new engineers learn the architecture and code base.
- One common and effective technique to ensure new work is compatible with the overall architecture is for the architects to attend all of the code and design reviews. This also helps the architects stay current, but the primary benefit is to detect and prevent problems in the code and architecture.
- The architects also are resources to help evaluate 3rd party integrations and participate in M&A due diligence.
If you organization is small, your architect will likely just be one of the senior developers. But as your organization grows, a designated architecture team can make a big difference. As a general rule, architecture teams generally represent roughly 5 percent of the engineering organization. Ideally, there is also someone from site operations on the architecture team, especially as companies come to appreciate how difficult the site operations considerations can often be when it comes to keeping a large and complex site up and running.
Whether you promote your architects from among your senior engineers, or whether you hire architects from the outside, it’s important that the architects have the trust and respect of the engineering team. The architect is in an important sense representing the engineering team, and when they say something is feasible the team needs to know that was an informed statement.
As a product manager embarking on a new project, your first task is typically to identify the user experience designer and the engineer or architect that you’ll be able to work closely with throughout the product discovery process so that you can work together to identify a product that is valuable, usable and feasible.
If you’ve never had a chance to collaborate like this on the creation of a product spec, I promise you that you will much prefer this process to the old model of writing PRD’s and asking engineering to review and provide a schedule. You’ll also very likely see a dramatic improvement in the quality of the products you come up with.
Email to a friend
Sign up for the free newsletter here.
There are, in general, two other key roles besides yours. In other articles I have written about the critical role that a user experience designer (aka interaction designer) plays. In this article, I’d like to talk more about how and why you need to include the engineering organization in this discovery process.
First a terminology note. When I refer to “architect” in this article, I am referring to an engineering or systems architect. I’m not referring to an information architect (which is similar to an interaction designer and is part of the user experience team). Also, I use engineer and developer interchangeably.
There are actually two topics when discussing the architect role. The first is to discuss why and how to have architects participate in the discovery process. The second is to elaborate on this relatively new role within product development that has several benefits to the product organization.
Participating in Product Discovery
One of the most common mistakes that product managers make is to not include engineering early enough to make a difference. By the time engineering is often brought in, you are so far down a path that time is running out and there’s little that can be done. Sometimes this happens because the product manager believes it’s his job to define the product, and it’s engineering’s job to build it. Sometimes this happens because engineering is so busy building that they can’t free up any resources to participate earlier.
There are really two main reasons you need strong representation and active participation by the engineering organization during the product discovery process:
- First, the engineers and architects know best what is possible. They can help identify new solutions to user’s problems. They can contribute ideas, evaluate ideas, and improve on ideas. They are an absolutely essential ingredient to the product discovery process.
- Second, the engineers and architects can evaluate the cost and complexity of the different ideas and features. They can review prototypes, and help flesh out what is involved with each idea. It is essential that these time and cost estimates are provided early, during the discovery process, as this is key information for the product manager to decide whether or not a feature or capability is worth including in the resulting product definition.
The idea is to avoid the common problem where the product manager comes up with a great product, and then hands it off to engineering where they estimate the cost, and of course it turns out to be far too long to build, so the horse trading begins when it is too late to come up with good alternatives and test them with users; and more generally the problem of the product manager coming up with great ideas that are simply not feasible.
In terms of the engineering time required for this participation during product discovery, I typically tell engineering and architects that they need to plan for a few hours a week to review the latest ideas and prototypes and provide the necessary feedback. As product ideas progress, they’ll be asked to give more than just preliminary advice on cost and scoping, and at that point they’ll need to dig in more and provide estimates that the team can count on as they make the critical trade-offs.
The Architect Role in Product Development
As products and teams get larger, especially for large consumer internet sites or consumer electronics devices, the product development organization needs people that have a holistic view of the complete product. These people know not just one or two areas, but they are responsible for knowing, at least at a high level, how the whole product works including architecture, site operations considerations (including scale, performance, and provisioning) and topics such as test automation and release management. Increasingly I am seeing companies establish a centralized architecture team to develop these people, and I think this is an important trend, for several reasons:
- The architecture of large systems needs constant attention to ensure the system can continue to meet the needs of the business. This includes worrying about site availability, scalability, performance, maintainability and internationalization, as a few examples. The architecture team is always looking for bottlenecks and inefficiencies in the system, and they typically provide prioritization, guidance and assistance on the different areas needing attention.
- The architecture organization is an additional contributor to the overall Portfolio Roadmap. They are the owner of Technology Sponsored Initiatives, and often will debate with other parts of the business for precious engineering resources. The architecture and systems engineering activities need to be prioritized against other business initiatives, as it's not always sufficient to use the small, dedicated group of system engineers and architects to do everything that must be done.
- It is important that your top engineers not feel that they have to move into management to progress in their career financially or professionally. The dual track serves this need well, and the architects are typically the top of the engineering ladder as an architect job is valued by the organization at all levels.
- The truth is that most product engineering teams today don’t maintain internal system documentation. They may have something written down but it’s probably old and nobody trusts that it’s accurate. So when new engineers start, they generally learn by talking to other engineers. The architects represent the institutional knowledge (living documentation) of the system, and they are responsible for helping new engineers learn the architecture and code base.
- One common and effective technique to ensure new work is compatible with the overall architecture is for the architects to attend all of the code and design reviews. This also helps the architects stay current, but the primary benefit is to detect and prevent problems in the code and architecture.
- The architects also are resources to help evaluate 3rd party integrations and participate in M&A due diligence.
If you organization is small, your architect will likely just be one of the senior developers. But as your organization grows, a designated architecture team can make a big difference. As a general rule, architecture teams generally represent roughly 5 percent of the engineering organization. Ideally, there is also someone from site operations on the architecture team, especially as companies come to appreciate how difficult the site operations considerations can often be when it comes to keeping a large and complex site up and running.
Whether you promote your architects from among your senior engineers, or whether you hire architects from the outside, it’s important that the architects have the trust and respect of the engineering team. The architect is in an important sense representing the engineering team, and when they say something is feasible the team needs to know that was an informed statement.
As a product manager embarking on a new project, your first task is typically to identify the user experience designer and the engineer or architect that you’ll be able to work closely with throughout the product discovery process so that you can work together to identify a product that is valuable, usable and feasible.
If you’ve never had a chance to collaborate like this on the creation of a product spec, I promise you that you will much prefer this process to the old model of writing PRD’s and asking engineering to review and provide a schedule. You’ll also very likely see a dramatic improvement in the quality of the products you come up with.
Email to a friend
Sign up for the free newsletter here.
What Product Management Is Not
03.07.08 Filed in: SVPG Blog
I find that many companies remain stuck in old, failed models of product management, and don’t always realize how important role definition is to building effective teams and successful products.
In several articles I’ve tried to explain what the role of the product manager is really all about, but in this article, I’d like to come at this from another angle and try to emphasize what the job is NOT. I’m hoping that calling out these misunderstandings will help companies realize where they have issues and hopefully revisit how they are defining this role.
- Product Management is not defining the business case
Some product managers believe their job is simply to define the business case for why this product should be built. Is the business case important?
Of course. Mainly because management will use this to make decisions on where to invest. But this doesn’t really do anything to contribute to actually creating the product. In many organizations the product manager does put the business case together, or at least contributes to creating the case, and this is fine, but don’t confuse this with the product management job.
- Product Management is not defining market requirements
For many companies, they think the product manager defines the market requirements and the engineers build a product to meet those market needs. The product manager creates an MRD (Market Requirements Document) that enumerates what the product manager thinks the market is looking for, and then actually defining the product that meets these requirements is an exercise left to the reader (which is typically an engineer). There are really two issues here.
The first is the fallacy of so-called “market requirements.” Markets don’t have requirements. People do. And the person that’s actually going to be defining this product has got to talk to these people directly. If the engineer is the one defining the product, then that person is the true product manager and you can only hope he understands that as the product manager he needs direct face-time with actual users and customers.
The second issue is the fallacy of market requirements separate from product requirements. The whole idea is to discover a product-market fit and this requires a deep understanding of both the market needs and the technology’s capabilities. It is during the discovery process that you identify true market requirements and technical solutions that successfully address these requirements.
- Product Management is not requirements gathering
Many companies, especially those with a direct sales organization, have the model where the job of the product manager is to gather up the requirements from the customers or prospective customers, document them for engineering, and then make sure those requirements are delivered by the dates the sales guys promised the customer.
This is not product management. This is project management for custom software solutions. True product companies know that customers have issues that need to be addressed, but they are not in a position to dictate the product requirements. In other words, you can’t make the mistake of confusing a customer requirement with a product requirement.
Be wary of anything that encourages this “requirements capture” or “requirements management” mentality. It is a very slippery slope and one of the surest paths to failed products.
- Product Management is not project management
In some companies, the product management group was borne out of the project/program management organization, especially when the company has an IT or custom software heritage. In this model, the product manager is considered the person to collect and document the requirements, and manage the project from conception to delivery. But the discovery process is not simply a task in a project plan. It is its own process, which is very different than the product development process. Moreover, rarely do you find individuals that like both product management (discovery) and project
management (delivery) as the nature of each type of person is so different.
- Product Management is not product marketing
Finally, product management is not about pricing, promotions, positioning and messaging, or product launch activities. Nor is it about online marketing and customer acquisition strategies or influencer marketing programs. These are all critically important activities, and the product manager will provide input to many of these activities, but don’t confuse them with product management. These are product marketing activities, and for all but the smallest products, you are going to need a skilled marketing person dedicated to this. While the company might be tempted to ask the product manager to cover these responsibilities as well, realize that the nature of these marketing-based activities is dramatically different than the discovery-based activities, and it’s very hard to find people that are skilled at both.
In contrast to the above, the product manager is responsible for discovering a product that is useful, usable and feasible. If he can do this, he’s done his job. If he can’t, there’s no point in spending the time and money to build and launch the product.
If your company makes any of the mistakes above, pass this note on to your management. Ask if perhaps you could try adjusting the role on your next product to see what happens. I think you’ll find that if you can focus on discovery, you’ll get a chance to show your company what product management is really all about.
Email to a friend
Sign up for the free newsletter here.
In several articles I’ve tried to explain what the role of the product manager is really all about, but in this article, I’d like to come at this from another angle and try to emphasize what the job is NOT. I’m hoping that calling out these misunderstandings will help companies realize where they have issues and hopefully revisit how they are defining this role.
- Product Management is not defining the business case
Some product managers believe their job is simply to define the business case for why this product should be built. Is the business case important?
Of course. Mainly because management will use this to make decisions on where to invest. But this doesn’t really do anything to contribute to actually creating the product. In many organizations the product manager does put the business case together, or at least contributes to creating the case, and this is fine, but don’t confuse this with the product management job.
- Product Management is not defining market requirements
For many companies, they think the product manager defines the market requirements and the engineers build a product to meet those market needs. The product manager creates an MRD (Market Requirements Document) that enumerates what the product manager thinks the market is looking for, and then actually defining the product that meets these requirements is an exercise left to the reader (which is typically an engineer). There are really two issues here.
The first is the fallacy of so-called “market requirements.” Markets don’t have requirements. People do. And the person that’s actually going to be defining this product has got to talk to these people directly. If the engineer is the one defining the product, then that person is the true product manager and you can only hope he understands that as the product manager he needs direct face-time with actual users and customers.
The second issue is the fallacy of market requirements separate from product requirements. The whole idea is to discover a product-market fit and this requires a deep understanding of both the market needs and the technology’s capabilities. It is during the discovery process that you identify true market requirements and technical solutions that successfully address these requirements.
- Product Management is not requirements gathering
Many companies, especially those with a direct sales organization, have the model where the job of the product manager is to gather up the requirements from the customers or prospective customers, document them for engineering, and then make sure those requirements are delivered by the dates the sales guys promised the customer.
This is not product management. This is project management for custom software solutions. True product companies know that customers have issues that need to be addressed, but they are not in a position to dictate the product requirements. In other words, you can’t make the mistake of confusing a customer requirement with a product requirement.
Be wary of anything that encourages this “requirements capture” or “requirements management” mentality. It is a very slippery slope and one of the surest paths to failed products.
- Product Management is not project management
In some companies, the product management group was borne out of the project/program management organization, especially when the company has an IT or custom software heritage. In this model, the product manager is considered the person to collect and document the requirements, and manage the project from conception to delivery. But the discovery process is not simply a task in a project plan. It is its own process, which is very different than the product development process. Moreover, rarely do you find individuals that like both product management (discovery) and project
management (delivery) as the nature of each type of person is so different.
- Product Management is not product marketing
Finally, product management is not about pricing, promotions, positioning and messaging, or product launch activities. Nor is it about online marketing and customer acquisition strategies or influencer marketing programs. These are all critically important activities, and the product manager will provide input to many of these activities, but don’t confuse them with product management. These are product marketing activities, and for all but the smallest products, you are going to need a skilled marketing person dedicated to this. While the company might be tempted to ask the product manager to cover these responsibilities as well, realize that the nature of these marketing-based activities is dramatically different than the discovery-based activities, and it’s very hard to find people that are skilled at both.
In contrast to the above, the product manager is responsible for discovering a product that is useful, usable and feasible. If he can do this, he’s done his job. If he can’t, there’s no point in spending the time and money to build and launch the product.
If your company makes any of the mistakes above, pass this note on to your management. Ask if perhaps you could try adjusting the role on your next product to see what happens. I think you’ll find that if you can focus on discovery, you’ll get a chance to show your company what product management is really all about.
Email to a friend
Sign up for the free newsletter here.