Feasibility Risk

Everything that needed checking before building used to get lumped together as risk. That makes the checking method impossible to choose, because not knowing whether people will use something and not knowing whether you can build it are answered by completely different means.

So pre-build risk got split four ways, and the question of whether it can be built was pulled out as this one. The moment it gets abandoned is familiar: someone asks in a meeting whether this is possible, engineering says they'll find out when they try, and the topic moves on. Left there, it usually surfaces in the final week — a fact that could have been known in week one arrives after four months.

This risk differs from the other three in that the person who knows the answer is already on the team. Asking customers gets you nowhere; you ask the people who would build it. Judging it takes three steps.

1. Narrow the uncertainty to one sentence. "Payments will probably be hard" can't be checked. "We don't know what form the payment provider reports a failed recurring charge in" can.
2. Size it. Is the technology new to the team, is a value like response time or accuracy involved that can only be learned by trying, is it a problem that appears only at our data volume? Two of those three means treating it as large. All three share the trait of being something nobody here has done before.
3. Check it the cheapest way available. Some answers come from a day of reading documentation; others need two weeks and a proof of concept (PoC) that actually runs.

Items carrying a lot of this risk go early in the plan. Pushed late, everything built beforehand is resting on the answer, so a no means throwing away much more than the two weeks a check would have cost.

"Feasibility risk is high here. Let's check it before committing to a date."

Establish whether it can be built, and only then make promises about dates.

"Value risk is low, but feasibility is the open question."

Demand is clear; the technology is the unknown.

"That's not feasibility, that's viability."

The question isn't whether it can be built but whether the company can carry it.

When Pagedeck looked at searching document contents by meaning, this judgment came first. That customers wanted it had already been settled on the value risk side, and the screen was simple enough that usability risk was low. What remained was whether results came back within a second across 100,000 documents, and the quarter's plan was only finalized after Theo spent two weeks checking that one thing.