It seems many executives, salespeople, and marketing teams have little understanding of how product management contributes to the success of today’s products.
Tom Smykowski: Well… well look. I already told you: I deal with the damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people? (Office Space, 1999)
One VP believes “waiter” is the role of product management. In his view, the customer (or salesperson) asks for a feature, the product manager takes the order to development, and then the product manager delivers the feature to the customer when it’s “cooked.”
Here’s what’s wrong with that metaphor: It assumes that the desires of one customer represent a market full of customers. And for that matter, it assumes that customers actually know what they need, which is often not the case.
The challenge of managing products, whether you have a product manager or not, is balancing market demand with organizational resources. Finding the vital few rather than the compelling many.
You can't have everything
An understaffed team cannot produce more than they can produce, no matter how "agile" you think they are.
Every organization has a request list that is greater than its resources. Do the math: You’ll never reach the end of your request list if your team is staffed to build 10 things per week but 20 new things are coming in every week. In no time, the queue of work to be done is 9-, 12-, 18-months long. New (and often important) ideas can’t get done because of the overloaded backlog.
There’s an unwritten rule in product management: if it ain’t been done in a year, it ain’t never gonna get done.
In one company, the president told me development was broken. When I checked with the development team, they explained how they got new and different requirements every week, immediately after the senior staff meeting. They could never finish anything because the executives continually changed their priorities. I went back to the senior staff and said, “I found the problem in development; it’s you!”
Showing Kanban to the senior leadership team helped them see the flow of work—especially the idea that “once it’s being worked on, we will accept no changes.” We can reprioritize planned work but never touch work-in-progress.
You can't have everything now
Which of your number one priorities is the most number one?
You can probably have most things eventually, but you must have some order of priority. You must choose what is truly important today. Ideally you want a method that aligns priority with strategy. In any case, there's always another release; there’s always another model.
Sales and marketing teams want to know which features will be available a year in advance. And the answer is: nobody knows—when priorities and resources are in constant flux.
One of my sales teams demanded a commitment. “Okay,” I said. “I can commit to this, assuming there are no changes.” And they didn’t like that either. They needed to revise the plan based on changing market conditions. So which is it? Do you want a fixed commitment or a flexible plan? (And yes, I can hear every salesperson thinking, “Yes. Both.”)
Johnson’s Resourcing Conundrum: We allocate 100% of our resources to the roadmap—and then somehow expect to use the other 100% for special situations.
Feature ideas are like marketing leads. Sales teams pick the best leads to pursue now—the hot ones—and put the rest on the back burner to consider as time allows. Same for feature requests: product managers focus on the hot ones.
You can’t get anything if you don't have anyone working on it
One product manager reported that her entire team was in the hospital with Covid-19. And her boss said, “Will that impact the roadmap?” (Doh!)
No work can be done when there are no people working on it. It’s not like we have a spare technical team standing by!
It’s similar to the airlines. They don’t have spare planes or people. Your flight will most likely be canceled If the equipment is broken or the crew is unavailable. And still, despite the airlines incredibly sophisticated scheduling systems, over 10% of flights are canceled or delayed each year.
People are not interchangeable “resources.” They cannot easily be moved from project to project. Moving team members from one urgent problem to another urgent problem slows down the resolution of both problems.
One person’s top priority is not necessarily the organization's top priority.
For product organizations, profitability lies in building it once and selling it many times. The single customer (or salesperson) doesn’t represent the market full of customers. But, of course, everyone wants their thing to be the top priority. The challenge for product managers is to identify the few items that meet the needs of most customers.
I once presented a roadmap showing the epics for the next year—the big chunks of work. Kevin, the world’s worst salesperson, asked, “Where is the feature I want?”
I replied, “That is part of this epic, and it will probably be in the summer timeframe.”
“But I want it now!” he said.
Since I was speaking to the entire sales group, I asked, “Who else needs this?” And it was only Kevin. Putting Kevin’s request at the top of the queue doesn’t help anyone but Kevin. And made me wonder if any customers really needed the feature—including Kevin’s.
Creating products is less like cars and more like books.
Manufacturing is simply the wrong metaphor for product creation. Consider automotive manufacturers: They don’t just start building cars. They spend years designing and testing the new model, then they design a manufacturing process, and only then do they start producing cars.
Writing software (or any content) is more like writing a book.
Most writers block out an outline of the characters and the major plot points. They group the plot points into chapters and then write the sentences and paragraphs. Sometimes the process of writing results in interesting discoveries or plot twists that weren’t originally planned.
This metaphor closely matches software and content development. Products serve personas. Personas have journeys. Each journey is a series of epics addressing major problems. The epics are broken into scenes (or stories). And, as with some books in the old days, software can be released one chapter at a time.
“[Charles Dickens] novels, most of them published in monthly or weekly installments, pioneered the serial publication of narrative fiction, which became the dominant Victorian mode for novel publication. The installment format allowed Dickens to evaluate his audience's reaction, and he often modified his plot and character development based on such feedback.”—from the Wikipedia article on Charles Dickens
Hmmm, sounds like software to me.
The Three Keys
Prioritize. Good product managers are constantly evaluating the market’s top priorities and adjusting product plans accordingly. They focus more on problems to be solved than features to be built. They filter and prioritize and validate continually. And keep stakeholders informed of what’s really happening (and likely to happen) with their products.
Be Transparent. Good product managers use roadmaps, plans, and schedules to keep all stakeholders informed.
Be Market-focused. Good product managers focusing on the needs of the market full of customers and potential customers, not the needs of one customer.
Product management is how product businesses scale. Our goal, and hopefully yours, is to turn good ideas into successful products systematically.
Read our eBook How to Achieve Product Success for more!
