One person, the whole loop: designing, prompting and shipping without a PM in the middle
What actually changes when the same person frames the problem, designs the screens, writes the prompts, ships the code and watches the analytics: the leverage, the failure modes, and the product-management work that does not disappear.
For a specific class of product (early, small surface area, one clear owner) the most productive team in 2026 is sometimes one person holding every role at once: the one who talks to users, decides what to build, designs it, writes the prompts, reviews the diff, ships it, and reads the analytics the next morning. I have been working this way for a while. This is what it is like, including the parts that are worse, not just the parts that are faster.
The handoff tax#
The traditional chain has a lot of arrows:
user need
│ (interview, notes)
▼
PM ──▶ PO ──▶ designer ──▶ engineer ──▶ QA ──▶ release
◀───────────── feedback, re-scoping, "that's not what I meant" ─────────────Each arrow is a spec written by one person and reinterpreted by another. Each one has latency: a backlog, a grooming session, a sprint boundary. The person who feels the friction of a bad data model (the engineer) is three hops from the person who decided the feature was worth it (the PM), and by the time feedback travels back, the context is cold.
None of that is a knock on the individuals. It is the structural cost of splitting one continuous act of judgement across five people and two weeks.
What AI actually moved#
The naive version of this story is "AI writes the code, so I don't need engineers". That is not it. The real change is narrower and more important:
The cost of going from a clear intent to working, deployed software dropped by an order of magnitude. So the bottleneck moved up the stack, to taste, problem framing, and knowing what is worth building at all.
When implementation was the expensive step, it made sense to have a whole role dedicated to deciding what implementation to spend money on. When a working prototype is an afternoon, the calculus changes. You can build the thing, use it, and throw it away faster than you could have written the ticket for it.
What you gain#
- No telephone game. The person who understood the user problem is the person choosing the component, naming the database column, and writing the empty state. Nothing is lost in translation because there is no translation.
- The decider feels the cost. You do not casually spec a three-week feature when you are the one who has to build and maintain it. Scope discipline gets easier when the person who wants the feature and the person who pays for it are the same person.
- The loop is minutes, not sprints. Idea, rough build, click around in it, "no, actually", rebuild. Three times before lunch. Most ideas die in that loop, which is exactly where they should die.
- Coherence. One head holds the product intent, the visual language, the data model and the deploy setup at the same time, so the seams line up. The design assumes what the API returns; the API returns what the design needs.
What you give up, and have to replace#
Collapsing the roles does not delete the work those roles were doing. It just makes it your job to do it deliberately.
- No one to disagree with you. A good PM or design partner is friction in the useful sense: they catch the bad assumption before it ships. Alone, you have to manufacture that: adversarial self-review, a written "why I might be wrong" list, and real users in front of the thing early, because "I am the user" is a trap unless you really are.
- Prioritisation does not vanish. Deciding whatnot to build, sequencing, cutting scope under time pressure: that is the PM function, and it is now a hat you consciously put on, usually on Monday morning, before the building starts.
- You are the single point of failure. No bus factor, no cover when you are sick, no second person who knows why that module is shaped the way it is. Write things down as if you were onboarding someone, because one day you might be.
- Stakeholder communication, if you have any stakeholders, is still a job, and it is one the PM role used to absorb.
The skills that carry the weight now#
| Skill | Why it matters more now |
|---|---|
| Problem framing | The model executes whatever you point it at, confidently, including the wrong thing. A crisp written spec is the highest-leverage artefact you produce. |
| Prompting as craft | Decomposition, constraints, worked examples, and knowing the moment to stop prompting and take the keyboard yourself. |
| System-design taste | The model will happily build a plausible architecture that will not survive contact with the second feature. You own that call. |
| Review discipline | Reading a diff like a senior reviewer (data flow, edge cases, failure modes), not skimming for vibes and merging. |
| The last 20% | AI nails the 80%. Edge cases, performance, security, accessibility, and "this feels wrong" is the actual job. |
A day in the loop#
- Pick one thing. Not three. Write, in plain prose, what it is, who it is for, and how I will know it worked.
- Design it where it is cheapest. Often straight in the browser with real components; sometimes a quick canvas when the layout is genuinely uncertain.
- Spec, then prompt. The spec from step 1 becomes the prompt. Build it behind a flag.
- Review the diff properly. This is where the engineering seniority is spent: on reading, not typing.
- Ship it dark, then use it. Live, with my own data, for a day. Watch the analytics and a couple of session recordings.
- Decide. Keep, cut, or iterate. Most things get cut or heavily trimmed, and that is the loop working.
Where this model breaks#
| Works when | Breaks when |
|---|---|
| Zero-to-one, small surface, one owner | Large existing codebase with many stakeholders |
| Low regulatory / safety load | Safety-critical, regulated, or audited domains |
| You already have senior judgement | The driver cannot tell good output from confident output |
| The domain is one you understand | Deep domain expertise lives in other people’s heads |
| Coordination cost is near zero (it’s just you) | The work really needs many hands in parallel |
The moment real coordination is needed (multiple engineers touching the same system, a specialist whose knowledge you cannot absorb, a compliance process with sign-offs) the roles come back, and they come back for good reasons.
It is leverage on judgement, not a substitute for it#
This way of working amplifies whoever is driving. Someone with ten years of shipping instincts gets a real multiple on their output. Someone without them ships polished, confident, subtly broken software faster than they ever could before, and cannot see why it is broken.