What is a Spike?
There will be times when you have to make a key technical decision about your product and the right answer is not known. It might be that you’re deciding between two possible partners for payment processing, or deciding whether to use a mobile framework like Ionic to build the next version of your app, or some other dilemma that has everyone scratching their head.
The right answer isn’t known by you or your developers because none of you have solved this problem before. What do you do?
One of the best ways to solve these kinds of problems is to have the developers create a spike.
What is a Spike?
The generally accepted definition of a spike is rapid prototype meant to demonstrate each of the possible solutions to a hard technical or design problem. I like to think of it as a bake-off. The purpose of a spike is to give you a more complete understanding of the options so that you can make the best possible decision.
A spike is not meant to be pretty or to have real users ever see it. It is the roughest possible version of a working end to end solution for the identified problem.
Running a Spike
So, how do you actually run a spike with your development team? Here’s the process I’ve used over and over, with much success.
- Define the problem clearly
- Set a clear, short time boundary
- Objectively evaluate the outcome
Define the Problem Clearly
This may sound obvious, but if you don’t clearly articulate the problem you’re trying to solve, there’s no purpose in running a spike. In our examples from above, I would define the problem something like this:
- For payments processors: We need to be able to support recurring payments in addition to one-off transactions, we don’t want to store credit cards anywhere on our network, and we must be able to support both US and Canadian currency
- For Ionic framework: We need to be able to support Android and iOS, but not Windows mobile, we have to be able to support GPS, accelerometer, and SMS from our app, and it must “feel” like a native app on both platforms.
Whatever your particular problem is, make sure everyone involved understands exactly what the objectives are and how you’ll evaluate the possible outcomes when complete.
Set a Clear, Short Time Boundary
A spike should be only as long as absolutely necessary. Most spikes can be built in far less than two weeks, usually in a day or two. I generally won’t run a spike any longer than two weeks because you can learn enough about even the hardest problems in two weeks to make the next decision. If at the end of the allocated time you’re still not sure or the answer is not as clear as you’d like, take a step back and identify the parts of the problem that remain unresolved and set up a second, clearly defined spike to resolve just those remaining issues.
Objectively Evaluate the Outcome
Developers (and perhaps others) will have biases toward one particular solution or another at the end of the spike. It might be that one payment gateway API was better documented, or there was something they didn’t like about a particular part of one of the options. Your job is to help uncover the truth in a particular recommendation. I typically will ask questions like:
- What did you like / dislike about Option A? Option B?
- What would you do if time and money were not an issue?
- If you were arguing against the solution you’re proposing, how would you argue it?
- If you were me, would you bet the product’s direction on your solution?
The purpose of this part of the spike is to learn as much as you possibly can from everyone involved so that you can make the final call. To the extent possible, you want to check everyone’s bias at the door or at the very least understand why the bias exists.
Just Remember
- Use a spike when the best path forward is not known to anyone on the team
- Make sure the problem is clearly understood by everyone before you start the spike
- Set a clear, short time boundary to ensure focus on the problem itself
Your Assignment
The next time you’re struggling with a decision on your product, use a spike to find the answer. Instead of trying to research and read your way to a solution, spend a few days actually building the solution with each of the possible options. The best possible solution will almost always reveal itself in the spike process.