Businesses often follow a define-plan-execute method of problem solving: spend time up front rigorously defining a problem, develop a solution plan, and execute.
This sounds simple enough, but businesses large and small inevitably spend excessive resources following this method only to realize that, in hindsight, they should have solved a different problem. To lead an innovative company, learning to find the right problems is at least as important as solving them well.
The danger of setting a problem in stone.
The right problems are often concealed by deceptively unambiguous problem statements. For example, in 2006, Netflix offered a $1 million award to anyone who could figure out a way to improve their viewing recommendations algorithm by 10 percent. Hitting the benchmark took competing teams from top companies and universities almost three years. While the amount of work procured for $1 million was impressive, the effort failed to solve the right problem and was never fully implemented.
If Netflix had framed the problem ambiguously, i.e., “we want to improve recommendations” rather than “we want to improve our recommendation algorithm,” the answer might have been easier to come by. As Netflix’s business evolved to accommodate the preferences of each family member and provide more personal recommendations, they found this problem could be solved by simply splitting family accounts.
Most businesses set goals in terms of “we need to improve X by Y percent.” On closer inspection, improving X by Y percent is often just a partial solution to a bigger, more ambiguous problem. Improving X by Y percent may incrementally improve your business, and using the define-plan-execute method will get the job done on a number of projects. However, if you don’t revisit and redefine the problem, you run the risk of misusing valuable time and resources.
To this end, businesses should also look to set concrete goals while defining problems ambiguously. Problem solving methods for ambiguous problems aim to continuously redefine the problem. They start with a big, ambiguous problem and take an iterative approach to testing out solutions and changing course. At each step it’s not worth figuring out details, because the problem statement will change at the next iteration.
Many names, one concept.
People across many fields use these methods, but call them by different names. Designers and engineers who practice human-centered design “research, prototype, test, and iterate” to develop solutions. Entrepreneurs practicing the lean startup method use the “build, measure, learn” loop to build their businesses. Programmers practicing agile development use “minimal planning, short feedback loops, and iterative testing and improvement,” to deliver software. Project managers talk of the Deming wheel: “plan, do, check, act.”
Each community emphasizes slightly different aspects, but all of them have a common pattern: planning (just a little), building, testing, and doing it all over again better as quickly as possible. They all recognize that when we begin, we don’t know exactly what problem to solve, and that in the process of solving it the problem will change. Without a willingness to periodically consider ourselves ignorant, reflect on the problem and adapt by building something new, it’s easy to struggle with deciding what to solve, or worse, blindly sink time and resources into things that don’t matter.
Ambiguous problems call for fast and cheap iterations.
The more ambiguous the problem, the less important the planning step. Why invest in a plan that will be obsolete? This is why, for example, the design community opts to make the cycle faster and less expensive by starting with quick, low fidelity sketches and “duct-tape-and-popsicle-stick” mockups when the design goal is still ambiguous. They only transition to slower, higher fidelity prototypes as the design goal crystallizes.
Problems in data science (where our company Datascope operates) or in areas requiring large upfront investments are areas where an iterative design process can be especially valuable. Big Data has been in the news for a few years, but it’s a classic ambiguous problem. Most companies are still grappling with if and how to use it. On top of that, Big Data projects can require large infrastructure costs, so the penalty is high for picking the wrong problem to solve or paying for tools that aren’t flexible enough to adapt to future problems.
This is why we start with the biggest problems and the smallest pieces of work we can do. We “plan by doing”, using these tiny pieces to clarify the most useful problems to solve. It’s a technique that’s been used in many different types of work, to great effect. And in our experience, it’s the only way to produce truly transformative questions and answers.