A vote for everybody is a vote for nobody.
The best software and products dazzle out of the box. They set new boundaries and exceed expectations. And they don’t settle for less than outstanding.
Designing software with lots of stakeholders is complicated, but when the product manager prioritises reaching a compromise between all the stakeholders instead of pushing for unique, beautiful and remarkable, the result is more often than not unspectacular.
Worse still are product teams that are set up without a clear product leader – product teams comprised of a group of ‘area’ product managers, who are each responsible for their own product piece, but who together, and in a purely democratic way, are supposed to come up with one aligned, cohesive and most of all compelling end-to-end product proposition. This is called ‘design by committee’, and nearly always ends in mediocrity.
The problem here is that each area product owner is focussed on his or her piece of the overall proposition, and each have their own priorities, visions and strategies. Just packing these guys together in a room is not going to result in them coming up with a remarkable and balanced product proposition. What this scenario often results in is some kind of portal; it’s at best a mash-up of separate products – something that tries to do everything and ends up doing nothing particularly well.
A product needs a product leader – someone who is willing to make decisions that displease some people and to fight for the ultimate product vision. Michael Arrington, founder of Techcrunch, says:
“Product should be a dictatorship. Not consensus driven. There are casualties. Hurt feelings. Angry users. But all of those things are necessary if you’re going to create something unique.”
A product team should not be a democracy. A product team needs a leader; it needs someone who calls the shots and makes the decisions that will displease, disappoint and delight.
Consensus-driven teams often have challenges understanding and agreeing on what is important now (prioritisation) and what is important overall (scope). A product team made up of area POs have by definition conflicting objectives. The PO for component X believes that part is the key product proposition; the PO for component Y sees it differently. The result of the ensuing debate is often a compromise; “ok, let’s build it all”. In their fantastic book Getting Real, 37 Signals founders share their view on software design:
“Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit.”
Of course, there are important requirements that the ‘master’ Product Owner needs to fill. He or she needs to understand the product and be able to present a compelling vision. He or she needs to be able to make difficult decisions and disappoint some people, but be convincing and considerate in the explanation. Most of all, he or she needs to understand the product extremes that make the product unique and remarkable, and not compromise on them. In other words, they need to be a leader.
I’ve seen product teams try to fill this role with a Program Manager. It doesn’t work: a roadmap slide is not a product vision. I’ve seen product teams try to fill this role with a Requirements Manager. It doesn’t work: a requirements list, or even a product backlog, is not a product vision. I’ve seen product teams try to fill this role with senior managers who poke their heads in every so often. It doesn’t work: a day’s worth of rash, under-informed decision making does not substitute consistent and detailed thought.
A product needs a product leader. And if that’s you, then my tip is: don’t give in to consensus, and don’t settle! You will never please everyone… not all users, not all colleagues, not all bosses. So please, give up trying. Sometimes innovation comes from having the courage to disappoint people (and the wisdom to know when!).
