Are we using the wrong building block for start-up programs?

Picture a cooking show where contestants don’t get mystery boxes, new cuisines, or curve-ball challenges. Instead, everyone brings one dish from home on Day 1… and spends the entire series tweaking that same dish. 

No new techniques. No stretching. No real test of range. Would it be watchable? Maybe. Would it tell you who’s actually a great cook? Probably not.

A lot of early-stage startup programs run like that show. We ask people to arrive with an idea - the dish - and then we spend weeks trying to turn that dish into something palatable. Meanwhile, we learn very little about the founder’s underlying skills: how quickly they can ideate, how they approach problems, how they learn, how they lead, and how they make go/no-go calls before they blow the budget.

I help startups and scale-ups use product thinking to make fast, evidence-based decisions, and more recently I’ve been working with emerging founders in a number of fantastic incubator and accelerator programs. The more I do in this space, the more I’m convinced we’ve picked the wrong building block. 

Instead of structuring programs around ideas, we should be structuring them around founders and the skills that make them dangerous - in a good way.

The Problem With Idea-First

Programs that start by asking for the idea  can unintentionally anchor founders to a solution before the real learning begins. By the time someone applies to an accelerator or incubator, the wheels are already turning - sometimes the product is even live. From that moment, there are a number of factors that can mean the program is already fighting uphill. 

Here’s what often happens:

• Solution over problem. Founders arrive attached to “the thing” they’ve built (or want to build). Weeks get spent unpicking that attachment before we can do proper problem discovery.
• Late to validation. Even when “talk to customers before you build” lands, it’s hard to retrofit to something already in flight. Sunk cost clouds judgement and slows kill decisions.
• Shaky foundations. Some ideas are boxed in by early technical choices; more often, the commercial model can’t support a repeatable, scalable way to win and keep paying customers. You can swap toppings, but if the base is wrong, you’re still baking the wrong pizza.
• Misread signals. Polite nods and “you should build this” are cheap. The only signal that counts is repeat willingness to pay - and it’s the one that’s often least tested in idea-first cohorts.
• Low coachability, high friction. When a founder isn’t naturally coachable - or is deeply attached to their idea - the cohort can stall. What should be learning time turns into a stand-off or battle of wills, and progress flat-lines.

The result: we graduate “the best version of this idea” instead of “a founder who can repeatedly find, test, and commercialise good ideas.”

A Founder-First Alternative

I’ve been wondering what it would look like if more early-stage programs selected (or welcomed) people without a fixed idea - or at least required everyone to hold their idea lightly. Rather than a series of topics and mentors of the week, what if the learning arc focused on building the muscles that travel with the founder, not the features that ship with the MVP?

Here’s what I think that could look like in practice:

• Problem-finding before solutioneering. We train founders to spot valuable problems, segment real users vs buyers, and map the economics behind a market—not just the pain points.
• Rapid ideation sprints. We focus on generating multiple solution hypotheses per problem. Kill most of them on paper. Advance a few to low-cost tests. No code until the evidence earns it.
• Evidence over enthusiasm. We define success metrics and pre-commit to kill criteria before running tests. We celebrate invalidation as progress, not failure.
• Go/No-Go cadence. We bake in regular decision points with a simple rule: if evidence doesn’t clear the bar, you stop, learn, and try the next thing.
• Commercial model early. We focused on testing for repeatable willingness to pay, realistic channels, and plausible unit economics before obsessing over product polish.
• Funding literacy. We teach when bootstrapping, grants, revenue, or investment make sense - and when they don’t. We align funding paths to model, stage, and risk.
• Co-founder and talent matching. We match skills to gaps after you’ve clarified the problem space and constraints, not before.
• Portfolio mindset. We treat ideas like a portfolio of experiments, not a personality test. Your value is your process, not your pet project.

Why Accelerators and Investors Should Care

Programs optimised for high-growth, investable outcomes get an extra lift from founder-first:

• It removes the idea-quality ceiling. In idea-first admissions, your cohort’s upside is capped by whatever ideas happen to walk through the door. Founder-first widens the aperture: you’re selecting for behaviours (curiosity, speed, evidence-seeking) that produce multiple good ideas over time, not just one lucky pitch.
• It builds in talent identification. A founder-first track surfaces patterns: who learns fastest, who sells before they build, who navigates ambiguity well. That’s a better predictor of investability than early product demos.
• It fosters stronger co-founding teams. With structured skills mapping and matching, programs can assemble complementary teams after problem framing. That leads to better founder-market fit and fewer single-point-of-failure teams.
• A higher shot volume means cleaner signals. More validated experiments per cohort = more “shots on goal”. The evidence gathered (kill criteria, pricing signals, early channel learnings) de-risks follow-on capital and speeds the path to scalable growth.

How Programs Would Change

There are three simple shifts that I think would make a big difference:

1. Admissions: Application and interview processes could be optimised for curiosity, resilience, and evidence-seeking behaviour over pitch polish. Ideas are welcome, attachments optional. Add a light-touch skills inventory to inform team formation later.
2. Curriculum: We front-load problem discovery, customer conversations, and commercial tests. Build activities are gated by evidence. We include explicit talent & co-founder matching sprints once problem spaces are defined.
3. Milestones: We replace “demo day” theatrics with an “evidence day” narrative - what you tested, what you learned, and why you killed or advanced. Track individual learning velocity alongside venture progress.

A Quick Self-Check for Founders

If you’re reading this mid-build, you don’t have to torch everything. Try this:

• State your core assumption that must be true for this to work (e.g., “SMEs will pay X/month to automate X”).
• Design the cheapest test to get a yes/no on that assumption in the next 10 days.
• Write your kill criteria now. If the test doesn’t clear the bar, pause. Don’t add toppings to the wrong base.

Why This Matters

Ecosystems that reward shipping anything can accidentally train founders to conflate motion with progress. If we reframe success around learning velocity, commercial evidence, and talent formation, we help more people avoid expensive dead ends—and we produce founders (and teams) who can do this again and again.

That’s the cooking show I’d watch: not “make your lasagne slightly better each week”, but “show us how you master new techniques under pressure, plate something edible fast, and decide when to bin a dish and start over”. The winners of that show won’t just make one great plate; they’ll build great kitchens.