Why did we build this feature?

Product managers are guardians of limited resources. Your business is on a budget and you’ve got to maximize value for the investment made. Let me start again: successful product managers are fierce guardians of limited resources.

You need a good answer when anyone asks why your engineering team built, or is building, a feature. Your organization agreed to spend its limited resources and the ‘why’ must reflect causal value. Random, inexplicable projects form an excellent hammer to shatter confidence in product strategy and product management leadership.

Far beyond producing a plausible answer on the spot, the product manager must ensure behaviors and actions that yield consistent, defensible product decisions over time. Three types of organizational situations shape your leadership approach.

Engineering does what it wants

“I’m not sure…ask engineering.” This is not a good place to be, as you’re a product manager in title only. Engineering has taken product management responsibility – justified or not, explicitly or otherwise. They may be doing a great job…or not.

Your choice is to find another gig, capture use cases and value justification after-the-fact, or influence a fundamental change in relationship. Only the latter will ensure consistent, defensible product decisions over time. (If engineering is truly doing a great job, either join them or refer to option one.)

A focus on product management basics – market opportunities, customer use cases, competitive position – goes a long way towards Influencing a healthy relationship with engineering. You are fully enabled to define a product vision grounded in differentiated value to customers. Articulate the gap between what is being built and what will maximize overall value. Your leadership can bring engineering, sales, and marketing together with objective data and common business goals.

Your predecessor screwed up

Take nothing for granted when you’re doing a turnaround. It’s important to quickly get your organization on a stable path and stop the bleeding of poor product plans still in progress. I’ve done several things in these situations.

Clarify product strategy. You need to know why your product exists and what value it can deliver over time. The organization around you needs to share that perspective to build and sell it effectively. Be your product’s worst critic and lead the definition of sustainable value and differentiation. Don’t assume the strategy you’ve inherited is correct.

Own the user experience. Knowing your product’s reason for being and who it’s meant for is the first step in identifying valuable use cases, which leads to articulating a compelling user experience. Soliciting feedback from existing users, listening to those in your organization who interact with your users, and assessing competitive products are ways to get started on user experience. You’ll need to perform primary research on new technologies and use cases when dealing with completely new products and markets.

Reboot product requirements. Documenting requirements becomes much easier once you are confident in exactly what your product should do. It can be tempting to edit requirements documents that you’ve inherited. Don’t! Force yourself to understand and think through every use case and requirement by rebuilding from a clean sheet of paper. Copying and pasting from questionable sources will subtly constrain your turnaround and allow inexplicable content back in.

You manage the product

If you’ve read this far, it’s clear that product managers should perform the responsibilities mentioned above on a continual basis to maintain consistent, defensible product decisions over time. Your dynamic world means that these processes are repetitive, not performed once. When sales or another stakeholder inevitably asks a question you’re not comfortable with or an important aspect of your business isn’t clear, consider it a turnaround situation – your predecessor is you.