Four risks

Your coding agent has mastered one of the four risks that decide whether a product works. The other three are the whole job, and none of them is in the code.

Title card reading 'Four Risks' in green type on a cream circle, framed by abstract organic shapes in muted green, orange, and tan

For most of the history of software, the hardest question in the room was "can we build it?" Feasibility ate the schedule, the budget, and the arguments. So it is easy to miss that feasibility was never the only question. It was one of four, and the other three are the ones that quietly decide whether a product works at all.

The framework is Marty Cagan's, from decades of product work at Silicon Valley Product Group, and it is worth knowing exactly, because it is a better map of building than most teams carry in their heads.

The four big risks

Every product idea faces four risks, and a serious team tries to kill all four before it commits a single engineer to delivery:

A detail worth keeping, because it is the whole point in miniature: Cagan's early work listed only three, valuable, usable, feasible. He added viability later, because leaving it implicit let teams build things customers loved that the business could not survive. The number of risks you can name is the resolution at which you can see failure coming.

Your agent has mastered exactly one of them

Here is the part that makes this the most useful framework to hold right now. A modern coding agent is, genuinely and impressively, a feasibility machine. The question that used to dominate every project, can this be built in the time we have, is falling away for a widening class of work. That is not a small thing. It is the hardest-won of the four, and it is being handed to us.

But feasibility is one of four, and to the other three the agent is mostly blind. Not because it is weak. Value and viability are simply not in the code, and neither is the part of usability that actually decides outcomes: an agent can build a technically usable interface, accessible and responsive, and still have no way to know whether the flow matches the mental model a real person shows up with, or the job they are trying to get done. What the other three risks turn on lives outside the repository: who the customer is, the alternative they will pick if you disappoint them, the contract your biggest account signed, the margin the business needs, the regulation in the next market. None of that is recoverable from the repository, at any model size, because it was never written there. So an agent left to itself builds the thing right and has no way to know whether it is the right thing. It answers the one question it can see, perfectly, and cannot even perceive the three that decide the outcome.

The bottleneck just moved

Follow that where it leads. When feasibility was scarce, it was the bottleneck, so it got the attention, the tooling, the best people. Now that feasibility is becoming abundant, the constraint moves to the other three, the way a constraint tends to move to whatever you have not automated. The scarce thing in 2026 is not the ability to build. It is knowing what is worth building and whether the business can carry it, and getting those answers to the thing doing the building.

That reframes what product intelligence even is. For twenty years it was a tax on velocity: discovery slowed you down before engineering could start. Now it is the opposite. The agent removed the wait. What is left is almost entirely value, usability, and viability, which means the product knowledge that used to live quietly in a few senior heads is no longer a supporting function. It is the input that determines whether all that cheap feasibility produces something real or just produces something.

Democratizing the part that was never written down

The good news is that this knowledge is not mystical. The four risks are teachable, and the answers to them for your product, the value your customers actually get, the jobs they hire you for, the viability constraints the business runs under, are knowable and writable. They just usually are not written. They sit in the head of the person who made the call, in a decision nobody recorded, in the reasoning behind a constraint that looks arbitrary until you know the account it protects.

This is exactly the gap Brief exists to close, and I will be plain about it rather than coy. Brief is a product navigator: the layer that holds your product's answers to value, usability, and viability, the decisions and context that a coding agent cannot infer, and hands them to the agent at the moment it builds, so it produces the right thing and not merely a working thing. For enterprises the case is sharpest, because their product intelligence is the most valuable and the most scattered, spread across dozens of teams, thousands of decisions, and years of hard-won constraints that no single engineer, and certainly no single agent, can hold in one head. Feasibility they can now buy. The other three risks are theirs to know, and the only question is whether that knowledge reaches the machine that is doing the building.

None of this asks the agent to do product discovery for you. The four risks still take human judgment; a model cannot decide what your business should value. What it can do, once feasibility is cheap, is act faithfully on the value, usability, and viability answers you already have, if you make them explicit and put them where the work happens.

So here is the question worth sitting with. Your team can increasingly build almost anything it decides to. Does the thing doing the building know the other three quarters of the job?

Frequently asked questions

What are the four big risks in product? Value, usability, feasibility, and business viability, a framework from Marty Cagan and the Silicon Valley Product Group. Value asks whether anyone will want or choose the product; usability asks whether they can figure out how to use it; feasibility asks whether it can be built with the available time and technology; viability asks whether it works for the business across sales, finance, legal, and support. Good product discovery tries to retire all four before engineering commits to building.

Why can't an AI coding agent assess product value? Because value is not present in the code. It depends on who the customer is, the job they are trying to accomplish, and the alternatives they would otherwise choose, none of which the agent can read from a repository, no matter how capable the model. The agent can judge feasibility, which lives in the code and the tooling, and it can build the mechanics of a usable interface; what it cannot judge is value, business viability, and whether the design actually fits the user, all of which depend on product context that has to be supplied.

If AI handles feasibility, what is left for product teams? Nearly everything that determines whether a product succeeds. As feasibility becomes cheap, the constraint moves to the other three risks, so the work shifts from "can we build it" to "do we know what is worth building and whether the business can carry it, and can we get those answers to the agent." Product intelligence stops being a tax on velocity and becomes the main input.

What is business viability risk? The risk that a product works for customers but not for your own company: it violates a regulation, undercuts your pricing, creates an unsustainable support burden, conflicts with sales incentives, or damages the brand. It is the risk teams most often forget, which is why Cagan made it explicit rather than folding it into value, and it is almost entirely invisible in the code.

GET TLDR FROM:
← Back to Blog