Celebrating ticket #1,111

Today Byrd hit a new - somewhat surprising - milestone. We’ve just made it to ticket #1,111. If you’re a developer you’re probably wondering why we didn’t celebrate after the first four number palindrome (quick answer: we didn’t notice). If you’re anyone else you’re probably already bored of the fact we’re talking about development tickets.

It seems counterintuitive that a product about running would have a strong opinion about development tickets.

Our mission is to enhance people’s health and well-being by providing personalised coaching experiences for runners. That mission extends to how the product interacts with runners. We have no interest creating a product that adds digital noise to an already noisy world. And we certainly don’t want to do anything that might inhibit someone from going out on an adventure. 

In early September 2020 we released our first beta. We had high hopes. I was getting over-excited talking as though it was a potential release candidate rather than an early test version. It did exactly what it should have done and it failed. With the benefit of hindsight the failure stings less and we can see more clearly how much we learnt. Over the last six months we’ve continued learning. We’re in the privileged position that we’re building something that hasn’t been built before.

Moving fast and breaking things is awesome if you’re happy to monopolise the time of the user who’s forced to fix it. We have a responsibility even greater than simply using up someone’s time though. Byrd is giving coaching advice and if it gives poor suggestions we run the risk of injuring a runner. When we first started as a team we created a series of design principles to guide creating Byrd. Top of the list “Don’t injure anyone”. It’s why in our white paper we talk extensively about how we’re trying to encourage disobedience and avoid learned helplessness. We’re determined to empower people using Byrd to question their training to better take control of their own progress. But whilst we have those safeguards we also want someone to be able to use Byrd without having to walk along a cognitive tightrope deciding whether the run they’ve been given is the correct run or merely a bug in the machine.

After that initial beta we added a new design principle to our sprint planning and retro ceremonies: “Measure twice, cut once”. We would - as much as we could - avoid releasing something broken to anyone by testing, dogfooding and refactoring. We’re the last people who want to get involved in premature optimisation - anyone who’s seen us running will see that we’re on the throwing-caution-to-the-wind end of the strategy spectrum - but we’ve also seen projects try to move too quickly and fail to get back up once they fall. As consumers we’ve all experienced the frustration of pieces of code that were put together poorly. We want to avoid anyone having that experience with Byrd.

So we’re celebrating the fact that we’ve reached ticket #1,111. It’s a signal that we’re committing to the first decade of existence rather than the first years. Our biggest hurdle in almost any conversation is the fact that we’re pre-revenue. There’s a pressure, and tension, to get something released as quickly as possible. We’re pushing against that. We want Byrd to be ready as much - perhaps more - than anyone else but we’re not releasing it until it’s ready.

We passed #676 in November, we hopefully won’t make it to the next prime palindrome with our tickets - ticket #10301 - before we launch. But if we have to run through tickets #1,221, #1,331 or even #2,001 we won’t mind too much. We’ll take it as an indication that we’re still learning, still experimenting  and ensuring that when we do launch the experience matches our vision.