The Seven Deadly Sins of Product Planning
Product planning is a big topic that many product organizations struggle with. It spans a range of activities including business strategy, product strategy, product roadmaps, portfolio management, opportunity assessments, project planning and tracking, and project oversight.
But in a phrase, product planning is where you decide what projects to invest in.
I have a series of articles I¹m working on that talk about different dimensions of product planning, but I wanted to start with one of the most common sources of problems for product companies.
No matter what product planning process you use, they all depend at some point on separating the good ideas from the bad. In several earlier articles I discuss Product Discovery, and emphasize how it is the job of the product manager to discover a product that is valuable, usable and feasible, and I argue that it doesn¹t make sense to proceed unless you have some evidence that you've achieved this.
What this means, to be explicit, is that projects that don¹t demonstrate this likelihood of success should be killed before proceeding to engineering.
What I wanted to discuss in this article are the reasons that projects that should get killed often don't get killed, and the consequences to the organization of this inaction.
So here are the seven biggest reasons that I see out there for not killing the bad ideas:
1. Inertia - probably the biggest reason that weak projects or bad ideas aren't cancelled is just because it's just easier to keep moving forward. Killing a project implies that you have the checkpoint in place to make this decision, and the data to make the call one way or the other, and many teams simply don't.
2. Denial - for many people it is hard to hear criticism, or deal with the reality of customers not liking their idea, so they basically try to convince themselves that there are explanations for the poor response and that once they build and launch the product for real that things will be great.
3. Pride - many people have this perception that if your project is killed then you have failed, and further, that failure is a bad thing. I keep trying to explain to these people that the far bigger failure is to proceed with the project, spending the time and money to build and launch, only to see it fail in the market. Sure it's possible that your project was killed because you weren't smart enough to discover a good solution, but it¹s more likely that the idea just wasn't that great and customers just didn't respond to it the way you hoped. Killing a project for these reasons is not a failure in any sense of the word.
4. Abdication - many leaders of product management think their job is to worry about who gets the cubicle by the window rather than take responsibility for the products the company produces. These managers are abdicating their responsibility as leaders of the product organization by not making the hard decisions.
5. Culture - some corporate cultures believe that it borders on being mean to cancel weak projects. Especially after all that hard work that has gone into the project. But company cultures that truly value their people despise the thought of wasting their most precious resource, their people, on doomed projects. It's only cruel if you punish or humiliate the people involved.
6. Deadlines - I call this the "feed the beast" problem the engineers are coming available next week and we have to give them something to build so get that spec finished! As ridiculous as this sounds, this is an all too common problem. This is why it¹s so important to build a backlog of worthwhile work so if you do have a team coming free and the project you were hoping for is not ready, you have other valuable work that is ready to go.
7. Hubris - let's face it, a lot of projects are the pet ideas of some executive that is personally convinced that something is essential. It's not so much denial as arrogance; they are the boss so by definition they must be right. Don't get me wrong, a lot of great product ideas come from very smart executives, but executives have bad ideas just like everyone else.
I view product discovery and innovation a bit like farming. You want to plant the seeds of a lot of ideas, and you want to nurture these ideas, but if you don't thin the weak ideas then they sap resources from the good ideas.
The truth is that many organizations out there are doing too many projects, many of which aren't worth doing, and the result is that the organization is stretched too thin to do a good job with the good ideas.
Ultimately it is the executive staff, starting with the head of product, that is responsible for ensuring that the weak ideas are killed so that the strong ideas can be pursued.
While most people can see the wasted time and money that goes into building and launching bad ideas, many don¹t realize that the even larger cost is often the opportunity cost what you could have been building instead. Most product teams have plenty of good ideas, they just have a lot of bad ideas as well and they don¹t know the difference until after they build and launch.
It is the job of product discovery to remedy this, and the job of the executive team to ensure that only the strong ideas are actually given the precious resources to build, test and deploy.