Where the Habit Started
At ZURB, the product design consultancy where I spent a good few years, the whole place ran on one line: how do you build better products faster? Simple enough question. Living inside it every day, though, is where I got comfortable putting one word ahead of everything else: reimagine. Before you go researching anything, work out what you’re actually trying to achieve first.
That habit followed me straight into First Data, where I landed right after ZURB. One of the mandates for the new R&D centre I joined was to build a genuinely new fraud-detection capability, a clean-sheet build rather than another layer on an existing system. It wasn’t the only mandate on the table, but it’s the one that matters here. I walked into an organisation that already wanted to change how it worked, and the framing I’d carried over from ZURB is what shaped that particular conversation. It was where “build better products faster” started turning into something wider in my head: how do you build better outcomes faster?
Why R&D Never Quite Fit
That widening is the whole reason “R&D” never sat right with me as a name for it. Research and Develop only covers two stages in the middle, not the whole of the work flow. For me, the fuller picture runs Reimagine, Research, Innovate/Iterate, Develop, Deploy, and it’s the two bookends that make the middle mean anything. Reimagine makes you define the outcome before you go chasing it. Deploy is the reminder that none of this counts for much until it ships with commercial intent, not just gets built.
This whole process sits inside a broader philosophy I believe in, in general. In Marty Cagan’s work at SVPG on product teams versus feature teams, leadership sets the outcome, and an empowered product team works out the output that gets there, rather than being handed a feature list to build. It only works with people who are genuinely comfortable owning an outcome instead of waiting to be handed a spec, and it only works if leadership actually trusts those people with that kind of ownership. That creates its own tension, worthy of a blog of its own another time.
In between, Research throws up a handful of candidate directions, and Innovate/Iterate is where you hunt for the best outcome inside a time-box, rather than just executing a spec someone wrote months earlier. James Clear’s Atomic Habits is one influence on that middle stretch: break a big, ambiguous process into smaller parts and people move with an actual sense of progress instead of staring down the whole mountain. This is the first of a few pieces I plan to write on this framework, stage by stage; today’s just the introduction.
The Bottleneck We Built Around
For most of my career, actually building and shipping something, the Develop and Deploy end of that spectrum, was the expensive, slow part: months of engineering time and real budget just to find out whether an idea even worked. At VeriSign, a “New Initiatives Group” got stood up as its own skunkworks, purely because the standard legacy and operational development cycle couldn’t move fast enough. Not from a lack of will, just the sheer volume of maintenance work already clogging the pipe.
At PayPal, the shape was different but the cause came from the same family: QA cycles had stretched long, not from process for its own sake, but because earlier ideas hadn’t been architected onto a solid foundation, and the technical debt caught up later. Both of these are old stories now, and I’m not claiming today’s organisations look identical. The pattern still recurs though: plenty of good ideas existed, they just couldn’t get through the pipe.
That expected lag between an idea and a shipped product sits in everyone’s head, and it pushes people to rush the earlier stages to compensate. It’s not that MRDs, BRDs and PRDs went away either, they’re still very much alive, especially inside large multinationals. The tension was never whether the documents got written. It’s what they were quietly optimising for: what can get through the pipe, rather than what’s actually the highest-value work to do.
Then came the “move fast and break things” years, and CI/CD made the shipping itself quick: many small commits an hour instead of one big release. That solved the speed problem. It never solved the actual one. Slow pipe or fast pipe, in either world we still weren’t spending enough time in discovery, working out if we were building the right thing in the first place.
What AI Actually Changes
None of the five stages disappear, but AI is moving fast through the back half of this, specifically the function of coding, the actual execution. That’s not a knock on engineers, if anything the judgement side of the craft matters more now.
It does expose how we actually trained people, though: the industry treated rote coding as the on-ramp, write it, repeat it, build the muscle memory, and picked up real judgement and architecture later, once you’d put in the years. That on-ramp is closing fast, and anyone who was promised a career on the strength of it has every right to be frustrated. The harder truth sits one level up: we taught the execution and left discovery and judgement, the skills that were never going away, to sort themselves out later. That’s the gap worth being honest about, more than the coding itself.
Meta’s internal usage dashboard is a useful, uncomfortable illustration of what happens when that shift goes unmanaged. Reported by The Information and analysed in detail by The Pragmatic Engineer, Meta tracked AI token usage across roughly 85,000 employees, complete with gamified titles like “Session Immortal.” Employees burned through 60.2 trillion tokens in a month; priced at standard API rates that works out at roughly $900 million, and likely still $100 million or more even after whatever discount Meta actually negotiates. Meta pulled the leaderboard once the backlash hit.
A study from Jellyfish, across 12,000 developers and 200 companies, backs up why that backlash made sense: heavy AI usage does increase output, but nowhere near proportionally. The top-20% of users spent over $600 a month for 23 merged pull requests, against roughly a dollar a month for 11 at the bottom. Goodhart’s Law, as the anthropologist Marilyn Strathern states, “when a measure becomes a target, it ceases to be a good measure,” is the whole story summed up in one line.
Reimagine and Research aren’t fully immune from this either, AI can do a fair chunk of the research legwork now too. What doesn’t get commoditised, anywhere on that spectrum, is understanding what’s genuinely being asked and having the judgement to know what “good” actually looks like. If anything, that bar should go up once the busywork excuse disappears. What this really points to is spending more time in a discovery mindset than a delivery one, at every stage, not just the first. Most people have never properly trained that muscle.
I got lucky in a way: having dyslexia meant I could never compete in rote-memory-type tasks, and for a long time I didn’t know why. It pushed me into figuring things out from first principles instead, long before I had a name for it. These days it mostly shows up when I’m walking a founder or a mentee through their own challenges and frustrations, and something clicks for them. That’s the only proof I’ve got so far, and it’s enough to make me think the question’s worth asking more often than it gets asked.
So, How Are You Building?
I don’t have this fully worked out, and I don’t think anyone does yet. How are you building your products today? Does any of this resonate? Have you thought about where the real bottleneck actually sits in your own process?
