Ship First, Debate Second: How To Build Better Products

Tell me if any of this sounds familiar. You’ve worked for the past week to optimise one of your product features, and it’s been going well. You have a few options to show the team, and you book in a slot at the design crit. After all, it’s good to get everyone’s eyes on it.

On the big day, you walk the team through the problem, your hypothesis, your thinking, and show them your ideal solution. You expect some minor feedback and green light to ship, because you’re eager to see how customers use it. Then, reality kicks in. Droves of feedback; some relevant, some not. You leave confused and frustrated; and certainly without any green light.

Designing is often the easy part of our job. We often spend more time waiting for feedback and going back and forth with decision-makers. We tweak copy to appease some opinionated, well-paid stakeholder. We make last-minute changes because someone was on holiday and gave feedback late. We modify bits of the design that will make exactly zero difference to the end user. As a bonus, to make sure you really earn your paycheck, you’ll also get battered by your engineers for not being ready on time. And they say Design isn’t a fun job…

If you know what I’m talking about, chances are you’re working in a company with a deep Culture of Consensus. To put it mildly, this whole work experience is likely only marginally better than a visit to the dentist.

Product Culture of Consensus

Let’s start by acknowledging the good intentions of the people running Cultures of Consensus. They want to build companies where everyone agrees, feels heard, and is excited about what they’re building. Sounds like a dream.

In practice, however, it’s not always so buttery smooth. ‘Consensus Cultures’ rarely inspire and excite employees. Most often they create work environments where people are frustrated, demotivated, feel a lack of empowerment, and where work ships at snail speed. The biggest issue is that ‘consensus products’ are nothing special.

So let’s take a second to summarise: good intentions, check. But the people are not happy, the work is slow, and the results are subpar. Perhaps we should take a critical look at those good intentions. After all, the road to shit products is fully paved with them.

—

In early-stage start-ups, consensus is easier to reach. If your entire team can share a pizza for dinner, decisions are likely easier to make. After all, most early employees tend to have a similar product vision. The problems appear when companies grow beyond those first few hires, and when it’s not clear who’s in charge of making decisions. When no one is making decisions, it means that everyone can make decisions. And since all opinions are equal, whether people have the full context of the work or not, the need for consensus becomes a universal veto.

As a Designer, you know this well. You’ve spent a week designing, working through all the edge cases, painstakingly editing each word to fit your narrative. You then show it to people who haven’t been involved, so they give you feedback without the context. Since everyone strives for consensus (or since some of these people are keeping your ass employed), you have to action that feedback. How many designers feel empowered to ignore opinions from a CEO or a Design Director? Might as well hand in your notice.

You might say that the solution is obvious: give more context when presenting work. No shit. I’m sure most designers try. But it’s difficult to put a week’s worth of context in a 5-minute Loom. Make it any longer and good luck getting timely feedback from a senior stakeholder busy managing three other product teams.

On top of this, I also find that in Consensus Cultures there’s usually a low level of self-awareness; a lack of understanding that the only certainty is reached when we ship. No one knows what’s going to work. There’s no secret recipe. If there was, we’d all be dining with Zuck and Bezos rather than sitting alone in front of the computer trying to redesign your portfolio for the third time this year. Feedback is just someone’s opinion. At best, those opinions are based on a successful track record. But even if that’s the case, the world is changing constantly. Something that worked three years ago in a different company with a different product might not work today. Shipping is what separates certainty from opinions.

Not sure you were able to guess by now, but I’m not the biggest fan of Consensus Cultures. We all have our faults, I guess. There are two ways of coping with it (or three, if you consider finding another job to be a coping mechanism): one is clarifying roles and learning how to seek better feedback. The other one is encouraging your team to adopt a Culture of Shipping.

Clarifying roles and seeking better feedback

Don’t tell anyone you’ve learned this from me, but not all stakeholders come equal, and neither does their feedback. But in a Consensus Culture, you have to act otherwise. This is made more difficult because, in general, our work can only ship after being ‘approved’ or ‘reviewed’ by someone else. We aren’t the ultimate decision-maker. But it might not always be clear who it is. Could it be your Design Director? Your Product Manager? The engineers? The CEO? It’s a Consensus Culture, so it probably is all of them.

Before starting a project, it’s worth rounding up the team and figuring out who’s in charge. Who has to say ‘go’ before you push the proverbial button? Frameworks such as RACI help define who is responsible, who needs to be consulted, and who needs to be kept in the loop. Take this with a grain of salt, but generally speaking, feedback from someone only kept in the loop carries less weight than feedback from someone directly responsible for the success of the release.

Having better feedback hygiene is also important. I like to use Flashtags to force people to think before dropping their wisdom on me, rather than me having to do all the work for them. They help you understand how strongly someone feels about their opinions. Flashtags might seem like an alien language to your stakeholders, but generally once you introduce the concept, most people get on board quickly. They also encourage people to be self-aware. Since they have to attach a Flashtag, they’ll think about their feedback more carefully. Is this really that important, or is it more of a suggestion that I wouldn’t die on a hill for?

Here’s an example of how I set the right context to get feedback. This was the first time we used Flashtags, so it warranted an introduction.

Notice two main points here:

One
We’ve made it clear that there are only two types of feedback we need—what needs actioning right away and opinions. That’s it. There’s no in-between. We’ve set the expectation that we’ll filter the feedback, so we might not action some of it.

Two
We’ve held people accountable. There are no exceptions to the Tuesday EOD deadline, unless you want to delay the launch. There are consequences for feedback given late. If a stakeholder has the power to slow down the team, happy days. But in that case, they are the ones who need to take responsibility for the pace of shipping, not the team.

Setting the right expectations, asking for feedback clearly, and keeping people accountable is step one. It will solve some of your headaches. It might even make a Culture of Consensus slightly more bearable. But there’s something better out there: pushing your team towards a Culture of Shipping.

Product Culture of Shipping

The other day I was listening to a podcast about Duolingo’s optimisation culture. I knew that they run loads of experiments, but I had no idea that by ‘loads’ they actually mean ‘a fuckload’. Six hundred experiments on their streak feature alone is an example of how biased for action they are. Listening to their story, I struggle to think of any reason for their rocket-like success…

Cultures of Shipping thrive on experimentation. Opinions and suggestions don’t matter as much as shipping fast, learning, and iterating matter. No over-valuing feedback from people who keep you employed. No weeks spent debating. No countless copy changes to the same damn paragraph. No releases delayed because feedback came in late. No having to sit in a circle, sing kumbaya, and agree that this, and only this, is the variant we’re all happy to go live with. None of that happens in companies with a Culture of Shipping. You know why?

Because they understand that we all build products using biases and experience and stealing inspiration and luck and so many other factors. There’s no way to predict what’s going to work regardless of how well you’re being paid, how talented you are, or how many people report to you. Experimentation is the holy grail of Product work. Unless you really enjoy the bitter taste of failure, there’s no way around it.

Cultures of Consensus aim to make people feel heard but rarely ship products that people love. It’s too much design by committee, success depends mostly on making the right decisions based on little to no context, and it’s slow. By the time you manage to launch, your competitor has shipped three times. They have a bias for action. For every week you spend debating, they learn and iterate. Now let that play out over a year, five, or ten. Who’s further ahead?

Here’s the best part about it: Cultures of Shipping readjust power imbalances. Seniority doesn’t entitle anyone to push their feedback at the top of the queue. Any reasonable opinion, whoever it’s coming from, becomes a hypothesis, which becomes an experiment. That way, we never launch the one version that we all agreed upon, even though none of us are completely satisfied with it. Instead, we split test more variants and let the customer decide which one is the best.

As a bonus, nothing levels the ego of your team like a failed test. Experimenting has a way of teaching everyone just how important it is to launch first and fight fierce opinion battles later never.

So how do you convince people in a deep Culture of Consensus to change their ways? My first answer would be that you don’t. You just change jobs, because trying to change people’s minds will lead to you losing yours. But that would be a silly conclusion after all this foreplay, wouldn’t it? So let’s put the best option aside and try to answer this in a different way.

From Consensus to Shipping

I’ve got good news and bad news. The good news is that there probably is a bulletproof way of shifting culture. The bad news is that I don’t know what it is. So instead, I’ll list three principles, which I follow when met with Cultures of Consensus, that might help.

First, understand that change takes time. Believing that you’ll come in and part the waters with your Design prowess is naive. You’re not that important and no one cares about your opinion as much as you think they do. I’ve learned this the hard way. This will take time and you’ll need help. You’re more likely to make a difference when you have backing. If you have a good relationship with Product or Engineering, leverage it. It’s hard to stop the train when all three—Product, Design, and Engineering—are on board.

Second, it’s best to start small. You don’t need a seismic shift, but to display the power of shipping fast in a safe way. Don’t go for the company cash cow. Pick a somewhat important project or feature, but not the main breadwinner, and use that to showcase this new approach. Demonstrate the power of shipping fast, learning, and iterating, then compare that to the ‘old’ way of working. Highlight how speed and learning benefit the company more than consensus does.

And third, whenever you see opinions diverge in the design phase, don’t encourage more debate. Instead, encourage experimentation. “I see we can’t agree on a direction today, would it be crazy if we tested both and let the users guide us?” Since you’ve already shown the benefits of testing, this should land well.

Your approach will differ from company to company. What works here won’t work there. Among other things, it depends on the culture, the openness to try new things, the people already on board, your relationships, and your seniority and respect. This is a complex issue, and the answer to complex issues is rarely simple and easy to explain in an article.

It won’t always be so black or white either. Companies will often mix the two cultures. Some fall bang on in the middle, some at the extremes. In some companies, it’s none of these; instead, you have one person who makes all the decisions. Bizarrely, I’ve even seen two product teams in the same company adopt different cultures.

Shifting your team away from a Culture of Consensus to a Culture of Shipping takes time, effort, and hard work. It’s worth doing, though. Once you change people’s minds, the benefits will show. From then on, it usually is a slippery slope. Sooner or later, the team will be keen to do more experimentation and sit less through the consensus pain.