The term tracer bullet development originates in software engineering by Andy Hunt 1. In any software project, possible solutions may vary or even be uncertain after all. The idea of tracer-bullet development, just like the original idea of a tracer bullet is to shed light from beginning to end in an unknown territory 2. It aims at providing a basic architecture and a proof of concept as early as possible.
Transferring the concept to services
In recent projects we transferred the concept of tracer bullet development into service design and expanded on it. Below you find a few basic rules to consider, whenever a feasibility challenge, no matter if hard- software or service arises.
Risky bits first
Make sure to tackle the most risky aspects of the challenge at hand first. The whole idea of the tracer-bulelt is to have early validated learning along the entire customer-journey. So make sure the key aspects are working as you expect them. There is no need for a shiny “production ready” version. Making sure to know “how it will work” is enough for the start.
End-to-end test
It is easy to fall into the trap of testing the most challenging bits only. However, you can only make sure a service works if the whole thing is working from beginning to end. What does this mean? Take for instance the idea of having a parcel delivered to the trunk of your car by a delivery service (yes, there was an actual prototype for this). 3 There are several rather technical challenges at hand, e.g. opening the car temporary, defining the authentication mechanism and so on. However, a major issue with the underlying service is: trust. End we must not forget this aspect. It is as crucial as the technical challenges. So make sure you also solve the not-so-obvious but most probably eventually deal-breaking issues as well, from beginning to end.
Prototypes will be thrown away
The first rule of prototyping is that prototypes are made to be thrown away. Make sure to exercise this task early. Create a “shitty first draft” (more on this soon) and then throw it away. It is widely known (and you most probably also know taht feeling) thatn when you spend enough time with something, you are less likely to throw it away. This is true for any work, be it concepts, books, presentations or designs. The more time is spent with someting, the less likely it is going to be discarded in its entirety.
Set up for learning
This is an often missed point. When you set up your tracer-bullet make sure to consider how you are going to learn from what you have at hand. And even before that, define what you actually want to learn. Why are you building the prototype? Is performance an issue? Is feasibility an issue? Size? Weight? Trust? Whatever it is, think before you start how you are going to measure the result and define what success looks like.
Keep it lo-fi
The higher-fidelity the prototype, the higher-fidelity the feedback. While I don’t entirely trust this saying, there is some truth to it. Give someone a shiny design for a service ad and you will receive feedback on colors, fonts, alignment, image usage and so on but never on the actual thing that the ad is, well, advertising. The main point here is not to waste time with shiny little details but rather keep a high level and overall-perspective. A nice analogy that I like: If we were travelling to a city somewhere, what we need in the beginning is a map of the whole distance, not a district in the destination city. The latter won’t get us anywhere in the beginning.
Happy hacking!
