The part that doesn’t get cheaper

A question on a ticket#

A question came back on a ticket I was reviewing: “if this is unchecked, how does the user select the source?”

The team building the feature could have answered it themselves. The feature does nothing without a source, so the answer was to make the source required.

As AI makes building cheaper, questions like that one are most of what stays expensive.

What gets cheaper#

AI coding agents write code well, and they build well against a clear spec. Where the spec leaves something open, they need judgment they don’t have: knowledge of the domain, of the customer and of why the product exists.

So as building gets cheaper, the work that keeps its value is settling those open questions. That takes the product’s intent, its existing patterns and real knowledge of the people using it.

Where a decision gets handed back#

Every open question has to land with somebody. When a builder sends it back as a plain question, the person who set the intent has to stop and rebuild the context before deciding. Then they wait for the next question.

Each round trip costs days, and that person’s calendar becomes the limit on how fast the team can move. The same thing happens when a product hands a decision to its users as a new setting.

Send a proposal with every question#

A proposal keeps the next decision with the builder, so the person who set the intent only has to confirm it or redirect it.

• Instead of asking “what should the default be?”, say “we’re defaulting to the most common case, which the data says covers most accounts. Confirm?”
• Instead of asking “which pages does this apply to?”, say “we’re applying it everywhere the same pattern already appears, unless you tell us otherwise.”
• Instead of asking “what happens if this is left blank?”, say “we’re making it required, because the feature can’t work without it. Confirm?”
• Instead of sending five questions, say “we settled four of these from the existing pattern, and this one needs your call.”

Especially the defaults#

Most people never change a default, which makes it the decision that most shapes what they experience. So the default is the first decision a builder should arrive with a proposal for.

What it changes in the work#

The change starts with what a leader asks for.

• Ask builders, people and agents alike, to send each open question with the answer they would pick and why
• Hand over the intent, the existing patterns and real examples at the start, so builders have what they need to propose
• Count the questions that arrive without a proposal, and read a rising count as a sign the context didn’t reach the builders

Back to the ticket#

With a proposal attached, that question comes back as one line: “we’re making the source required, because the feature can’t work without it. Confirm?” One word back, and the team keeps moving.

Sources

• Marty Cagan, Empowered Product Teams
• Fred Brooks, No Silver Bullet (1986)
• Joel Spolsky, Choices (2000)
• The Linear Method
• Nielsen, The Power of Defaults