How to actually get things built
I’ve made some edits on 8 May 2025 to clarify some points I’ve made - I was worried that I have discounted the hard work that goes into building products and I wanted to make sure I was clear on that. I’ve left my original wording in here for reference. I don’t intend to make offence, but I want to be honest about the challenges we face. I may have done that unintentionally. I apologise and have amended my wording to add clarity.
Product teams often over-complicate things.
They create extensive PRDs, run exhaustive user research, and follow Agile methodologies to the letter. But somewhere along the way, they lose sight of the actual point: delivering value to users.
This over-complication is a symptom of care. People want to do good work — so they pile on process and documentation. But more layers don’t mean more clarity. Often, it just slows everything down.
Product teams often treat PRDs as the definitive map for delivery – detailed, thoughtful and grounded in customer research. And rightly so.
But from an engineering perspective, these documents can sometimes feel like they’re optimised for traceability and context, not clarity of execution.
This isn’t a criticism of the rigour or approach – if anything, it’s a reflection of how complex modern product development has become. But when I’m building, I need a blueprint. A clear, simplified view of what’s expected, how it works, and what success looks like in code.
Add to that the breakdowns in communication. Teams have different ways of working. Without shared language or alignment, those differences create gaps. And the gaps create delays.
Then there’s the MVP — misunderstood and misused. It’s not about launching a half-baked version of the product. It’s a minimum deliverable bet — a testable hypothesis with just enough built to prove or disprove something. If it doesn’t land? Kill it and move on.
“Keep It Simple, Stupid” — the old KISS principle — still applies. Simplicity is underrated. Especially when you’re trying to build something quickly with a team of smart people who all think differently.
Dave Thomas, one of the authors of the Agile Manifesto, put it well:
“Agile has become a noun, and that’s the problem. We need to focus on agility.”
Agility is the goal. Not rules, not rituals — just responsiveness. You want to be able to change direction without friction.
The way forward is dead simple: less bloat, more clarity.
Start with one-pager blueprints. Just the essentials:
- User journeys — who’s trying to do what?
- MoSCoW priorities — what must be done, and what’s out of scope?
Treat these like living docs. Keep them in Notion or wherever you collaborate. When something changes, update the blueprint. Ping the team. If it’s a major shift, book time to regroup.
That’s your source of truth — not a PM tool, not a Jira board.
Use Linear (or Jira if you hate yourself) to track what needs doing. Not to log edge cases or decision history. If an edge case matters, add it to the acceptance criteria or capture it in the blueprint. Otherwise, don’t clutter the board.
When it comes to technical implementation, engineers can lean on UMLs, ERDs, sequence diagrams — all the usual stuff. That’s their world. But the rest of the document? That’s a letter from Product to Engineering. And it should read like one.
Clear. Focused. No fluff.
And once something’s built, testing isn’t just dev territory. Product owns the hypothesis. You talked to users. You scoped it. Now go back and validate. Did it work? Did it actually solve the thing?
This whole process — when it’s humming — is a beautiful machine. When it’s not, it’s a mess. But the fix isn’t more process. It’s less. Just the right amount. Enough to align people, not paralyse them.
If you want to dig deeper: