Both you and your manager should want you aiming for the top product management job, whether the situation makes it the vice president or chief executive. It’s not about propagating unrealistic, naïve expectations that everyone can or should be the CEO. Healthy organizations need leaders at all levels who think proactively about requirements for success and who take responsibility to ensure the right things get done at the right time.

Several years into my product management career, I transitioned from a smallish, closely-managed product organization where executives had high-fidelity context on our business to a company so massive that executives were swamped by keeping multi-billion-dollar business units on track. My prior CEO called bullshit on sloppy analysis and imprecise product planning. The new executive team – hundreds of them – was unable to proactively identify problems unless things were so bad that negative feedback was incoming from multiple senior vice presidents. By then, of course, problems were much harder and more expensive to address.

My abrupt change from being closely managed to essentially unmanaged was an exciting opportunity and daunting challenge. It was exciting because I had a shot at developing executive leadership skills of my own. It was daunting to realize there was no longer a safety net. There was no meaningful filter on the product plans I developed or the marketing content I released. Any big screw-ups would eventually become known – and I wanted to win by building and selling a great product.

The situation quickly taught me to pretend my managers didn’t exist for purposes of data-driven decision making, recognizing market conditions, and executing within available budgets, timelines, and resources. In short, I operated like I was the executive.

Did my executive leadership feel I overstepped my bounds? To a person, the executive team encouraged my development and invited me into the highest level conversations. They wanted me to take their job. They were already too busy and desperately wanted leaders to help shoulder the burden.

How to take your manager’s job

A confident, want-to-win manager needs someone to take her job so she can grow with the business and create space to tackle increasing responsibilities. This realization changed my perspective about successful product managers. To preserve anonymity, I’ll synthesize real examples of good and bad product managers I’ve worked with into two pairs of people.

Good product manager #1
Gertrude knows her technology, validates use cases she hears from others, is proactive about engineering outreach, and crisply documents her thinking. She doesn’t fall for red herrings. Instead, she sets the record straight when anyone makes an inaccurate claim about her product, customers, or market. Engineers trust and respect her judgement because they know she’s in their corner, while fiercely representing customer needs and not accepting incomplete use cases.

Good product manager #2
George knows the economics of his business and the value customers are willing to pay for. He is proactive in analyzing what works and what doesn’t, communicating tangible outcomes quickly and accurately. He puts focus on the product’s value, ensuring that partnerships and marketing return maximum value. George identifies where sales is having trouble, driving product enhancements and enablement activities to respond.

Bad product manager #1
Barbara can’t or won’t learn the product, market, and underlying technologies to be conversant with engineering, customers, or sales. She doesn’t understand the core value of her product beyond the marketing messages that have been created by others. She depends on her manager to set and manage her goals and timelines. While Barbara can execute basic tasks that have been assigned to her, she requires close ongoing guidance to ensure a successful outcome.

Bad product manager #2
Bobby transcribes engineering plans into requirements documents and cannot explain why they are being implemented or how they will meaningfully improve user experiences. He repeats last year’s strategy with incremental changes regardless of market changes. He actively avoids challenging plans of record with new analysis of market threats and opportunities. Lots of people like Bobby and sales often invites him to meet with customers because he presents well.

It’s about your career

“Hiring your replacement” is an axiom that confident, want-to-win managers take seriously. Whether or not you work under such circumstances, think about how holding yourself to executive discipline without a safety net can improve your product management skills and opportunities for the future.

“Mark, I want to be strategic,” said the product manager in our 1:1.

Judging from a quick LinkedIn “strategy” search, many other people want to be strategic as well. What does that mean? Is a product manager’s role ever not strategic?

From conversations with product managers over many years, “want to be strategic” appears to mean “want someone else to take care of the details.” The irony is that details are absolutely critical to achieve strategic influence.

A product manager earns strategic influence by mastering the details of her business, bringing meaningful data and rigorous conclusions to conversations of all stripes. There are no shortcuts to mastering the details – she has to do them everyday. Examples include:

• Understanding market conditions and competitors beyond trendy headlines and superficial claims
• Artriculating use cases and user experience thorough validation of user environments and practical workflows
• Enforcing whole product delivery that addresses complete use cases rather than checking boxes in a requirements list

If the “strategic” product manager isn’t doing these things, who is? How will she call bullshit when someone else makes an incorrect assertion that derails her product.

Without mastering market conditions, use cases, and product capabilities, the product manager has no platform on which to be strategic. Common errors include:

• Select a market we wish to serve: undefined how to enter or monetize
• Define a use case we’d like to handle: it’s incomplete or uncommon
• Build what is convenient: it doesn’t solve the user’s actual problem

Here are a few real examples showing that strategy without details amounts to a low-probability gamble of precious engineering and go-to-market resources.

Market miss

“Let’s start a cloud business that will attract developers to our platform…though we can’t yet articulate the value we’ll bring over existing cloud services.”

Unfortunately, this tops-down directive failed in a very public manner. The business owners were unable to establish meaningful differentiation and monetization strategies, while attacking entrenched cloud competitors with strong developer and ecosystem relationships.

They believed their own claims that customers would appear due to the company’s enterprise brand and channel relationships. Trendy headlines of rapid cloud growth were used to justify impossible expectations for an uncompetitive feature set several years behind the market.

The product manager must challenge unclear directives with data-driven arguments and tough questions. Why would an objective user adopt our new product versus what’s already in the market? What valid criticisms of our product would an aggressive competitor make?

Broken use case

“Let’s help customers to more efficiently access their data by building a new protocol…that doesn’t work with their existing communications equipment.”

A bet on third-party technology must be based on a reasonable expectation of its implementation. Success is more difficult when another technology must be deployed first: your product must overcome the total adoption costs.

Warning signs were raised from the outset, though the company pivoted too late to recover. The use case was broken because it relied on thinly implemented, bleeding-edge networking technology.

The product manager must validate target user environments to identify each step in the user’s tool chain and workflow. An otherwise great technology will fail if users can’t consume it. By accurately capturing the steps required to use her product, the product manager can ensure usability and prevent unacceptable dependencies.

Convenient and useless

“Let’s manage application relationships with a slick UI that aggregates information from Linux command line tools.”

Solving a real problem requires starting from what users need, rather than from what is easy to capture. The product was convenient to build because it leveraged existing libraries and frameworks with relatively few engineers to develop new components.

An attractive UI yielded pretty marketing collateral. Sales got excited about upsells. Yet proof-of-concept conversions to revenue were rare. Users had difficulty seeing sufficient value. It was an intriguing engineering concept converted to a product without first exploring use cases and requirements.

A product manager is responsible for the outside-in customer view of product delivery. Convenient projects aren’t necessarily wrong, but must be channeled to deliver whole use cases and objective value. The product manager finds herself adding new requirements and re-prioritizing engineering’s feature list to yield a valuable product.

No shortcuts, no handwaving

A product manager requires competency in the details of her business to make informed decisions and validate others’ assumptions. Her path to being a strategic influencer runs directly through an understanding of her market, customers, and product, which is achieved by taking care of the details everyday.

What should we be building next year?
How should this GUI button operate?
Will our competitor’s announcement hurt us?

A product manager faces questions like these on a daily basis. Her responses, or lack thereof, quickly determine her standing and success in the organization. She is hired to lead with a crisp, reasoned perspective and get others aligned around a common product direction. Executives and peers lose confidence when a product manager punts, expecting others to figure out the bigger picture and make decisions. Consider the personal decisions you make for yourself:

How do you spend your money?
What food do you choose to eat?
Where do you choose to live?

I coach product managers to be the boss as they are outside of work. Take the responsibility personally and don’t expect others to blaze the trail. When answers aren’t immediately clear, the product manager has research and learning to do. She can begin by asking herself what factors influence the answer, regardless of what the answer turns out to be. Factors range from external (e.g., technology, economics, users) to internal (e.g., resources, products, customers). Since the product questions posed above are so common, I’ll discuss them further.

What should we be building next year?

Regardless of phrasing, roadmap questions are never casual queries for feature lists. The question is often a challenge to validate product-market fit and instill confidence in the product direction. Interpret the question as “what market forces and emerging technologies create new opportunities and require a change in our current approach?”

Given the impromptu nature of such critical questions, the product manager must always be clear on her product priorities. Near-term strengths and weaknesses in serving today’s customers and sales objectives must be balanced by longer-term opportunities and threats that require sufficient time to address.

How should the UI operate?

Engineering may be seeking clarification as they are coding. Pre-sales may be confirming how to address a customer’s need. This question is an opportunity for everyone involved to understand the use case – the aspects of a user’s daily life and their influence on product design and operation.

Avoid casual “do it like this” answers that lack sufficient context. By first articulating her initial understanding of the use case and asking others to confirm or amend it, the product manager increases the probability that sufficient information is available to make a good decision. Or, she exposes a critical question that must be researched before a decision can be made.

The product manager must bring a crisp perspective on customers and use cases, leading a conversation where everyone benefits with greater product context.

Will our competitor’s announcement hurt us?

Competitor-triggered questions require broader market context. Is this an expected move that we have already accounted for? Is this a surprise we should react to? Is this a neutral situation to monitor, but not immediately respond to?

Quickly (and accurately) categorizing the competitor’s news as positive, negative, or neutral is critical to keeping everyone focused and spending their time usefully. The product manager needs to clearly explain her analysis and the resulting implications for her business.

Regardless of the conclusion, she has an opportunity to articulate necessary changes to product strategy and execution by highlighting weaknesses or threats surfaced by the competitor’s news. Don’t waste a learning opportunity made possible by competitor’s news: an external trigger can facilitate often-delayed conversations.

Have something useful to say

I expect a product manager to always have something useful to say because she is immersed in all aspects of the business on a daily basis. Impromptu questions typically come in unique circumstances where busy executives and peers are open to new perspectives. These are valuable moments for the product manager to show her leadership.

Product managers create product requirements documents, right? Despite this long-standing relationship, some people question whether the PRD remains relevant in fast moving, agile development organizations. They suggest that a PRD can become static, rigid, and confining, preferring other forms of communication between product management and engineering.

The PRD holds product management, engineering, marketing, sales, and peers accountable for the agreed plan of record. It enables broad product planning using a common reference point. If it’s not written down, it doesn’t exist.

Like other communication media, a PRD can yield great outcomes or be abused and neglected to irrelevancy. The product manager must formally communicate what product success looks like to a cross-functional organization. Formal communication should be written and subject to broad review and debate. Committing ideas in writing is a critical, formative process that forces her to confront ambiguities and resolve disconnected logic, fostering constructive debate on the product goals and strategy – exactly the rigor expected of product managers.

Informal cormmunication – hallway conversations, ad-hoc email threads, chat logs, backlogs – means most people aren’t quite sure of the bigger vision of success. Even in small teams, informal communication poses high risk of misunderstanding context between business requirements and use cases after achieving a fleeting consensus. New arrivals face difficulty coming up to speed. Not everyone will have access to all the informal communication channels. Those who do are left to piece together history, never sure if something is being missed.

Everyone in the organization should be able to inspect and consider the vision of product success on their own time and at their own pace. Informal communication works against this transparency.

Many people misunderstand the purpose of a PRD to be mainly a prioritized requirements list. Rather, business goals and use cases are the fundamental goal posts that define a new product or release. Documented requirements are an important element, but provide insufficient context on their own to ensure a winning product.

Why are we building this?

Business goals set the context into which the product fits, allowing everyone in the organization to understand why they are building it, who they are building it for, and what systems it replaces or complements. The organization must understand the product’s unique value – why the market should care.

• The why identifies the market being served and the potential for monetization (or the appropriate business metric). It lays out the essential problem being solved and introduces the foundational use cases that demonstrate product-market fit.

• Documenting target users is necessary to ensure a serviceable audience, understand their needs, and determine appropriate degrees of user interaction. Identifying product buyers and influencers helps ensure that messaging and use cases are complete.

• Market alternatives and competitors must be clear to everyone. The product manager must honestly assess competitors’ strengths and weaknesses, ensuring that real value is being delivered to users versus simply another way of operating.

What will people use it for?

A product’s user interaction and interface design rely heavily on the PRD to detail the product’s defining use cases. These use cases illustrate core product value and the most common ways the product will be used.

• Engineering can put features in context and make informed design decisions with clear, focused use cases. Asking “do we need to build ‘X’?” often indicates an incomplete understanding of use cases between engineering and product management.

• Marketing and sales are best positioned to succinctly articulate and demonstrate product value by understanding foundational use cases. Rather than delivering a me-too pitch, they can communicate with users’ familiar language and experiences.

Most products benefit enormously by interoperating within a technology ecosystem. Inability to work with necessary third-party products can make it nearly impossible for users to consume your product’s benefits. The PRD must be clear on other systems in the user’s world the product must operate with and the full set of interactions required to address user needs.

Informal won’t work

Business goals and use cases are too fundamental to product success for informal communication and must be written down for broad review and debate. While a PRD may fail to deliver these prerequisites for success, the solution lies in the product manager improving her work versus believing that relaxing the need for formal, written communication will somehow lead to success.

The maxim that a product manager is the CEO of her product motivates me to think broadly and avoid blind spots caused by narrowly focusing on daily tasks. It also informs how I mentor product managers and set their goals and objectives: “You’re the boss – and I mean that literally,” is my frequent guidance, with an explicit expectation of the product manager highlighting broad requirements, supporting decisions with relevant data, and ensuring action across the organization.

The CEO comparison can be empowering, but may also seem daunting or impractical. While this idea is espoused by many successful leaders, some people push back by pointing out numerous differences between product managers and CEOs.

Objections to a product manager being compared to a CEO are rooted in the differences between a coach and a king. A coach rallies her team and achieves desired outcomes through influence. A king orders his subjects to do as he wishes. A weak product manager wishes for power to force others – engineering, marketing, sales – do what she believes is correct.

Being the CEO of your product is taking responsibility and accountability for product success, not pretending that you are everyone’s boss or have full control over all situations. The product manager can’t force anyone to do anything. She has no budget authority. Executives can overrule her. No one reports to her.

Keep in mind that a CEO lacks omnipotence. Many factors lie outside her control, though she is officially the boss. Employees have autonomy to leave her company and slow-roll her vision in the absence of motivation and buy-in. Everyone second-guesses her decisions. Competitors, governments, and nature refuse to behave as expected. Product managers and CEOs are at their best when they lead by influence and everyone around them wants to follow.

Being the CEO without being the boss

It takes a CEO mindset to step out of narrow job descriptions and consider what overall success looks like and how it can be achieved. The product manager is best positioned for this responsibility because she operates cross-functionally, observing gaps to success and opportunities for improvement without being limited by functional boundaries.

Problems selling often involve multiple factors including product, messaging, and field enablement. A successful product manager identifies broad, cross-functional gaps, works with her peers to understand practical remedies, and evangelizes her vision for success across the organization. Narrowly defining product management as writing a PRD won’t work.

I’ve seen product managers walk away from problems because other teams “won’t cooperate” or “aren’t investing enough.” Predictably, the results are varying degrees of failure both for the business and the product manager’s standing. These product managers believe they did their job and the other guy is at fault, while the situation worsens. Rather than getting trapped in cycles of indecision and blame, you can leverage your unique role to create a cycle of influence:

Articulate what success looks like: create a succinct problem statement focused on specific, actionable gaps. While you may have an accurate vision of the successful outcome, it’s critical to achieve buy-in from your constituents who will consume, benefit, and execute the outcome. Everyone who has a stake in the outcome should share in the solution. This must be done in writing so appropriate people can review, contribute to, and approve the shared vision. You can always return to reference the shared vision and, if necessary, modify it as you progress.

Define the steps to achieve success: this is about identifying and resolving organizational dependencies versus telling others how to do their jobs. Engineering can manage a bug-fix project. Support can draft a customer communication plan. But support may first require a better understanding from engineering on what went wrong before customers can be contacted. Engineering may first require more customer data to confidently recreate the problem. Work with each stakeholder to ensure there is a documented, agreed set of responsibilities and hand-offs sufficient to achieve success.

Eliminate obstacles to doing the work: talk to the people who must execute each step. What do they need to succeed and what is blocking them? Sometimes there is a priority conflict with another product release or go-to-market activity. An important tool or access to information may be missing. Resolve obstacles by reprioritizing, helping to acquire what’s missing, or seeking executive support for necessary resources. These are often “taking out the trash” or “sweeping the floor” responsibilities that fall through gaps in organizational boundaries and require the product manager to step up and make things happen.

Sell your vision for success aggressively, but fairly: having accomplished the first three steps, executing the plan is rarely easy and will require everyone to work hard and invest extra effort. Adding up all the tasks may yield a timeline far longer than what the customer or market will tolerate. With the broadly agreed facts on your side, set an aggressive goal that balances external requirements with internal capability. Excessive tension will result in execution failure, while a lack of urgency risks the customer and market. You’ll need to achieve executive buy-in from all the affected teams by demonstrating value for each team, a realistic plan agreed by each team, and vision shaped by each team.

This is being CEO of your product. You’re defining success and ensuring a plan that is executable while achieving a necessary business outcome. Do this a few times and you’ll be regarded as an influential problem solver who your organization turns to for answers.

“Strong desire to have an answer…Important to realize that “I don’t know” is often better than a long-winded response…”

This quote from my performance review summed up what my manager advised: don’t put all the burden on yourself – ask for help.

Being a leader doesn’t mean you have all the answers, but rather a clear vision and engagement skills to shepherd your team in solving the challenges at hand. The product manager must be assertive and take prudent risks, striking a balance between conjecture and waiting for perfect information.

Not everyone can, or should, be in the room when the product manager meets with customers, sales, engineering, or executives. Full visibility will never occur as competitors maneuver, use cases shift, and development surprises appear. There are times when she has the benefit of thoughtful group discussion and others when she must be decisive in the moment. My manager was saying that “let me get back to you” can be an acceptable response when my type-A personality screams “let me figure this out” in the moment.

A critical third approach is “let’s figure this out together.” I’ve learned to employ this approach by checking my assumptions and soliciting details and perspectives from everyone around me. Knowing when to employ each approach enables the product manager to move quickly and instills confidence in her leadership.

Figure this out now!

Sometimes you’ve got to make an executive decision in the moment. There may be only one correct answer even when not all the details are available to support it.

I’ve been fortunate to observe great leaders with the confidence and conviction to look out for the customer even when it means a near-term, unexpected disruption. Our largest customer put its faith in us to manage their Windows servers using our latest software release. Despite careful research into the customer’s use cases, both sides missed a requirement that significantly reduced the value of what we promised.

Once the product gap was recognized, our executive team immediately pledged unconditional support with a timely, targeted release to satisfy the customer’s need. This was despite lacking a full understanding of what it would take to deliver the new features. Though we had time to partially scope the work, uncertainty remained. It was abundantly clear that we had an obligation in rising to the faith that was invested in us.

I’ll get back to you

Complex use cases and multiple priorities can mean a more lengthy process in understanding a problem and the appropriate response. When you can do more harm than good with an immediate response, admit you don’t have all the answers and commit to a timely follow-up. This approach boosts confidence compared with off-the-cuff pronouncements that turn out to be wildly inaccurate.

Following organizational changes, a sales team unwittingly set customer expectations for software delivery that were unachievable. Promising every requirement in the originally stated timeline simply wasn’t possible and would have misled the customer. My general manager delivered an unequivocal message that the customer would be taken care of and tasked my team with figuring out the best approach that would balance the needs across our customer base.

We pulled together several engineering teams, considering existing commitments plus the late-breaking customer challenge. With finite time and resources, we went back to the customer to more accurately understand their deployment priorities, which were not monolithic. The product team spread use cases across multiple releases that coincided with the customer’s timeline and that of our broader business.

Let’s do this together

Joint investigation allows the product manager to solicit feedback in the moment when challenges are first uncovered and domain experts are in the room. Seeking details on the ask and hearing others’ ideas improves clarity and makes her constituents part of the solution – whether they are within or outside her organization.

A partner released a new boot feature that complemented our configuration abilities and would hand us another way to deliver unique value to joint customers. Unfortunately, engineering was already committed on the next release. Missing that release would prevent us from realizing the full value of the partner’s product launch. Initial feedback was grim: we either wait for the next release cycle to build a whole new feature or rely on third-party software to make our two products work together. I certainly couldn’t solve this on my own.

Together with engineering, we outlined the steps a user would follow to manually achieve the use case with and without our product’s unique capabilities. Actions would be required in both the partner’s UI and ours. As the use case became more clear, we realized that a short string could be inserted in our UI that would activate the user’s desired boot image. Adding this string turned out to be a modest effort that fit into the upcoming release. We demonstrated our new capability at the partner’s user conference and marketed the value it brought to customers who were adopting the latest capabilities.

Personality traits

Some people may find it easier to ask for help than others. If you’re an engineer turned product manager like me, there may be a lingering sense of pride in figuring out something for yourself or wanting to always appear informed. Knowing when to say “I don’t know” or “I’ll get back to you” or “let’s do this together” is both personally liberating and most fair to those you’re working with.

It’s easy to blame salespeople when a product isn’t meeting expectations. You’re convinced of your product’s superiority, but somehow competitors are winning too many deals. Though some salespeople may not be up to the task, it’s more likely that either you’re targeting the wrong market segments or your product is too complex to explain and consume.

Market fit

My general manager correctly observed a multi-billion dollar market for data-intensive, high-performance computing and instructed our sales team to aggressively pursue. Engineering ran benchmarks to prove how fast we were and marketing did their thing. Qualified sales opportunities started coming in. Some of the deals were potentially huge: seven and eight figures.

As sales got deeper into these opportunities, data points started rolling in that customers were expecting proposals near or even below our cost. Everyone knew that portions of our market were lower margin, but expected that our competitive advantages would deliver value customers were willing to pay for. Wasn’t it much faster to setup our product versus that of our competitors? Wouldn’t these large-scale deployments benefit tremendously from our powerful management software?

Three of the largest market segments in data-intensive, high-performance computing were higher education, web, and enterprise. While the first two had tantalizingly large deployments, systemic factors such as cheap labor (graduate students) and internal software development cultures meant they demanded bare-bones systems. Each customer would deal with the operational and management issues in their own custom manner – ignoring some of our key product differentiation. This was not an issue of sales competency, but simply lack of demand for what we built.

The data-intensive, high-performance computing market was anything but monolithic. Each segment had its own requirements, while also sharing underlying similarities. It became clear that we had to focus on the segments, most notably enterprise, that valued the product we had built and could buy with margins reflecting our value to those customers.

Our product roadmap continued to focus on performance and ease of management. We increased density and demonstrated market-leading throughput for the applications that mattered to enterprise users. We expanded our management software portfolio so that enterprise users could quickly and reliably operate large computing environments across geographic locations. Our marketing and sales efforts focused on enterprise, where we built a rapidly growing, profitable business while declining to pursue opportunities with low or negative margin.

It’s complicated

In another situation, our executive team was excited when we released a new set of configuration management capabilities. Our target users managed a broad set of configuration files and objects for every application they deployed. Many were looking for ways to define expected configuration state, periodically verify that state, and correct configurations where needed. A competitor had been winning deals partly because their configuration management capability was already available.

Marketing prepared collateral and trained the sales team on our latest release. Opportunities surfaced and we began live demonstrations for each customer. Feedback from the customer demos started to expose a common issue: our configuration management worked well for text files common with Unix/Linux systems, but required custom work for each customer to fully support Windows-based applications.

Sales teams are rightly expected to overcome certain product gaps by focusing customers on the product’s strengths and providing customers with consultation to satisfy their use cases with minimal effort. Our sales team was able to win deals when Windows configuration management was not a primary driver. They were even able to win certain Windows deals by offering customers capabilities beyond configuration management. But we contnued to lose deals that were heavily Windows focused. This also was not a sales faliure, but a product deficiency that made some customer use cases overly complex.

We knew our product had to get better in managing Windows application configurations, which was a top priority in the following product release. Rather than customers having to create scripts for each Windows object they worked with, we built native Windows object support into configuration management.

Look in the mirror

It’s too easy to blame sales for outcomes that are instead due to product and positioning gaps. While sales can underperform like any other function, it’s critical to brutally evaluate your product from customer and competitive perspectives and honestly identify weaknesses. The product manager has to answer a basic question: if my product is so good, why isn’t it selling?

“I’m part of the two-person marketing team.”

It took five years in product management for me to make that statement during lunch as I explained my new job to a friend. Throughout my engineering career, everyone outside engineering was “the dark side.” I regarded marketing as fluff – surely not real work like we did in engineering.

When I first became a product manager, I viewed the role as requiring technical competency, which made it worthy in my eyes. I still regarded other non-engineering functions with skepticism. Fortunately, my early product management years were spent alongside excellent marketers, from whom I came to understand their value and the close relationship between product management and marketing.

Product evangelism

Just as product management is not engineering, it’s also not marketing. But there are fundamental marketing responsibilities within product management. Product managers are evangelists, always promoting their vision across a broad constituency both inside and outside their organization. This is marketing – explaining the product value that exists today and the journey that lies ahead.

The product manager is in the best position to articulate her product’s value because she deeply understands her customers’ use cases and the impact her product makes on their experiences. She is primarily responsible for ensuring a compelling product and broad awareness of its value. Everyone else – sales, marketing, engineering, executives – come to her for motivation and the core concepts they will each use in their own responsibilities.

Though marketing refines, amplifies, and syndicates the product message, the product manager must be clear on what is being built and why. She must put on her marketing hat everyday to ensure each use case and product capability supports a strong message and product vision. Engineering should not be tasked on something that lacks a compelling message.

Isn’t this feature a checkbox?

My product was behind competitors in managing Linux and Windows patches. When we decided to leapfrog and build a superior product, the task seemed daunting. Lots of tablestakes capabilities needed to be built. How would we market the tremendous effort being invested by engineering when many of the features were considered checkboxes on an evaluator’s long list?

As with many disruptive products entering an ecosystem of established products, we faced the risk of never being able to catch up in addressing every use case. Yet we had powerful advantages in the breadth of our platform and adjacent capabilities that could amplify the value of individual patch management functions and address broader use cases that more narrowly focused products missed.

The marketing and sales teams were looking for answers. We were losing business to entrenched patching tools and our existing customers were facing pressure to adopt alternatives. A basic feature comparison matrix looked grim – we couldn’t fill all the checkboxes fast enough. We could, however, change the game by adding new, more valuable use cases to the competitive evaluation process.

My product management responsibility was to identify new use cases that advantaged our product, work with engineering to define a viable product plan, and evangelize the resulting value. Beyond basic patching, we integrated global policies, compliance leveraging a wide range of criteria well beyond patches, and flexible remediation. Once everyone understood what we were building and its competitive advantages, marketing was able to execute our launch and sales took the message to win new and existing customers.

Humble pie

My wife never lets me forget my unfounded skepticism for marketing and the time necessary for me to become proud of the marketing role I serve. She’s visibly amused at my 180-degree turn whenever I discuss the pros and cons of marketing programs. Like any role, marketing can be done poorly: generic messages, unfocused audiences, or nonspecific problem statements. Product management has a critical responsibility to lay a foundation for successful marketing by developing and evangelizing a crisp product message and vision.

“Mark, you told us to build this feature for the customer’s pilot deployment, but they just told me they need something different – what’s going on?”

I walked into this trap during my first months as a product manager. It took a small crisis to teach me that product managers are responsible for validating requirements no matter who is asking. While this sounds obvious on the surface, I’ve seen too many instances where features appear in a requirements document because “my VP told me to put it in.” Or, “the account team says the customer needs it.”

As the product manager, it’s your job to validate all requests and take appropriate action. Chances are that your VP has been told that a particular capability is important to your business. The VP is doing her job in placing this request on product management’s radar, expecting you to make an informed decision. Likewise, your account manager wants a satisfied, paying customer and passes the request to product management, expecting you to manage the roadmap towards winning more business.

In both scenarios, the higher goal being communicated is not literally building a new feature, but growing your business. Each person requests what they believe will lead to that success.

The product manager must prioritize and implement either what was requested or other capabilities that will more effectively meet her business goals. It’s a critical responsibility requiring transparent reasoning and clear data to support your decision. Product requirements become an arbitrary list without a clear rationale, easily swayed by the loudest voice – a sure way to kill confidence in a viable product strategy.

It’s personal

Validating requirements gets personal, especially when working with new technologies and market disruptions. Abstractions fall away in deference to specific users and use cases. Mature businesses inevitably encounter a large customer opportunity or competitive situation where “one more feature” is mooted as the key to winning the deal. New ventures must make decisions without a proven path forward – else the problem would already be solved.

A product manager can maximize her chance of success by working directly with users and not allowing information to be filtered by intermediaries, no matter how well intentioned. Your VP doesn’t have time to fully dissect the customer’s environment, processes, and goals. Your account manager is operating on many fronts to secure a win and has a full-time job prospecting for new opportunities.

My beginner’s error was mistaking the account manager’s feature request as being already validated. One of the customer’s IT architects proposed that we integrate with a specific storage array, though they had many storage arrays that could be used with our product. Had I contacted the customer directly following my discussion with the account manager, I could have discussed their use case, exposing the fact that it depended on the capabilities of a different type of storage array. We fortunately discovered the gap soon enough, but with unnecessary delay.

Moving from ‘no’ to ‘yes’

That early lesson taught me to exercise positive skepticism when anyone in my organization requests that we build something. The skepticism is positive in that I know the person is doing what they believe is right given their perspective on our business. Yet it’s still skepticism because the product manager, being accountable for product strategy, has the responsibility to maximize product success in the face of many stakeholders offering their own perspectives on what should be built. The product manager must inevitably say ‘no’ to many incoming requests and offer instead a crisp roadmap that achieves the success your stakeholders seek based on an understanding of what will make users successful.

My CTO came out of a meeting convinced we needed to move quickly on an Openstack market opportunity. She directed that my team adopt a business partner’s apparently simple solution: demonstrate that our products worked together in an Openstack configuration and make it easy to buy the packaged offering. By this point, I had been speaking with customers every week about their cloud requirements and recognized a general perception of undifferentiated, “me-too” Openstack capabilities. Customers wanted to know what unique Openstack benefits our product offered as compared to other solutions. We did not yet have a good answer, yet our CTO directed us to proceed with the partner’s offer.

The skeptic in me refused to spin up sales and marketing on a generic Openstack offering because I knew we would be forced to sell on price due to our lack of differentiation. The effort required to close deals would distract us from larger opportunities and result in poor margins. Yet it was clear that Openstack represented a market shift and our business could benefit by delivering value to customers deploying Openstack. I also knew that my CTO’s real interest was ensuring that our company had a competitive portfolio in the Openstack market.

Spending time each week with customers who showed specific interest in Openstack, educating ourselves about evolving Openstack technologies, and knowing what our product was capable of, our product management team identified a range of value-added benefits we could deliver into a “me-too” market. We created a roadmap for Openstack differentiation and made that our priority. Partner activities became one element of our overall roadmap and were introduced after our own value was clear.

Confidence comes from knowing your users

Intimacy with your users and their use cases allows you to make crisp, confident decisions based on problems that are truly useful to address. Everyone around the product manager has opinions on what should be done. The product manager is ultimately responsible for guiding the roadmap with a clear articulation of what will make users successful and return value to her business.

Sending notes and action items soon after a meeting ends.
Telling your CEO what she needs to do for a successful product release.
Getting engineering leaders in a room to commit a new product plan.
Drafting a customer presentation when no one is sure how to articulate product value.
Documenting what a successful sales engagement looks like before first customer contact.

Do these actions describe the kind of things you do each day? Or do you feel more like:

Everyone is telling me what to do and nothing ever seems to get done.
My CEO gives rapid-fire orders that change by the day.
Engineering does what it wants and tells me about it later.
We go in circles trying to figure out our marketing message.
I’m always fighting fires with the sales team.

Product managers are hired to be leaders. Across numerous groups that make a business function, someone needs to be accountable for product strategy and ensure the market is properly served. While exciting to masochists, the diversity of responsibilities can spread the product manager thin and lead to a sense of overwhelming futility.

I’ve seen product managers who are always on their game. They know when to take action items and when to give them. Channeling the customer, they dispense recommendations to senior executives who don’t report to them, yet who gladly follow because there’s a clear path to success.

I’ve also seen product managers who always seem to be catching up, unsure of how to move out of crisis. Like an overburdened waiter runs to and from the kitchen, they are serving many masters and often show frustration. Managers and peers consider them ineffective despite their hard work.

No one reports to you

Product managers don’t get to boss people around because no one reports to them. Good managers don’t boss their people around, of course. Yet I’ve heard embattled product managers explain their problems with,

“If only these people reported to me, I could make them do what we need!”

Ouch. That’s a clear sign of being unable to lead through influence – a critical skill for success in product management.

Managing requires a vision to accomplish something, discipline to build an actionable plan, and commitment to ensure it gets done. People who don’t report to the product manager willingly follow her when they come to share her vision, believe her plan is viable, and share success in the execution.

The product manager begins to lose credibility when she doesn’t offer sufficient vision for the situation at hand. I’m not necessarily talking about something as grand as rebooting the product strategy. If, for example, several important sales engagements aren’t going well and there is no product response, uncertainty takes root as everyone develops their own opinion and there is no clear path to recovery.

Her credibility declines further when a defacto vision takes hold and planning becomes murky. No one is sanity checking the facts, validating action items, and keeping the conversation focused. At this point, execution is almost irrelevant to the product manager’s success. She is, at best, following someone else’s strategy and, more likely, struggling to deliver on a flood of half-baked directives. In other words, the product manager is being micromanaged by everyone around her – the exact opposite of what she was hired for.

Lead from the front

If you don’t already have a type-A personality, you’ve got to channel some of those characteristics. Consider the major issues facing your business and the practical path you and those around you can take for the best outcome. Be your own worst critic: what is the best you can do?

Some product managers fall into a fallacy of extremes, either trying to do other people’s jobs or retreating into “that’s not my job.” Leading by example is a powerful way to crystalize your vision for those around you and build consensus around an actionable plan.

Sit with engineering to work jointly on tradeoffs that improve the product position. Draft strawman marketing materials in concert with your peers to jumpstart demand generation activities. Meet customers with the sales team to find out what works. Tell the CEO what her business requires and back it up with hard data – the changes you’re advocating require broad, ongoing buy-in.

Being your own worst critic also means that your proposals must be practical for the situation. A typical startup can’t fund a $20 million marketing campaign. A Fortune 500 company isn’t going to retrain the entire sales team in a week. Your CEO doesn’t have a magic wand to make everyone exceptional collaborators, instantly aligning to your vision with a smile.

As in other aspects of life, the product manager can get big value from small things that show her personal investment in shared success. Taking responsibility for decisions, guiding meetings with clear outcomes, and spending time to understand thorny tradeoffs show that she is working on solutions in the trenches, not giving orders.

Overall, the product manager must take time to regularly maintain her own vision for the business, identify gaps over the horizon, and propose the next set of actions to those around her. This is managing versus being managed.