start⬆Mngr handbook pt. 4: Intro to innovation & quality improvement

start⬆Mngr handbook pt. 4: Intro to innovation & quality improvement

First, a personal story.

Like most ambitious companies, our team is constantly looking to improve our performance. We’re never OK with the status quo. If sales conversion were at 90%, we’d want to take it to 100%. And as a start-up, there are so many things we can improve…

This meant that in the early days, before we had adult supervision and a clear company strategy, we changed processes a lot, switched focus weekly, and experimented with many different product features. On the customer success side, we’d setup retention email campaigns to keep churn rate down in one month, and  we’d leave that behind and work on up-selling customers the next month to boost revenue. Two quite different goals. On the product side, we’d get excited about an idea that a customer wants, spend a couple sprints developing it, but then never touch it or improve it again. This speed of change is not uncommon at early stage start-up companies.

…most successful innovation projects started with a problem definition stage before jumping to problem solving

On the good side, we were never bored. We always had something new and exciting to do. Yet on the downside, we had little consistency in our approach to improve the company’s performance, going in all directions and doing everything at once. Team members would be left wondering what our long-term goals were, and what set our product apart from the competition. We tried to be everything for everyone, without the resources necessary to do so.

This led to process changes and product features that didn’t improve our bottom line. We’d waste time and resources on non-coordinated initiatives that failed to convert more customers, did not attract more prospects, and didn’t retain users. Worst of all, we’d execute and move on from all these projects without documenting our learnings, so we’d repeat some of our mistakes.

To help correct for this lack of direction, I spent much time exploring how other companies managed innovation projects: From hospitals to grocery stores, from tech start-ups to auto-makers. To my surprise, I found a consistent theme: Almost all innovation projects were carried out in a systematic way, following scientific processes that relied on data and experimentation. More importantly, most successful innovation projects started with a problem definition stage before jumping to problem solving (very hard concept to grasp for engineers).

In this blog post, I’m going to explore how to properly challenge the status quo and innovate systematically. We will discuss a system to help us lead innovation and quality improvement (QI) projects in order to:

  • Increase effectiveness of a process or product;
  • Solve the root cause of a problem rather than the symptoms; and
  • Boost creativity in problem solving.

For a quick introduction to innovation and quality improvement, I highly recommend the following TED style video by Professor Russell Ackoff.

The purpose of quality improvement projects is to change the way a problem is currently solved for the better. Better can be defined as doing something right, increasing effectiveness / efficiency, or lowering cost / margin for error. Since the market continuously changes, and our competitors never stop evolving, innovation projects are necessary for organizations to stay relevant.

Now let’s explore the basic steps of carrying out an innovation or QI project in an agile environment:

quality improvement process

This process ensures that we solve the right problem, test different solutions, and validate results before scaling. It avoids jumping to solutions that solve the wrong problem and wasting resources (realize that finding solutions is the fourth step, not the first). Let’s explore this in detail.

I. What’s the problem?

As a first step, let’s find supporting evidence to the problem, understand why it is occurring, and whether it’s relevant to the company/team mission.

Does the problem really exist? Is there evidence?


Innovation projects tend to arise from frustrations and desires to improve existing systems or processes. Before jumping to solving what we believe is a problem, it’s critical to gather evidence in the form of quantitative or qualitative observations to prove that a problem actually exists. Through this step, I’ve often found that the actual problem is quite different than our initial perception.

Evidence can take the form of data reports, analyses, interviews, or surveys to name a few examples. With recent innovations around analytics, there’s no excuse to have at least one piece of statistical evidence.

For example, one may be frustrated at the slow speed at which team members answer and complete customer service calls. Evidence to support the fact that team members are working slower than possible can come from:

  • Listening in and interviewing call agents to understand if there are opportunities for further improvements on the call process.
  • Evaluating the average time it takes a group of fully trained agents to complete a call; and the average number of daily calls one agent can take.
  • Assessing whether the number of calls an optimal team can take in a day is higher/lower than the current volume.
  • Assessing the reasons customers call to receive help

With evidence, a more complete picture of the problem(s) will emerge. Again, we’re very likely to discover that initial assumptions on the problem are wrong, or that they are only a small part of the actual problem. That’s great. That’s why we gather evidence.

What’s the root cause?

root of the problem

Once all the necessary evidence has been gathered, a root cause analysis can be performed using the 5 why’s method. This ensures that the QI project focuses on addressing the source of the problem rather than its symptoms and side effects.

In our example, we may find through root cause analysis that the actual problem is that the agents are receiving too many calls due to business growth. This could result from the fact that the number of agents has remained unchanged, while the number of customers and calls has grown. Data could also show that agent’s response time and call duration have not varied over history. So the problem may not be that agents are too slow.

Ensuring that our problem is accurately defined is crucial. Otherwise, our solution will be useless. Yet more often than not, we are too eager, impatient, and jump right to identifying solutions. We enjoy solving things, coming up with ideas. Unfortunately, a good idea to an misdefined problem is not as effective as a bad idea to a well-defined problem. The result is wasted time and resources that may not bring the desired innovation and quality improvement.

This widespread behavior is likely from undergoing 15+ years as students where problems are defined for us, and all that is expected is for us to solve them. We get rewarded to solve problems, not defining them. Unintentionally, schools have failed to teach us how to pinpoint problems.

A good idea to an misdefined problem is not as effective as a bad idea to a well-defined problem

I personally have greatly benefitted from reading “Are Your Lights On?” in an attempt to get better at problem definition. I highly recommend it to everyone that solves problems, especially engineers.

What’s not part of problem?

Every project should have a defined scope. This specifies the part of the problem that we’re aiming to solve (Do we want to solve climate change, or do we want to reduce the amount of CO2 released by our fleet of vehicles?). It is critical to set a clear scope to our problem, as the 5 Whys process has a tendency to yield potentially irrelevant problems that we may not want to tackle just yet. We need to resist the urge to take on every problem we discover and focus on the problem that is most important, relevant, and that we can effectively make an impact on. If the 5 Whys reveals multiple large problems, the QI project can be broken down into phases, focusing on the most pressing problems first. There is more details on prioritization later on in this blog.

Is it relevant to the team goal and company strategy?


Next, compare the problem to the team’s goal and the company’s strategy: If they are aligned, the project will push the team and company toward its ultimate goal, but if they don’t align, the project will waste precious resources.

In our example, assuming that everyone agrees that “having too many inbound customer service calls that potentially don’t need agent help to resolve” is the problem, we will need to evaluate whether the behavior is desired or not in relation to the company strategy and team goal.

If the company strategy is to offer best in-class human support, then the problem identified may be irrelevant, and a potential business case should be made to hire additional agents to help with the lack of bandwidth. Yet if the company strategy is to empower customers to self-serve wherever possible and maximize the ratio of customers to agent, then this may be a project worth pursuing.

OUTCOME: At this stage, we’ve gathered evidence that validates the problem, a root cause analysis has been performed to identify the problem’s source, and we know whether the problem is relevant to the organization. There is thus enough preliminary information to decide whether this is a problem that the organization wants to pursue.

II. Is this a priority?


Most organizations are bound to have multiple innovation and QI projects running at once, yet limited resources. We thus need to prioritize. Here are some questions that can help us do that:

  • What’s the potential impact / value of this project?
  • What if we didn’t do it?
  • What if we didn’t do it now, but later?
  • What’s the cost? human, material, time, …
  • What’s the ROI? [Value / Cost]

Based on our answers to the questions above, we’ll be able to compare and rank projects by priority.

It’s important to realize that ultimately, a project’s priority is reflected by how much resources we allocate, so we need to ensure that each project has the appropriate allocation of time, people, and other resources. Generally speaking, important projects deserve more resources.

What about low priority projects? Again asking “what’s the impact if we didn’t pursue it?” will help us decide whether to:

  • Cancel the project and never revisit it; or
  • Re-assess its priority later when resources are freed.

When it comes to prioritization, choosing what not to do is more important than choosing what to do. This ensures that top priorities get the right amount of attention and resources, and that plans are realistic. This applies especially to ambitious teams that tend to take on too much. Let’s thus recognize that doing everything is not successful prioritization. It runs the risk of juggling too many balls, and consequently, dropping all balls. Our startup companies have limited resources, so let’s choose how we spend our time wisely.

OUTCOME: Our project is now prioritized against other initiatives, which gives a clear idea of when to pursue it.

III. What do I expect?


Now’s the time to envision our desired end result and answer: What do we hope to achieve?

Of the three categories of goals (individual goals, functional team goals, project goals), projects need the clearest goals and expectations at the start. For example, before building a house, a clear blueprint needs to be drafted to communicate to all stakeholders what is expected in the end. The same applies to innovation and QI projects. Setting expectations before work begins ensures that all stakeholders  can agree or debate the desired outcome before it is implemented. Being specific in outlining expectations is key, so I recommend adopting a SMART approach.

Note that this is not yet the time to envision solutions or think of how to achieve the desired expectations. Doing so would be like starting to drive toward California before figuring out that we should actually be going to Florida. 

Based on our example case of a company wanting to decrease the number of inbound calls that can be resolved with self-service, the expectations for the project can be to:

  • Decrease the percentage of self-serviceable requests addressed on calls from X% to Y% in three months.
  • Lower customer call wait time to less than 5 minutes for 90% of all calls by X date.
  • Maintain Net Promoter Score at X and above beginning on Month/Day/Year. 

When it comes to measuring our goals, there are two types of metrics that we can leverage: progress metrics and outcome metrics.

  • An outcome metric assesses whether the desired outcome was achieved. e.g. In our example, a call’s wait time is an outcome metric, necessary to check whether 90% of all calls are answered within 5 minutes.
  • A progress metric tracks the impact of specific solutions, which in turn may contribute toward the desired outcome. e.g. In order to achieve the desired expectation around response time, one change or solution may be to have all calls completed or resolved within 10 minutes to ensure a high level of bandwidth availability. To that effect, the percentage of calls that are resolved within 10 minutes is a progress metric, which may in turn impact the desired outcome of answering calls within 5 minutes.

OUTCOME: A clear set of expectations has now been identified, including, measures that will help gauge success objectively.

IV. What are potential solutions?

multiple solutions

To explore potential solutions, we’ll first need to identify relevant stakeholders that can help imagine solutions, and then use divergent thinking to dream of all possible solutions.

Who should participate?

Having the right people on the project will maximize the potential of finding successful solutions.

In my experience, it can be a good idea to have people that are frustrated by the current process, that may not be top achievers, to participate in innovation projects. This is because top achievers work so well in the current process that they may not want to change. It may be hard for them to think outside the box. In other words, we need to find people that feel and understand the pain of the current problem to participate.

I also recommend the use of RACI to identify key players that need to be involved:

  • The product owner(s) / sponsor(s) / stakeholder(s): Who needs this project?
  • The scrum master(s) / project manager(s): Who’s managing progress of this project?
  • The team member(s): Who’s helping execute on this?
  • The subject matter expert(s): Who has special knowledge or skills that we need to consult? Who are the ones that live this process? Customers? Agents?

Without a clear solution or detailed project plan just yet, it is normal to involve additional players later on. Right now, let’s focus on involving the core people that are impacted by this problem.

Exploring solutions


Now comes the fun part. It’s time to identify solutions.

I will not discuss in too much detail processes by which teams and individuals solve problems – this demands deep knowledge of a specific industry, and special skills that I probably do not have. I do however recommend familiarizing ourselves with the concepts of Idealized Design and divergent thinking as frameworks to help think of solutions and answer the following questions:

  1. What’s the ideal solution? (If we don’t know what we want in an ideal world, how will we know what we want under constraints?)
  2. What’s preventing us from getting there today? (What constraints exist?)
  3. What’s the first step that we can take toward that solution? (Work backwards from the ideal solution to what is possible today under constraints. There may be multiple steps to eventually achieve the ideal solution, but what’s the first step that we can take? What’s the second?)

Another valuable resource that has helped me with problem solving is The Art of Problem Solving

Once a series of potential solutions have been scoped out, I recommend for the project manager to work with relevant players to:

  1. Describe the solutions in detail including:
    • What it is;
    • What impact is expected (both positive and potentially negative);
    • What resources are necessary;
    • Potential risks
  2. Rank solutions by a set of criteria relevant to the problem and the organization
  3. Seek agreement with stakeholders on which solutions to test
  4. Design experiments that can prove the effectiveness of the solutions chosen. This can take the form of a scaled-down version of the full solution, a fake back-end where the solution is launched without the full infrastructure or resources necessary to support it, or even vaporware if one is testing for market need.

The reason that I recommend testing solutions before changing processes is to minimize risk. Should a solution not produce the expected results, only limited time and resources would have been sacrificed.

Once the list of solutions to test are chosen, the project manager will draft project plans including a timeline with clear deadlines and deliverables. This ensures that all necessary tasks are outlined for accurate implementation.

OUTCOME: We now have a list of solutions to test, including a detailed project plan.

V. Does the solution work?

plan vs reality

Managing progress

To ensure that the project runs as planned, the project manager will be responsible to manage and report on progress. Questions that the project manager needs to ask include:

  1. Are we on path to the next milestone(s)?
  2. What challenges are we facing?
  3. Do adjustments have to be made to the project plan based on latest progress?
  4. Are we discovering new insights as work is done on this? Should the end solution be adapted now that we know more?

Many project management methods exist out there to help answer the above questions. In the context of start-ups that need quick validation and delivery of solutions, I recommend adopting an agile approach to project management.

Reviewing test results and identifying next steps

After experiments around solutions are done, it’ll be time to assess results.  Did we meet our SMART goals?

Specifically, all stakeholders and players need to:

  • Compare final results to initial expectations;
  • Understand where things went wrong, why, and how we can prevent that in the future;
  • Understand where things went well, why, and how we can consistently achieve this in the future.

It is especially important to review results of both progress metrics, that assess how specific initiatives and solutions performed, and outcome metrics, that assess whether the desired outcome was achieved. The ideal scenario is one where both progress and outcome metrics changed as expected, but there can certainly be scenarios where both were not impacted, or where the progress metric changed as expected yet failed to impact the outcome.

Insights gathered at the review meeting will help us decide whether to:

  • Cancel a solution due to its ineffectiveness; or
  • Iterate a solution and further experiment to see if additional improvements can be achieved before scaling its implementation; or
  • Scale a solution to the entire organization / process.

OUTCOME: By the end of this QI process, there is evidence to support the effectiveness of different solutions, and decisions are ready to be made as to whether to scale their implementation.

VI. We solved it. Are we done?

We’re never done. It’s human nature to never be satisfied. Once we’re on top of a peak, we will naturally shift focus onto the next peak to conquer. If we became market leaders in one segment, we’d shift focus to widen our lead or conquer other segments. We have the same mindset in our personal lives: The moment that I find parking in a downtown area where parking is scarce, my focus naturally shifts to whether I could have found parking closer to wherever I was going.

Fact is that most problems that we’re solving today are the same ones that our ancestors were solving hundreds of years ago. Love, communication, food, shelter,… Each generation solves it differently, using technologies available at the time. We used to communicate with smoke signals, and now we have emails and Twitter. We used to farm our own food, and now we have food delivered via apps. We used to listen to neighborhood announcements for news, and now we have email newsletters (so many of them). These fundamental problems will never ever disappear, and we will continuously innovate to solve them differently.

Whether our company will be leading these innovations and disruptions is another story. In the “Innovator’s Dilemma,” Clayton Christensen makes the argument that some of the best companies risk becoming irrelevant because they are too well managed. Sounds ironic? I highly recommend reading his book.

How do I project manage?

Considering that project management skills are essential to the successful execution of innovation projects, I recommend reading up on the subject should anyone be unfamiliar:

Recommended exercise

The next time that a problem comes up, let’s take a moment to investigate the problem, and accurately define it, before starting to solve it.

Subscribe on the right for new insights every week!

Leave a comment

Be the First to Comment!