Living in Amsterdam, I own - like everyone here - a bike. I use it to commute to work, go to parties, race to buy groceries just before the store closes; in short, I use it every day. Or at least I did, until my bike stopped booting.

You see, as I spend a significant amount of time sitting on the bike, I figured I might as well invest in a decent ride. So I got myself a first-generation VanMoof - a hip, fancy city bike that's slim and light, and has a built-in bike computer.

The computer itself is the bike's brain. It connects to my phone via bluetooth (completely useless), sends out a distress beacon and GPS coordinates if the bike has been stolen (useful) and turns the integrated lights on and off (can't ride without).

Imagine my surprise when, on a late post-lockdown Friday night, I jumped on the bike after a few drinks and instead of being greeted with the regular electronic startup tunes and the lights flickering to life, I got silence and darkness. My attempts to boot the computer into recovery mode were unsuccessful: whether using the app or the physical buttons themselves, all I got from the bike was a weird 'error' tune. Only a weekend trip to the store - where they took the frame apart and completely replaced the hardware assembly - got me my trusty bike back.

The one thing I got from this experience: I have been thinking about that 'error' tune a lot.

You see, the tune is completely different from every other sound cue the bike uses. In short, the bike is aware that something has gone awry - something that can only be fixed by fully replacing the on-board computer assembly.

That in turn means that someone coded the boot sequence to check whether something has gone irreparably wrong, and give the 'bleep' tune instead of a regular startup sound. Which of course means someone signed off on a 'play error tune when firmware is borked' feature.

Someone consciously took a product decision to have the bike recognize that the startup sequence has gone wrong, and instead of trying to fix it, it will simply play an 'error' tune and turn off, stuck in an infinite boot loop.

If this was a regular Product Management blog I would be ranting about how the bike shipped in unfinished state, how this is bad project management, about the abysmal user experience of - god forbid - actually have to go to a physical store to get your bike repaired.

But this is not a regular blog and I'm not a PM guru, and I think that whoever shipped the bike with a simple try/catch block during startup and a distinctive 'error' tune is actually a pretty brilliant product person.

You see, when shipping a product it's important to perform the holy trinity of good products: scope well, build well, test well. But, especially in the scoping phase, it's also easy to go into overdrive mode and overthink every possible edge case. Even more edge cases will pop up when building and testing, and fixing every single one of them will quickly turn your strategic product launch into a nasty game of whack-a-mole. As the team morale drops and the features start creeping, you'll start having doubts about whatever was important in the first place.

Whoever designed the bike didn't tumble into this pitfall, and managed to ship by aggressively solving down a very wide class of problems ('something is wrong in either firmware or hardware') with a single user experience loop:

  • refuse boot sequence
  • play distinctive 'error' tone to indicate user to seek adsistance
  • design a process for operations/support to resolve the issue as quickly as possible.

The bike, as a core product, is still operable when this feature is triggered. However, the ancillary product layer (the lights and sound assembly) clearly signals to the end user that something is wrong. It does so with a very clear, visible and difficult to ignore signal (the unique 'error' bleep). When the faulty state is triggered, it's up to the end customer to hit up customer support with a 'fix' request, that is performed relatively easily by swapping the ~50 € on-board computer in a few minutes, entirely free of charge.

Imagine the cost of developing all kind of feature flags and reboot sequences for a hardware product, which has no possible way of receiving over-the-air updates. Hundreds of possible edge cases, most of which would never be triggered, would need to be scoped and developed. And of course you'd probably end up missing a few - leading to confusion when the bike inevitably breaks in an unexpected way and goes completely silent.

Within the product's constraint (fast development for a hardware product, no way of updating the firmware ever, first generation bike only sold in a small geographical region with easy access to brand store for repairs), lifting the 'faulty booting sequence' set of edge cases outside of the product scope and into the operations/support scope makes total sense, and is a smart, time-effective and cost-effective solution.

Sometimes it's better to leave fault-tolerant design to space engineers, and focus on delivering products that are 99% functional and manage to push the user towards a well-defined operations and customer support flow. The bike that didn't boot did exactly that - hats off to the PM who shipped it.