For years I carried around this particular blend of skills like a strange inheritance I didn’t quite know what to do with. Solution architecture. Product management. An obsession with understanding how software actually gets built—not just the coding part, but the whole messy journey from “someone has an idea” to “users are clicking buttons in production.”
The “Technical PM” thing. It always felt like being stuck in a weird in-between.
Not quite engineering. I could read code, reason about systems, and hold my own in architecture discussions—but I wasn’t writing production code every day. Not quite pure product either. I should have been doing JTBD interviews, instead I found myself deep in bug triage and engineering workarounds.
Something adjacent to everything. Useful in many rooms, but never quite belonging in any of them.
The Hybrid Curse
If you’ve spent time in tech, you know how specialisation gets rewarded. The 10x engineer. The visionary product leader. The data science wizard. Clean, legible identities that fit neatly into org charts and job descriptions.
Being a Technical PM never fit that mould. In engineering meetings, I was “the non-coder who barged into the room.” In product meetings, I was “the guy who keeps bringing up technical constraints.” In architecture reviews, I understood the systems but wasn’t the one designing them.
In the early days, this was genuinely a problem. I couldn’t easily find jobs because everyone wanted specialisation. The hybrid skillset didn’t match any job description anyone was advertising. Every role I landed, I got because the organisation needed three roles in one person. The problem was they didn’t know how to write that JD. I had to chance upon these opportunities rather than apply for them.
For a long time, I thought this was something to solve. Maybe I should commit fully to engineering. Or maybe I should drop the technical obsession and become a “real” PM who focuses on customer research and stakeholder management.
I never did. The in-between was where I kept gravitating.
And eventually, the curse became a career. I parlayed the hybrid skillset into consulting, where being able to bridge presales to delivery was exactly what clients needed. I became Head of AI Engineering not despite the in-between nature of my skills, but because of it. The ability to plug into any gap, put out any fire, translate between business and technical teams. That was the value proposition.
But it took years to find organisations that valued the hybrid. And even longer to realise that what felt like career awkwardness was actually preparation for something that didn’t exist yet.
The Skills That Seemed Useless
Looking back, I can see what I was actually building all those years, even if I couldn’t articulate it at the time.
Systems thinking. Understanding how the pieces connect. Not just “this service calls that service,” but the full picture—how data flows, where complexity accumulates, what breaks when load increases, why some architectural decisions create downstream problems that take years to manifest.
SDLC comprehension. The whole lifecycle, not just the parts I was responsible for. Requirements gathering. Design. Implementation. Testing. Deployment. Operations. What happens at each stage, who’s involved, where things typically go wrong.
Requirements obsession. The belief that getting requirements right is half the battle. Not just capturing what stakeholders say they want, but understanding the underlying problem well enough to know when their proposed solution is wrong.
The “why does this matter?” reflex. Always connecting the tactical to the strategic. “We’re building feature X” → “Why?” → “Because customers want it” → “Why do they want it?” → “Because they’re trying to solve problem Y” → “Is feature X actually the best way to solve problem Y?”
These skills felt somewhat abstract. Useful, sure, but hard to point to. They didn’t produce code or ship features directly. They lived in the spaces between the things that were easy to measure.
The Moment
A few weeks ago, I finished wiring up something I’d been building for months. Eight AI agents, each specialised for a different phase of the software development lifecycle. Built on Claude Opus 4.5, orchestrated through Claude Code.
SDLC-01, the Product Lead, handles product requirements—PRFAQs, PRDs, user stories with acceptance criteria.
SDLC-02, the Architect, does system design and architecture—ADRs, technical specs, data models.
SDLC-03, the Designer, focuses on frontend design—user flows, wireframes, design systems.
SDLC-04, the Builder, builds—actual implementation, following the specs.
SDLC-05, the QA Lead, handles quality and testing—test pyramids, risk-based testing, coverage.
SDLC-06, the Ops Lead, manages shipping and operations—deployment scripts, version tracking, rollbacks.
SDLC-07, the Security Lead, runs security—threat modelling, OWASP reviews, security requirements.
And orchestrating all of them: SDLC-08, the Chief of Staff. A consigliere that dispatches the right agent for each phase, reviews what comes back, catches gaps, manages handoffs, and maintains a single source of truth for project state.
I ran it on a real project. Defined what I wanted to build. Kicked off the system.
Then I just… watched.
Watched it knock out a sprint’s worth of work in half an hour. Code. Documentation. Testing. Full PRD to deployed feature with test coverage and architecture docs.
Then do it again.
That’s when I realised that all those years of learning to think in systems, to see the whole board, to understand how the pieces connect—it all came together to make that moment possible.
The weird hybrid skillset wasn’t a limitation. It was exactly what was needed to orchestrate this.
Why PM Skills Matter More Now
Here’s the thing I didn’t expect: AI doesn’t make product management skills less important. It makes them drastically more important.
AI amplifies requirements quality. Give an AI agent vague requirements, you get vague output. Give it precise, well-structured requirements with clear acceptance criteria, and the output is remarkably good. The quality of what goes in determines the quality of what comes out—at a much higher leverage ratio than with human developers.
When I was working with human engineering teams, mediocre requirements could still produce decent code because engineers would fill in the gaps, ask clarifying questions, make reasonable assumptions. AI agents will execute exactly what you tell them. They’re incredibly literal. The skill of writing requirements that are complete, unambiguous, and correctly scoped becomes the bottleneck.
Systems thinking enables orchestration. Understanding how the pieces of software development connect means knowing which agent to invoke when, what information needs to flow between phases, where to expect problems, and how to structure work so that each agent has the context it needs.
You can’t orchestrate a system you don’t understand. When my SDLC-04 (testing) agent produces tests, I need to know whether those tests actually validate what matters. When SDLC-02 (architecture) produces a design, I need to know if it’s going to cause problems for SDLC-05 (operations) later. That judgment requires the same systems thinking I’d been building for years.
SDLC knowledge means you can direct the full pipeline. Not just the coding part. The whole thing. Requirements through to deployed, monitored production systems. Each phase has its own practices, pitfalls, and quality gates. Knowing these is what allows you to build a multi-agent system that covers the full lifecycle rather than just “code generation.”
The headline writes itself: You’re not the builder anymore. You’re the architect. AI does the building. Your job is to design what gets built, orchestrate how it gets built, and verify that what was built is correct.
That’s a PM skillset. Always has been.
The Maturity Model
I’ve started thinking about this in terms of levels.
Level 1: Human-Only Coding. The traditional model. Humans write all the code. This was the default from the 1960s through roughly 2021.
Level 2: AI-Assisted Coding. The Copilot era. AI suggests completions, humans accept or reject. The human is still writing code, just faster. The skill that matters is still coding—you need to understand what the AI is suggesting to know if it’s good.
Level 3: Human-Directed AI Coding. This is where I’m operating now. The human defines what to build at a higher level of abstraction. AI executes the implementation. The human reviews, provides feedback, and iterates—but isn’t writing most of the code line by line.
The skill that matters at Level 3 isn’t primarily coding. It’s requirements definition, system design, quality judgment, and orchestration. You need to be technical enough to review what the AI produces, but the bottleneck is everything that happens before and after the AI writes code.
Level 4: Full AI Teams. Human sets goals, AI handles everything—including breaking down goals into tasks, executing tasks, reviewing its own work, and deploying. Human involvement is strategic and supervisory.
Level 4 isn’t here yet. The AI isn’t reliable enough for fully autonomous operation. It hallucinations. It loses context. It makes mistakes that require human judgment to catch.
But I can see it from where I’m standing. It’s not a distant future—it’s maybe a year or two away for certain types of work.
The One-Person Army
Here’s what Level 3 makes possible: a single person, with the right orchestration setup, can execute what previously required a team.
I don’t mean this in a hustle-culture “grind harder” way. I mean it structurally. The work that a PM + architect + 2-3 engineers + QA + DevOps would typically do across a sprint—requirements, design, implementation, testing, deployment—can now be executed by one person directing AI agents, in a fraction of the time.
The leverage is unreal. And I’m not even particularly good at this yet. The tooling is primitive. The prompts could be better. The agent orchestration has gaps. I’m probably leaving 10x improvement on the table through inefficiency.
This is still early days. The one-person software development army is now a real possibility—and we’re just getting started.
The In-Between Was the Point
Looking back, the career awkwardness makes sense now.
The “weird hybrid” skillset was never a bug. It was training for a role that didn’t exist yet.
Technical enough to understand systems and review AI output. PM enough to define requirements and think strategically. Architecture-aware enough to design how agents should work together. Process-obsessed enough to think about the full lifecycle.
All those years of being “adjacent to everything” prepared me for a world where the adjacent position—the orchestration layer between human intent and AI execution—is exactly where the leverage lives.
If you’re reading this and you recognise yourself in the Technical PM description—the systems thinker, the requirements obsessive, the person who cares about how all the pieces connect—your moment might be coming too.
The skills that made you feel like an awkward in-between in the old world are precisely the skills that matter in the new one.
This is Part 1 of a series on AI-assisted software development from a PM perspective. Next up: The 8-Agent SDLC—how the system actually works.