The whole thing clicked for me around one idea: our process was a response to cost. Building used to be slow and expensive, so we put gates in front of it. Workshops, problem statements, alignment rituals. All of that was insurance against an expensive mistake.
The frameworks I was taught (double diamond, problem-first discovery) aren’t neutral best practices. They encode an assumption about how much a wrong move costs. When AI makes a prototype an afternoon’s work, that assumption quietly becomes false, and everything built on top of it wobbles.
The reframe I want to keep: fall in love with learning, not being right. “Fall in love with the problem” made sense when testing a solution was costly, you couldn’t afford to guess. Now guessing and checking is cheap. Clinging to the problem-definition phase can mean delaying the thing that teaches you most: actually building it. Learning by building beats learning by planning when building is nearly free.
The line that stung: teams aren’t ignoring design out of malice or ignorance. They route around it because the process moves slower than they can build, and from their seat that’s the rational call. “Good enough shipped today beats perfect shipped later” is genuinely true a lot of the time. I can’t argue against velocity by appealing to process purity.
But the article is honest about what the workarounds cost, and this is where I think my value actually lives:
- consistency across features (otherwise the product feels like five products)
- solving the root problem, not the symptom someone happened to name the gap between “works” and “resonates”
- conceptual scale: does each new feature make the whole thing easier or harder to understand?
None of those show up in a single shipped flow. They show up across the product, over time. That’s the argument for design that velocity can’t make on its own.
The trap I want to avoid in my own work: process becoming the product. Judging myself on whether I ran the workshop, made the artefact, followed the diamond, rather than on the outcome. That’s how you end up busy and sidelined at the same time: lots of output, no influence on direction.
Bottom line for me: the skills (taste, synthesis, systems thinking, empathy) aren’t the problem and aren’t going away. The delivery mechanism is the problem. My job now is to figure out how to inject those skills into a fast build-test loop instead of in front of it.