For years I watched big companies spend millions on innovation labs. They hired design thinkers, bought whiteboards, and ran workshops. Most of those labs failed. Not because the ideas were bad, but because the methods never left the building. I worked in one of those labs in 2018. We had a $2 million budget and produced exactly zero products that made it to market. The experience taught me something useful: the tools themselves are powerful. The problem is how they get used. Small teams can take those same methods and get real results. No budget required. I now run a small product team of six people. We use techniques from corporate innovation labs every week. The difference is we skip the theater and go straight to the work. One resource that helped me rethink this process is theingenuity.org, which breaks down complex innovation methods into practical steps for smaller operations.
Start with the problem, not the solution
Corporate labs love brainstorming sessions. People throw sticky notes on walls and vote on ideas. This feels productive but rarely is. The real value comes from spending time on problem definition. In my experience, teams that spend 40% of their project time defining the problem finish faster than those that jump straight to solutions. We use a simple rule: write the problem as a question. «How might we reduce onboarding time by 50%?» is better than «We need a new onboarding tool.» The question creates focus. It also makes it easier to test whether you solved anything. Innovation labs call this the «problem statement» phase. You can do it in one afternoon with a whiteboard and a timer.
Use rapid prototyping with found materials
At the lab, we built elaborate prototypes. We hired developers and designers to create near-final versions. Each prototype cost thousands and took months. Small teams cannot afford that. But you do not need expensive prototypes to learn. I use paper, cardboard, and free software tools to mock up ideas in hours instead of months. One of my teams built a working checkout flow using linked Google Slides. We tested it with five customers on a Tuesday afternoon. The feedback changed our entire approach. That slide deck cost nothing. Corporate innovation labs would have spent $50,000 on the same test. The lesson is simple: prototype only what you need to test. Do not build the whole product. Build the one feature that answers your biggest question.
Run experiments, not projects
Innovation labs talk about «experiments» but often run them like projects. They set timelines, assign teams, and measure completion. An experiment should measure learning, not output. My team runs two-week experiments. Each experiment has one hypothesis, one measurable outcome, and one decision point. For example: «If we add a progress bar to the signup form, we think completion rates will increase by 15%. We will measure after 200 new users. If it works, we keep it. If not, we try something else.» This approach comes straight from corporate innovation methodology. The difference is we limit experiments to two people and two weeks. Anything that takes longer probably needs to be broken into smaller experiments first. We have abandoned 60% of our experiments after the first round. That is not failure. That is learning what does not work for $200 instead of $20,000.
Build cross-functional teams of two
Corporate innovation labs often assemble large teams. They pull in a designer, a developer, a product manager, a data analyst, and a business strategist. That is five people before anyone writes any code. Small teams should do the opposite. Pair one person who understands the user with one person who can build something. That is it. Two people can move faster than ten. They make fewer compromises. They communicate without meetings. In my current team, we rotate these pairs every month. One month the designer works with the backend developer on data visualization. Next month the same designer works with the frontend developer on the interface. This cross-pollination spreads knowledge without hiring more people. It also prevents any single person from becoming a bottleneck. When someone leaves the team, we do not lose all their knowledge because others have worked alongside them.
Measure progress against customers, not timelines
The cruelest metric in corporate innovation is the quarterly review. Teams present slide decks to executives who have never used the product. Approval comes from persuasion, not evidence. Small teams answer to a better judge: customers. We measure progress by how many customer problems we solve each week. Not by how many features we ship. Not by how many hours we worked. One concrete number we track is «customer problems resolved per week.» We set a target of three per week for the entire team of six. Some weeks we solve one. Some weeks we solve five. The number keeps us honest. If a feature does not help a customer solve a problem, it does not count. Corporate innovation labs would benefit from this approach. Many of them produce beautiful demos that nobody uses. A demo is not progress. A customer using your thing every day is progress.
- Limit brainstorming to 30 minutes and spend the rest of the time building something rough
- Test every assumption with the cheapest possible method before investing real resources
- Document what you learn, not just what you ship, to avoid repeating mistakes
- Share experiment results openly with the whole team so everyone benefits from failures
- Set a maximum of two weeks for any experiment before deciding to continue or kill it