3 June 2021
Theory of Change: How we tackle the Discovery
by Doug Alcorn
I was recently talking with a colleague about our Product Discovery and he introduced me to an old concept I was unfamiliar with: the Theory of Change (ToC). This is a very broad field of study that focuses on outcomes and develops programs to work backward to achieve those results. A naive application of ToC to our work here at Gaslight is to say that our software is the desired outcome and building features is how we achieve that result. We like to work with our clients to take a step back. The goal isn’t to write software, but to affect some larger change. In a future post, I’ll explore how software can do that. In this post, I’d like to take a brief look at how our discovery satisfies the Theory of Change. Consider this a jumping-off point for digging deeper.
The first thing that is needed is a shared understanding of the context. What is the problem you’re trying to solve? What context does that problem exist in? What assumptions are you making about the overall context? In our discovery, we like to focus on the users of our product. Those users live in a particular slice of the world. Understanding that perspective is key to a good solution.
After understanding the context and problem, the next step is to identify the impact you’re trying to make. That could be both near-term and long-term. In the short term, you might be looking for better data that might help you make better decisions. But what’s the impact of that? What does having this data really do for you? Sometimes we refer to this as “popping the why stack.” Think about what you want and ask why. When you get that answer ask why again. Do this several times until you really can articulate what you’re trying to accomplish without sounding too hand-wavy.
Lastly comes the solution. How does technology help you achieve these outcomes? What are the incremental steps you can take that will get you closer to those outcomes? In the Theory of Change, these steps along the way are called the sequence of required events. The justification of why these required events will produce the outcomes is called the logical model.
I’ve seen some complaints that the Theory of Change might be too complicated or too academic. It might very well be too heavy-handed for what we’re trying to do. However, I do believe very strongly that even though it seems like our job is to just write software, I think it’s much better to focus on what change you’re trying to achieve.
