Alpha is discovery

The problem with moving fast in a discovery, when you’re exploring a new problem domain or trying to validate a hypothesised solution, is that many things are uncertain. You’re working in the Great Unknown and it’s hard to get your bearings: when will we be done? what do we know and not know? have we made any progress? are we even in the right place?

These are all questions you’ll be asking yourself.

It’s a common trait for teams to get stuck in a discovery for weeks or months on end. This is normal. You’re trying to bottom something out, find the edges, and it’s natural to keep digging because the end is never clear.

As Jeff Patton says:

the primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity. And sadly, we can’t measure its features or stories completed. And, even worse, we can’t plan two weeks of it in detail because what we learn today can and should change what we do tomorrow.¹

The goal posts we normally set ourselves during delivery aren’t going to work. We need to optimise for learning velocity, and apply tactics that help us learn faster.

Loops not stages

Discovery and alpha stages are often presented as sequential. You do some discovery then move on to alpha. We think there’s these clear boundaries between the modes of working, and that you can generate enough knowledge in discovery to allow you to move on to alpha.

But it doesn’t really work like that.

Discovery – problem understanding – is a divergent activity: we go broad to gather lots of information and ideas.

In the Problem Understanding phase we gather data to help us understand and frame the problem. Data includes both qualitative and quantitative data, such as customer interviews, surveys, support tickets, sales call feedback, product usage, and NPS feedback.²

Alpha – solution exploration – is a convergent activity: we whittle those ideas down to the most promising ones.

In Solution Exploration, designers use the data gathered during Problem Understanding to frame the problem to be solved. Designers explicitly write down what the problem is, use cases, target users, and anything that’s out of scope. After getting buy-in from the PM and team, they explore solutions by creating sketches, wireframes, and prototypes. Engineers are looped in to provide feedback on technical feasibility. Researchers do usability testing in this phase as well.³

If you learn that an idea is promising, you’ll probably have more questions about it. But if your discovery stage has finished, it’s hard to go back and ask those. When viewed as separate stages, what we learn when exploring solutions cannot feed back into what we understand about the problem.

So we need to view discovery and alpha as a loop, feeding learnings from exploring solutions back into our understanding of the problem.

Manifest ideas to check understanding

To create this loop, do away with the idea of discovery and alpha as stages. Blend them together. Start bringing ideas in to your discovery to check understanding.

Make more use of sketches. You don’t have to plan time to create sketches or spend ages doing it, just get an idea out there quickly. “Sketches have fleeting value. They are valuable for a very short period of time.”⁴ You can validate ideas with a sketch, bottoming things out and whittling down ideas.

The sketch is not the end goal. The end goal of the drawing process is what you learn while sketching. So don’t worry if you can’t sketch. In fact, if you’re too good you might just fool yourself into thinking your sketch is a deliverable. It’s not. The real value of sketching is that it allows you to explore and refine ideas in a quick, iterative and visual manner with little overhead or learning curve. Rapid ideation around flow and interaction, layout and hierarchy, can be quickly established, rearranged or discarded wholesale—all without ever touching a computer.⁵

And a sketch can be anything. It doesn’t need to be what a UI might look like, it can be a series of words and arrows to map out a story in a scrappy, sketchy way. Or it could be the JSON output of an API call, a list of properties.

Manifest your ideas and put these in front of people, to check you’re understanding the problem fully.

Learning by doing

Working in this way is at the heart of lean product development. It’s about speeding up learning and reducing uncertainty by becoming comfortable with showing scrappy ideas. “The sooner we get our ideas out, the sooner we can figure out what those revisions should be.”⁶

It’s about learning by doing. Thinking and making as one activity, where what you learn improves your next try.

Don’t view these as separate stages. Alpha is discovery.

---