Understand, Design, Build: The World’s Simplest Problem Solving Framework

It’s easy to assume the most important part of a software engineer’s job is coding.

But actually, the most important thing engineers do is solve problems — coding is just a skill they use to create the solutions.

Think about it: When a project fails, or even when it just takes way longer than it should, is it because of problems with the code? Usually, no. It’s because the engineer carefully built something that technically worked, but didn’t solve the right problem. In that case, it’s back to the drawing board for the developer, which is a huge—yet common—waste of time and resources.

This is part of what makes the job so challenging. Learning to code is no walk in the park, but learning to be a good problem solver might be even tougher.

Luckily, problem-solving is like any other skill. With practice, you can become a better problem solver, and thus, a better engineer. With this simple framework, you can successfully tackle any problem.

Understand, Design, Build: The World’s Simplest Problem Solving Framework

We recommend a three-step approach to problem-solving: Understand, Design, Build. By following those three simple steps, engineers can finish projects in less time, with less backtracking, and with better results that solve big-picture business problems.

Here’s how it works.

Step 1: Understand the Problem

Before you go any further, stop and ask yourself these questions:

• What’s the business outcome you need to achieve?
• What’s standing in the way of achieving that outcome right now?
• Have you solved a similar problem before? Is there something in your existing codebase or infrastructure that can be reworked or directly applied to this problem?
• What do you need in order to solve this problem?

If you don’t know the answers to all those questions, you don’t understand the problem. If you move on to designing or building a solution without understanding the problem, here’s what’s likely to happen: You’ll get to work, and then realize at different points during the process that you’re missing information you need. When you have to interrupt your flow of work to ask someone a question or research something, it’s hard to get back into flow—humans don’t have infinite attention, so interruptions during productive work are tough to recover from, making them costly and time-consuming.

That’s why it’s so key to resist the urge to jump right into coding and to use every step of this framework. And once you have a rock-solid understanding of the problem, keep resisting, because there’s still another step to complete before you write anything.

Step 2: Design Your Solution

Before you start coding, you have to have a more fleshed out plan. You have to design your solution—or multiple solutions, because the first one you come up with isn’t likely to be the best one. Sorry, not sorry.

Consider multiple different approaches that will land at the business outcome you identified in Step 1. And as you identify possible approaches, think about the benefits, risks, and mitigations of each one.

Coming up with all these different approaches could look like a few different things in practice. Try these techniques to find some possible solution designs that might be worth pursuing:

• Group of individual brainstorm
• Whiteboarding exercise
• Design doc
• One pager
• Technical design review

The key thing to understand about this part of the process is that, as a company ages, it’s likely to become more complex. The simple problems tend to get solved in a company’s early days, which means problem-solving begins to go beyond pure implementation and become more creative work. There may not be an exact right answer to solving your problem, but by considering as many approaches as possible, you can compare the costs and benefits of each and hopefully land on the best solution.

A solid framework for this is First Round’s Benefits, Costs, and Mitigations strategy. Create a simple table, like this, to compare all the possible solutions you’ve targeted.

This isn’t too different from a simple pros and cons list… until you get to the mitigations section. That’s where you brainstorm ways to adjust your plan to create more benefits and fewer costs.

And, of course, part of the design step is to create a road map to how to implement your solution. Once you’ve chosen which potential solution is the best fit for the problem, think about how to build and implement it. This might mean creating an outline or workflow. The point is to go into step 3 (the actual coding part) with a solid plan about what you’re building and how.

Step 3: Build the Best Solution

By fully understanding the problem at hand, and then taking time to carefully consider the pros and cons to multiple different approaches to solving it, you should now have a deep and thorough understanding of the solution that will best solve the problem. Now it’s time to build it.

And after step 2, you should also have a good plan for how you’re going to build it. The hard decisions have been made. Now you get to plug in your headphones, put on a great new album and crush it.

When you use this problem-solving framework, the actual building is no longer the hard part. It’s like in English class when you had to outline your paper before you wrote it. All the points for your project are there are planned out. It’s time to connect the dots.

And the best part: With such a solid plan in place, you know that what you code will be a great solution for the problem. No backtracking. No rewriting. Just coding something awesome.

UDB: Why It Works

Every engineer has been in a position where they’ve had to backtrack to rewrite code that isn’t working, or they’ve finished a project just to discover it doesn’t meet the business needs of the project. Can such a simple framework really eliminate those kinds of failures?

That’s why this three-step process works—it addresses those common reasons and ways engineers get their jobs wrong.

Here’s an example that illustrates the framework in action, courtesy of Lenny Rachitsky, a former developer at Airbnb. In 2012, Lenny was new at Airbnb and tasked with turning the travel platform into a more social experience.

So Lenny and his team got to work. They created a platform that allowed travelers to the same locations to coordinate meet-ups and activities, hoping to turn Airbnb into a new kind of travel-focused social network that brings new friends together in real life. When the product was rolled out in San Francisco, it looked great and provided a beautiful, smooth user experience. Except people didn’t use it. Why?

It turned out that Lenny and his team failed to understand the problem they were solving. Here’s what they thought the problem was: Airbnb users are siloed and want to hang out with other travelers.

Here’s the actual problem they needed to understand: Airbnb users want authentic, local experiences they can’t find on just any tourism site. Hanging out with other travelers is one potential solution to this problem, but it’s not the problem itself.

So Airbnb’s developers headed back to the drawing board and created Airbnb Experiences, which are live on the site, used by many people, and definitely provide the unique travel experiences users are looking for. Eventually, Airbnb got it right. But a lot of time and money could have been saved if its engineers had used a framework that helped them identify and understand the correct problem. A framework like this one.

Very few people are lucky enough that problem-solving comes naturally to them. But adopting this framework and then practicing it will allow you to develop and hone those skills, making you a better problem solver, and in turn, a better engineer.