Defend only the defensible

Product managers operate in the gap between product vision and reality. You’re asked to create a strategy and roadmap for your product, setting future expectations across a broad community including customers, sales, and engineering. Do your job correctly and everyone is energized with a bright product vision. But what about the inevitable inaccuracies in your forecast?

Product strategy involves forecasting where your market, customers, and products will be over time. The product roadmap is a forecast of how you will execute on the strategy, including assumptions of pricing, use cases, and development velocity. Get any of these substantially wrong and the strategy will fail.

Defend only the defensible

Everyone recognizes that forecasts have inherent inaccuracies. The product manager is responsible for addressing subjective questions of acceptable risk and forecasting. And here’s the rub: who’s to say what is overly aggressive? We’ve all seen situations of overpromising and under delivering. Being too conservative creates grave disappointments as well.

You can do better than that

It’s too easy to allow wildly optimistic assumptions to guide strategy and roadmap by saying that all forecasts are inaccurate, so we’ll figure it out later. Early in my product management career, I experienced the personal discomfort of defending the indefensible and watching customers, sales, and engineering become disillusioned when the inevitable shortfalls became apparent. Those situations taught me to push back on glaring inconsistencies and force conversations on what is plausible versus fantasy. Though requiring more effort up-front, this approach builds trust with your community and allows your organization to focus its resources where they can truly succeed instead of being spread too thin.

Here are a couple of real situations which can be related to many IT products where I took my earlier learnings and influenced defensible product plans.

“We need to support three more storage arrays and two more versions of Linux in the next release.” Platform support is the gift that keeps on costing: more development, more QA, more equipment, more dependencies across third-party products and versions. With every new customer interaction, your organization will be tempted to support new platforms and interfaces. Unchecked, the situation will deteriorate into disappointing product quality, longer execution, and unfulfilled customer expectations.

The product manager needs to be brutally analytical in identifying what platforms will truly move the business and be prepared to decline some business opportunities to strengthen her core market. The specifics vary substantially by circumstance, so there’s no formula to follow. I’ve stood my ground with senior executives, account teams, and customers to ensure we supported platforms that are sustainable and that maximize revenue in our target markets. Doing this requires accurate data on adoption rates, use cases, and competitiveness in target markets.

In one particular case, a CTO lobbied aggressively to support a platform for a market we were poorly prepared to serve. I pushed back by showing the totality of what would be required to win such business at scale. We ended up serving that market, albeit later on, with an existing platform that played to more of our overall strengths.

“Let’s accelerate a release for our large customer in May, then do a summer release with the features we’re announcing at the tradeshow, and deliver the rest of the originally planned features in the fall.” Agile development processes may enable a faster release cadence versus waterfall. Your team may be faster than others. But light only travels so fast and you’ll eventually hit a wall trying to deliver too much too quickly. Quality and customer satisfaction will suffer.

Though it’s good to be aggressive, setting your business on a path you know can’t work is indefensible. The product manager has an obligation to speak up during release planning meetings and dig deeper on the assumptions and dependencies driving what appear to be overly optimistic plans. I’ve presented our agreed priorities to my business’ leaders and restarted conversations about what we’re willing to trade off to increase success in core business goals. It’s far better to have a frank conversation now than to run out the clock with unhappy customers and a wrecked roadmap later.

The last time this happened, we went back to the large customer, negotiated a phased delivery that aligned with our broader business goals, and consolidated into fewer releases we could execute on. We didn’t get everything that everyone wanted, but we kept the customer in the boat and met our announcement commitments. We managed the impact proactively.

A bigger payoff in the end

If you’re like me, you want to solve people’s meaningful IT problems and make them successful – “yes, we can do that!” Remember that success ultimately lies in delivering a solution versus the initial euphoria of delivering a roadmap promise. Ensure your team is defending only what is defensible. While the product manager needs to take risks involving imperfect forecasts, she’ll maximize her success by questioning glaring inconsistencies and unlikely dependencies to build and execute a defensible product plan.