Why read this book?

We’ve written this book to share a strategy for Product and Engineering leaders trying to introduce (or, more likely, re-introduce) innovation to their company’s way of operating. Whether your company is doing fine and you want to future-proof it, or a competitor has already disintermediated the core product and you need to turn the ship around, Scaling Innovation will provide you with a holistic framework for creating an innovation fire within your company. It also offers numerous useful strategies for stoking that fire until your next innovation is wildly successful.

Beyond the strategy, there’s a story playing out on these pages. If you sit back and take it in, you’ll see opportunities to apply principles from Scaling Innovation to any team you run. Every team needs to innovate, and you should filter these ideas into your company and role. So, take what works for you, skip the rest, and share your experiences with others. That’s the beauty of this industry: we’re all a work in progress.

What is Innovation?

Let’s start by clearing up a few things on Innovation. This book presumes three types of Innovation, with the core focus on the final type. There are probably a million more definitions you could use, but one of the things we’ve learned over the years is to keep things simple enough they can be repeated easily and regularly, and three fits nicely on one hand and in people’s brains. The three types of Innovation we will reference owe a lot to the McKinsey study on the three horizons of innovation. That’s a good read when you’ve got the time, but we’ll provide a cliff notes version to get you started today. (Incubator Principle #1 – get started and then get better!)

Merriam-Webster defines Innovation as “the act or process of introducing new ideas, devices, or methods.” For our purposes, we’re heavily focused on software engineering, particularly product innovation, given our backgrounds in both startups and enterprise organizations. So our focus is on new product ideas, new devices to solve customer needs, and new processes to further our business.

The first type of Innovation is Sustaining Innovation. These incremental improvements keep a product functioning well, more flexible for your users, and using the vernacular is often referred to as KTLO (Keeping the Lights On) work. Teams must recognize the impact of these innovations even though they only produce small incremental changes overall since those improvements continue to help keep the core of the company afloat and show users that you still care about this product. A few examples of this type of Innovation include improvements to friend recommendations, improved ad relevancy, new processes that simplify the user flow, features that make the product more usable, or new technologies that dramatically improve the page load time. This work is done by core Product and Engineering teams every single day.

The second type of Innovation is Emerging Innovation. The goal is to leverage your existing product base into a new opportunity. It’s a fairly natural extension of your current product or services into a new but related space that users expected your company to move into. It will likely change some of your business processes, teams, and maybe even business models, but ultimately you are still in the same overall business afterward as you had been previously. Your existing Product and Engineering teams will also accomplish this type of Innovation if you give them the mandate and opportunity to do this work. Examples of Emerging Innovation include techniques like updating the product to move from a pay-as-you-go model to a subscription model, utilizing machine learning techniques to automate previously very manual portions of a task, or changing the delivery mechanism from email to the latest platform that reaches your audience (SMS, Twitter, Facebook, TikTok, or whatever comes along to make these references out of date).

Both types of innovation are still mainly on the S-curve, as described in Clayton Christensen’s book “The Innovator’s Dilemma.” A great read as well, but to butcher a masterwork and keep us moving forward, we’ll summarize it with this: incremental innovation (whether sustaining or emerging)  will lead you to a local maximum within your current market but is unlikely to notice and foster the growth necessary to take your company to a new growth curve, in a new market, with a higher maximum. The important part is not to miss the opportunity to innovate and jump to the new curve at the right time.

The third type of Innovation is Disruptive Innovation. Here the innovation will replace your core business or add another more valuable line of business to your existing company. These big ideas are locked up in your organization, and you need to execute them, or else a competitor or a startup will come along and beat you to the punch. These opportunities are yours to lose and are the book’s focus. These processes and techniques can be adjusted to help discover and deliver Sustaining and Emerging Innovations. Still, the goal is to provide a framework for building a Scaling Innovation team that regularly delivers disruptive innovations to your company. Disruptive Innovation can not be done within your existing Product and Engineering teams; you’ll need dedicated and specially equipped teams to do this work. Let’s talk about why.

Killer Innovation or Innovation Killer?

Many teams will discover Disruptive Innovations in the course of their daily work. This happens when a salesperson speaks with a customer, and the customer explains how they wish the company could make something easier. Or when a customer service representative takes a call and listens to an upset customer disappointed that your company’s product doesn’t meet their needs. On the Product and Engineering side, this occurs when a team sees an opportunity to re-think their product and dramatically provide users more value. Unfortunately, most of these ideas aren’t shared with anyone. The lucky few may get started but then die on the vine when a team tries to tackle it, finding that there isn’t organizational support to make it successful, and concludes that the business idea failed.

At a certain size, companies often begin to take on a portfolio approach to the work. Dividing into divisions or general manager areas will simplify decision-making and clarify ownership. Innovation teams often don’t fit nicely into these paradigms, and some corporate structures will work against innovation teams running rogue. Let us look at a few reasons Innovation teams will need different support structures.

Nurturing Growth

Successful Innovation can take off at a new speed, often growing five (or 10, 20, 50) times faster than the core business (while still much smaller). That growth on its own may not be that scary, but when you couple that with some of the other risks, it can be a very scary proposition for teams. Nurturing that growth and turning it into a large new business area will require extra time, attention, and resources to keep it alive.

Coexistence

Disruptive Innovation teams also find it hard to relate to the teams around them as they work on the next new thing and find that none of them are doing anything similar. The Disruptive Innovation team is often on their own to get access to the resources (be those technical tools like APIs, data, or services or cross-functional support like Marketing, Legal, etc.) that they need to be successful because the company has to focus on the core product line.

Transform the Business

Disruptive Innovation teams are often a risk to the core business metrics. They may be challenging the way business has always been done or actively pull users out of your sales funnel to their new (lower margin, higher cost, less proven) product interface. Giving them time to grow and mature (or flounder and fail) will allow the business to see if a new market opportunity is just on the horizon.

Adaptability

In our experience, this is the most common scenario that kills Disruptive Innovation teams. The rest of the business struggles to hire or hit key business metrics, and the Innovation Program is indiscriminately shut down to reallocate those staff members or budget dollars to other projects. 

Note, this doesn’t mean we advocate never shutting down Disruptive Innovation teams. On the contrary, we regularly assess the projects in flight and shutdown Disruptive Innovation teams very often, but always because that innovation isn’t likely to pan out or there is a bigger innovation opportunity on the horizon that needs exploration (more on this later.)

So what does work, then?

So if embedding Disruptive Innovation teams into your core business doesn’t work, how should you structure your teams? The rest of this book lays out a structure for building a program, a collection of teams dedicated to Disruptive Innovation. A process for discovering those innovations, incubating them, and seeing them transition successfully into the core business. 

Executive Summary, or TL;DR for the younger, hipper crowd

So many business books are written about business, but they fail to demonstrate one of the key successful business communication techniques. In business communication, the executive summary at the top of a document or a TL;DR (too long; didn’t read) section allows those under time pressure to feel like they’ve learned the book’s core message without spending hours reading it. Additionally, a summary up front makes the whole context clear so that the remainder of the content is easier to consume. This follows the adage: “Tell me what you’re going to tell me. Tell me. Tell me what you told me.” 

Scaling Innovation establishes a framework for building a program to find, foster, and integrate Disruptive Innovation within your company (or organization.) It draws on the examples and iterations from a program run at Indeed for the last five (more now) years. It will guide you in establishing a program, finding the executive buy-in and budget, and building the organization to execute these Scaling Innovation teams. 

You’ll learn what makes the Engineering and Product teams successful and how those teams differ from your typical ones. Additionally, you’ll see how the program’s operation works and learn from some of the most successful products in the first five years of the Indeed Incubator and a few missteps we made along the way.

The core values for this program focused on autonomy (of the program as a whole, but also for each team,) speed of experimentation and learning and a holistic view of each project. Breaking down some of the other keys to this model:

1. A dedicated team to explore ideas.

Disruptive Innovation programs should be detached from your core business. They’ll get oversight from the executives they report to and through the leadership placed in charge of this program but should not be directly responsible for other lines of business or business metrics.

Dedicated teams provide focus. They prevent other work from interrupting this Disruptive Innovation team. Dedicated teams let you hire for the additional skillsets necessary to make this growth and exploration successful (entrepreneurship, flexibility, and others). Separating this program into a separate team with a separate budget allows you to track the costs and revenues attached to this work to understand the return on investment. It also provides a sub-cultural identity that the team can rally behind as they work to re-invent your organization.

2. Executive sponsorship.

Having multiple executive team members, namely the chief executive, head of product, and head of engineering, bought in on building a Disruptive Innovation program will be crucial to the program’s success. The program will require their time regularly. Their input on product ideas, pivots, and other strategic directions to explore will give the team the high-level direction they need, as well as the validation of their current work.

Executive sponsorship also provides these dedicated teams with a “trump card” they can use (sparingly) to keep their project moving forward. Executive sponsorship provides a broader context to a team that could otherwise be very inwardly focused. Having at least one executive buy-in on the new product idea provides an air of legitimacy to the work to the other parts of the organization and a sounding board for pivots.

3. A cross-functionally aligned approach.

One of the biggest challenges of running fast-moving Disruptive Innovation teams is interfacing with other parts of the business. It’s like meshing a set of gears. The Scaling Innovation team is running very quickly (at a very low scale, most likely) and still trying to discover product market fit. The company’s existing parts are used to a much more tried and true (and likely scalable, repeatable, documented) process. Bringing these two things together can cause some friction. Having a cross-functionally aligned team can provide a layer of grease between the Scaling Innovation team and other parts of the organization. For example, having a Marketing person attached to the Scaling Innovation team allows the team to speak “Marketing” and know what systems are there to support the team. They have a liaison in Marketing and someone who can execute various Marketing components of growing this new idea into a full product. Pulling in all of the necessary cross-functional staffing to support these teams will save a ton of time and energy. Examples of the sort of help needed likely include (but are not limited to) Marketing/Growth, Sales, Legal, Security, and Program (beyond the core of Software Engineering, Product, and User Experience.) We’ll talk more about the role each of these plays in later chapters.

4. Minimal overhead, maximum speed.

While Disruptive Innovation teams have to meet your company’s minimum guidelines for data governance, security, privacy, etc., dropping as many of the other limitations on these teams is helpful. Allowing teams to use whatever style or software development lifecycle, customer engagement tracking, email campaign tools, and more will allow them to learn from their customers and discover new businesses quickly. 

Additionally, they should only own the product experiments they’re building (no maintenance of legacy projects.) Any legacy products should be shut down to avoid building up a backlog of products that must be updated, measured, monitored, and maintained. Occasionally, Scaling Innovation teams may find it helpful to build a tool or a service to make innovating faster or easier. These should be as small, simple, and low maintenance as possible.

Finally, Scaling Innovation teams should have a bias toward action. They live and breathe moving forward. They leverage processes that get products live as soon as possible and start measuring from day one. 

5. Projects are dead unless proven otherwise.

To keep the maintenance burden on legacy products low and ensure the team is always working on the most important things, you’ll need an effective way to shut down projects quickly and move on to newer or more important work. Investing upfront in a process for quickly disabling products, transitioning users out of the product, cleaning up all lingering data or other assets, and capturing learnings from the project will pay dividends. You’ll shut down more projects than you claim success on.

An Example Project

Another way to quickly understand the Scaling Innovation approach would be to walk a fictitious product through the lifecycle from pre-pitch to exit/shutdown. Suppose a Sales Engineer at BigCompany has just discovered a new opportunity adjacent to their core business. They research the idea and discover the Incubation program that allows them to pitch the idea for funding and apply to pitch at the next round in a few months. In the meantime, they meet with a Pitch Coach who helps them think about the total addressable market, minimum viable product (MVP), and competitive differentiation for this idea.

The months fly by, and soon, it’s time to pitch to the Executive team. The Sales Engineer has created a slide deck and comes into the pitch well-prepared for many of the questions the executive(s) will ask. The pitch goes quickly, clocking in at just a bit more than the five minutes allotted, and the questions and answers portion also goes pretty smoothly. They can answer several questions about the competition, how they plan to get started, and the key measures for this new product. They feel good, and the executives can tell the Sales Engineer has done their homework. After the Sales Engineer steps out of the room, the executive team discusses the pitch briefly, and very quickly, one of the executives agrees to fund this product. This executive will be the executive sponsor. They give the team a typical Angel Round of funding – three months, a budget for three-five full-time team members, and a general expenses budget of around $50,000 that they can use for Marketing, customer rewards, contractors, services, or anything else within reason that will help the team go faster or learn more quickly.

In the before COVID-19 times, the Sales Engineer would have relocated to the office where the Incubator team was located. However, since everyone is still working from home, they plan to leave their Sales Engineering role and join the Incubator team as a founder. In the meantime, the Incubator team is a flurry of activity, lining up two (maybe more) engineers, a product manager, and some additional user experience, marketing, sales, and other help to launch this new idea. Most of these people come from other Incubator projects or were working on internal projects until a new Scaling Innovation team was formed, so there is no need to wait for new hires to interview and start getting this project up and running.

The new Founder’s first day on the Incubator team is hectic. They’ve been introduced briefly to their team a bit ahead of the start, but today is the official kickoff. The whole team will be there – all full-time members and a handful of other folks supporting this product alongside others, e.g., User Experience, Marketing, Sales, Legal, etc. They’ll spend the next three or so days in a modified Design Sprint (hat tip to Google Ventures and Jake Knapp for this great process) to learn what this product will look like when it ships to production. They focus on the customer and the pain point the team is trying to attack. Next, they consider how the company and team can help solve this pain, paying special attention to how the company platform can be leveraged to create a competitive advantage. They are going back to the first principles of the design of this product, ensuring that everyone on the team understands the key value the product is meant to provide.

After the kickoff, the Founder moves into an advisory role guiding the team and helping to line up the necessary clients to test the idea. The Engineers, Product Manager, and others set out to build the MVP, ideally shipping it before the end of the first month. This will give the team time to measure and test a few different ideas before they have to pitch for continuation around weeks 10 to 12. The Marketing and Sales team partners for this team kick into high gear to explore messaging and sales models. The User Experience team has already lined up a few user tests of various mockups and other simulated screens to begin getting user feedback.

In a flurry of activity, the MVP goes live one month into this project (after a preliminary review by Security, Legal, Privacy, and a few other teams to ensure compliance.) The team will do a deeper dive with many of those teams in the future, but enough of the boxes were checked for now to start gathering real user feedback. It’s a rough and somewhat embarrassing MVP, but it does provide some value, and customers begin to sign up and use the product. The team regularly gathers to watch user sessions and see how users expect the product to work or what value they hope it can provide for them and continue to plan the enhancements to the product. 

For the next four to six weeks, the team works feverishly to develop the key features for this product, with a heavy focus on things that provide the most business value or reduce the risk to the product’s success. They know they are shipping some less-than-ideal code and user experiences (i.e., technical debt, more on that later), but they also know that if the product doesn’t get continuation funding in a few weeks, none will matter. As they approach the end of the first quarter, they begin to work together as a team to prepare the continuation pitch, which will show the results of their work, what they have learned so far, and where they will go next if given additional funding. 

Each week throughout the project’s life, the team gathers to discuss the results of A/B testing for various key features, the overall strategy, and the deliverables that have shipped since the last chat. It’s an informal meeting with other Incubator team leaders and senior Innovation leadership. It works as a way to challenge assumptions and help the team move faster or with more clarity and direction. The team meets with their executive sponsor monthly to review progress, get their guidance, and ask for additional help.

The day of the continuation pitch arrives, and the team watches with bated breath as the founder shows the executive sponsor and a broader funding committee a snapshot of what the team has accomplished and where it plans to go next. This time they have a bit more time, and everyone has more context on the product and progress, so the focus is on direction and execution. All signs point to a strong start for this new product. So after the founder and team step out of the room, the executive team has a quick discussion that makes it clear they want to continue the product experimentation in this area and increase the investment. Of course, they could have chosen another three months of funding, but the project is promising, and giving them more time to run could be what it needs. This time instead of only three months, the team will have six months before the next continuation pitch, and rather than just doubling the budget, they’ll get a triple budget. They now have room to bring additional engineers or other necessary roles onto the team and have a larger general budget. The next six months look a lot like the first quarter. Weekly check-ins with the broader Incubator team. Monthly executive check-ins. Experimentation and growth. Rinse and repeat.

Now the team has come to a fork in the road; they can continue to receive additional funding rounds, 12 months, maybe others even longer, and eventually reach a point where the project is so large and successful that the best thing for it is to exit the Incubator all together, or they can reach a point where the executive team no longer wishes to invest additional time/money into this project in which case it will shutdown. Either way, the team will work to produce several presentations and other documentation on the learnings from the product and share them with a variety of stakeholders around the company. Those final presentations will also be archived on a wiki page or other internal documentation hub allowing everyone in the company to see what the team tried and learned.

All of this can play out over ten weeks, or it can take years to reach a point where the product is ready to exit the Incubator. This system of metered funding provides the framework for evaluating products regularly to compare the opportunity cost of continuing with the various other ideas the company could be pursuing. It also acts as a governor to prevent wild overspending on any new ideas to make sure that they compare apples to apples with other experiments the company has tested previously. It prevents a product from looking successful because it’s getting pumped with so much extra funding compared to other products and rewards the frugal successes. The first thing you’ll need to build this is a team who understands how to Scale Innovation.