The Tarantino: how to do product design the wrong way and learn from it

Our team at MetaLab is piloting this new thing when we start on a new project, and it’s working really well. At the very start of the project—once we have a rough idea of what this product or feature looks like—our team block off a full day. Then we each go away individually and design the whole product in one day, solo. No wireframes, no user testing, no iteration, no feedback or sharing.

If this sounds wrong, it’s because it is. Good product design work is done by doing the exact opposite: starting broadly and exploring lots of potential solutions in really rough fidelity (sketching, wires), working collaboratively and getting feedback from each other early and often, and testing and validating our assumptions with users.

The reality is that after we do this exercise we regroup, share our designs with each other, and then go back and do everything again, the right way, over the course of a few months. So why do we do this? Well, there’s a few really exciting things that happen with this exercise:

1. Blank slate syndrome: Starting on a net new product or feature is hard. The more ambiguous the idea is, the more daunting this first step is. The beauty of the Tarantino is it puts a forced constraint on you and leaves no time to waver over how to approach things and makes you just DO it. For me, it’s the same clarity of thought and creativity that comes with procrastinating on a task and leaving it to the last minute.
2. Throw down the dumb idea: I love getting the bad ideas out of the way. Just like crazy eights, the interesting solutions often come after the obvious, boring ones. A Tarantino lets you get those top of mind ideas out, and lets you see where (or if) they break down in execution.
3. Pinpoint the hairy problems: Doing a Tarantino is like doing a test run of a ski slope. You get to see which part of the product or feature you vastly underestimated complexity of, and need to allocate lots of time and exploration to in order to nail all the gotchas. Now, when you go to design the product for real, you can plan accordingly.
4. Get aligned: Because we all go away and work in silo before coming back together, everyone’s vision for how the product should work and be designed is different. I love seeing how each of us has interpreted the problem differently, and this lets us having fruitful conversations around the benefits and drawbacks of each approach. Doing this early, and with something tangible in front of us means we have a really solid alignment on the problem.
5. Get a wealth of explorations to start from: Since our full team does their own executions, we effectively get a variety of ideas to draw from that are usually quite different from each other.
6. Keep the good ideas: Every time I’ve run a Tarantino, some nuggets of really great product ideas come out of it. Take these and develop them further.

There’s a lot to be gained here, and I think it’s a great investment of one or two days time. Give it a shot on your next project!

P.S. Oh, why is it called a Tarantino? It’a a witty name Brandon_Arnold came up with because Quentin Tarantino movies are known for their non-linear (time travelling) story structure.

P.P.S. Prior art: I’m sure we are not the first to have adopted this approach. I know many other design teams have “discovery” phases, but I haven’t heard of ones this short. For further reading, there is also this great post by Stuart Eccles on a related topic of designing into the future with some great ground rules.