Research gives us the problem, not the answer

I often get asked about how research fits into timeboxed work. If a team is working in a cycle and they can’t decide on a direction, should they do research? How do they fit that in a fixed timebox?

This cuts to a fundamental question of where research belongs. If the team can’t decide which of multiple directions is better, it means the project wasn’t sufficiently shaped. There wasn’t enough problem definition.

When I’m just starting to shape something, I go through this checklist in my mind:

1. What’s the current way people do this, without the new solution?
2. When does the current way not work?
3. What are they trying to do when it doesn’t work?
4. How will they know if the new way is working better?

If I know the answers to those questions, I can start looking for solutions. I’ll have a frame I can plug ideas into to judge whether they are better than the old way and if they do what they should.

If I don’t have that reference frame, I — and whoever subsequently works on the project — will be lost. There will be no way to judge where we are and whether any design choice is better or worse.

Any research needed to answer those questions has to happen beforethe cycle starts, before the bet is made, before the pitch is written, when the work is first shaped. It’s the very outer wall of the project that constrains everything else.

If we understand what’s wrong with the old and what the new needs to do, we won’t need to ask anyone, at any downstream phase, which idea is better. We have the information to decide ourselves. We can combine the constraints from the problem definition with the constraints of the timebox to select viable options. Then any option we like that works is okay.