Twelve months ago, my stack looked like every PM you know.
Miro for journey mapping. Google Docs for requirements. ProductPlan for epics and roadmaps. Confluence for documentation nobody read. Jira for the backlog. Figma for design handoffs. Google Slides for stakeholder theatre. And a calendar full of alignment meetings where I had all the responsibility and none of the authority.
Five roles kept the machine running: a PM, a BA, a designer, a tech lead, and a scrum master. Each one a necessary node in a chain that moved information — slowly, lossily — from idea to shipped software. Each handoff a place where things got misunderstood, delayed, or quietly dropped.
Weeks became the unit of work. “We’ll have something to show you in two sprints” was the standard response to urgency.
That model is dead. And I know because I helped kill it.
What actually changed
The tool graveyard is real. Miro to Google Doc to ProductPlan to Confluence to Jira to Figma — that’s not a workflow. That’s six places for an idea to get lost. I don’t use any of them the way I used to.
| What I used to use | What I use now | What changed |
|---|---|---|
| Miro (journey mapping) | Structured spec docNew | Journeys written once, properly — no fidelity loss at the whiteboard-to-doc handoff |
| Google Docs (requirements) | .md files, version-controlled |
Clean, structured, readable by humans and agents alike |
| ProductPlan (epics & roadmaps) | Agent-managed scope | Roadmap is the spec; agents work the queue |
| Confluence (docs nobody read) | Spec = the documentation | One source of truth that doesn’t drift from what was built |
| Jira (backlog) | Agent queue | No ticket-writing overhead; work flows directly from spec to execution |
| Figma (design handoffs) | Spec-driven AI output | Design emerges from journey mapping — it’s a byproduct, not a phase |
| Google Slides (stakeholder theatre) | Approved spec | Alignment document is the deliverable, not a presentation about the deliverable |
| 5 people · weeks | 1–2 people · hours to days | Coordination overhead was the cost — it’s now close to zero |
Here’s what my day actually looks like now:
I write the brief. Not a summary — the real thinking work. Detailed user journeys. Epics. Stories. The context that used to get lost in translation between the PM’s head and the BA’s document and the developer’s interpretation. I write it once, properly, in a structured spec.
Then Claude takes that brief and generates the scope in .md files. Clean. Structured. Version-controlled. The kind of artefact you can hand to any developer — or any AI — and have them understand exactly what needs to be built without a single clarifying meeting.
Then I review the build in Cursor. Then spec2web handles the ops layer.
One PM. Doing product, design brief, marketing, content, and GTM.
What used to require five people across weeks now requires one or two people across hours and days. That’s not an exaggeration. That’s Tuesday.
The honest part? Most of my day now is waiting for responses. Not waiting for alignment. Not waiting for “can we prioritise this next sprint.” Just waiting for agents to finish what used to take a team to even begin.
That is the new bottleneck. And it is a drastically better problem to have.
Why this isn’t just AI hype
I’ve been building software products for over a decade. I ran a 40-person studio. I know what over-promise looks like in this industry, and I’ve been burned by it. So let me be precise about what’s actually changed and what hasn’t.
What’s changed is the upstream work — the thinking, structuring, specifying work that happens before a line of code is written. This is where the leverage is.
What hasn’t changed is judgment. Someone still needs to know what the right thing to build is. Someone still needs to read the market, talk to users, make the call when the spec and the reality diverge. That part remains stubbornly human.
But here’s the structural shift nobody is saying clearly: the number of people you need to do the execution work around that judgment has collapsed.
The JD that still reads “3–5 years experience. Strong communicator. Comfortable with ambiguity. Must know Jira” is describing a role that has already been restructured around it.
The uncomfortable truth about who survives
The PMs and founders who survive this aren’t the ones who managed backlogs.
They’re the ones who could always do the hardest part of the PM job — understand the problem deeply enough to brief a brilliant team with clarity, context, and taste — and now do it faster than a team of five used to.
Breadth just got weaponised. Depth just got leveraged. And the middle — the coordination layer, the handoff management, the Confluence-maintaining, Jira-grooming middle — is being automated as you read this.
The question isn’t whether your role is safe. The question is whether you’re operating above or below the automation line.
Five questions I actually get asked
You don’t need a traditional PM. You need someone who thinks like a great PM — who can turn ambiguity into a clear, structured spec — and who uses AI to execute what used to require supporting roles.
If you’re a founder who can articulate what your product needs to do and why, you’re already doing the hard part. The execution layer around that is thinner than it’s ever been. What used to require a BA to document, a PM to prioritise, and a scrum master to coordinate can now be handled by one person with the right workflow.
The trap is thinking you can skip the thinking entirely. You can’t. AI amplifies clarity. It also amplifies confusion.
It means you don’t write a single line of code until you’ve written a spec that answers three questions precisely: what does this product do, who does it do it for, and what does a user actually do inside it — step by step.
Not a slide deck. Not a Miro board. A structured written document that describes user journeys, edge cases, and expected outputs clearly enough that a developer (or an AI) can build from it without a briefing call.
The spec is the product, before the product exists. It’s where you find the problems before they become expensive. It’s also — not coincidentally — the thing that most development projects skip, and why most development projects go wrong.
At specshop.dev, The Spec is literally our first paid deliverable. Five days. Fixed price. Before any code is commissioned. It exists because we’ve seen what happens when you build without one, and we won’t do it.
No. And the difference matters.
Vibe-coding is: describe what you want in natural language, let the AI generate code, iterate until it roughly works. It’s fast, it’s accessible, and for throwaway prototypes it’s fine.
Spec-first AI development is: write a precise structured spec first, have AI execute against that spec, review and refine against the original spec rather than vibes. The spec is the source of truth, not the output.
The practical difference shows up at scale and at handoff. Vibe-coded products are hard to maintain, hard to hand to a new developer, and tend to accumulate hidden structural debt fast. Spec-first products have a document that explains what was built and why. When something breaks six months later, you know where to look.
One is fast to start. The other is fast to finish.
This is the right question, and here’s the honest answer: it happens, and you catch it in the spec review, not in production.
The reason spec-first exists is precisely because catching a wrong assumption in a .md file costs hours. Catching it after four weeks of development costs thousands. The AI generating a flawed interpretation of your brief is a feature of the process, not a failure — because it surfaces misunderstandings that would have existed anyway, earlier and cheaper.
The spec review is where the human judgment earns its keep. You read it like a lawyer reads a contract. If something doesn’t match your mental model of the product, you don’t ship. You fix the spec.
This is also why we don’t hand clients a spec and walk away. We built the process — and spec2web, our own ops toolchain — specifically to make the gap between spec and shipped product as small and observable as possible.
Yes. We know because we are one.
The constraint isn’t headcount anymore. It’s spec quality. A two-person team with a precise, well-structured spec and the right AI toolchain can ship what a six-person agency team used to deliver — faster, and with better documentation.
The caveat: “real software” still requires real engineering judgment at the architectural level. AI accelerates the building. It doesn’t replace the person who knows what to build and how to build it to last.
What’s changed is that you don’t need to hire that judgment into a full team. You can access it in a studio model — engaged for the duration of the project, aligned to a spec you own, at a fixed price you agreed before the work started. That’s the model we built specshop.dev around, because it’s the only model that makes sense for how software actually gets built now.
What this means for how you build next
The software industry spent twenty years building coordination infrastructure — tools, roles, ceremonies — to manage the gap between what people wanted and what developers built.
That gap is closing. Not because AI is magic, but because the translation layer between idea and execution is getting thinner every quarter.
The studios and teams that already work this way — spec-first, agent-augmented, with a process that treats the brief as the foundation rather than an afterthought — aren’t faster because they have better tools. They’re faster because they removed the coordination overhead that was never value, it was just friction that had become familiar.
The founders who build with them will ship faster, spend less, and own more. The rest are still syncing their Miro board with their Jira backlog.