zero21 Book a call

Guide · Dubai · MENA

Product team structure for early-stage startups: who you actually need

A founder with five engineers and no product manager will ask the same question every few weeks: who is supposed to be doing this job. No one put it on a job description, so it gets split between whoever has time, which means it gets dropped the week the whole team is stretched. Across engagements in Dubai and MENA I keep seeing teams solve this by hiring a PM before they have agreed what the PM would own.

This piece covers the structure that works before product-market fit, who covers each part of the PM function when there is no PM, the order the first three product hires should land in, and how AI-assisted engineering has changed the ratios that used to hold.

The default startup product team structure before product-market fit

Before product-market fit, the unit that works is small: the founder owning product, plus one cross-functional pod of two to five engineers and one designer. The whole pod touches the same codebase, the same backlog, and the same customers. There is no handoff between discovery and build because the people doing both sit in the same standup.

Founders kill this stage by organizing it like a bigger company anyway: the researcher hands a brief to the designer, the designer hands a spec to the engineer, the engineer hands a build to QA. Each handoff adds a day of latency and a chance for the brief to lose the reason it existed. A five-person team running a waterfall handoff between functions ships slower than a five-person team that argues about the same problem in one room. Keep the pod flat until growth forces a split, not before.

Who covers each PM function when there is no PM

The product manager role disappears before product-market fit. The product manager function does not. Someone still has to run discovery, decide what ships next, write a spec tight enough to build from, check the result against reality, and read the analytics. Map it across the pod you have:

Write this split down. "We all pitch in" is not a structure, and it is the reason the same gap keeps reappearing every few weeks with no one responsible for closing it.

The order of the first three product hires

First: a senior product manager, not a junior one. A junior PM needs direction the founder is already too stretched to give, and a junior PM with no clear mandate spends the first quarter negotiating authority it should have had on day one. A senior PM arrives knowing how to run discovery and write a spec without a template, and starts contributing inside the first sprint.

Second: a designer or researcher, once the PM has a backlog that needs more than wireframes borrowed from a competitor. Bringing design in before the PM often produces polished screens for features no one has validated yet.

Third: product ops or a product marketing hire, once the team ships often enough that release notes, documentation, and cross-functional coordination start eating a PM's week that should go to discovery and specs.

The common mis-order is hiring a designer first because a landing page needs to look credible for fundraising, then discovering six months later that the roadmap behind the landing page was validated by no one whose job was to validate it.

How AI tooling changes the ratios in 2026

Founders used to peg the first PM hire to seven or eight engineers, on the assumption that each engineer needed a comparable amount of product decision-making to stay fed with well-scoped work. Teams building with AI coding tools break that assumption. A team of four or five engineers shipping with AI assistance now moves at a pace that used to need eight or nine people, so the same four or five engineers burn through a backlog fast enough to hit the coordination ceiling earlier than the old ratio predicted.

The bottleneck moves from "can we build it" to "do we know what to build next, and is it specified well enough to build without guessing." A founder measuring readiness for a first PM hire by headcount alone will hire two quarters too late, because the team outgrew the founder's bandwidth to prioritize before it outgrew the old hiring trigger.

Patterns across 60+ founders in a Bahrain fintech program

Working with more than sixty founders across two cohorts inside a Bahrain venture studio surfaced a pattern that held across the group. Teams that wrote down who owned discovery, prioritization, specs, QA, and analytics before they needed to hire a PM transitioned into that first hire without friction. The new PM inherited a function that already existed and sharpened it. Teams that let the function stay implicit hired a PM into chaos. The PM's first month went to archaeology: reconstructing who had been deciding what, and why, before writing a single new spec.

The stalled teams mostly had a PM. What they lacked was a written answer to who had done PM work before that PM arrived.

When to restructure, and what fractional leadership covers in the gap

Around twenty to thirty employees, the single flat pod stops working. By that size a company often has two or three product lines or customer segments, and one backlog cannot represent all of their tradeoffs well. This is the point to split into multiple pods, each with its own PM, rather than stretching one PM across work that needs two different sets of judgment.

Between the signals above and a full-time senior hire landing, fractional or embedded product leadership covers the gap: someone senior enough to run the function right away, for the hours the stage needs, while the founder runs a proper search instead of a rushed one. The structure matters more than the title at any stage. Get the function covered, in writing, and the right hire becomes an upgrade to something that already works rather than a rescue for something broken from the start.

FAQ

Do we need a product manager before product-market fit? Rarely, before product-market fit. The founder, plus a lead engineer and designer sharing the PM function explicitly, covers discovery, prioritization, specs, and analytics well enough for a team of two to five engineers.

How many engineers justify a first product manager hire? The old benchmark was seven to eight. With AI-assisted engineering teams shipping faster per head, the coordination ceiling now often arrives closer to four or five engineers, so watch for the symptoms (slow decisions, re-explained context, a roadmap set by whoever asked loudest) rather than waiting for a fixed headcount.

Should the first product hire be junior or senior? Senior. A junior PM needs scaffolding the founder does not have time to build, and tends to spend the first quarter negotiating authority a senior hire would already carry in.

What changes in product structure once the team passes twenty to thirty people? One flat pod and one backlog stop representing each product line's tradeoffs well. Split into multiple pods, each with its own PM, rather than stretching one person across unrelated judgment calls.

Get the structure and the hiring order wrong and the cost shows up as stalled sprints and a PM's first quarter spent reconstructing decisions no one wrote down. Book an intro chat to work through where your team sits against this and what the next hire should cover.

For more on how early product teams take shape in practice, scalable.news covers the patterns as they happen.

More from zero21