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!