how teams work
the process artifact trap
design teams spend a week producing artifacts the user never sees, then ship one screen. process was meant to help teams avoid dumb mistakes, and somewhere it became something to stay faithful to.
in enterprise product orgs we work with, tuesday often looks like this: 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 6 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 podcast1: "this design process that designers have been taught, we sort of treat it as gospel. that's basically dead."
she is right. that is an anti-worship position, and it still leaves room for process that earns its keep.
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 produces rituals. it does not ship products.
the particular religion that ate design was the double diamond. discover, define, develop, deliver. 4 phases, each with its own prescribed artifacts, workshops, tools to purchase, and methodologies to certify in.
none of it is bad in isolation. stakeholder interviews are valuable, journey maps reveal things, and personas have their place. the problem was accumulation and 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 is happening inside every product org we know.
the fastest builders we've worked with are not anti-research. they just don't perform research as theater. 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 5 people.
call it reasoned judgment made quickly. intuition here is expertise moving at the speed of thought, built on years of watching real users interact with real products.
you still need structure, team alignment, decision documentation, and stakeholder context. none of that goes away. 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.
the ritual does not ship the product. the outcome does, and that is the only score that counts for the user.