Most product orgs have more titles than definitions. Product owner, product manager, technical PM, technical program manager and the domain expert overlap until nobody is sure who decides what. This planner separates them: where each role's week goes, which decisions it owns, what that buys the business, and how many of each a team your size needs.
01
Pick a role and stage
Eight roles, from product analyst and domain expert to head of product, across three company stages.
02
Check decision rights
See which role is accountable for each decision, and where PM, PO and TPM overlap.
03
Size the team
Enter your engineer count, what you build and how specialised the domain is, and see the product org it implies, with every ratio's source graded.
Role
Stage
Product Analyst
IC, analyst – senior analyst · Growth (B–D)
Archetype
Evidence engine
Scope
Squad
Typical experience
2–4 years
Turns data and requirements into decisions the squad can act on: metrics, analyses, user stories and acceptance criteria. Product works, the org does not yet. Balanced profile.
6
8
Specs22%
Backlog14%
6
Data & tests23%
Failure mode. Becomes a report factory for whoever asks loudest. Point the analysis at one squad's open decisions or it stops changing anything.
Adjust the week
Capacity is fixed at 100%. Raising one activity pulls the others down in proportion, which is the whole argument.
6%2h
8%3h
2%1h
4%2h
22%1.1d
14%6h
6%2h
23%1.2d
3%1h
2%1h
5%2h
0%0h
5%2h
Split of the week
Hover a segment or slider
Expected outcome profile
Change against the benchmark allocation for this role and stage. Relative, not a forecast. Diminishing returns are modelled, so pouring everything into one activity does not max anything.
PO or PM? Technical product manager or technical program manager? Each role and activity the planner uses has a plain-English definition in the glossary.
In this model the product owner owns one squad's backlog: stories, acceptance criteria and sprint scope. The product manager owns an outcome: which problems to solve, which KPI moves, and whether it worked. Many companies combine the two in one person, which works until a PM covers more than one squad.
Both usages are common, which is why the planner models them separately. A technical product manager owns a technical product, such as an API or internal platform, and decides what it should do. A technical program manager owns cross-team execution, meaning dependencies, timelines and risk, and does not decide what gets built.
Published figures range from about 1 PM per 3 engineers to 1 per 20. Practitioner surveys cluster around 5–9 for consumer product squads, enterprise benchmarks run higher, and 2026 hiring data shows AI application companies hiring far more PMs per engineer than infrastructure companies. Product type moves the ratio more than company size.
In specialised or regulated domains, yes, and on AI products they are increasingly essential, because their judgement is the ground truth for evals. The planner gives them ownership of domain correctness and of what a good AI output looks like, while the product manager keeps the success metrics. That split stops one person from writing the exam and grading it too.
It changes the ratio by what you build more than by how you build. 2026 hiring data shows AI application companies hiring about one PM per 2.7 engineers, against one per 7.7 at infrastructure companies, because model behaviour, evals and quality need product judgement every week. AI coding tools make individual tasks faster, but no study yet shows teams needing fewer PMs or designers because of them, so the planner applies no discount for that. Pick what you build in the Team mix view to see the difference.
When cross-squad dependencies no longer fit in one planning conversation: in this model, around ten squads at growth stage or six at enterprise scale. Hiring one earlier usually papers over unclear product ownership rather than fixing it.