Two-Week Shipping: What Happens When Product Managers Learn to Build with AI 🤖
How I shipped in two weeks what would have taken months with a traditional product agency
Have you ever felt like you had you had superpowers and that you could build anything you set your mind to? Well after working in startups for nearly two decades, I finally got that feeling on a recent client project and I want you to have these powers too…
Here’s the recap 👇
Two weeks. Three AI-powered apps.
An analytics dashboard with natural language queries.
A call center QA monitoring tool with baked in-compliance.
A self-improving knowledge hub that ingests calls and emails.
Partner-facing tools. Risk scoring. Benchmarking. A full testing suite.
Normally, based on industry benchmarks, an external agency would take at least 6–8 weeks and a small team to deliver something similar. But here’s the twist: I’m not a software engineer. I’m a founder and product manager who learned to use Claude Code, Taskmaster, Cursor and Wisperflow.
This raises questions most people avoid:
What happens to traditional PM workflows?
What does engineering look like when AI builds production apps in days?
Why are people talking about AI as “the future” when it’s clearly the present?
How I got here (and why this isn’t hypothetical)
Back in late 2023, I took a sabbatical from building startups. Since then, SO MUCH has changed in that timeframe in the land of technology, products, and AI. At the end of my sabbatical, I started learning all the latest AI systems. Not just “how to use ChatGPT” but “how to build production software with AI.” Eight to ten hours a day, treated it like a bootcamp. Claude Code, Cursor, multi-agent orchestration with worktrees—the works.
Then I had my first consulting project after sabbatical.
Week one: Two internal tools built in five days that unlocked 20-30% efficiency gains.
Week two: A business intelligence platform designed to materially support revenue growth.
Suddenly I was shipping full-stack applications in days, not weeks. It felt like running a Google Ventures Design Sprint and ending up with the entire working product.
And it wasn’t black-box code or one-off prototypes. Everything was structured, readable, and easily maintainable by any engineer.
The old model (already breaking)
Here’s how it used to work:
PM writes spec (3 days) → Designer makes Figma mockups (4 days) → PM writes user stores (1 day) → Engineer reads stories, asks questions, provides estimates (2 days) → Engineer builds feature (2 weeks) → QA finds issues (3 days) → Engineer fixes issues (3 days) → Deploy
Total: 4-6 weeks per feature.
AI-powered development:
Idea → Claude Code → Working software → Deploy
Total: 2 days.
I spent two days interviewing users, partners, and stakeholders — then moved straight into build mode. Plus one day of storytelling afterwards to communicate the value of what we’ve created and align with business and user needs.
Build Day Breakdown
Day 1 – Morning
Architecture planning with Claude Code
Ingested all transcripts + notes
Generated a PRD with architecture recommendations
Combed through PRD line-by-line with Claude
Converted PRD into tasks via Taskmaster
Day 1 – Afternoon
Built project foundation
Database + schema + API
Analytics engine + risk scoring
Natural-language query layer
Benchmark research via Perplexity
Day 2 – Morning
Early demo with stakeholders
Rapid iteration
AI features aligned to client’s value proposition
Modernized UI through Figma Make → React components
Day 2 – Afternoon
Integrated design system
Error handling
Testing & QA
Deployment
On the third day I used Claude Code to review the codebase, my notes and project summary to help me assemble a slide deck that told the story of our work, the problems we discovered and the solutions we built.
No handoffs. No bottlenecks. Just: “What should this do?” → “Here it is.”
The cost breakdown (or: why finance people should care)
Traditional approach: 8 weeks × £800/day = £32,000 (conservative)
AI-assisted approach: 5 days × £2,000/day = £10,000
The compression isn’t incremental. It’s a fundamentally different loop.
What I’m actually doing now
I’m not writing functions and debugging syntax. I’m not on Stack Overflow searching for answers. I’m not fighting TypeScript compiler errors. Claude Code does all of that.
What I’m doing is:
Describing what user and business goals the system should accomplish
Making architectural decisions collaboratively (database structure, API contracts, component hierarchy)
Iterating based on what I see working after each task
Directing the build the same way I’d direct a team—except the team is an AI agent that writes production-quality TypeScript and I can review every few minutes
To be clear: it wasn’t magic. Claude got the database schema slightly wrong initially and I had to redirect it (it made up two fields that weren’t in the API). The first deployment failed because of Next.js version issues with file upload sizes. I spent far more time back and forth iterating on the design than I would hope.
But I still shipped three products in less than two weeks. Not because I’m special—because the tooling is now here to make this possible and the feedback loop went from weeks to hours.
I’m not becoming a “junior engineer.” I’m becoming what I probably wanted to be all along: someone who ships products without waiting for someone else to implement my ideas.
And if I can do this, what happens to the PMs at all those companies who are still manually writing specs, designers pushing pixels in Figma and engineers living in Jira or Linear all day?
The uncomfortable truths
Let me say the quiet parts out loud:
For Founders:
Your engineering backlog isn’t a capacity problem. It’s an architecture problem. Fix the system, not the headcount.
For PMs:
If you’re spending 80% of your time in Figma and JIRA or Linear, you’re not a product manager—you’re a specification writer waiting to be automated.
For Engineers:
“Junior engineer” as a career path is dying. You either become an architect or you compete with AI. You choose.
Here’s the shift: from Feature Builder to Platform Architect.
Not “build this dashboard” but “design the system where anyone can build dashboards and integrate into the same product suite.” Not “fix this bug” but “create the infrastructure where bugs are caught automatically.”
The new role for engineers isn’t writing more code—it’s writing better constraints. Component libraries. API contracts. CI/CD pipelines. Architectural review of AI-generated code. System coherence when multiple builders are shipping in parallel.
You don’t want to spend the rest of your life implementing CRUD endpoints. Let AI do that. You should be architecting systems that ten people can build on simultaneously without stepping on each other’s toes.
The structure that emerges
I think we’re heading toward three distinct tiers:
Product Builders → Ship features with AI assistance
Platform Architects → Enable builders at scale
Specialists → Solve problems AI can’t (yet)
Let me break these down:
Product Builders (PM + AI)
Anyone with product sense who learns AI-assisted development
Own vertical features end-to-end
Ship within architectural boundaries
10x-100x traditional PM velocity
This is what I’m doing now. This is the template.
Platform Architects (Senior Engineers)
Build the “rails” that Product Builders run on
Design systems, component libraries, microservices architecture
Enable 5-10 builders to ship safely in parallel
Maintain system coherence, not feature implementation
What they build:
Component libraries and design systems
Microservices architecture with clear boundaries
API contracts
Automated testing and deployment
Security and performance infrastructure
Architectural review of AI-generated code
The shift:
From “Write code” → “Write constraints”
From “Ship features” → “Ship systems”
From “Implement” → “Enable”
Specialists (Deep Expertise)
ML/AI systems, data infrastructure, security, performance
Solve problems AI agents can’t handle yet
Go deep on complex domains
The critical insight: if seven PMs at a startup all learned Claude Code tomorrow without platform architecture in place, you’d have total and utter chaos. Seven people committing to main simultaneously, no architectural coherence, duplicate components, security vulnerabilities, a franken-product.
You need engineers to become Platform Architects—defining module boundaries, creating the component library, setting up testing and deployment pipelines, reviewing PRs for architectural consistency.
What dies, what emerges
What dies:
The PM → Designer → Engineer handoff
Figma files as “deliverables”
40-hour design sprints
JIRA tickets as units of work
Sprint planning estimating story points
“I’m not technical” as an identity
What emerges:
Idea → deployed feature in hours/days
Design systems integrated into code
Working software as the output
Architectural coherence as the bottleneck (not eng capacity)
“Can you ship?” as the primary question
What this means for existing organizations
If you’re working inside an organization with a more traditional product development process that hasn’t gotten up to speed with AI-assisted development and all that this enables, here’s what I’d recommend:
Phase 1: Train the PMs to become product builders (3 months)
Phase 2: Build Platform Architecture (6-12 months)
Phase 3: Scale the Model (12+ months)
PMs could become parallel product builders, with platform engineers ensuring it all works together.
Or they could stay in Figma while their competitors ship. That works too.
The future (it’s not three years away)
This is happening right now. The organizations restructuring around this model in 2025 will have an insurmountable lead by 2026.
What replaces traditional PM:
Product Builders (ship code)
Product Architects (design systems)
Product Strategists (market/positioning, no coding)
The startups that figure this out first will 10x their competition. You can ship faster, iterate faster, learn faster than anyone still doing waterfall product development with handoffs between disciplines.
The personal bit
After years grinding through handoffs and slow loops, I took a sabbatical, rebuilt my workflow, and came back able to ship end-to-end. No waiting for capacity. No friction, just:
Idea → Claude Code → shipped product → customer value.
If this isn’t the dream of every product person, I don’t know what is…
And if you want to learn this…
I’m considering running a small immersive cohort in 2026 — a week-long sprint in nature (Portugal or Morocco), limited to 8–10 people serious about transforming how they ship products.
If that’s interesting, DM me or subscribe for updates.
Either way: Keep shipping.
Peace ✌️