Guide · Dubai · MENA
Running product without a PM: an operating system for small teams
A startup without a product manager still has product management happening somewhere. Someone decides what gets built this week. Someone decides what gets cut. In some teams one person owns that work on purpose. In others it falls to whoever argues loudest in standup.
Across engagements in Dubai and MENA I keep seeing the same gap. A team of five or six ships fast for a few months on founder instinct, then slows down, and the founder cannot name the cause. The founder assumes the fix is a PM hire. The fix is five functions covered, whoever does them.
What does product management cover?
Five functions, regardless of who does them or what their business card says.
Discovery. Someone talks to customers and turns what they hear into a problem worth solving, instead of logging it as a feature request.
Prioritisation. Someone decides what ships this month and what waits, with a reason attached to the decision instead of an unrecorded gut call.
Specs. Someone writes down what "done" means before an engineer starts, so the team is not debating scope mid-sprint.
Delivery cadence. Someone keeps work moving through a visible rhythm: what shipped, what is stuck, what is next.
Learning loop. Someone closes the loop after launch: did the thing work, and what does that mean for the next bet.
Skip any of these five and the gap shows up fast. Skip discovery and the team builds polished features no customer asked for. Skip the learning loop and the team repeats the same mistakes with a new coat of paint each quarter.
A weekly cadence a founder can run alone
A ritual makes the function stick. The weekly loop below works for small teams covering product without a dedicated PM.
A customer-call quota. Three calls a week, minimum, logged somewhere the whole team can read instead of the founder's memory alone. Fewer than three and discovery stops, replaced by whatever the founder assumes customers want.
One prioritisation ritual, with a written tradeoff log. Thirty minutes, same day each week, where the team picks what ships next and writes down why, in one sentence, next to what got passed over. The log matters more than the meeting. Six months later it tells you whether your calls were right, and a meeting without a record teaches the team nothing.
A shipping review. Fifteen minutes, end of week, to look at what shipped against what was planned at the start of the week. Gaps between plan and reality are the earliest signal that scope or capacity estimates are off.
A metrics check. One sitting, one dashboard, one question: did what shipped move the number it was meant to move. A team that skips this step ships features forever without learning which ones earned their place.
Four rituals, roughly two hours a week outside the building itself. Light enough that a founder running sales calls and fundraising at the same time can keep it running.
Who owns what: founder, engineers, designer
A small team covering product without a PM still needs a clear split, or the founder ends up as the only person allowed to make a decision.
The founder owns prioritisation and the customer relationships that feed discovery. No one else on the team has the full context on why the company exists or what a key account needs, so that work stays with the founder.
Engineers own more than tickets. A good engineering pod on a PM-less team owns the scoping of their own tickets and the edge cases inside them, beyond the happy path handed down from a spec. A founder who tries to spec each edge case alone becomes the bottleneck the system was built to avoid, and the engineers who could catch problems early lose the chance to.
The designer, where there is one, owns the problem framing before anyone touches a tool. A design pass that starts from "build this feature" produces a different product, and often a worse one, than one that starts from "solve this problem for this user."
Specs still need a single owner per feature, someone who can say what "done" means before a line of code gets written. That does not have to be the founder. It has to be someone who talked to the customer the request came from.
Where AI absorbs the admin, not the judgment
The five functions above come with real administrative weight: call notes, ticket drafts, changelog entries, support triage. That is where AI workflows earn their place on a PM-less team, and it is worth reading the AI workflow automation guide for how to scope a first one.
Call summarisation turns a 30-minute customer conversation into a two-paragraph discovery note, so the person who ran the call spends five minutes on writeup instead of twenty. Ticket drafting takes a raw feature request and turns it into a structured ticket an engineer can size. Support triage sorts incoming tickets by theme before a human looks at any of them, so the learning loop above sees patterns instead of a flat list of individual complaints.
None of this replaces the fourth function in the list, prioritisation. An AI summary can tell you what ten customers said this week. It cannot tell you which of those ten problems is worth six weeks of engineering time against everything else on the roadmap. That call still needs a human who knows the business, holding the tradeoff log described above.
Signals the system has hit its limit
The operating system above holds until it does not, and the failure signals look a lot like the ones in the founder-led product ceiling.
A growing queue of decisions that only the founder can make is the first sign. If specs sit for days waiting on a single person's approval, the weekly ritual has stopped being enough coverage for the volume of work moving through the team.
A team that stops pushing back is the second, and the quieter one. Engineers who used to flag a weak idea in the Monday prioritisation call start building what they are told instead, because debating a founder's idea costs more social capital than shipping it without comment. Lost pushback is a bigger risk than a missed deadline, because it costs the company bad bets that surface only after launch.
Headcount is a rough proxy, not a trigger on its own. Most PM-less systems like the one above start to strain somewhere around 15 to 20 people, or earlier if the team is running more than one product line at once. Two roadmaps competing for one founder's prioritisation slot break the weekly ritual long before the headcount number does.
What comes after the operating system
When the signals above show up, a full-time PM is not the only answer. Product team structure for early-stage startups covers the order of hires that works, and fractional product leadership covers the option that takes the backlog and the specs off the founder's desk before the team commits to a full-time seat.
FAQ
Do startups need a product manager from day one? No. Pre-product-market fit, a founder running the five functions directly, with a customer-call quota and a written tradeoff log, tends to outperform an early PM hire who still has to learn the business from scratch.
How do I do product management without a PM title? Cover the five functions, discovery, prioritisation, specs, delivery cadence, and the learning loop, and assign each one to a person, even if that person also writes code or does sales. The function has to exist. The title does not.
What is the first sign a PM-less system is breaking down? A growing backlog of decisions stuck waiting on one person's approval, paired with a team that has stopped questioning that person's calls out loud.
Can AI tools replace a product manager on a small team? AI tools can absorb the admin load, call notes, ticket drafts, support triage, that eats a founder's week. They cannot make the prioritisation call, because that call needs judgment about the specific business beyond any summary of what customers said.
If your team sits somewhere between founder-led working fine and needing a hire, a short conversation sorts out which side of that line you are on. Book an intro chat to talk through where your team stands.
For more on how small teams run product without a dedicated PM, scalable.news tracks the patterns as they show up in practice.