Stewart Butterfield, Slack’s founder and CEO, wanted to bet on an idea called the “Bot Team” to solve one of the company’s most pressing product challenges. ¹

A year and a half after the company’s beta launch, over 500,000 people were using its team messaging product every day. ² But to maintain that rapid growth, Slack needed to expand to new audiences and reach beyond early adopters in the technology sector.

But how do you convey the value of Slack to a new user who hadn’t used an enterprise communication product before? How do you explain the benefits of having direct messages, channels, and service integrations all in one place, before someone has even signed up their team?

That’s where the Bot Team idea came in — new customers could try out Slack by chatting with a team of computer-controlled bots. Through the simulation, they’d get a clearer idea of how the product worked. It was a reasonable hypothesis — after all, what better way to learn about a product than to use it?

The engineering team estimated that building good-enough bots capable of basic interactions with new users would take at least six months of effort. Plus, the more time they could spend on it, the more believable they could make the bot team. There was a risk, however, that the fake team might confuse users — who are these bots, and why are they here? And after half a year, the team might be so emotionally attached and invested in the idea that it would be hard to change directions even if the idea didn’t work that well — would any problems rest with the idea or would they be solved with better bot quality?

So — should the team take the bet?

The Critical Role Pride Plays for Craftspeople

As craftspeople, we take pride in the quality of our work.

We want to attach our names to products that people love, to experiences that delight users, to code that elegantly solves technical problems, to systems that reliably scale to handle incoming traffic, and even to hacks that cleverly work around seemingly impossible problems.

We want to be able to point proudly to what we’ve built and tell people, “I built that” — and not have to hide behind a corner as they point out how bug-ridden or copy-and-paste-laden the code is or how slow or confusing the product experience is.

Pride in our work keeps our motivation levels high, and it’s essential to building high-quality products. If we’re not proud of what we’ve built — which can happen, for instance, when business deadlines pressure us into adding more and more technical debt — we feel drained and exhausted.

The strong emotions that come with pride, however, can also get in the way of our best work.

We’ve likely all been in the situation at least once in our careers where we commit to a certain decision — perhaps it’s how to structure our code, what architecture or design to use, or what feature to build and how to build it — only to realize a few weeks or months down the line that we made the wrong call. And yet, we’ll plow forward anyways and ship projects that are no longer good ideas and that we’re not happy with.

When we consciously make this tradeoff because what we built is “good enough,” that might be a reasonable outcome. But when we refuse to change direction or to abandon our work — even if that tough decision is the better choice — then we’ve let our emotional attachment to what we’ve built hold us back.

Psychologically, this happens for a number of reasons. We have trouble dealing with sunk costs — acknowledging that we might have to scrap all the work and effort that we’ve invested so far.

Sometimes, we just want closure — we want to just ship and wrap things up so that we can move on.

Yet other times, we worry about looking bad to our peers or reneging on any promises we have made. What will I say to everyone on the team whom I convinced months ago to go along with this approach? How will I look if go back on my commitment? In Give and Take, Adam Grant calls this phenomenon ego threat, and it can be a powerful motivation that keeps us on the wrong path for too long. ³

Our difficulty in reversing a poor decision is roughly proportional to the time, energy, monetary, and emotional investment that we’ve put in. When we’ve invested months or years into a certain effort or decision, it can be tough or demoralizing to simply throw it all away. Even if we logically convince ourselves that starting over may be the right thing to do, escaping the feeling that we’ve wasted a bunch of effort can be difficult.

Caring less isn’t the solution — that would just result in lower-quality and unmotivated work.

So what’s the answer? And how did the Slack team dodge this trap with the Bot Team idea?

Validate Your Ideas Early and Cheaply, Before You Get Too Attached

The Slack team adopted a clever approach to validate the Bot Team idea.

As part of a five-day sprint, they designed and built out a facade of a new user experience, and they had team members pretend to be bots by sending and replying to messages in a quasi-robotic fashion. The experience definitely didn’t scale, but it was more than sufficient to test out against five users to learn whether the idea had merit.

The Bot Team idea flopped. Only one out of five people enjoyed talking to who they thought were computer-controlled teammates, and feedback on the experience ranged from “she’s confused” to “I’m not really sure what this is.” They ended up shifting away from the bot team idea and focused on other ways to explain the product. ⁴

That test ended up saving the team at least six months of engineering effort, and they could easily move on to a different set of ideas and arrive at a better outcome. But just as more importantly, the approach meant that the team avoided getting too emotionally invested in the Bot Team idea — something that certainly would’ve happened with a project championed by the CEO and worked on for half a year.

The longer we work on something, the more emotionally attached we’ll get. And so if we can reduce the initial investment it takes to evaluate an idea, we’re more willing to make the right call and walk away.

We do that by validating our direction as soon as possible with real feedback, before we get too far.

When we iterate more quickly and when we incorporate feedback into our iteration loop, we’re less emotionally invested to any particular idea. After all, we’re just testing out different ideas to see which ones stick. We’re less likely to associate our reputation with any particular one. That gives us the freedom and the confidence to pursue the route most likely to succeed. This reduced emotional attachment is a benefit of fast iteration speed that’s not commonly emphasized.

So how might we build workflows to consistently get that early feedback? Here are some recommendations:

• When building something new, write a short design document that highlights salient details, and circulate it on your team to get feedback before you start building. At Quip, this has become a normal part of the engineering process that we do on Quip docs.

• When you’re pursuing a risky idea, optimize for learning about unknowns and de-risking the project early on. Don’t optimize for how you’d complete it or make it scale. During my time at Google, one common anti-pattern I’d see is that many engineers and product teams would build the first version to handle Google’s scale — that meant fewer and slower iterations and more costly failures.

• Build the simplest and minimum version of a product you can to collect user feedback. Or better yet, go a step further like the Slack team and just build a facade of that version that you can show to users first to further validate your product.

• Front-load your research and talk to real users and customers to understand their burning pains and needs before devoting your energy toward addressing what you think might be their problems. Tools like Intercom make it easier for teams to engage with users and collect real feedback.

• Aggressively defer any work not related to getting your first version out the door in front of a user. Close your product’s feedback loop as soon as possible.

• Run continuous user testing to build a healthy cadence of validating what you’re working on. At Quip, we’d sometimes run up to 12 user tests per week to build confidence in our choices.

By taking a validate-first mindset, we can prune out promising ideas that ultimately flop and be proud of shipping the ones we’re more confident about.