“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.