In my last post, I highlighted a core problem with how most of us work in tech. We’re obsessed with building solutions, often before we understand the problem. I proposed a better way to build products with POST. Today I want to talk through each part of POST, starting with the problem space.
Problem Space – What is the problem or opportunity?
It’s impossible to know whether you’ve picked the right solution if you don’t know what you were trying to solve in the first place. Teams must have a clear problem space they are responsible for. Problem spaces can come from a lot of places – an unmet need of your audience, a market opportunity, or a product innovation. Whatever the source, problem spaces should be based on solid evidence. If at any point in the process, you aren’t sure you have a strong case for your problem space, you should focus on testing that before anything else. Figuring out the best way to climb a hill is useless if your map was flat to begin with.
As a UX Researcher, I’m biased to believe that you should have at least some evidence that there is an audience with this problem. But behavioral analytics, market research, or even deep product experience can all be valid sources of evidence. The most important thing is that you have a strong, logical, and validated reason to believe this opportunity exists.
Objective – What does success look like?
If you want to choose a good solution, you need to know what good looks likes. Your objective should describe the state of the world when this problem has been solved or opportunity met. What has changed because of your team or product?
You should also have a way to measure whether this condition as been met. I want to stress this next point: a KPI/metric is not an objective. Metrics are a proxy for measuring your objective. There are often many ways to increase metrics that have nothing to do with your objective. That’s why it’s important to have a combination of metrics that represent success (including sentiment and behavior).
It’s also important to know what bad looks like and think through how you will know if you are failing. I often ask teams “what could it look like if you were close but meaningfully off from your objective?” For instance, how might your product or feature be used in a way that looks positive from a metrics standpoint, but is actually bad for your audience.
Finally, you need to know what “good enough” is for your objective. How high is high enough to get that view you care about? Call your shots before you start developing (and make sure your stakeholders are onboard). There might be a point on that mountain where you start losing oxygen. Too low, however, and you won’t be able to see over the trees.
Strategy – What are the paths to get there?
Once you know what you are trying to achieve and why, it’s time to figure out the best way to get there. Most teams I’ve worked with in the past tend to start with tactics (what I’ve been calling solutions). For instance, they might run a brainstorm to pitch different features they could build to reach the objective. Or maybe the team was started based on a specific feature idea and now is being asked to think about the problem. This is a fine place to start, most developers think in terms of features. But it’s important to hold yourself back from going and building the best idea of the bunch right away.
Why? Because it’s likely that you haven’t explored the full solution space. We’re right back to the local maximum problem again. Instead, use the tactics you’ve generated to form categories of approaches. I call this “bucketing up”. Come up with as many ideas as you can based on the problem and objective. Then take all your ideas and search for commonalities that describe similar approaches. These become your buckets. Based on these buckets, you can probably come up with a lot more ideas you didn’t identify in the first round. Rinse and repeat.
Let’s use video game development as an example for a second (my bread and butter). Imagine your objective is to improve teamwork in your game. It’s easy to jump straight to solutions:
- Give them prizes for good behavior!
- Take away prizes for being a jerk.
- Ban them from the game if they are too mean.
- Teach them about teamwork.
You can try it yourself. How many ideas can you come up with before you get stuck? Go ahead. I’ll wait.
…
Okay, if you’re like most people, you can probably come up with 5-10 solutions right away. But what happens after that? We stall out.
But what if we take these a level higher to categories of solutions. For instance: we can reward players, punish them, remove them from the game, or help them improve their behavior. Guess what? There are hundreds of ways we can do each of those that we hadn’t previously considered. And some of those strategies are likely to be more effective than others.
We can also evaluate this smaller set of high-level approaches more efficiently than testing each of those hundreds of ideas independently.
Tactics – What would you actually build?
Now, finally, it’s time to think through and evaluate what you might actually build to solve your problem. Based on the strategies (buckets) you’ve identified, you can generate and prioritize solutions to test. It’s at this point, and this point only, that you want to start doing more tactical evaluation like concept testing, usability, and A/B testing. Doing those any sooner and you’re likely wasting your time.
Here’s another metaphor to help explain what I mean. Imagine that your decision-making process is a body of water. Big decisions (like what problem space to work in) are like a river. Your strategies are streams that come off of that river. And the tactics are creeks. Changing the direction of a creek can only redirect the flow of water so much. Moving the river (while difficult) can result in major shifts. It’s important to make sure your river is flowing the right direction before you go fussing with the creeks.
It’s important to validate big decisions — like what problem space you are tackling — before worrying about tactics. Changing the direction of a creek can only redirect the flow of water so much.
How does your team keep focused on the problem to build the best solutions? Let me know in the comments below or message me on Twitter @tiny_data_tech.
Genevieve Conley Gambill is a UX Researcher and strategist on a mission to make tech better for all.
