Choose boring solutions

One of my favourite posts ever is Choose Boring Technology by Dan McKinley. In that post, Dan explains why it's important to limit the number of unknowns that a team has to deal with at any given time.

He introduces the concept of innovation tokens as a simple way to track and limit the introduction of unfamiliar technologies or architecture. An innovation token is consumed every time you use a new tech or concept that requires a substantial learning curve, and you're only allowed 3 innovation tokens at the start of your journey.

The goal is to create a stack where most parts are boring – meaning that the team can easily understand and implement them. The idea isn't to pick bad technology, but rather to minimise the time spent on learning how things work, and to maximise the time spent on understanding what users want.

For instance, a new startup doesn't need to start with Kubernetes, especially if they don't have product-market fit. And even an established company does not need to rewrite their critical billing service in Rust if that's the first time the team is exposed to that language.

There are many great technologies out there. But, most companies won't need them to make their users happy and grow their business.

Innovation needs to happen, yes, but only 3 tokens at a time.

Boring also applies to strategy

Dan's post was mostly focused on engineering, but it translates really well to strategy. You set your OKRs, then figure out the best roadmap and tactics to achieve the goals newly established.

But the problem with strategy is that it's really hard to predict what will work. Most experiments fail, and it's quite likely that 25% (or more!) of your projects won't deliver the results you expect. That's why you should treat projects like bets. Some bets will work, and you will double down on them. But other bets will miss the target, and it should be easy to discard them.

So the question is:

What's the fastest way to discover what works and what doesn't?"

Similarly to the tech problem, your goal should be to minimise the time spent on implementing bets and maximise the time spent learning from your customers.

And one way to make that easier is to pick boring solutions.

Once again, boring doesn't mean bad. It just means that we should pick approaches that we know or are easy to learn, so we can quickly get to the point where we are testing our ideas. It also means doing things that don't scale before building the automated version of it. The more complex we make our solutions, no matter how innovative, the more time goes by before we can get real feedback and data.

I remember clearly the example of an online retail business that tested a new approach to returns by having devs manually print QR codes for a batch of users. They quickly learned that their proposed solution would not work, even if automated. They saved 3 months of work by picking a boring way to test their bet, then quickly switched their focus toward other opportunities once they realised it wasn't a good one.

At Tability, we recently added a list of task statuses to allow more flexibility than just "open"/"closed" (ex: planned, in progress, in review, done...). We know that the best solution is to allow the list to be customised, but we decided to ship a simpler static list as an MVP. Tasks usage grew by 20% as a result, and we can now work on a more sophisticated solution.

Some other examples:

• Buying a proven email marketing solution instead of rolling out your own newsletter service.
• Using Qwilr or Canva to quickly test a sales deck instead of waiting a few weeks to get a custom design.

Validate with boring, scale when confidence increases

Our brains love novelty. There's something quite exciting about exploring new technologies, and it's hard to resist the temptation of applying innovative solutions to complex issues.

But, we should always optimise for time-to-feedback. That is, how much time goes by before you can get real feedback from the market. The more we accept that we can be wrong, the easier it is to start small.

You can then iterate as your confidence increases.

• Start with a boring MVP: this is the non-scalable approach that you should be able to deliver within a couple of weeks. It might not handle all use cases, and the underlying approach might not be pretty. But, it's a simple way to validate your bet and confirm that you're on the right path.
• Then upgrade to a boring solution: the boring solution is still built with simple tools and methods. But you're now plugging some of the edge cases and automating the manual tasks.
• Finally, optimise with innovation: once you're quite certain you've got it, and when you also feel the need to scale, then you can look at innovative approaches to your problem. But that should be rare. A boring solution will be enough in most cases.

One last thought before we go. A boring solution should not result in a sh*tty user experience (pardon my French).

The minimum threshold for UX is "Good". There's a big difference between finding a simple way to ship something good and lowering your standards to ship a project faster.

You can downsize the scope of your projects, but you can't diminish the quality of your outputs.

--

Are you using OKRs? We've got a "boring" way to simplify tracking rather than crafting your own spreadsheet → Check out Tability.