There are a lot of engineering techniques that are not specific to running a Disruptive Innovation team. Still, continually guiding these teams to be relentlessly focused on producing business value has made a handful of tricks worth sharing.  Boiling it down, the focus is on the value of the product being delivered, on learning more about the market and reducing the risk that one or more of our assumptions about this product are incorrect. We’ve already covered A/B testing and other experimentation tools, but there’s so much more to it than that. 

Team Size

We first need to address the optimal team size for Disruptive Innovation teams. Jeff Bezos and Amazon are famous for their two-pizza teams, meaning two pizzas would feed the entire team, and this is a good thought. Assuming everyone eats, on average, two slices, and each pizza has about eight pieces, we’re sitting with about eight team members. But let’s break that down a bit more. If we have eight spots on the team to fill, we’ll start with one Product Manager, User Experience Designer, Marketing partner, and one representative from Sales. That leaves us just four spots to fill, and depending on the product you’re trying to build, perhaps four engineers is the correct number. If you have other disciplines that need to be involved in the development, say Legal, Program, Client Success, etc., you may have fewer “seats” for Engineers, and perhaps that’s OK. However, if we get to a place where we feel less than two engineers is necessary, we should seriously reconsider whether we need a full-time engineering team. 

A team of one is no team at all. Adding a second engineer helps with a few different things. First, it encourages higher-quality code reviews. If the code reviewer for your application’s changes is not regularly involved in the deployment and maintenance of the product, they may cut some corners or allow the team to ship code that isn’t thoroughly thought out. Beyond that, having a second engineer on the team enables either of the engineers to take time off and not feel guilty that the product is not advancing. Of course, you can have more than two engineers on a team, but it should almost always be your lowest level of investment in any Disruptive Innovation team.

There are exceptions, of course. Sometimes, it’s helpful to start without any engineers at all on the team. For example, if you have quality low-code/no-code tools to test assumptions. Other times, you may have a strong indication from the market that this will be a high-stakes product, and you want to start with a larger team to lay down solid platform components as you launch this new product. The key is to strike a healthy balance between the team size you need to move the product forward successfully without allowing the team to become too large too early and get bogged down in communication and other processes. 

We regularly consider the team size and Metcalfe’s Law: “The value of a telecommunications network is proportional to the square of the number of connected users of the system.” Said another way, you add N more communication points for every person you add to an N-person team. As an example, if you have a four-person team, you have only six points of communication (A->B, B->C, C->D, D->A, A->C, and B->D), but adding another person, E, add’s four more lines of communication (A, B, C, and D now each need to communicate with E) bringing the total lines of communication to 10. Every additional line of communication has a potential for mistakes or translation errors between the start and end of a discussion. 

Let’s take an example. Suppose Product Manager A is planning a new feature and has the experiment specification. First, they must communicate that with the Designer, B, and get their input. A & B then need to share their ideas with the developers who’ll build this feature, C & D. Once C & D finish building the feature, they can quickly confirm it’s correct with A and usable with B, and then ship it to production. Simple as can be. With only six lines of communication and the ease of fitting everyone into a tiny room, office, or Zoom call, you can efficiently communicate and deliver software.

Now, instead, imagine we have a Product Manager A, Designer B, five Engineers (C through G), two QA engineers (H & I), and two Release Engineers (J & K). Now, we have 55 possible communication points, some more used than others, but all are still available. Any of these points of communication can introduce noise into the transmission, which can result in either a need for repeated communication or a mistake being delivered. Perhaps a misunderstanding in the requirements for the feature was introduced by one of the engineers, or a change in the requirements along the way was not captured, and the QA engineers flagged it as a bug. No matter what the miscommunication is, you can see that the opportunity for miscommunication has risen incredibly, and you can also imagine that it results in more time taken for the feature to be delivered. To help mitigate this, you might consider standardizing the communication processes, e.g., the Product Manager writes down what they’re proposing, the UX designer captures mockups in a graphical tool, Engineers produce design reviews or other specifications, QA writes test plans, etc. These are practical tools; however, they are supplemental deliverables that have increased the time required to deliver a feature as you generate more and more metadata about the feature to live alongside it. Still, they do not directly provide any business value in and of themselves.

Team Charter

The origin story of our Incubator (the name we gave to the organization fostering all of the Disruptive Innovation teams) started with the exploration into team charters. Amazon (and a number of other notable companies, too) has a culture of creating a team charter for discussion when creating any new team within the company. As we reviewed the past successes and failures of the Labs team, we decided to write a team charter to capture what the team was meant to do. Our main goal was to capture what it meant for the team to be impactful.

Impact is a great tool to guide your teams if you can understand and measure it. Understanding it alone takes time but starts with considering what is essential within your organization. Impact can be any number of things: clicks, revenue, connections, and growth of CPM, but it can also be less tangible things like customer adoption, high-speed execution (coding or experimentation), or collaboration. A clear definition of what is impactful to your organization serves as an invaluable North Star for your teams to guide their decisions.

Initially, our team had already shown a remarkable ability to operate quickly and collaboratively. Our team focused on discovering business value, which was also an asset to leverage. We set out to write a team charter and realized that if we turned this effort towards Disruptive Innovation exclusively, we could create an innovation engine for the company. The first draft of a team charter for our Incubator included statements guiding us to continue to be great partners to the various stakeholders around the company, to be a level playing field for all Disruptive Innovations we were testing, and to ruthlessly prioritize the various investments we were making into those innovations.

Whatever target you set for your Innovation team, you’ll want a measuring stick included in this charter. This can be tricky because you want to avoid simple Ivory Tower innovation, Innovation for the sake of Innovation, or innovation that doesn’t lead to any lasting change in the organization. Our organization knew from the beginning that we wanted to be measured by Innovations that impacted the core business, or as we termed them, “exits.” Thus began our reuse of the various venture capital terminology: angel round, series A, exit, bridge rounds, and more that we’ll explore in the chapters to come. Depending on your organization, exits may not make the most sense; it may be more around the influence of other product areas or creating a repeatable pattern that can be adopted in other product groups, but this measure (even if it seems impossible to guess what the target value should be) will help the team to know what success looks like.

While we didn’t know how to set the total value of every exit in revenue terms as you would for a VC-backed startup, we did know that if we were successful at convincing the other organizations around the business that there was value in our products and that they were worth adopting and merging into their lines of business that we would have produced something Impactful. We gave our team a lofty goal to grow each of their products into something impactful to another business area and to align with the various company metrics that made the most sense to help make it directly comparable. For the program, we picked a somewhat arbitrary goal of having at least one out of every six experiments exit successfully. This could easily have been anything between one out of four or one out of ten, but anything outside of that seemed ludicrous and like sandbagging, respectively. 

Measures v2.0

After a few years of building products and running the program, we stepped back and realized we could summarize the organization’s most essential values into three key deliverables. First and foremost was the desire to create “exits.” Exits are the most tangible measure of impact as they are, by definition, your team creating additional business value for another business group. In some cases, you may even be able to do a back-of-the-envelope calculation on the true dollar value created or, to make yourself feel even better, just how much the company would have spent purchasing a similarly sized startup. But of course, that’s not strictly necessary, just a bit of navel-gazing.

Learnings are the second area that demonstrates value, albeit a lesser type. Here you’ll capture the failed experiments and early iterations of various teams trying to find business value. There are a lot of assets shed by the Innovation process we’re describing: original pitch decks, re-funding decks, planned expansions or pivots, and most importantly, the presentation of the final learnings. 

This final presentation summarizes all of the key learnings over the timeline of this product experiment, showing both the things that were successful and the things tested which did not work. This is a blameless exercise and should be celebrated (we like cookies, or cake, or cookie cake!) as the team may feel down about the inability to produce a new viable product. The significant part is that if you keep all of these assets in a widely accessible place in your company’s documentation/knowledge-sharing system, you’ll find that it cuts off similar ideas that have not been thoroughly researched and that it also makes any related pitches for new Disruptive Innovation teams that much stronger.

Finally, as your Innovation teams need to quickly and efficiently discover new viable product ideas regularly to continue this investment, using Velocity as a measure of impact is a good idea. This encourages the team to remember that the instinct is to slow down as the product matures, but we must continue investing in ways to keep the product moving forward quickly. This means both the development and deployment of the product to end users and the experiment velocity — the speed at which an idea can be created, deployed, validated, and rolled out to all users, or else invalidated and removed from the codebase. While we didn’t work hard to directly measure the actual Experiment Velocity in any real units (See Goodhart’s law for one reason to consider not directly measuring this), having a number of other measures related to it (delivery lead time, team health, experiment duration, etc.) will give you a good indication as to whether your team has a health Experiment Velocity.

Given our team design and constraints, we had a goal to be the fastest-moving team within the company. We never made the competition with others explicit or denigrated other teams with lower velocity (recognizing that they had very different constraints they were operating under). Still, as a leadership team, we were constantly on the lookout for any tools or techniques that other teams were using that we could leverage to go even faster.

Executive Support

Once you’ve designed your team charter and defined your success metrics, it’s time to get executive support. This will take a number of forms, and you’ll need more than one executive bought in to make it work. These executives will be the board members overseeing each of your Disruptive Innovation teams to make sure they stay on track, helping clear blockers for those teams, and the person who holds the most sway in whether a team continues to innovate on this experiment or moves on to another opportunity.

First and foremost, you’ll need an executive sponsor for the program. This could be the CEO, President, or any other executive, and with their broader reach across the organization, it will be helpful if it is. The first thing they’ll do is provide legitimacy to the program to other senior leadership team members, convincing them to lend a few members of their teams to your program. You’ll also need some regular time with the executive sponsor to discuss a few key topics: cross-functional needs beyond the bounds of your program to ensure that all of the blockers and slow areas of the company are (relatively) smoothed out for your Disruptive Innovation teams. They’ll be essential in helping promote the organization and the opportunities to contribute to the broader company. And finally, the executive sponsor will also be the one to determine who else within the company has the power/privilege of selecting the Disruptive Innovation teams (a role they’ll likely play as well.)  We’ll call this role the Product Executive Sponsor to keep it clearer.

Having seen this a few times before, if this program is solely sponsored by the Product or Engineering organization leadership, you’ll miss the larger opportunity to use the force multipliers of Marketing, Sales, Legal, and so much more. Additionally, you’ll limit your learnings from Disruptive Innovations to the Product/Engineering realms. Having Marketing, Legal, Sales, and more involved in the early stages of the project will allow their organizations to learn ways to improve their process and extract additional insights from your team processes.

The Product Executive Sponsors could be heads of various business divisions or their delegates, the heads of Product Management, Sales, or another functional area, or even active board members. What matters here is that they have the authority to green-light a Disruptive Innovation team and the business experience needed to guide it as it seeks to produce additional business value. These sponsors will meet regularly, likely monthly, with each sponsored team to review the current progress, product experiments, and planned work that’s coming up. Additionally, they’ll be the ones to lead the decision around whether or not a Disruptive Innovation team should continue or stop work on this product at seminal moments of the product lifecycle.

Avengers Assemble

Assembling the “perfect” team is another area for much consideration. A few clear elements are needed for a Disruptive Innovation team, namely the Product and Engineering team members. Still, the Innovation Program should provide a number of other cross-functional staff members to help ensure that all of the roadblocks for your Disruptive Innovation teams are eliminated regularly and efficiently. 

Product Managers

The Product Manager will act as the CEO of this Disruptive Innovation team. They work with the team and the executive sponsor to establish a vision for where the product will go. They take in all of the user feedback, session data from your web applications, information from various product experiments, and feedback from the team on the return on investment of various features and provide a clear, executable roadmap for the next few steps. We’re not going to go into a ton of detail on the techniques of Product Management that make the most sense here, but “Inspired” by Marty Kagan and “Nail It, Then Scale It” by Nathan Furr and Paul Ahlstrom (especially the Nail It section,) are a great place to start. “Lean Startup” by Eric Ries also has a lot of great resources on this topic.

You may be able to use reasonably junior product managers for some smaller projects. Still, generally speaking, a more senior product manager for any sizable product will probably be necessary to establish the right culture of innovation, experimentation, and measurement, as well as the everyday tasks of keeping a healthy backlog of ideas for the team to keep moving forward.

Very briefly, let’s talk about an anti-pattern in Product Managers. They are not the decision maker. They facilitate the team making decisions. In the worst-case scenario, they cast the tie-breaking vote or override the team with a lean experiment that will shed data on the direction the team should go next. These Product Managers need to partner and lead their team through influence, not the strength of will.

Engineering Team

Engineering teams will be comprised of at least two software engineers, never less. A team of one is no team at all. Having at least two engineers allows individuals to take time off, attend conferences, and work on their career development without feeling bad about the project’s trajectory. Generally speaking, early on, you’ll be able to do a lot of the work with more junior and mid-level engineers, depending on how many integrations you’re using to leverage your core product, but as the product grows and expands, you’ll either need to give more responsibility to your engineers or bring on more senior engineers to help the product grow and scale successfully. 

Initially, some of this higher level design and planning can be led by the engineering manager for the team. They’ll be responsible for establishing simple, workable engineering processes that keep the team building and deploying software regularly. Given the overall team size, your engineering managers (unless they’re fairly new to the profession) will likely manage two or even three teams. More than that is possible for short periods, but if the teams have very many ceremonies at all or if the overhead of your organizational processes (security, procurement, privacy, etc.) takes much tax on your engineering managers at all, it will be tricky for them to manage more than three teams at any given time.

Occasionally, as the team grows, you’ll need additional engineers beyond what the project demands to ramp a new engineer up on your technology stack or cross-train an engineer joining the program. This should give your more senior engineers on the team a chance to mentor the new team member. Still, you should encourage them to use the extra time to contribute to your base project definition so that your team’s next experiment will start from an even better place.

User Experience

User Experience Designers are crucial to at least two main parts of the Disruptive Innovation teams. First, they’ll help provide mock-ups and designs for the product’s progress, such as the long-term vision. These mockups will help the team understand the value proposition for this product and how customers are expected to experience the product. But these designs are a vision, not a goal to be achieved necessarily. The second thing the Designer will provide is a clear picture of how the critical feature of the minimum viable product (MVP, see “Lean Startup” if you’re unfamiliar or need a refresher) will work. Engineers should be able to quickly and easily convert these designs into a usable products.

One critical thing is a common design language shared between Engineers and Designers. We recommend something simple and easy to use, like Twitter’s Bootstrap UI framework, but any design library will work. The goal here is to constrain Designers to use “off-the-shelf” components as much as possible so that Engineers can quickly and easily assemble those components and focus on the core business logic that makes the product valuable to your customers. You’ll need to customize it a bit to make it look like the rest of your site, but with minimal overhead, you can have a simple and usable design library.

Another couple of things we’ve tapped our Design teams to help with have been both kickoffs and collecting user feedback. Kickoffs are the first three to five days of a new product and typically involve a Design Sprint (See “Sprint” by Jake Knapp for more information on this technique). Still, historically we used a more home-grown approach of collaborating on a Lean Canvas to identify the product attributes. Having a designer lead this effort is helpful because they’ll become very familiar with the user’s use cases, pain points, jobs to be done, and desires. 

Our Design team has also been invaluable in collecting user feedback. We’ve used a number of techniques, from paying for feedback via tools like Usertesting.com to capturing structured data in our own Usability Lab (pre-Covid of course) or other tools like Hotjar and FullStory that allowed us to monitor user sessions after the fact. Teams would often do lunch every week or two and review key user sessions pre-selected by our UX team to help everyone feel connected to the pain and successes of our customers.

Marketing & Sales

The Marketing team will be critical in the early-stage Disruptive Innovation teams. Since it’s a brand-new market or product, user acquisition will be essential. A strong Marketing partnership will allow you to either “buy” users via search engine marketing (SEM) or run successful marketing campaigns via email or other mediums. Additionally, Marketing will be key in testing the messaging on your products’ landing pages, ensuring that the value proposition to users is clear and crisp. 

Depending on the product, you may also need some Sales representation. The Sales team will help test the various paths to customer acquisition (direct sales, phone sales, etc.). Sales will also be instrumental in discussions and experiments centered around pricing models and price testing. Some products will not require a Sales team member, but having someone to bounce ideas off of or give other advice will still be helpful.

Program

Program Management plays a vital role in running the Incubation program as a whole and guiding each Disruptive Innovation team through various hurdles that may present themselves. Either way, the Program function will make sure that dates and deliverables are communicated, they’ll help break down some of the larger projects into smaller milestones, they’ll work with various stakeholders to make sure trains keep running on time and equally important, they’ll spearhead capturing the key learnings from each project as it shuts down or exits.

Let’s first examine the program as a whole. Here, Program will manage the group’s calendar to ensure that all executive check-ins, regular and continuation pitches, and learnings presentations where acquired or shut down projects share their learnings with the broader organization and company. Program will also be helpful here in securing various commitments from partner teams around the organization to keep the Incubator program running smoothly. Teams like Procurement, Security, Accessibility, and Privacy will often want both commitments to quality and safety. Still, they will (with some finagling) be willing to give some concessions on speed, knowing that Disruptive Innovation teams will often only last a few quarters.

How Program supports individual teams will vary based on the team’s goals, where in the project lifecycle this team is (newly funded, rapidly growing, preparing to exit, etc.) Program will help ensure that any applications or services the team needs access to are quickly secured. Program will also be the heartbeat pushing the team to capture and share learnings regularly with the teams around them and the company. Program is a bit of a catch-all role, so it would be impossible to list everything they will do, but consider them the conduit through which most interactions with outside teams/organizations will often flow. As such, they play a critical role in helping the team keep their speed of delivery high.

Legal

Depending on your organization’s risk tolerance, your partnership with Legal could vary between a consultant on your projects and a key stakeholder with “veto” power over the Disruptive Innovation teams. The key here is to build a partnership with Legal that helps them understand that your program will work to minimize risk (fewer customers, less revenue, less data, less time, etc.) in exchange for a bit more forgiveness if they push the boundaries too far. 

It will be helpful to understand the key risk areas for the company as a whole (e.g., financial or health insurance compliance, Fair Credit Reporting Act or other disclosure requirements, or something else entirely.) We regularly referred to the largest risks for our company as the four horsemen, as they had the potential to end everything. These are critical to understanding and regularly training your team about them so that they can avoid running afoul of them.

Beyond the general company-ending type risks, each of your Disruptive Innovation teams will often face several other risks. Having a partner in Legal who can help navigate these risks and update any terms and conditions, privacy policies, or other legal documents will help maintain smooth operations. Initially, they’ll want to work on language that also protects the company from “beta” products. This umbrella legal coverage gives your team a lot of room to experiment.

Hiring for Disruptive Innovation

Creating and growing this team will require a fair amount of external hiring (and a healthy amount of internal transfers.) The challenge is that your Disruptive Innovation teams will likely have a rather different approach to software development than your other teams. With that in mind, simply reusing your existing hiring approach will not likely provide you with team members who are well-aligned with the Scaling Innovation approach. Hiring for these Disruptive Innovation teams is always tricky, but we’ve found a few techniques to make things a bit easier. 

Flexibility

Not surprisingly, Flexibility is a key attribute of Disruptive Innovation teams and team members. You’ll need team members who can flex from their core discipline into customer support, user experience, product strategy, sales, and so much more. Additionally, flexibility will be key in finding team members who can quickly move from one project to another without being overly attached or crestfallen when a project ends. 

Finding genuinely flexible people is one of the hardest things to interview for. Of course, typical behavioral interview questions will give you some indication. Still, we’ve found a number of questions like “Tell me about a time when you had to do something that wasn’t in your job description” or “Tell me about a time when you had to ‘hack’ a non-technical system to your benefit” can help you find people who not only are flexible but those who genuinely enjoy flexibility.

Initiative

Gets sh*t done. See’s a problem, kills a problem. Doers. Whatever you want to call them, people with initiative are worth their weight in gold. Initiative is critical for Disruptive Innovation teams because there’s much to be done and many more problems to fix. Of course, initiative on its own is a bit dangerous. You don’t just want people who took initiative on the various inane tasks that cropped up, but instead, those who could discern which items were worth their precious time and attention. Spotting initiative in a typical interview is tricky, but with deep questions about the work they undertook at previous employers or a few behavioral questions like “Tell me about a time when you went above and beyond” or “Tell me about a time when you had an idea and saw it implemented” you’ll be able to spot those who possess more initiative regularly.

Jack of All Trades

Being a “jack of all trades” can be considered a negative in many places, but for Disruptive Innovation, it’s a very strong complement to the flexibility we discussed earlier. Not only are you willing to take on a customer support call, but you also have vital emotional intelligence and can help solve problems to make the customer happy again. Or perhaps you can solve backend business value problems and create a clear user experience. Whatever sets of skills you have, they’ll be useful if put into practice. 

There’s a good corollary to this: hiring for diverse experiences and backgrounds will give your team more chances for success. Bringing on diverse talent with varying years of experience, skills, previous company sizes, industries, and other factors will empower your team in ways a monocultural team could never achieve. Yet another win for diversity!

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.

I announced in November of 2021 (with an update in December as well) that I was writing a book about our Incubator and the Scaling Innovation process. After approximately a year of mostly hiatus, I picked back up editing and re-reading that first draft. It’s not perfect. There are several other books out there about similar things. I have about a million other reasons to just delete it…but…it’s written, and now that my time at Indeed has come to an end, sharing a bit of our story feels like a useful ending. So, here’s the prologue to the book. I’ll try to release a new chapter approximately every week or two going forward. I’d love any and all feedback – LinkedIn, the contact form, Twitter (I’m paying less attention to this of late until the hubbub settles down, or Mastodon.

Prologue

Like any process, this one isn’t perfect, and it isn’t static. However, our strategy for scaling innovation proved successful on several occasions. Over five years, more than four dozen products have been tested using this approach. Many did not work out, but a few survived and thrived, making a significant impact. 

Our team comprised start-up veterans from Product and Engineering, leaders, boot camp graduates, and classically trained Computer Scientists. Before we started the Incubator, the team had honed several vital skills, such as rapidly delivering business value and measuring product success. They learned that shipping a product required acquiring users quickly to demonstrate the value created was something users truly wanted. Adopting the Scaling Innovation approach allowed the team to iterate swiftly on the innovation processes and the platform that powered them.

The team behind this success wasn’t special or unique. What set them apart was their deep-seated desire to improve the business every single day. They were relentlessly focused on helping more people find jobs. We couldn’t have achieved this without their diverse thoughts, opinions, and experiences.

Scaling Innovation is about the process we developed, discovered, and borrowed from various sources, along with the parts that made it work for us. It’s not a static process; it is still evolving today, more than five years later. However, it has been successful, as you’ll see. In this book, we will discuss the following:

• The importance of the Scaling Innovation process
• An executive-level introduction and a fictional example project
• Strategies and techniques to help Engineering and Product teams
• Meta-level guidance on running a Scaling Innovation program
• Case studies and anti-patterns for Innovation teams

We hope this book inspires you and your team to overcome challenges in innovation, persevere when your resources seem exhausted, and ultimately grow your business in unexpected and remarkable ways.

I’ve wanted for a few years now to stop and write a book about the amazing innovation team we’ve built over the last five or so years, but the pace of life with the kids and the hectic nature of growing 10+ startups simultaneously have always gotten in the way. This month is no better, and yet, thanks to the Nanowrimo challenge I’m three days into writing a book on Scaling Innovation (title to be determined, but that’s not a bad working title for a book, I think.)

Honestly, I have no idea if this book will ever see the light of day, but the very act of revisiting the early days of creating the Incubator team, hiring, staffing, planning, and with the help of hindsight reverse engineering the work we’ve done has already been an insightful exercise. I’m not ready to share anything more just yet but did want to take a few minutes to procrastinate and put a bit more social pressure out there for myself to accomplish the goal of writing a book. Nanowrimo is mostly about writing novels, but I figure a business book is more my speed. I’ve told several close friends and a good number of my team members that this book is in flight, but this is a bigger stage than any of the rest of that combined.

I did a fair amount of pre-thinking and some organizing of my thoughts for this book for the last month or two in anticipation of Nanowrimo, and then really just started writing on November 1. It’s not any easier to find the time, but thankfully given the five years of lived experience, and the long-winded nature of family members that I’ve clearly inherited, it’s not been too hard to have the words flow. I’m behind on my goal due to missing a day already, but I’m hopeful that between weekends and some extra days off here and there I’ll be able to make up for the missed days and get caught up.

If you’d be interested in reading a book on how to create successful innovation teams and the process we created/adapted/stole that as launched 10+ new ideas into the ecosystem (several of which are multi-million dollar opportunities) drop me a line via the about page, or on Twitter. I’m not doing this for the dozens and dozens of dollars, I truly have enjoyed this experience and look forward to sharing it with you all.