Innovation Archives

Perfect Doesn’t Mean Effective

Rapid testing is not something that comes naturally to me. As an engineer and a creator, I often find myself driven by the pursuit of perfection. In my spare time I spend days and weeks on woodworking or home improvement projects as I hone my skills and improve the quality of my work. In fact, I’d guess that just about everyone has a skill or interest they want to learn and work hard to improve upon. Likewise, I’d guess that most people view the pursuit of greater skill and higher quality output as the path to success. For the most part I would agree with them.

It may then surprise you that one of the most powerful strategies in business is to NOT pursue perfection.

Examples of this strategy are evident everywhere in the business world. New services often launch with messy, unintuitive signup processes. B2B applications rarely end up with clean, visually appealing interfaces. More and more products are releasing in “generations” rather than perfectly finished designs. In fact, while writing this article I prepared ramen with instructions to “ignore the indicated fill line” rather than the manufacturer simply providing a bowl with a correct fill line.

These trends are all coming from large companies with resources and talent capable of making their work “perfect”, so why are so few of them pursuing it?

80% of Consequences Come From 20% of Causes

To understand why, we first need to understand the Pareto Principle, also known as the 80/20. First proposed by management consultant Joseph M. Juran, the 80/20 Rule states: for many outcomes, roughly 80% of consequences come from 20% of the causes. While originally used in the context of quality control, the principle has been successfully observed in many practices. In fundraising, 80% of the funds raised typically come from 20% of the donors. In computing, developers can typically fix 80% of software issues by addressing the top 20% of bugs.

What people often overlook is how this holds true for business activities as well. You will likely capture the majority of an activity’s value at the beginning, with returns on investment diminishing as the effort continues. Although the perfect solution may in fact be achievable – and even more valuable – this principle shows us that the point when expended effort becomes a net loss is far earlier than “perfection”. Within that final 20% of quality lies the vast majority of our time and energy, which would be better served accomplishing 80% of several other business outcomes.

In short, perfection wastes time and money.

Speed is the Optimal Path to Success

The chart below represents an 80/20 curve relating to the business value of tasks. Each bar represents a task and its measured business value. What the 80/20 Rule shows us here is how 80% effort is “optimal” in relation to the value we get out of our actions.

However, with concepts as abstract as “effort”, shooting for a real number is futile. We can’t accurately quantify our effort, and even if we could, landing directly on 80% would be virtually impossible. How do you put in exactly 80% effort when doing things like deciding on sub-contractors or creating sales collateral?

If more value exists at the beginning of our efforts than at the end, it stands to reason that taking too long is more costly than finishing too early. Thus, our goal should be to focus on speed.

By focusing on speed, we ensure that if we miss the 80% mark we still “fail” in the most efficient manner. To see this in action, imagine two identical startups selling their own widgets. As these businesses grow, both startups realize they need some sort of CRM to manage customers and orders. Startup A, recognizing that this is a core part of their business, launches a two-week research project to determine the absolute best fit for their company. Startup B, however, spends an afternoon researching options then picks one that seems decent.

Fast forward two weeks… Startup B realized they rushed their decision and some business processes will have to remain manual. However, they now have two weeks of customer data in the system and are using this data to create sales strategies. Startup A ended up with the “perfect” solution with all tasks perfectly automated, but no data to determine sales strategy. They are now two weeks behind their competitor. Only now are they starting to enter customer data, and it will be another two weeks before they have enough information to start developing a sales strategy.

Startup B captured the bulk of the business value (a way to build a sales strategy) despite rushing the research task and failing to address some lower value business processes with their purchased software, whereas Startup A missed out on leveraging high value results because it was stuck waiting on “perfection”.

The Difference Between Rapid Testing and Recklessness is How Much You Learn

At this point you may think I’m encouraging you to act recklessly. I know I certainly thought that the first time I saw these rapid testing concepts in action. There is a final aspect separating recklessness from strategic speed: learning. Or, more accurately: you should frame your pursuit of the 80% value in the context of learning new information to apply to your next decision or action. When you treat every next move as a deliberate test for gathering information, you gain the insight to deploy your effort where it matters the most.

Let’s go back to our startups. This time Startup B had massive problems with the software that they selected. A purely speed based strategy would tell them to pick the next best software and cross their fingers it would work better. Technically they would still accomplish more because of their speed, but they also would still be charging down the same path without knowing if it was the right path. What happens if they treat the decision as a test with the explicit purpose of learning about their sales needs?

By framing it as a learning-based strategy, Startup B would pay closer attention to the business value provided by the software and note what conditions would cause them to change directions. These insights could lead to a better next pick but, more importantly, this deliberate focus on learning may reveal that the company’s business process doesn’t actually need a CRM at all.

Maybe these widgets require a unique sales process, or maybe a CRM is too complex and unwieldy to use efficiently at this stage. If that’s the case, their next action would be to pivot quickly to some other solution, completely abandoning the goal of getting a new CRM and saving money in the process. By inspecting the results, Startup B will gain business value even in failure.

Speed helps you get to your goal. Testing helps you determine if your goal is correct.

Rapid Testing Mindset is a Powerful Strategy for Innovation

Regardless of job title, everyone is operating with an incomplete understanding of their environment. Whether we know it or not, we conduct experiments every day with every action we take. Despite this – maybe even in spite of this – many companies punish failure and expect every result to be positive, leading employees to push deeper into the low value, time-wasting activities as they attempt to be “absolutely sure” their results will be positive. Some byproducts of this risk aversion are lower creativity and lower trust between employees.

However, companies that embrace rapid testing, and the failures that come with it, create an environment suitable for innovation. When the organization’s goal becomes learning, failures no longer carry negative weight. Instead, failures are celebrated as steppingstones towards better results. This environment is critical for innovation because, by definition, innovation is the exploration of the unknown. Exploration cannot exist without risk and creativity. If perfection is expected and failure is not an option, the business will get mired by group think.

Even failure-embracing organizations can stifle innovation if they remain focused on perfection. Innovation is a time-consuming process, often taking hundreds of iterations to find the best solution. When perfection is expected before results are known, these types of organizations will spend the majority of their time on the low value items that make up the last 20% of quality.

If the 80/20 Rule holds true, every “perfectly” completed task sacrifices the same effort as five 80% completed tasks. That’s four missed learning opportunities for every attempt. The result is large feed feedback loops, low agility, and even abandoned projects as the effort to gather new information becomes too costly.

Organizations embracing rapid testing will experience failure. It will be messy and often chaotic. However, these organizations will also generate business insights far more quickly than their competitors. They’ll be more agile, more responsive to changes, and, by necessity, foster cultures of exploration and creativity.

Scrum is designed to solve interrelated problems common – but not unique – to software development projects: project scope and estimation.

Do these problems also exist in innovation projects? Will the Scrum solutions work for innovation projects as well? Short answers: Yes and Yes.

Applying Agile Scrum methodology to the process of Innovation allows the product team to define the scope of the project more clearly, identify emergent work more easily, estimate the work to be done more accurately, and demonstrate value to customers and stakeholders more frequently.

Let’s walk through what Scrum looks like within traditional software development and then pair it with common problems faced by innovative teams.

How Scrum uses emergent prioritized work to solve problems

Scrum developed ways to address the problem of project scope (the total amount of work needed before the project can be considered done). Since software can do so many things, it is hard to limit our needs. Therefore, project scope in software development has always been a huge problem.

In software development projects, project scope usually starts out too big and only increases as the project progresses. Without understanding the project scope, it is hard to know when a software development project is ‘done.’ Therefore, projects often end when they run out of money or time, rather than being declared ‘done.’

Scrum addresses the project scope problem through ’emergent prioritized work,’ collectively referred to as the backlog. The backlog starts with currently known work and collects emergent work as the effort proceeds.

In Scrum, one person (the product owner) prioritizes the backlog; this makes the backlog manageable. In each iteration, the team faces a limited set of high-priority work and understands what it means to declare that set of work ‘done.’

When an iteration is completed, the project must always be functional so the users can touch and feel it for flaws or errors. Each time, the product owner shows the results to the users and asks their opinion on business value created or development errors (often some version of ‘what do you hate most’). In this way, the biggest possible mistake or waste of time is limited to a single iteration. If the project is off the rails, it can be reoriented before too much damage is caused. Thus, the process creates ideas for additional, emergent work which can be added to the backlog.

The product owner prioritizes the backlog items according to business value. In this way, the product owner can compare the business value created by an iteration to the cost of that iteration. If there is no combination of work items with a total business value larger than the cost of an iteration, then the project is finished.

Innovation projects have similar problems.

How do we decide what the most pressing problem is?

How can we know when we’re done (or even when we will be done)?

Why Agile Scrum is best for innovation

We build the result a little bit at a time, ensuring the work we’re doing fits within the whole idea of done and to make sure we’re also collecting any emergent work. This incremental approach helps solve scope problems in innovation projects, just like it does in software development projects.

Another problem iteration can help solve is estimation. Everyone wants to know how much a solution will cost and/or when it will be done.

Any time we discuss something in the future, we engage in estimation. Given what we understand in the present, we make predictions on how the future will play out. Unfortunately, the only truth we can predict is that humans are terrible predictors of the future (flying cars, anyone?).

In fact, we are so terrible at prediction that our only defense is to think small. Scrum helps solve this by using an iteration small enough that it allows:

Product backlog items to be estimated reasonably well
The risk of an estimation error to stay at a manageable size.

Over a handful of iterations, the team’s productivity per iteration (velocity) becomes apparent. The product owner can then estimate the completion of the known backlog with a reasonable level of accuracy. If this estimate is over budget or schedule, the backlog can be pruned, and/or the organization can (carefully!) work to increase the team’s velocity.

When you’re involved in innovation efforts, consider a lightweight Scrum process involving:

A backlog of needs
Iterations of work focused on a few specific needs from the backlog
Regularly showing how your solution actually works (even if it works poorly).

This way, you can focus on the most valuable work while effectively collecting emergent work and managing costs and schedules.

Rapid Testing Mindset: A Powerful Strategy