Personal · · 4 min read
Feasibility First: The Four Pillars of Real Assessment
Confidence is a mood. A feasibility assessment is evidence. Here's how to structure one that actually changes decisions.
Most teams skip the feasibility check because they feel sure. Feeling sure is cheap, though. Proof costs something, and that's the whole point of it.
Here's what skipping it looks like. A studio picks a bet and everyone's excited, so a team gets assigned, and a few weeks in somebody quietly discovers the data doesn't exist in the form anyone assumed. Or the system you need to plug into has no usable API. Or the model can't hit the accuracy the pitch depended on. By then you've burned runway, and worse, you've got people emotionally invested in a thing that was never going to work. Killing it now costs twice what killing it early would have.
I've seen this movie enough times to be properly sceptical of confidence. Confidence is a mood. A feasibility assessment is evidence.
So what does a real one look like? I mean one that actually changes decisions, not a slide deck that says "low risk" in green. It rests on four pillars, and I'll go through them in order because they build on each other.
Technical constraints come first. Not "can this be built in theory" (almost everything can) but "can it be built to the standard the business case needs, inside the limits we actually have?" Latency, accuracy thresholds, cost per run, hardware limits if you're anywhere near the physical world. You want a rough prototype or a spike that pushes on the hardest part, not the easy parts. Test the scary bit first. If the scary bit fails, nothing else matters, and you've saved yourself the pleasant weeks of building around it.
Data availability is where I see the most optimism and the least checking. Founders say "we'll have the data" the way people say "I'll start on Monday". Who owns it? Is it clean, or is it forty spreadsheets and a person's memory? Can you legally use it for this purpose? Is there enough of it, covering the awkward edge cases and not just the happy path? Actually open the files. Look at them. Anyway, you'd be amazed how often the answer changes once somebody does.
Integration risk is the quiet killer. The product might be brilliant on its own and still die because it has to talk to a legacy system nobody wants to touch, or a vendor who changes terms, or an auth setup that takes a quarter to get approved. Map every system the thing depends on. For each one, ask whether you've got access today, not whether you'll probably get it. Probably is a word that eats budgets.
Team capability fit is the one people find awkward to say out loud. Does the team you've got, or can realistically get, have the skills this specific build needs? Not skills in general. These ones. A strong web team isn't automatically a strong team for a retrieval pipeline, and a brilliant ML person isn't necessarily who you want wiring up production monitoring. Be honest about the gap and price it in, whether that's hiring, borrowing or narrowing the scope.
Now, who should run all this?
Internal is faster, cheaper and carries context. The trouble is that the people closest to the idea are the least able to doubt it. They've got a stake. I include myself here, because I've talked myself into bets I should have killed. If the assessor's career benefits from a yes, you'll mostly get yes.
External brings distance and no ego in the game, plus pattern recognition from having watched similar bets fail elsewhere. It costs more and takes some ramp-up time, but you're buying scepticism, which is hard to manufacture from inside.
My view is a hybrid. Let the internal team gather the facts, since they know where everything lives, then have someone with no stake challenge the conclusions. The challenger's job isn't to be nice. Their job is to try to break the case before reality does it for you at a much higher price.
This matters more in a studio than almost anywhere. A studio runs on a portfolio, and every dud that limps along eats runway that a better bet could have used. The model only works if you're ruthless about what gets through the gate. A feasibility step isn't bureaucracy; it's how you keep your capital pointed at things that might actually work.
Which brings me to the scorecard. Keep it to one page, because anything longer won't get read. Score each of the four pillars, and for each one write three things: the evidence you've got, the evidence you're missing, and the single biggest unknown. Rate confidence on a simple scale you define yourself, and set a hard threshold in advance for what counts as a pass. Deciding the threshold before you see the results matters, otherwise you'll bend it to fit the answer you already wanted.
Add a fifth line at the bottom: what would make us stop? Name the kill condition in plain words. If nobody can say what failure looks like, you haven't assessed anything; you've just agreed with yourselves.
Then make the call. Go, fix, or stop. All three are good outcomes, honestly, and stopping is the cheapest one.
Right, so, proof first. Confidence can come along afterwards, once it's earned it.
Filed under Personal