Why Product Planning Fails

One of the most common questions I get from folks looking to optimize their product team's performance is: what's the right development process for us to use? After talking with them, I’m constantly left with the impression that most product leaders think they should be running Agile (note the capital “A”) frameworks like Scrum. The problem is, they can’t confidently say why. All that matters is that they have a clear-cut plan. 

I’ll let you in on a secret: there is no universal approach to product planning. The process for building a new light rail switching system for the Denver RTD will look a great deal different from the process driving a team that’s trying to make the next DoodleJump. Every team has different goals, end users, and rhythms. Trying to apply a method like Scrum across the board just won’t work- you can’t fit a square peg in a round hole.

Picture this. There once was a group of college roommates living in a row house in Baltimore and over time, their house inevitably started to get a little messy. They made a plan to stay on top of cleaning by assigning each roommate a set of chores and putting a schedule on the fridge to see that they got done. This way, everyone was accountable for pitching in on real chores like washing the dishes, sweeping the floor, vacuuming the living room, etc. Until one day when one of the roommates added ‘Make Crystal Light’ to the schedule.

What’s wrong with this picture? We may not all be children of the ‘80's so let me fill you in: making Crystal Light is not a chore. It takes about 15 seconds, tops. But, because this task was checked off the schedule constantly, it looked like this person was outperforming everyone else. The problem with pre-defining your product team's framework and tasks for a given period of time, and then measuring success based on whether or not they were completed, is that it encourages a sort of sandbagging and Crystal-Light-making. Teams often wind up doing less as time goes on, while getting better and better at celebrating their supposed "increased velocity."

This is why I find the process of "planning poker" extremely flawed. It puts too much focus on defining and predicting success, and not enough on whether or not you’re actually achieving it. Instead, what teams should be doing is taking stock of their unique needs. The ‘right’ methodology will depend on your goals, end user, and talent. The biggest influence on your product development process should be the people at the core of it, the makers, not what everybody else is doing.

Starting without a process and solving workflow problems as they arise, while letting talent and culture set the tone, is a decent way to go. It might not be the universal answer most product leaders are looking for, but organizing the development of software products isn’t one-size-fits-all. The sooner they embrace that, the sooner they can GSD.