Based in LOs angeles, ca, bet, build, go is a blog by derek kwan. his posts explore building products at startups, and sometimes poker.

Too many cooks

You can overdo it with consensus. And your products may suffer for it.

 

Consensus is the absence of leadership.
— Margaret Thatcher

Gathering feedback is an important part of the product building process. It is only through the voices of your users and stakeholders that you can truly identify user needs and pain points. And it is only by identifying those needs and pain points that you can build great products.

From that feedback, you can discover commonalities, and then seek consensus from the larger group on those commonalities, which will lead to your solutions.

This may work perfectly fine for simple features or bug fixes. But for big bets, and generally any area where you are seeking to disrupt and innovate, overreaching for consensus will do more harm than good.

This is because consensus is seeking mass agreement, which is not easy to achieve. We are at times pretty disagreeable creatures. So consensus is often actually compromise. And mass compromise solves for safety, which will water down solutions, and consequentially fix problems for no one in particular. To hope for an outcome of innovation from this process doesn’t really make any sense.

True innovation approaches problems in unorthodox ways, and will put forth strange theses that trigger doubt, and sometimes ridicule. People find solace in familiarity, so to challenge established methods and solutions will be met with resistance. So how can true innovation ever really achieve consensus?

Additionally, consensus drags on the planning and development process. Everyone can have a voice, but ultimately, you as the product owner need to make a call. And those calls should not seek 100% of the information, or full consensus from every person. Doing so would equate to an enormous amount of group and individual meetings, and follow up after follow up. And you haven’t even started coding yet.

And honestly, very few people outside of product professionals consider all the trade-offs, complexity costs, engineering impacts, and broader needs required to build great products.

But how can you delicately turn people down without demoralizing them? One of the worst things you can do in a work environment is make individuals feel like they are not being heard. This is an express ticket to an organization that will hide feedback and issues from management, which will lead to disaster.

A good start is understanding why you are in such a rush in the first place. Speed to market matters a lot, especially in start-ups. Getting your MVPs out quickly not only puts your competitors on their heels, but improves morale across the organization. Furthermore, a speedy MVP will allow you to observe user behavior faster, so you can iterate (or pivot) quickly without having spent too many resources. Anything that prevents you from achieving fast speed to market is harmful, so pay attention to any hidden costs. So explain to the organization why speed matters, and why deadlines matter, and why coding needs to start tomorrow. In the end seek for a mindset of disagree and commit, instead of constant consensus.

Next, it is important to establish yourself as a product owner, who ultimately makes the final calls. Product owners need to establish themselves as an authority, and the most healthy way to achieve that is exhibiting constant good (and timely) decisions without needing all the information. An owner also needs to exhibit an intimate understanding of their users, problems, and priorities. The outcomes from that kind of background will be excellent solutions to user needs. So putting in that work to ensure everyone trusts your decision making will go a long way to getting people to disagree and commit. A great book that discusses building products that people love, is Hooked, by Nir Eyal.

Consensus can be great in a lot of situations, but when it comes to building innovations, you have to think differently, and execute on a vision for a future that no one imagined was possible. And this cannot be achieved by seeking mass consensus.

Learning materials for product managers

Making decisions under uncertainty