I can’t stop watching Taskmaster. On the British game show, 5 comedians are filmed doing a series of tricky, often convoluted, tasks solo. Later in the studio, their attempts are shown, ranked (often arbitrarily), and awarded points. Each episode has a winner, building toward a season winner.

It’s a delightful, relaxing, often hilarious watch. My favorite moments involve how different people solve the same problem. Once in awhile, four contestants go down the obvious path while another short circuits the whole thing with a far simpler, faster solution.

The best example came in Season 2. The task was:

Four contestants tried desperately to get the balls to the top of the hill, where one would inevitably roll back down while they fetched the next one.

Richard Osman, though, didn’t accept the premise. He simply went and got the yoga mat on top of the hill, brought it to where the exercise balls were, and set them on it, winning the task. If you read the task again, you’ll see that it's a clever, equally valid, way of interpreting it.

Product development is living those four words every day: Don’t accept the premise.

That starts with feedback. Most of the time, there’s another story behind what you’re hearing, a struggle that led to the frustration that’s actually being shared. It’s particularly true when people ask for a specific solution or feature. If you accept it at face value, your product quickly becomes a convoluted mess.

That’s fairly standard stuff. What I’ve seen from Jason, particularly while spending a year building the new version of Basecamp, is how to live out that principle even while improving and revamping an existing product.

Basecamp 5 is built on top of the same codebase we launched with Basecamp 3 in 2015. Over nearly 11 years, an app evolves and expands. Basecamp is a rich, deep product with many corners and edge cases.

The goal with Basecamp 5 was to rethink all of it. What can we simplify and speed up? How can we remove the friction and complexity that creeps in over time?

The premise in this case was Basecamp itself. Every feature or flow has assumptions built into it, reasons why it is the way it is — we can’t, some people use it another way, but what about, it has to because, and on and on.

Those are premises that every instinct says we have to accept. But only by rejecting them, can you innovate and push the product forward. You have to test it all and see what’s immovable and what’s malleable. It’s exhausting work because everything is on the table at all times. That’s why adding a fresh coat of paint while leaving things how they are is the easier path.

During development, we cut many things that we eventually added back. We did miss it, it did serve a purpose, it does come up often. Everything had to make its case, though.

The same thing is true since we launched last week. We’ve brought back things we could live without, but it turns out are essential to some of our customers. That’s good! We want to learn that just as much as learn that no one misses something.

And that’s proven true as well. There are many changes and simplifications that seemed risky that are already just how Basecamp works.

Not accepting the premise is the only way to find out.

P.S. Here’s some of what makes Basecamp 5 a joy to use: https://basecamp.com/5 
Give it a try. It's the best version of Basecamp yet and unlike anything else out there.