Anytime our team starts spinning our wheels trying to think up the best solution for a design, feature, decision, or general problem, Josh Rothman, OtherLeft’s CXO, proudly asks his favorite question (in a very southern accent): “What is the problem we’re trying to solve?”
It is all too easy to get stuck in a cycle of solutioning, especially in a group brainstorming environment. One good idea leads to another, but often the group swiftly ends up down the wrong creek without a paddle. We may end up with a great, technologically advanced, beautiful, elegant solution—but is it the right solution?
A client provides feedback on a design we’re very proud of, simply stating, “I don’t like how the user has to select their choices on this screen.” We take the design back internally, start to research all the ways to implement choice selection on a mobile device, and offer favorite examples from apps we use when Josh asks his question: “What is the problem we’re trying to solve?”
We take a step back and realize that substituting one method of choice selection for another may not even solve the client’s issue with the design. Do they think the current solution is too confusing? Should the choice selection come earlier or later in the workflow? Do they think it’s not obvious enough that a choice has been selected because the color isn’t dark enough? Each situation would require different changes to the design—some much simpler (and less expensive) than others. If we spend time solving the wrong problem, we put ourselves into a frustrating cycle of iterating without improvement, which can be costly in both time and budget for both sides.
Understanding the problem to be solved is important in both the smaller project tasks and the bigger picture of product innovation. At OtherLeft, we pride ourselves in being professional problem solvers: by identifying and solving the right problem, we ensure that a product truly meets the needs of its users. As Eric Ries repeatedly states in The Lean Startup, “If we're building something that nobody wants, it doesn't much matter if we're doing it on time and on budget” (sorry, project managers!). Creating the wrong product, i.e., solving the wrong problem, wastes money, time, resources, and lost opportunities due to extended time to market. That is why we at OtherLeft place extraordinary value on defining problem statements.
A problem statement should act as a guide by which potential solutions, features, and decisions are evaluated. If a proposed feature does not contribute to solving the defined problem, it should not be included in the build—ESPECIALLY not in an MVP release. Once the problem statement has been carefully crafted, we tell our clients to write it on a sticky note and hang it on their monitors (or if they’re really passionate about their product: tattoo it to their foreheads).
Identifying the problem statement has many benefits:
1.Exposing stakeholder misalignment
Problem statement creation occurs toward the beginning of our Strategy & Design engagements. We begin the activity by requiring all stakeholders to individually write what they believe the problem statement for their product to be (see ideal format below). Our team members also each write a problem statement based on what we have learned up to that point in the project.
Often, client stakeholders will assume that their team is aligned, but their eyes are opened when we collect the problem statements and compare them to each other. Now, an exercise that seemed to be fruitless quickly turns into all stakeholders scrutinizing each and every word of the new problem statement until everyone agrees. And if everyone cannot agree, this misalignment is exposed up front in the project and dealt with to allow the client team to move forward with a unifying and clear goal.
2.Keeping team members aligned
Especially in an agile environment, visions, features, gaps in the market, and priorities for the product change over time. It’s important to use the problem statement as a source of truth throughout the entire lifecycle of the build. This can prove extremely useful when your stakeholder analysis power-interest grid resembles a pepperoni pizza. When so many voices and competing interests have input into a product, agreeing on a problem statement first and foremost will keep your product focused and the build (and release) efficient.
3.Keeping focus on users
Problem statements should be written in a way that focuses on solving a problem for your users. The problem statement for a product should not encourage a solution to make your business more money, to make your business run more efficiently, or to fix an existing problem within your business. Your product should serve your users—to create the optimal product, you need to fully know and understand the people who will be benefiting from and using your product. By writing the problem statement with a focus on solving a problem for your users, your solution will also be focused on your users.
Problem statements work best when they are concise and provide an actionable summary to guide the solution for the problem that your product is trying to solve. Our favorite format is:
(Users) need (outcome) because (driver). Our solution should…
The first sentence should simply state a problem that specific users have and why they have it—and the problem should be research- and evidence-backed. As practitioners of human-centered design, users are our biggest priority. Why waste resources solving a problem that doesn’t exist (or build a product that no one will use)?
The second sentence of the problem statement should provide criteria with which to judge potential solutions (or products, features, decisions, etc.). Solutioning or specific solutions do not have a place in your problem statement—that’s what the rest of our Strategy & Design engagements are for! The focus should remain on what the product should provide the users. We often see our clients’ first problem statement drafts include things like, “Our mobile app should…”. Is a mobile app the best solution? Do we know that potential users want an app? Will we paint ourselves in a corner if we focus on a mobile app only to realize six months from now that users and revenue would have doubled if we built a responsive web app up front?
Below is an example of a problem statement in our recommended format, but every day we are reminded that no client or product is the same. We have helped write problem statements that have two sentences, ten sentences, bullet points, and different colors. No matter your need, our focus remains on solving the right problem for your users, and a problem statement that is well-informed, actionable, and communicable facilitates great product strategy from start to finish.
Example:
Busy working professionals don’t have an easy, time-efficient way to eat healthily because they often work long hours and don’t have time to shop and meal prep. Our solution should deliver a quick and easy way for users to procure ingredients and prepare healthy meals that they can take to work.