Teams struggle to understand when a solution is good enough. They get stuck in endless development cycles trying to meet the arbitrary standards of insiders, causing schedules to slip, budgets to balloon and eventually projects to fail.
Table of Contents
- The real reason why digital technology projects fail and how to fix it
- Solve the right problem
- Find a good solution to the problem
What is a solution?
Before we understand what a good enough solution is, lets first look at what is a solution.
A solution is a direct antidote to the problem.
A Solution has three parts
- It is a system
- It does not rely on or wait for people to change
- Instead, it works by changing the environment
The key idea here is that the success of the solution doesn’t depend on people to be internally motivated to change their behavior and habits — instead focuses on changing the environment around them to make good habits easy to engage in, and bad habits difficult to engage in.
Here are some simple examples from behavioral studies that explains this idea.
If you use a big spoon, you’ll eat more. If you serve yourself on a big plate, you’ll eat more.
If you move the small bowl of chocolates on your desk six feet away, you’ll eat half as much.
If you eat chicken wings and remove the bones from the table, you’ll forget how much you ate, and you’ll eat more.
Let’s examine each part of a solution in reverse order to see why it works, starting with why solutions should not overly rely on people changing their behavior.
Changing behavior is hard
Changing people’s actions and thoughts is hard and takes time. This video simplifies the complex neuroscience behind habits and why change is hard for the brain.
The video explains that we all have something we want to change or improve in our lives but for many of us despite our best attempts we just don’t — why do our brains make it so hard to change our habits?
Our habits are managed by the Prefrontal Cortex (PFC) and the Basal Ganglia.
The PFC is the responsible boss telling you not to eat that plate of cookies when you’re trying to lose weight. The PFC needs a lot of metabolic fuel to function and when it consumes this limited resource, it makes resisting cookies much harder. As your PFC loses control, your basal ganglia, the place where your habits and routines hang out, takes over. Unlike the PFC, the basal ganglia are highly energy efficient and can operate without you even knowing it — that’s how you are able to drive at 100 Kilometers per hour for long stretches of time with no conscious awareness.
Habits get transferred to the Basal Ganglia through repetition — often referred to as “muscle memory”.
So rather than exhausting your PFC with willpower and discipline, if you make repetition of a simple task a priority, over time you will realize that you just developed a new habit or skill.
Perhaps we are more like Pavlov’s dogs than first imagined.
Changing behavior takes a long time
Internally motivated behavior change takes a long-time because people have to go through various stages and tend to move back and fourth through these stages, re-cycling through them until the change becomes fully established.
Psychologists analyzing this field have summarized these stages as follows:
- Pre-Contemplation — The first stage of change is one in which individuals become aware that a change is needed; however, they have no intention of changing just yet. Often this may be due to a lack of insight or full awareness into their problems or the advantages of the change
- Contemplation — in this stage of change, individuals begin an internal debate about pursuing the change and are caught in the pendulum of thoughts, swinging between changing vs not changing
- Preparation — in this stage individuals commit intention to change in the immediate future. At this stage one may begin to take or experiment with small steps towards change
- Action Stage — individuals move from planning to doing, they put plans into action and make significant behavioral changes
- Maintenance Stage — in this stage the desired behavior is now a reality and the threat of returning to old behaviors becomes less intense with frequent practice.
-
Change habits by changing people’s environment
Solutions that are overly reliant on people changing their behavior, will struggle to gain adoption, as habit change is hard and happens gradually and over time — instead, environmental changes might be more useful in getting people to do difficult tasks regularly.
To radically change your behavior: radically change your environment.— Dr. B.J. Fogg, Director of Stanford Persuasive Lab
The classic financial example of saving vs. spending by changing the environment vs relying on personal behavior change illustrates this principle.
Instead of relying on willpower to save money, the savings system takes away the decision altogether by having automatic withdrawals from your paycheck into a savings account. This allows you to spend with less worry, since the system has already taken care of the savings for you, by withdrawing money before you even see it.
To effectively design such environments, you must:
- Reduce choices that people must make
- Routinizes tasks that are repetitive
- Promotes desired behavior by rewards good habits and make it harder to engage in poor habits
- Compounds the benefits — few things happen overnight; success is often the result of the compounding effect of consistently executing a difficult task
Such environments a type of “Control System”.
What is a control system?
A radar speed sign is an effective control system.
It is an interactive sign, generally constructed of a series of LEDs, that displays vehicle speed as motorist approach. The purpose of radar speed signs is to slow cars down by making drivers aware when they are driving at speeds above the posted limits.
The basic design of the radar speed sign has five elements and is illustrated below.
- The Condition — is the goal the system wants to achieve (in this example — the speed limit)
- The Sensor — is means for measuring the condition. In this example the sensor is a radar to measure how fast the vehicle is traveling
- Information Display — is the display or flow of data needed by the Checker and Doer (in this example the speed is displayed on the LED to the driver)
- The Checker — determines the need for correction by comparing what is occurring vs. the condition. When variations are beyond what is acceptable, corrective action is required.
- The Corrector — is the corrective action taker and returns the system to its expected level. In this example the Doer is the driver who performs the corrective action and slows down the vehicle.
-
Control systems in IT / Digital solutions
The Control system principle also applies to Enterprise IT and Digital transformation solutions.
Here is a familiar example:
Problem: it is difficult to navigate using a paper map, whilst I am traveling.
Solution: Google Maps is a service that helps plan routes for traveling by foot, bicycle, car, public transport, or air. It also offers satellite imagery, aerial photography, street maps, 360° interactive panoramic views of streets and real-time traffic conditions on your route.
The list below illustrates this solution, when viewed as a Control System.
- Condition: An awareness of the condition (the goal) — Ability to request users for their location and destination from an end user computing device (e.g. phone, pc, car navigation, smart watch, etc.)
- Sensors: capable of observing and measuring people’s behavior — Ability to detect the user’s current location using GPS
- Information: the means to show people relevant information and provide feedback — Ability to show the current location, the destination and the route on a street map including delays and traffic conditions
- Checker: the ability for the system compare actual behavior and assess how far off it is from the expected behavior. Ability to continuously check if the user is still on the most optimal route.
- Corrector — is the corrective action taker that returns the system to its expected level.
If the user veers off the optimal route, the ability to recalculate a new route to get the user back on track.
What is a good solution?
A good solution reduces choices, routinizes tasks, promotes desired behavior, and compounds the benefit to the people and the system.
When benefits compound — the system grows and gets better over time.
Whilst the specific growth metrics depend on each solution, typical metrics include the number of users, revenue and or, risks reduced.
New solutions typically follow an adoption S-curve — it quickly gains the innovators and early adopters, but then must overcome stiff resistance before it penetrates the Early majority. From thereon, it evolves to the largest group of the late majority and late adopters and goes on to become the dominant solution.
A tipping point is when a small step along this continuous path suddenly makes a big, irreversible difference in some outcome.
The little bits of action continue to compound until suddenly one more little bit of action creates a big impact — the straw that breaks the camels back. In real life, these moments are very hard to predict, and even in retrospect it’s not so clear what did it.
Malcom Gladwell defines tipping as the “Boiling Point”. His book the Tipping Point, seeks to explain and describe the “mysterious” changes that happen when ideas, products and messages spread like viruses.
How to get past the tipping point
When teams are stuck in the tipping point zone, they intuitively find that the fastest way to get through this stage is by trial and error. Trial and error is generally the last resort when a clear way is not obvious. This does not mean that the approach is inherently careless or haphazard, teams often systematically brainstorm different ideas, try them, learn from them, and try something different until they stumble upon a good way. In some cases, there is also an element of luck.
Design thinking is a systematic, organized approach to trial and error. Teams need to improve their use of design thinking techniques such as, user development research, prototyping, user validation. Teams must work to get early, often, and direct feedback from actual users, not just from the insiders.
Teams must stay focused on tipping over the very next segment of customers in the life cycle. Teams should only proceed when, the next segment of users accepts it, begins using it and tells others about it. To do this they need to deeply empathize with their issues and motivations, understand their resistance and points of friction and continue to improve the solution through systematic trial and error.
The magic “tipping” idea
The magic idea that helps a solution cross over the tipping point, does not need to be an original idea.
Mark Twain is credited with pointing out that:
“There is no such thing as an original idea. We simply take a lot of old ideas and put them into a sort of mental kaleidoscope. We give them a turn and they make new and curious combinations. We keep on turning and making new combinations indefinitely; but they are the same old pieces of colored glass that have been in use through all the ages.”
A closer look at patent filings supports this. Rarely are inventions the first of their kind. Instead, many inventions are variations or improvements of previous inventions. Most patent applications are improvement patents, simply an invention that adds something extra.
The good enough solution — or the Minimum Viable Product
The version of the product that is used to start this trial & error stage is referred to as the Minimum Viable Product (MVP). The MVP allows teams to collect the maximum amount of validated learning with the least effort.
Founders and product owners often struggle to know if the solution has reached this point of “good enough”. They continue to add features that may never get noticed or matter to the Early Majority. Teams must resist getting stuck in endless development cycles trying to meet the arbitrary standards of insiders, causing schedules to slip and budgets to balloon. Instead teams must get out of the building and focus on getting the opinions that matter — those of the “Early Majority”.
Developing the MVP is a fine art of architecting a solution that balances economics, customer-development, technical debt and extensibility.
Great is the enemy of good
This Wikipedia article gets to the root cause of why teams and insiders struggle with knowing when the solution is good enough.
The Best (or Perfect) is the enemy of good
Aristotle, Confucius, and other philosophers provided the way out of this trap with the principle of the golden mean, which counsels against extremism in general. The Pareto principle or 80–20 rule explains this numerically. For example, it commonly takes 20% of the time to complete 80% of a task while to complete the last 20% of a task takes 80% of the effort. Achieving absolute perfection may be impossible and so, as increasing effort results in diminishing returns, further activity becomes increasingly inefficient.
Robert Watson-Watt, who developed early warning radar in Britain to counter the rapid growth of the Luftwaffe, propounded a “cult of the imperfect”, which he stated as “Give them the third best to go on with; the second best comes too late, the best never comes.”
Only scale good solutions
Through a combination of hard work, trial and error and a bit of luck, teams cross the tipping point and eventually get to a version of the solution that gains the adoption of the Early Majority. Once this point has been reached, teams can safely invest in scaling the solution and investing in continuously improving it, until the solution appeals to the next major segment the Late Majority and so on. If done right, the solution will eventually dominate the space and reach saturation.
Investing too early in capabilities that are needed for scale will only distract the teams focus. It wastes the precious resources available in the early days, that are better spent trying to get the product to cross the tipping point.
Conclusion
A Good Solution is a direct antidote to a problem — it completely solves the problem.
A Solution has three parts
- It is a system
- It does not rely on or wait for people to change
- It works by changing the environment around them to make good habits easy to engage in, and bad habits difficult to engage in.
The system, is a type of control system. It :
- Reduces the choices that people must make
- Routinizes tasks that are repetitive
- Promotes desired behavior by rewarding good habits and making it harder to engage in poor habits
- Compounds the benefits — few things happen overnight; success is often the result of the compounding effect of consistently executing tasks
- The system grows and gets better over time
The system is rarely adopted by all users from the beginning. Instead solutions typically follow an adoption S-curve — quickly gaining the innovators and early adopters, but then slows, as it faces stiff resistance (The Tipping Point), before it penetrates the Early majority. From thereon, teams must scale the solution to reach the remaining user segments.
A tipping point is a small step along the path that suddenly makes a big, irreversible difference in some outcome. These “magic” moments are very hard to predict, even in retrospect.
Teams stuck in the tipping point zone generally resort to trial and error, and a bit of luck to get through it.
Teams need to get better at using techniques such as Design thinking to systematically approach all stages of the journey especially the tipping point trial and error stage.
The magic idea that helps a solution cross over the tipping point, does not necessarily need to be an original idea. Many useful break throughs are variations or improvements of previous ideas.
The Good Enough Solution (or MVP) is an early version of a solution that is used to start the trial & error to allows teams to collect the maximum amount of learning with the least effort, in the quickest time possible. Teams struggle to understand when a solution is good enough. They get stuck in endless development cycles trying to meet the arbitrary standards of insiders.
Team should foster a culture that promotes a “cult of the imperfect”, and be comfortable releasing a good enough solution in 20% of the time that meets 80% of the problem.
Teams should resist building capabilities that are needed to scale until the product has crossed the tipping point.
