Tech, we have a problem. We’re too good at coming up with solutions.
If you give us a problem, we’ll give you solutions. We might even come up with a whole bunch of solutions. And fast. And then we’ll want to build them. And test them. And ship them.
But sometimes, these solutions we’ve built don’t solve the problem. Or they do solve the problem, but not very well. Or it looks like they’ve solved the problem but actually they made things worse. And sometimes, there wasn’t actually a problem at all. We just built stuff for the sake of building it.
I want to propose a better way of building products. A way that focuses on what we’re trying to solve before we decide how. That explores the full range of solutions while driving us towards the best ones. Something that doesn’t require the countless hours of debate, wasted work, or endless discovery sometimes associated with planning.
Enter POST. POST is a lightweight, data-powered solution that puts the problem space front and center and empowers teams to identify the best strategic path forward.
POST was initially created as an answer to the local maximum problem.
What is the local maximum problem?
Imagine we wanted to reach the highest point on a map. I drop you somewhere on that map and give you one simple instruction: you can only take a step if that step will take you higher than your current position. Using this rule, eventually, you will reach the top of a hill – at which point you won’t be able to move (because every step would take you downward from your current point). You may actually be pretty high up at this point. But now you’re stuck at the top of this hill. What are the chances this was actually the highest point on the map? What if there was a giant mountain at the other side of the map? You’ll never know.
When we optimize too early, we end up stuck at the top of a hill. POST helps us scan the terrain for big opportunities before we build, so we can spend more time on mountains.
To solve this, we stack our chances of discovering a mountain by exploring the territory before starting our search in earnest. The first thing we do is pick a map that we believe contains mountains. This is our problem space. Then we define what success looks like. Why do we care about height? Is it because we want a nice view? Or do we just want the exercise? This informs our objective. Next, we think about our overall approach to exploring the map. Do we start with North, South, East, or West? We use what we know about the map to narrow down our choices. These overall approaches are our strategies. Finally, we decide which hills to climb. These are our tactics.
- Problem space – what is the problem or opportunity?
- Objective – what does success look like?
- Strategies – what are the paths to get there?
- Tactics – what will you actually build?
Hold on, you may be thinking. We don’t need more process to slow us down. I’ve heard horror stories of companies that spend years in development hell trying to pick the perfect solution.
And, look, I hear you. I’ve been there. But POST isn’t about endless exploration. It’s actually the opposite. POST is about narrowing the solution space and identifying key areas where you need more information before proceeding so you spend more time building solutions that solve the problem.
For smaller projects where there is less unknown, I typically spend at most 1-2 hours building out a team’s POST. Just going through the process of filling out the framework provides an immense amount of clarity about what our team is trying to do and how we are thinking about our process to get there.
For bigger, riskier projects, POST can be used to identify areas that need more data. Each part of the framework can be used to identify an area that needs more validation.
- Problem Space: Does the problem space clearly ladder into company goals? Is this a real problem for your audience (or a big opportunity that exists)?
- Objective: Do you know what success looks like? Do you know how to measure it? Will you know if you are having the opposite effect?
- Strategies: Have you considered all the ways you could solve this problem? Why is your current strategy the best one?
- Tactics: Will the thing you are building solve the problem? Why is this solution the best one?
Simply asking these questions can identify critical areas of misalignment on the team and force discussion between team members and stakeholders about what, exactly, the team is supposed to be doing. The answers to these questions can also form the backbone of a product strategy, which can be used as a razor by which to judge decisions throughout the product lifecycle.
Stay tuned for Part 2 in this series, where I will dive into more detail on how to put POST into action on your team! If you’re interested in learning more about the difference between objectives, strategies, and tactics — check out my earlier post What is Strategy, Anyway?
Questions? Let me know in the comments below or reach out on twitter @tiny_data_tech.
Genevieve Conley Gambill is a UX Researcher and strategist on a mission to make tech better for all.
