Design Outcomes Weekly reflections on the real-time work of supporting a design org.
Building Is Not the Constraint

Building Is Not the Constraint

Why this matters

When anyone can prototype 10 ideas in an afternoon, the cost of building stops doing the choosing for you. Someone has to.

Building Is Not the Constraint A senior leader's case that building is cheap now and picking is the hard part, the 2 gut-checks I'm handing my leads, and why customer absorption is the new limiter. When anyone can prototype 10 ideas in an afternoon, the cost of building stops doing the choosing for you. Someone has to. Building is no longer the constraint; picking is. Gut-check every idea twice: is it a moat a customer could never build alone, and what would they have to stop doing to absorb it?

A senior leader's case that building is cheap now and picking is the hard part, the 2 gut-checks I'm handing my leads, and why customer absorption is the new limiter.

A senior leader called out something this week while we were planning a gathering for our product and design org. The agenda we reviewed leaned hard on building: demos of prototypes, sessions on agents, the tooling that has let designers and PMs ship fixes end to end this year. His question was whether there was enough in there about what AI means for those roles beyond the building piece. His theory, which he was careful to call a theory, went like this. Building is going to get very cheap and very accessible to a lot of people, so building is not a constraint, and having more builders is not, by itself, what an organization needs. The hard part is picking the right idea to build, because even if you can build 10 ideas at once, you’re going to get throttled by what your customers can absorb.

I’ve spent most of this year making the case that designers and PMs should build, and I still believe it (Issues 20 and 21 are largely that argument), so my first instinct was to defend the agenda. What I said instead was an attempt to restate his point in our language. Each of our disciplines has a swim lane: design owns discovery and the shape of the thing, product owns the problem and the sequencing, engineering owns making it work at scale. AI has made every one of those lanes faster, and there’s a slice underneath all of them where people are learning to build end to end regardless of which lane they sit in. The builder work lives in that slice. His push was to spend the room’s time on the top part, on how AI changes the curve on choosing. He agreed, and then added that he wasn’t sure the swim lanes stay swim lanes for long, which is probably right, and which is a different write-up.

You can build 10 ideas at once now. Your customers can still only absorb a few of them.

The absorption point is the one I keep testing against our own work. Clinicians run their practices on routines, and every change we ship costs them a little of the attention they’d rather spend on clients. That was true before agents. What’s new is that the supply of shippable things has stopped being the limiter. When building was expensive, the cost of building did the choosing for us, and a lot of bad ideas died in the estimate. Now they don’t die there. They get prototyped in an afternoon, they look finished, and somebody has to say no to them on purpose.

So what does choosing look like as a discipline? I’ve been handing my leads 2 gut-checks. The first came out of an executive note on strategy that I translated for one of my design managers this week. The trend line right now says SaaS is dead and every customer will build their own software, which is the same story we heard about design last year and is equally not true, but the useful part of it is a question. Is this a moat? Is it something a clinician could never build for themselves, like the network, the referrals, the patterns that only exist because thousands of practices share one platform? If it is, make it better. If it isn’t, don’t work on it. The second gut-check is absorption. If we shipped this next month, what would a practice have to stop doing to notice it? If the answer is “nothing, it just shows up where they already are,” that’s a springboard and it’s probably fine. If the answer is “relearn a screen they use 40 times a day,” it’s competing with everything else we’re asking of them that quarter, and it has to win that competition on purpose.

Worth calling out that the non-building uses of AI in our org are already the less visible wins: a competitive analysis tool designers use weekly, a PRD drafting flow, an agent wired to our design files that does lightweight ideation against our actual component library. One of my design directors mapped the fringes, the stages before and after building where prototype, share, and scope happen, and most of the leverage on his map sat in scoping, not in the build.

If you’re a leader whose org just learned to build, I’d put a session on choosing next to every session on building. The builders will be fine, and the people who need help are the ones who have to look at 20 working prototypes and pick 3, and that skill was always ours.

Filed under TR The Reframe — Assumptions, examined.