The design process. Love it, hate it — you have an hour to spare for listening to me talk about it. Or 45 minutes, depending on the speed you play your podcasts on. I don’t judge (out loud).
This episode of Design Overtime is not a prerequisite to today’s issue of the Picnic, but it does touch on an important theme that I want to expand on today.
Velocity has always been a commodity
It’s almost a cliche that the only thing executives want from product managers is faster feature delivery. So it’s refreshing to see a C-suite executive ask:
❝
For years, everyone was obsessed with delivery speed. How do we run Scrum better. How do we write tighter user stories. How do we ship more tickets per sprint. Almost nobody was asking the question that mattered: is any of this actually useful to a customer?
Crucially, Michalik recognizes that we were making progress on fixing this, up until AI showed up. Suddenly, teams had an excuse to avoid doing anything that was hard. Design teams were told “we don’t need information architecture because AI can do it.” And product teams were told, “we don’t need to fix out process anymore because we can just ship really fast now.”
And this felt like a huge step forward. Because those teams were struggling with process at the most fundamental level. Forget “outputs vs outcomes” — many teams were struggling to stitch together their various deliverables into a single output that might actually reach prod. What a breath of fresh air to jump straight to “everyone writes code.” How liberating to ask Claude for changes and see them render live.
Just one small problem with that: code was never actually the goal.
These teams had set outputs as their goal for so long that they forgot what the outputs were for in the first place. The only step they could imagine after “ship the thing” was “go back to the backlog and ship another thing.” And this lack of imagination is because they never resolved the central problem that the process definition was meant to fix: the definition of the intent behind the work.
❝
Code is an encoding of intent. As with any kind of instruction, brevity is power.
The team never had a problem with pushing code to prod. No teams truly do. Software engineering orgs hire programmers for their ability to push code to prod. What was missing is the intent. What AI let people do was skip intent formation — a prerequisite when working with one or more colleagues — and have every person strike out as their own designer, coder, and PM. The forcing function of convincingly explaining why we are doing the thing was something we got “for free” with a real product development lifecycle. Now everyone can make ten thousand bowls of oatmeal.
“Skipping process” is a corruption of intent at the system level
As a side effect of the “you can just do things” antiprocess, all the thinking that used to lead to strategy is obsolete. What’s the point of a startegy doc when your developers are shipping one feature every hour based on a cool idea they had during lunch?
And what do we do with pointless work? We delegate it to AI. Now, a synthetic strategy doc is feeding into a synthetic PRD into synthetic user research findings into synthetic design into synthetic code into synthetic deployment. At the pace of AI, no “human in the loop” can afford to take the time to read any of this without being branded as a blocker.
The trouble is that by the end of that workflow (even if the original idea originated from some kind of real need — which is not at all guaranteed) the intent behind the work has been hopelessly corrupted:
❝
Even frontier models corrupt an average of 25% of document content by the end of long workflows, with other models failing more severely…. degradation severity is exacerbated by document size, length of interaction, or presence of distractor files.
It sure would be a shame if we had “democratized” this work and every person in the company had generated pages and pages of contradictory research and strategy docs. That would exacerbate the degradation severity, so it’s definitely something orgs are working hard to prevent.
❝
We try to take on a whole system ourselves. It feels heroic, and movies and myths make it seem realistic, but when you work against a system, it’s like swimming upstream in a powerful river. … The place you work for is unlikely to be worthy of this kind of sacrifice.
Scott gives a lot of good advice in that article for how to make the system work for you instead. But with the industry increasingly undermining its systems for the sake of intentless velocity, don’t be surprised if you have to start rebuilding that system yourself.
— Pavel at the Product Picnic