the process artifact trap

walk into most enterprise product orgs on any tuesday and you’ll see the same thing. a designer deep in a figjam file building a journey map. another on a whiteboard session sorting sticky notes into themes. a third writing personas for user types the engineering team will never read. a fourth running a workshop to synthesize research from six months ago.

by the end of the week, the team has produced an enormous volume of work. personas. journey maps. affinity diagrams. jobs-to-be-done statements. empathy maps. service blueprints. research debrief decks.

the user sees none of it.

the user sees one screen. maybe two. maybe a half-finished onboarding flow the designer delivered after the research phase finally ended.

we call this the process artifact trap. jenny wen, who leads design for claude at anthropic, made the underlying case on lenny’s podcast¹: “this design process that designers have been taught, we sort of treat it as gospel. that’s basically dead.”

she’s right. and it’s not an anti-process position. it’s an anti-worship position.

process was supposed to be a tool. a set of practices that help teams avoid dumb mistakes and build shared understanding. somewhere along the way it became a religion. religion doesn’t ship products. it produces rituals.

the particular religion that ate design was the double diamond. discover, define, develop, deliver. four phases. each with its own prescribed artifacts. each with its own workshops. each with its own tools to purchase and methodologies to certify in.

none of it is bad in isolation. stakeholder interviews are valuable. journey maps reveal things. personas have their place. the problem was accumulation. ritualization. the sense that if you didn’t produce the full set of artifacts in the correct order, you weren’t doing real design.

meanwhile, the world changed. a product manager with claude open can build a working prototype in the time it takes a designer to write a problem statement. that’s not hypothetical. that’s happening inside every product org we know.

the fastest builders we’ve worked with aren’t anti-research. they just don’t perform research. they have a library of accumulated experience from watching real users use real products for years, and they use that expertise to make judgment calls quickly. when they genuinely don’t know something, they go find out. usually by building a prototype and putting it in front of five people.

call it reasoned judgment made quickly. intuition isn’t guessing. it’s expertise moving at the speed of thought, built on years of watching real users interact with real products.

you still need structure. teams need alignment. decisions need documentation. stakeholders need context. none of that goes away.

but when the structure takes longer than the answer, the structure is the problem.

the best teams we’re seeing in 2026 have a simple rule: if a prototype can answer the question faster than a workshop, build the prototype. process should serve the outcome. not the other way around.

the ritual doesn’t ship. the outcome does.