A Brief History of Product Management: Starts With a Spark
Product management was originally seated in marketing but has evolved. It's still misunderstood but it's now getting the recognition it deserves with product people...
Although this will sound counterintuitive, one of the most difficult aspects of a product manager’s job is the fact that most people are optimists.
Seems like a great trait, right? So why does it make a product manager’s job so challenging?
Because it means you’ll need to set the right expectations for your product — and you’ll need to help your stakeholders understand that the roadmap is a guide, not a promise. In this post, we will show you why setting expectations is vital both to your product’s success and to your own success as a product manager. Then we’ll share some tips on how to set expectations effectively.
Real estate investors often say that you don’t make your profit when you sell a property; you make it when you buy that property. In other words, if you can purchase a piece of investment real estate for lower than its market value, you create the conditions for a profitable sale at almost any time.
A similar principle applies to product management. If you set and communicate appropriate expectations for your product at the outset, you are in effect creating the conditions to increase the chances that your product will be a success.
Here are two reasons why setting expectations as early as possible is a great way to lock in a better shot at a successful product.
As a product manager, you are ultimately responsible for the successes or failures of your products. But, of course, you won’t be the only person working on those products. Indeed, bringing a product to fruition will require that you delegate tasks and responsibilities across a broad range of teams.
It’s important to establish an agreed-upon set of expectations as early as possible in your product’s development. If you aren’t clear up front about what you want, whom you expect will be responsible for what, and by when, then there is very little chance they will build the product you want in the timeframe you want it.
The later in the development process you establish expectations, the greater the chance that some of the development will have already gone in the wrong direction. And the longer you wait, the more magnified the problems will likely be.
Which metrics — and whose definition of success — will you use to evaluate your product launch?
If you’re developing business software, for example, you might think that success means entering beta-testing within a certain timeframe. Your executive stakeholders, on the other hand, might be assuming your product will already be in general availability by that time and will have already earned a substantial amount of revenue.
Setting expectations for your product — early, clearly, and with all relevant parties — is necessary to establish an agreed-upon framework by which everyone can determine whether or not the product is on track.
If you don’t ensure everyone is working with the same success metrics, you might see your product as performing perfectly according to plan — while your developers, sales team, and executives, on the other hand, are underwhelmed because they had their own ideas about what success would mean.
Product managers often worry that setting expectations mean that they need to be a downer in presenting their product strategy. “I don’t think we’ll able to do these things,” they’ll have to say, or, “We probably won’t make much revenue in the first few months.”
But setting expectations doesn’t need to be this way. Indeed, it can be just the opposite if you do it intelligently — by employing realistic optimism.
When you set expectations — and remember, this needs to happen as early as possible in the process, ideally at your product kickoff meeting — frame your expectations positively.
For example: “In this phase of development we should be able to accomplish these three things, and if we can pull them off, they will represent a fantastic first version of our product.”
Of course, in some cases, a constituent will challenge your expectations. An executive might ask, “Why can’t we expect to have $X in revenue by end of the year?” A developer might demand, “Why do we need to include both of these features in the next release; can’t we choose just one?”
In these cases, I have two related pieces of advice. First, it is vital that you keep the discussion strategic, objective and focused on the product itself. You cannot afford to make things personal. The answer to these questions isn’t simply “because your gut tells you so” or because you really believe your approach makes the most sense. Your reasoning must be based on objective information — data you have about your product or the market, details about the company’s other projects and resource constraints, etc.
The second piece of advice, then, is to bring solid reasoning and data to any discussion in which you will be attempting to establish expectations. Your ability to cite legitimate examples supporting your strategy, especially when that strategy is at odds with the wishes of a stakeholder, will go a long way both toward convincing her of your point and enabling her to trust your strategic thinking elsewhere.
In its early days, Amazon often wowed customers by posting “estimated delivery dates” of five or six days away — and then in many instances actually delivered the products within two or three days.
Founder Jeff Bezos publicly stated that this was a feature, built into the Amazon shopping experience intentionally. Better to under-promise — to set expectations a little lower — and then over-deliver and delight your customers.
One great way to set expectations for your product, particularly with customers and with internal teams you will be working with on many projects over the long-term, is to set expectations a little lower — and then when you have the ability, over-deliver.
Give development a little more time in the final stages of a release. Be a bit conservative with your management team about revenue projections, and wow them by beating those estimates. Promise your customers a few key additions in your next release, and then deliver a great one they weren’t anticipating.
This tactic accomplishes several things. First, it trains you to become better at the difficult task of setting expectations. Second, it allows you to rack up successes for your product, yourself and your team. And third, it gives you more credibility with your constituents over time, an invaluable benefit for any product manager.
If you present a complete set of expectations all together, your constituents will often view them as one massive, unattainable goal — and become overwhelmed. What they see is: “We need a product that does this, that and those things, and we need it by this date.”
For this reason, part of the art of setting expectations is to present your strategy in chunks — a theme, a set of features, and maybe a timeframe — and to discuss each one independent of the others, at least at first.
This is why ProductPlan’s roadmap software allows product managers to build roadmaps without dates. Such roadmaps allow the relevant constituents to view and discuss the product’s strategic plan without a concern about what is or isn’t feasible in the timeframe — because the timeframe is simply removed from the conversation.
Often when a product manager presents a strategic plan — in a roadmap meeting, for example — and receives immediate pushback from development or sales or some other team, what’s happening is that those stakeholders are overwhelmed by the totality of the plan and unable to focus on its strategic pieces.
So treat each piece of your plan separately; give it the discussion time it deserves to earn your team’s buy-in. In other words, agree on expectations for each individual piece. Only after this process should you begin to discuss and set expectations for the plan as a whole.
At the beginning of a new product initiative, everything seems possible. The executive stakeholder envisions a product that will quickly take over the market and become synonymous with the entire category, like Kleenex. The sales team imagines an elegant offering sells itself. And the development team envisions a streamlined product they can build with minimal effort using an existing codebase.
But pretty quickly after these early, anything-is-possible moments, reality sets in. Budget constraints. Time constraints. Competing internal projects vying for the same resources. Stakeholders lose interest. Customers lose patience. Developers push back on timelines. Bug reports flow in from beta-testers.
The odds are low that your product will enjoy a smooth trip from your roadmap to becoming your industry’s Kleenex. Indeed, as a product manager, you can expect every product you oversee in your career to experience at least some significant setbacks and problems on its way to the marketplace.
But are these necessarily signs of failure? Not if you appropriately and clearly set expectations for your products, early and often, with all relevant stakeholders.
For understandable reasons, many product managers fail to properly communicate their expectations during product development. Sometimes product managers equate setting expectations with disappointing people. Product managers might also fear that setting expectations mean making demands of their co-workers, and they worry about the damage this could do to these all-important working relationships.
But, as I hope this post has demonstrated, the disappointments and damages will almost certainly be greater if you fail to set proper expectations.