YC seems good. Why not build your own?
how to launch an innovation lab within BigCo (or startup) and do it all so that the teams learn the max and have the most fun
Est reading time = 5min
Today at a glance:
Create strike teams = small independent teams (2-5 ppl)1
Leave them alone. Optimize for speed
Focus on the core loop
I’ll break down exact steps and learnings from building products from 0-1. In my experience, this applies to both startups and to teams within big companies who are trying to innovate. If you want to skip to the building part- scroll to the bulleted list. And if you want brief context -read on.
Among the 4 failed start-ups that I tried to build and or joined - those that got along the furthest were the smallest teams. These were the teams that also had the most fun and learned the most, even when we failed (which was 100% of the time).
After Microsoft purchased Minecraft for $2.5B in fall of 2014, a small team was formed in Seattle to partner with existing team in Stockholm. Someone believed in me and gave me a shot. After handling a mix of ops tasks, I was focused on new bets within the studio. One of the principles set by our Studio Head was to act as stewards of the community and to protect the IP. This was the right call.
So there were many goals and not many people. Limited resources, many goals, and an over-arching principle that we had to be hyper thoughtful about what we commit to in public → strike teams were born. Strike teams were small autonomous units that were trusted to execute against a goal. New bets by design got little funding relative to the core.
Constraints forced speed and creativity.
At Streamlabs, there is the core business, which is all the products and infrastructure to empower creators to live-stream and to grow on Twitch/YouTube/Facebook. We built moonshot bets before, but our pace of innovation was ~1 bet/year. Building moonshot bets while nurturing an existing core business in the creator-economy space is hard. It’s really fucking hard. But the team willed it to existence. In 2020 the team shipped 9 moonshot bets, some of which are in production and growing today. And the team shipped those 9 new products with exact same headcount (!) and all while nurturing the core business, selling the company, and handling a # of issues along the way.
How?
Here are some of the main things that worked that I am comfortable sharing. There is nuance I am skipping to keep this short.
Form strike teams = small teams (2-5 people). Teams doing the work have complete autonomy over what to build, how to do it, and in what order. Optimize for autonomy, learning, and speed. Working team believes in building ABCD first, using a different design system, or not using the company ticket system. Sure!
Adding more people is not the answer. Team moving slowly or struggling to find product-market fit? Answer is rarely more people. Do pour on resources (ex. QA, growth) if team gets traction.
Strike team leads must have strong conviction in solving this problem and in the proposed solution. This conviction must border on obsession. New ideas are fragile and building something is hard. You don’t want the leads to run out of energy. Obsession will funnel into solutions. Joining a strike team for the wrong reasons (ex. this-seems hip-today or this-will-get-me-noticed or someone-asked-me-to-join) is setting yourself and team up for failure when you slowly quit.
Strike team resources are locked in. Dedicated resources to the seed project. Avoid shifting resources. Context switching kills speed and breaks flow. Goes without saying - get meetings down to near zero.
Core loop/MVP is key. Seeds should have a narrow scope. Define core loop->build->ship. Stick to that scope. Avoid feature creep for v1. Happy flow must be intact. Make the core loop unforgettable. Precognitive. “Just works” as an edge.
Establish heartbeats on strike team from inception, leading up to the go-live date (ex. vertical slice, strike team only bug bash, design review). These can be within the strike team and/or within entire company (ex. demo day, review with leadership). There should be a rough date to ship an internal and a public beta.
If it’s a company-wide review (ex. demo day) - main goal isn’t to ask for permission from CEO or to impress anyone. No dog and pony shows. The main goal is to over-communicate what we are building and why. Yes public accountability helps, but it’s also about sharing what the team learned, bringing rest of the company along and letting folks cheer for you and visa versa.
If stuck - ask for help. Do not wait for reviews. Share learnings about strike teams async → no meetings.
If you are building the innovation muscle for first time - okay to fund a bunch of projects just to do it. Build to learn. Build moonshots to build culture and to learn who is who on the team. After a cycle of bets once innovation is in the DNA and core business remains healthy, be much more deliberate about what projects you start or just 2x down on the strongest bets.
Reward teams for shipping. Cash bonuses for failure.
Ship for the user. Not for the press and not for the one-and-done splash. What does that mean? Build to learn and to get closer with customers. Find a way to get the product in the hands of the user, have them break it, and then improve. Do not build for press hoorah or large launch. Avoid this for v1 outright. Spend 100s of hours doing customer support and on calls with user. Spend 0 hours pitching press or thinking about how to trend when you go-live.
Be willing to pay money to ship a seed faster. Expensive off the shelf API/service that will save dev team time (ex. auth, handling payments, video infra)? Use it.
PMs should focus on getting first batch of users. No marketers. PMs should also do 100% of QA and customer support.
Play to people’s strengths. Some excel at building the core and some at 0-1 for seeds. Best way to figure that out is by going through this exercise and then you can lean into strengths.
Team-wide hackathon can be good to (1) spawn new ideas, (2) bond as team, (3) generate energy. You can give light constraints on what to build or let it rip.
Own things. Full stop. Want a new service to help your strike team go faster? All you, but you have to use it and if you don’t use it - wind it down and share the learning. Want to sunset the project? Loaded question on when it’s time to stop vs keep pushing, but if stopping - do not leave it on life-support. Make a decision, unwind gracefully, prioritize for max empathy towards users, and share learnings with team.
I’ve been parsing through my mistakes, thinking what I’d improve in the future. So while this stuff did work, I will figure out a way to do better.
I understand that "small-teams-work isn’t a hot take. And to me, this goes back to the notion of you experiencing it to rewire your brain.