3 Factors You Have to Get Right Before You Can Solve Hard Product Problems
Digital product development, particularly going from nothing to something, is very difficult. It’s difficult because there are so many problems to overcome and, truthfully, very little understanding of how to solve them in a reasonable amount of time or before running out of money.
People have been intrigued with human-powered flight for centuries. Henry Kremer, a British industrialist was so intrigued by human-powered flight that he announced a challenge to the world. In 1959, he offered a cash prize of £50,000 (equivalent to about $350k today) to the first person to continually fly in a figure-eight between two poles half-mile apart using only human-generated power. For nearly 20 years, many people attempted this challenge only to fail. It wasn’t until 1977 did someone meet the challenge. In about a year of working on the challenge, Paul McCready completed the challenge. And then about 2 years later, he completed the second Kremer challenge of flying 22 miles, across the English Channel, using only human-powered flight and claiming a £100,000 (equivalent to about $700k today) prize.
What did Paul McCready figure out that so many before him missed?
Factor #1: Solve the Right Problem
After observing the teams before him and making some early attempts, he realized that the problem is that he didn’t understand the problem. The problem was the problem-solving process itself. He asked himself, “how could I build a plane that could be tested and rebuilt in minutes or hours, rather than days or weeks?”
The problem is that we don’t understand the problem. — Paul McCready
This question unlocked his ability to learn at the pace needed to make reasonable progress towards the challenge. He challenged his team to figure out the best way to design a prototype plane that could be built inexpensively and rapidly repaired. Where most teams before him made a few attempts per year, McCready’s team made 222 attempts in about the same time, before succeeding on their 223rd attempt. The magic was that McCready first pursued a problem that didn’t directly solve the main problem. Solving the prototyping method enabled him to string together the learnings in a way that produced a plane that would meet the objective.
Factor #2: Solve Problems in the Right Order
McCready was faced with an assortment of problems. What’s the best way to generate thrust? What’s the optimal wingspan that balances weight, control, and lift? What’s the best way to transmit pedal power? What about turbulence? Steering? Communication? Once there is a system of learning, you then have to determine the right order to solve problems. In McCready’s case, it was determining the wingspan that provided sufficient lift given minimal weight and speed. The plane that crossed the English channel traveled at about 18 mph. To give you a reference, a marathon runner averages 10 mph, and Usain Bolt regularly ran about 25 mph. Rapid experimentation was needed early in the problem-solving process. Early on, very little was done to the plane that would be ready for the actual challenge. This is the “discovery” cycle of product development. This cycle requires clear boundaries or a sandbox that keeps the problem space manageable and a definition of success that warrants the idea to be added to the production-ready digital product. Once ideas were validated, then they were added to the plane in a more permanent way. The process of adding a feature to a “flight-ready plane” is done in the “delivery” cycle of a digital product. Then, the next problems are unlocked to start another “discovery” cycle.
Factor #3: Solve Problems Using the Right Methods
While developing the plane, McCready experimented with different combinations of materials and testing methods from computer-aided design, model airplanes, to full-scale prototypes. Each of these methods mitigated against different types of risks that could cause failure. McCready’s team used different methods according to the different problems they were solving. Critical parts of the plan were tested with various means before it was added to the flight-ready plane. Similarly, when developing a digital product, a team has to ensure that a product is doable, usable, beneficial (to the business), and valuable (to customers). Different methodologies need to be in a team’s toolbox to address the different types of digital product risks that could cause failure.
Technically Doable
Naturally Usable
Beneficial to the Business
Valuable to Customers
So here are some takeaways for application:
Repeatedly failing fast is intentional. Does your team have the right environment that allows for rapid testing? Do they have the right tools, processes, and set up to fail quickly and fail rapidly?
Decompose problems and solve problems in the right order. If done correctly, problem-solving feels like it naturally cascades. The learnings from one problem contribute to solving the next.
Use the right techniques to mitigate risk. Product ideas or features fail when they aren’t technologically doable, easily usable, beneficial to the business, and valuable to the customer. There are different methods of testing each of these risks.
Final consideration: It really helps to have a clear objective like crossing the English channel using only human-powered flight.