The collapse of the product process

I need to tell you about a whiteboard.

It was 2017, maybe 2018. I was working with a social media music startup and we were deep in the product process. Proper deep. We had a wall - a full wall - covered in sticky notes. Colour coded. Grouped by theme. Connected with bits of string like we were solving a crime. User journeys mapped end to end. Personas printed and pinned. Competitor analysis spread across three whiteboards. We’d been at it for weeks.

And it felt productive. It felt like rigour. Like we were doing the work. Being thorough. Following the process.

Then we moved into design. More weeks. Wireframes, user flows, component libraries, pixel-perfect mockups. Reviews with stakeholders. Revisions. More reviews. More revisions. By the time we handed anything to development, months had passed. Actual months. And then the build itself took more months on top.

The product we shipped was fine. Decent, even. But by the time real users got their hands on it, the market had shifted, our assumptions were stale, and half the features we’d agonised over turned out to be things nobody cared about. We’d followed the process perfectly and the process had failed us.

I think about that whiteboard a lot these days. Because everything about how we built that product - the sequence, the timelines, the way each phase handed off to the next like a relay race - has been completely and irreversibly blown apart.

The old sequence

For anyone who hasn’t worked in product, here’s how it used to go. And by “used to” I mean roughly the last fifteen to twenty years of mainstream product development.

You’d start with research. User interviews, surveys, market analysis, competitor audits. Weeks of it. The goal was to understand the problem space so thoroughly that you could make confident decisions about what to build.

Then you’d move into definition. Taking all that research and distilling it into requirements, user stories, job-to-be-done frameworks, whatever methodology your team subscribed to. More weeks.

Then design. Wireframes first, low fidelity, sketchy. Then mid-fidelity. Then high-fidelity mockups. Then prototypes - clickable but non-functional. You’d test these with users if you were disciplined about it, though plenty of teams skipped that step because it was expensive and time-consuming. More weeks, sometimes months.

Then, finally, at the very end of this pipeline, development. Engineers would take the designs, ask a hundred questions about edge cases nobody had thought about, and start building. Months.

The whole thing, end to end, could take six months to a year for anything meaningful. And the cruel irony was that the most important learning - what happens when real people actually use the thing - was locked behind all of that upfront work. You couldn’t test with real users until you had something real to test. And you couldn’t have something real until you’d been through the entire process.

So you’d make your best guesses, invest enormous amounts of time and money, and then find out if you were right.

Sometimes you were. Often you weren’t. And when you weren’t, you’d loop back and do big chunks of it again.

Why it worked (until it didn’t)

I want to be fair to the old process because it wasn’t stupid. It existed for a reason.

When building was genuinely expensive - when every screen took days of engineering time, when changing a user flow meant weeks of rework, when a pivot meant blowing up months of code - you needed to be as certain as possible before you committed. All that upfront research and design was risk mitigation. You were spending time to save money, because the cost of building the wrong thing was catastrophic.

The double diamond, the design sprint, the lean UX framework - they were all attempts to front-load learning and reduce waste. And they did work, within the constraints of the era. If building is slow, thinking first is smart.

But here’s the thing. Building isn’t slow anymore.

The new reality

I can spin up a functional prototype in hours now. Not a clickable mockup. Not a Figma flow with hotspots. A working thing. With real data. Real interactions. Screens that actually do things.

This isn’t a marginal improvement. This is a category change in how products get made. And it doesn’t just make the old process faster - it makes the old sequence wrong.

Think about what that means. The entire reason we did weeks of research and design before building was that building was the bottleneck. It was the expensive, slow, irreversible part. So we wrapped it in layers of upfront thinking to protect ourselves.

But if building a prototype is nearly free - if I can go from idea to testable thing in an afternoon - then the calculus completely inverts. Why would I spend three weeks researching and designing in the abstract when I could build the thing in a day and put it in front of actual users tomorrow?

This is what I mean by the collapse of the product process. The phases haven’t just gotten faster. They’ve collapsed into each other. Research, design, prototyping, and testing aren’t sequential steps anymore. They’re happening simultaneously, feeding into each other in tight loops that would have been physically impossible two years ago.

Testing before designing

This is the bit that gets me genuinely excited, and it’s the part I think most people in the product world haven’t fully grasped yet.

For my entire career, usability testing has sat towards the end of the process. You design something, build a prototype, and then test it. The testing validates (or invalidates) your design decisions. It’s useful but it’s reactive. You’re checking your homework after you’ve already done it.

Now? I can test before I design.

Let me explain what I mean. At Reboxed, when we’re exploring a new feature or workflow, I don’t start with wireframes anymore. I start by building three or four rough functional prototypes that each take a completely different approach to the problem. Not designed. Not polished. Sometimes genuinely ugly. But working.

Then I put all of them in front of real users and watch what happens. Which one do they gravitate towards? Where do they get stuck? What do they try to do that none of the prototypes support? What assumptions did I bake in that turned out to be wrong?

That learning used to come after months of work. Now it comes on day one. And it means the design phase - when I do get to it - is informed by observed behaviour rather than assumptions. I’m not guessing what users want and then checking if I guessed right. I’m watching what they actually do and then designing around that reality.

This is a fundamental inversion of the product process. Testing used to validate design. Now testing informs design. The arrow has flipped.

What this means for designers

I know some designers who find this threatening. If you can prototype without designing first, what’s the point of designers?

I think that’s exactly the wrong way to look at it. This is the most exciting time to be a designer in the last twenty years, and I’m not being hyperbolic.

Here’s why. The old process turned designers into guessers. Educated guessers, sure. Guessers with frameworks and methodologies and years of pattern recognition. But guessers nonetheless. You’d do your research, form your hypotheses, create your designs, and hope you were right. The feedback loop between your design decisions and actual user behaviour was so long that you were essentially working in the dark for months at a time.

Now the lights are on. You can see what’s working and what isn’t almost immediately. You can iterate in real time based on real data. You can explore ten approaches where you used to explore two. The craft of design hasn’t become less important - it’s become more focused. Less time speculating, more time refining based on evidence.

The designers who’ll thrive in this era are the ones who let go of the old sequence and embrace the mess. The ones who are comfortable putting rough, unpolished, sometimes embarrassing prototypes in front of users and learning from the reaction. The ones who see testing as the starting point, not the finishing line.

The designers who’ll struggle are the ones who cling to the process. Who insist on doing three weeks of wireframes before anything gets built. Who treat the handoff to development as the finish line. That version of the job is evaporating, and honestly, it should. It was always a compromise forced on us by the speed of building. The compromise is no longer necessary.

The new shape of product work

So what does the process actually look like now? If the old model was a relay race - research, design, build, test, each handing off to the next - the new model is more like a jam session. Everything happening at once, feeding off each other, with the team moving fluidly between modes.

At Reboxed, a typical feature development cycle now looks something like this. Day one, I build two or three rough prototypes exploring different approaches. Day two, we test them with real users or our ops team. Day three, I take the best elements from what worked and start properly designing and building the real version. By the end of the week we’ve got something in production that’s informed by actual user behaviour, not a three-month-old research deck.

That’s not cutting corners. That’s a better process. More learning, faster feedback, less waste, better outcomes. The old process felt rigorous but it was actually wasteful. All those weeks of upfront speculation were expensive insurance against the cost of building. When the cost of building drops, the insurance becomes unnecessary overhead.

I still do research. I still think deeply about user needs. I still design with care and intention. But I do it in a different order and at a different pace. The thinking and the making are interleaved rather than sequential. And the testing - the moment of truth when your ideas meet reality - happens at the very beginning instead of the very end.

The sticky notes stay on the wall

One more thought about that whiteboard from 2018.

I don’t regret those weeks of sticky notes. They taught me how to think about products systematically. How to break problems down, map user journeys, identify assumptions, and structure my thinking. Those skills are more valuable now than ever - they’re just applied differently.

The sticky notes aren’t gone from my process. They just don’t live on a wall for three weeks anymore. They live in my head for thirty minutes while I’m spinning up a prototype. The thinking is compressed, not eliminated. And it’s validated in hours instead of months.

That’s the real shift. Not that we’ve stopped thinking. That we’ve collapsed the distance between thinking and knowing. Between hypothesis and evidence. Between “I think this will work” and “I can see that it works.”

For designers, for product people, for anyone who builds things that other people use - this is the golden era. We’ve spent decades working in the dark, making our best guesses, and waiting months to find out if we were right.

The lights are on now. And I, for one, am not going back to the whiteboard.