space includes any product or representation of a product that is used by or intended for use by a customer. It is the opposite of a blank slate. When you build a product, you have chosen a specific implementation. Whether you've done so explicitly or not, you've determined how the product looks, what it does, and how it works.
In contrast, there is no product or design that exists in problem space. Instead, problem space is where all the customer needs that you'd like your product to deliver live. You shouldn't interpret the word “needs” too narrowly: Whether it's a customer pain point, a desire, a job to be done, or a user story, it lives in problem space.
The Space Pen
My favorite story to illustrate the concept of problem space versus solution space is the space pen. When NASA was preparing to send astronauts into space, they knew that ballpoint pens would not work because they rely on gravity in order for the ink to flow. One of NASA's contractors, Fisher Pen Company, decided to pursue a research and development program to create a pen that would work in the zero gravity of space. After spending $1 million of his own money, the company's president, Paul Fisher, invented the Space Pen in 1965: a wonderful piece of technology that works great in zero gravity.
Faced with the same challenge, the Russian space agency equipped their astronauts with pencils. You can actually buy a “Russian space pen” (which is just a cleverly packaged red pencil).
This story shows the risk of jumping into the solution space prematurely and the advantage of starting in the problem space. If we constrain our thinking to “a pen that works in zero gravity,” we may not consider creative, less-expensive solutions such as a pencil. In contrast, having a clear understanding of the problem space (devoid of any solution space ideas), allows for a wider range of creative solutions that potentially offer a higher return-on-investment. If the pencil and space pen were equally adequate solutions, then avoiding one million dollars of research and development cost would clearly be the preferable alternative.
To avoid fixating on pen-based solutions, we could rephrase the problem space as: “a writing instrument that works in zero gravity.” That would allow for a pencil as a solution. But that's still anchored on “a writing instrument” solution. We can do even better than that: “a way to record notes in zero gravity for later reference that is easy to use.” That problem space statement would allow for more creative solutions such as voice recording with playback. In fact, considering out-of-the-box solution ideas can help you refine your problem space definition, even if they aren't feasible. In this case, a voice recorder would probably not be as good a solution as a Space Pen. It would need a power source and would require playback to refer to the notes again, which would be less convenient than being able to scan and read them. But undergoing this thought exercise would allow us to further refine our problem space definition to: “a way to record notes in zero gravity for convenient reference later on that is easy to use, is inexpensive, and does not require an external power source.”
I always like to clarify that this example is by no means an attempt to make fun of NASA. I tell the story a certain way to highlight the point I want to make. Indeed, the conclusion that NASA came to turned out to be the best one. There are good reasons not to use pencils in space: the lead tips can break off and float into an astronaut's eye or cause a short in an electrical connection. After the tragic Apollo 1 fire in 1967, NASA required all objects in the cabin to be nonflammable, including the writing instruments. So the Space Pen actually was a useful innovation, which the Russian space agency also adopted.
When I mention the space pen in my talks, there is often someone who claims that the story is an urban legend. However, it isn't, as NASA explains at http://history.nasa.gov/spacepen.html, and the Fisher Space Pen Company confirms at http://fisherspacepen.com/pages/company-overview. The key point of debate usually is, who spent the money on research and development: NASA or Fisher? Fisher did, as I pointed out above.
Problems Define Markets
Early in my product career, Intuit's founder Scott Cook helped me solidify the concept of problem space versus solution space when I heard him talk about TurboTax. Speaking to a group of product managers, Scott asked us, “Who is TurboTax's biggest competitor?” Multiple hands shot up. At the time, the other major tax preparation software in the market was TaxCut by H&R Block. After someone confidently answered, “TaxCut,” Scott surprised us all by saying that the biggest competitor to TurboTax was actually pen and paper. He pointed out that, at the time, more Americans were still preparing their taxes by hand using IRS forms than all tax software combined.
This example highlights another advantage of clear problem space thinking: having a more accurate understanding of the market in which your product is really competing. Those of us in the audience were narrowly thinking in solution space of the “tax preparation software” market, as defined by the two main software products. Scott was thinking in problem space of the broader “tax preparation” market – one that would also include tax accountants to whom customers delegate their tax preparation. As the previous chapter discusses, a market is a set of related customer needs, which rests squarely in problem space. A market is not tied to any specific solutions that meet those needs. That is why you see “market disruptions”: when a new type of product (solution space) better meets the market needs (problem space). New technology can often enable a market disruption to deliver similar benefits at a much lower cost. Voice-over-Internet-Protocol (VOIP) is a great example of a disruptive technology that has replaced traditional telephone service. At first, the sound quality of VOIP calls couldn't compare to that of traditional phone lines, but the cost was so much lower that it offered a superior solution for much of the telephone market.
The What and the How
As a product manager at Intuit, I learned to write detailed product requirements that stayed in the problem space without getting into the solution space. We were trained to first focus on “what” the product needed to accomplish for customers before getting into “how” the product would accomplish it. You often hear strong product teams distinguishing between the “what” versus the “how.” The “what” describes the benefits that the product should give the customer – what the product will accomplish for the user or allow the user to accomplish. The “how” is the way in which the product delivers the “what” to the customer. The “how” is the design of the product and the specific technology used to implement the product. “What” is problem space and “how” is solution space.
Outside-In Product Development
A failure to gain a clear understanding of the problem space before proceeding to the solution space is prevalent in companies and teams that practice “inside-out” product development, where “inside” refers to the company and “outside” refers to customers and the market. In such teams, the genesis of product ideas is what one or more employees think would be good to build. They don't test the ideas with customers to verify if the product would solve actual customer needs. The best way to mitigate the risk of an “inside-out” mindset is to ensure your team is talking with customers. That's why Steve Blank urges product teams to “get out of the building” (GOOB for short).
In contrast, “outside-in” product development starts with an understanding of the customer's problem space. By talking with customers to understand their needs, as well as what they like and don't like about existing solutions, outside-in product teams can form a robust problem-space definition before starting product design. Lean product teams articulate the hypotheses they have made and solicit customer feedback on early design ideas to test those hypotheses. This approach is the essence of Lean – and was actually first advocated for years ago by practitioners of user-centered design.
Should You
