One of my favorite all time sayings goes like this: “A camel is a horse designed by a committee” This is by not by any way of denigrating camels, of course– I grew up in the Negev desert where we regularly encountered “camel crossing” signs, and I can attest that, they are wonderful animals capable of amazing feats. It’s just that they are not very good horses, and if your market research says you should build a horse and you give the market a camel instead, your product will probably not achieve its goal.

The distinction isn’t as cut and dry as you might think, either. Consider the following specification:

1. Build a stable animal that is not easily tipped over and can cross various, sometimes rugged terrain, at an average speed greater than a walking human.
2. Animal must be able to carry up to two adults or cargo of equivalent size.
3. Animal must be able to graze, drawing most of its nourishment from its surroundings.
4. Animal must be trainable and respond to basic commands.

You can probably see that these requirements could lead you to build a horse, a camel, or indeed an elephant. Further, while most companies would consider an elephant to be too resource heavy for the average user, the temptation to build a camel is great because it has a lot more cool features: It can cross deserts, it can go days without drinking, you can shear it for wool, and you can even race it.

When you have a committee that is building a product, every person tends to understand the market differently, and every person pushes for their favorite solution that they think will address market needs. The problem with that approach is that when you do that you end up with an animal that’s really cool, but one that also stinks, spits, takes longer to reproduce, and is a generally very bad horse. Ultimately though, what most horse riders out there want is just a good horse.

In Scrum, we address the committee problem by designating a Product Owner. One person, and only one, whose job is to have a vision of the product based on their knowledge of the market. It is the Product Owner who has the final say on what product to build, and it is their prerogative to decline any requests for features or modifications that don’t align with that vision. In other words, it is the Product Owner’s job to say “the thing that you are talking about is very cool, but it is not a horse.”

The Product Owner job is perhaps the most challenging job in Scrum. They must know what a horse is to build one, and they must figure out what kind of horse to build (more on that in a different post). Does the market need a draft horse, a racing horse, or something in between?

Further, Scrum says the following about the Product Owner:

For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

https://scrumguides.org/scrum-guide.html#team-po

This is a challenge to the whole organization. Imagine being the CEO of the company who comes to the Product Owner with a suggestion for a cool feature and is told no. Imagine being the Product Owner in that situation, especially when it seems to repeat again and again. The CEO must put their ego aside and trust the Product Owner to build the best product that they can envision, and to use every tool in their disposal to make sure that it aligns with market demands and expectations. As a freelance Scrum Master or agile coach part of my job is to help the CEO and Product Owner learn to communicate productively without the Product Owner becoming a meaningless position. And of course, as a freelance Product Owner it’s my job to listen closely to what the CEO wants and figure out which features they think should go into making a Horse.

While we’re on topic of horses, I will mention another famous quote, this one attributed to Henry Ford:

“If I had asked people what they wanted, they would have said faster horses.”

https://www.entrepreneur.com/article/290410#:~:text=Henry%20Ford%20was%20one%20of,would%20have%20said%20faster%20horses.%E2%80%9D

Ford was a Product Owner with a vision. He saw a demand in the market, and envisioned a new and novel way to address it. He wasn’t the first to do it, but he came up with a way to do it better and changed the course of human history in the process. That’s the power of one person with a vision.

Of course, Ford’s quote has often been criticized as espousing the idea that true innovation does not require customer input. This is clearly not the case, and Scrum defines customer feedback as being so important as to say that the only way for a Product Owner to validate the value of their idea is to release them to market. The product vision that the Product Owner holds and shares must be subject to constant scrutiny, expermination, and refinement to make sure that the assumptions they are making about the product are correct.

And who knows? Based on research, maybe the Product Owner will end up building a camel. But it will be a camel shaped by empirical process, by testing, experimenting, research, and the understanding that when the market says it wants a horse, this is what it really has in mind.