What PMs Do
External: Voice of the customer
- Who: Paint a compelling picture of customers for the other teams. This can include user/buyer personas, workflows, pain points, etc., market segments, etc.).
- Why: Understand what would drive the business forward by meeting customers, looking at analytics, studying the competitive landscape, and identifying market gaps.
- What: Prioritize a customer backlog of features, enhancements using the above data.
Inbound: Get product shipped
- Work with engineering to define what goes into a release (e.g. features from the backlog, bug fixes, addressing tech debt).
- Work with design on UX workflows, mocks, and research.
- Work with technical writers on documentation, training, and release notes.
- Make the call on scope changes, cutting features or sub-features, and assisting other teams with customer impacts of their decisions.
Outbound: Translate for other teams
- Work with leadership and engineering to create a product roadmap that can be presented internally or externally as needed.
- Assist marketing in crafting value propositions, setting pricing/packaging for new features, and helping them create collateral (battle cards, competitive analyses, etc.)
- Assist sales and support with explaining new features and value propositions (and triaging issues)
- Provide support with insights on new features (and bracing for release issues).
The Four Core PM Skills
Empathy
This is the most important skill in PM. Empathy means getting in the shoes of someone else and understanding everything about them--their hopes, dreams, motivations, and fears. As the voice of the customer, PMs must develop deep empathy for users and buyers. In the world of enterprise this is especially important; it's not always easy for development teams to understand the workflows, knowledge, and pain points of a specific business persona. (this is especially critical with developer tools--it's a bad idea to assume that a developer at a customer has the same knowledge and context as a developer building your product). It’s also important to build empathy for internal teams--engineering, sales, marketing, support, etc. Spend time with each team, understand the workflows they do, and how you can best be of service.
Prioritization
PMs must have a well-structured process for how they prioritize features and craft product strategy. This includes gathering data, establishing decision-making criteria, clearly ranking priorities, and communicating the results. While every PM’s process is a bit different, they should be able to clearly explain their process and rationale to relevant stakeholders. In enterprise, prioritization can become more complex due to weighing customers/prospects of different sizes and needs, which can lead to conflicting requirements. More on prioritization principles below.
Collaboration
PMs don’t get anything done by themselves. With technical teams, PMs need to explain customer pain points, translate business value into product features, and help get the product shipped. With non-technical teams, PMs translate new features into value propositions and assist with outbound materials. Expect to do a lot of translation and interpretation, especially in enterprise companies which may have complex go-to-market motions and technical teams with varying levels of end-user knowledge.
Execution
When interviewing PMs, one of the first criteria a good hiring manager looks for is "can they get something shipped?" PMs must have a "get stuff done" mentality when it comes to getting product and features out the door. That means picking up any non-technical work that may have dropped through the cracks or is under-resourced by other teams (project management, documentation, release notes, pricing, blogs, collateral, etc.). “That’s not my job” is the wrong mentality for a PM, if they are the only ones available to do it.
How PMs Prioritize
Customer Needs
What will move the needle in making customers successful? Note this says customer needs, not wants. You've probably heard Henry Ford's famous quote: “If I had asked people what they wanted, they would have said faster horses.” It’s important to understand the intent behind an ask, draw out the pain points, and then build the best solution, which may not be exactly what customers asked for. It's also just as important to ask prospects who did NOT become customers what went wrong--particularly for a new product, you can learn a lot about product-market-fit (or lack thereof) from unsatisfied prospects.
Strategic Alignment
How well does this feature align with the overall goals of the company? How much does it drive the business forward, regardless of whether customers are asking for it? This could be directly driving revenue, bolstering the platform by complementing existing features and product lines, or supporting joint partnerships with other companies and ecosystem projects. Of special importance in enterprise is not falling into the trap of building your product for one customer (usually a large corporate entity waving a new deal or renewal contract in your face). The easiest way to do this is to have a clear set of strategic priorities (e.g. through OKRs or similar means) and clearly weigh whether any single customer's needs match those of the company in the longer term.
Nuts and Bolts
Most enterprise companies select a vendor based on the following priority order: 1) will it not break my environment, 2) will it integrate with my existing tooling and processes, and finally 3) does it provide a useful value proposition. Thus, "move fast and break stuff" doesn't work well here, particularly if your product is a critical piece of a customer's workflow or infrastructure. Once a new feature is built, it is usually necessary to expand capabilities, polish rough edges, or otherwise improve stability. This becomes increasingly more important as a product moves further down the maturity curve and thus more locked into customer environments and the overall ecosystem. Also, it's critical to leave room in your planning process for stability and tech debt. Your engineering team (and personal sanity in dealing with customer escalations) will thank you.
What will move the needle in making customers successful? Note this says customer needs, not wants. You've probably heard Henry Ford's famous quote: “If I had asked people what they wanted, they would have said faster horses.” It’s important to understand the intent behind an ask, draw out the pain points, and then build the best solution, which may not be exactly what customers asked for. It's also just as important to ask prospects who did NOT become customers what went wrong--particularly for a new product, you can learn a lot about product-market-fit (or lack thereof) from unsatisfied prospects.
Strategic Alignment
How well does this feature align with the overall goals of the company? How much does it drive the business forward, regardless of whether customers are asking for it? This could be directly driving revenue, bolstering the platform by complementing existing features and product lines, or supporting joint partnerships with other companies and ecosystem projects. Of special importance in enterprise is not falling into the trap of building your product for one customer (usually a large corporate entity waving a new deal or renewal contract in your face). The easiest way to do this is to have a clear set of strategic priorities (e.g. through OKRs or similar means) and clearly weigh whether any single customer's needs match those of the company in the longer term.
Nuts and Bolts
Most enterprise companies select a vendor based on the following priority order: 1) will it not break my environment, 2) will it integrate with my existing tooling and processes, and finally 3) does it provide a useful value proposition. Thus, "move fast and break stuff" doesn't work well here, particularly if your product is a critical piece of a customer's workflow or infrastructure. Once a new feature is built, it is usually necessary to expand capabilities, polish rough edges, or otherwise improve stability. This becomes increasingly more important as a product moves further down the maturity curve and thus more locked into customer environments and the overall ecosystem. Also, it's critical to leave room in your planning process for stability and tech debt. Your engineering team (and personal sanity in dealing with customer escalations) will thank you.
Unexpected Magic
Not all ideas are driven in a linear fashion by customer requests and strategic alignment. Sometimes, it’s the crazy off-the-wall ideas (“out of left field”) that can be most impactful to the business. It’s important to leave a little room for serendipity, keep eyes and ears open, and be prepared to reprioritize when something unexpectedly game-changing comes along. Events like internal hackathons can also be a good source of this. As a side note, many fantastic companies have been built after a tool was created to support the needs of the company, and that tool turned out to be a much business in and of itself; Slack and Docker are two well-known examples.
Best Practices
NOT the mini-CEO of the product
When you ask a starry-eyed new grad why they want to be PMs, there's a good chance they'll say "I want to be the mini-CEO of the product (as outlined in the famous "Good PM, Bad PM" manifesto). The reality is that a PM thinking they are a mini-CEO can be personally misleading at best and downright harmful to team dynamics at worst. It's true that CEOs and PMs share some duties--thinking through strategy, working cross-functionally across teams, etc. But the reality is, CEOs can fire people. PMs don’t tell others what to do. It's an influence without authority role, and you are only as good as the insights and data you bring to the table. It’s on you to earn that trust, and to help the team do whatever it takes to get the product shipped.
Who → why → what
So what is your actual role as a PM? Usually it comes down to who-why-what (in that order).
Your first goal as a PM is to help other teams gain empathy for the customer (“who”), by painting a picture of their skills, workflows, pain points, and motivations.
Your second goal is to give a compelling justification for prioritizing a new feature (“why”) by making the case for why it would solve customer pain points and drive the business forward.
Your third goal is to provide the necessary requirements for building a feature (“what”), prioritized by what is must-have vs. nice-to-have.
Don’t specify implementation
Notice the last part didn’t specify “how”. This is for engineering, design, etc. to decide. Focus on customer pain points, value propositions, and workflow requirements. This is a common failure mode for PMs coming from technical backgrounds, or in some cases technical founders who are doing product management work early in the startup lifecycle. There are two issues: First, jumping into implementation may cause the PM to not completely solve the user's problems (or worse, solve for something that wasn't a problem to begin with). Second, PM-specified implementation can limit engineering creativity in coming up with the best answer to the problem. That said, PMs definitely do need to understand technical complexity and architectural trade-offs, and collaborate with engineering on the user impact of technical decisions.
Focus
Bill Hewlett (co-founder of HP) once said: “More companies die of indigestion than starvation.” It’s easy as a PM to get into a mindset of building more features, when the real job is figuring out where we should and should NOT spend our finite resources to drive the business forward. This one requires careful management as a product leader; often junior PMs are incentivized to build more features in order to further their career, whereas senior PMs know that in many cases the fewer knobs you have in your product, the better (e.g. the space shuttles and bicycles analogy I discussed under #2 in my previous product strategy article).
When you ask a starry-eyed new grad why they want to be PMs, there's a good chance they'll say "I want to be the mini-CEO of the product (as outlined in the famous "Good PM, Bad PM" manifesto). The reality is that a PM thinking they are a mini-CEO can be personally misleading at best and downright harmful to team dynamics at worst. It's true that CEOs and PMs share some duties--thinking through strategy, working cross-functionally across teams, etc. But the reality is, CEOs can fire people. PMs don’t tell others what to do. It's an influence without authority role, and you are only as good as the insights and data you bring to the table. It’s on you to earn that trust, and to help the team do whatever it takes to get the product shipped.
Who → why → what
So what is your actual role as a PM? Usually it comes down to who-why-what (in that order).
Your first goal as a PM is to help other teams gain empathy for the customer (“who”), by painting a picture of their skills, workflows, pain points, and motivations.
Your second goal is to give a compelling justification for prioritizing a new feature (“why”) by making the case for why it would solve customer pain points and drive the business forward.
Your third goal is to provide the necessary requirements for building a feature (“what”), prioritized by what is must-have vs. nice-to-have.
Don’t specify implementation
Notice the last part didn’t specify “how”. This is for engineering, design, etc. to decide. Focus on customer pain points, value propositions, and workflow requirements. This is a common failure mode for PMs coming from technical backgrounds, or in some cases technical founders who are doing product management work early in the startup lifecycle. There are two issues: First, jumping into implementation may cause the PM to not completely solve the user's problems (or worse, solve for something that wasn't a problem to begin with). Second, PM-specified implementation can limit engineering creativity in coming up with the best answer to the problem. That said, PMs definitely do need to understand technical complexity and architectural trade-offs, and collaborate with engineering on the user impact of technical decisions.
Focus
Bill Hewlett (co-founder of HP) once said: “More companies die of indigestion than starvation.” It’s easy as a PM to get into a mindset of building more features, when the real job is figuring out where we should and should NOT spend our finite resources to drive the business forward. This one requires careful management as a product leader; often junior PMs are incentivized to build more features in order to further their career, whereas senior PMs know that in many cases the fewer knobs you have in your product, the better (e.g. the space shuttles and bicycles analogy I discussed under #2 in my previous product strategy article).
Good ideas can come from anywhere
Another common failure mode for new PMs is thinking they have to come up with the ideas for new features or products, and to explicitly gatekeep ideas from other parts of the organization. The best PMs actively solicit good ideas from everywhere--technical teams, go-to-market teams, customers, household pets, etc. Your goal is cultivate these ideas, translate them into customer benefits, and help prioritize which to tackle first.
Another common failure mode for new PMs is thinking they have to come up with the ideas for new features or products, and to explicitly gatekeep ideas from other parts of the organization. The best PMs actively solicit good ideas from everywhere--technical teams, go-to-market teams, customers, household pets, etc. Your goal is cultivate these ideas, translate them into customer benefits, and help prioritize which to tackle first.
Go-to-market drives product
Experienced enterprise PMs know that GTM drives product, and not vice-versa. ”If you build it they will come” is a fallacy in tech; building a “good” product in a vacuum does not ensure business success. PMs should understand how customers learn about the product (marketing), are convinced to use the product (sales) and actually adopt the product (bottoms-up, top-down, or somewhere in between) and use this knowledge to drive strategy and feature prioritization. If you want to level up in enterprise product, go spend time with your sales and marketing teams.
Always be meeting customers
It’s easy to get stuck in the nitty-gritty details of the product development process. Remember that PM’s primary value add is providing customer and market data to help drive the right decisions. In enterprise, research and analytics are great, but there is no substitute for spending time with customers and building empathy with them. Try to talk with customers (or prospects, especially important for a startup or new product) in some capacity at least once a week. Of course, the actual frequency depends on the industry type and customer makeup, company lifecycle stage, and any organizational boundaries to external discussions.
No comments:
Post a Comment