Scaling PM Process at Series B: What Needs to Change

At Series B, PM process needs to shift from founder intuition and tribal knowledge toward repeatable, written structures — a defensible prioritization score, a cadenced discovery habit, and explicit decision rights — while keeping cycle times fast. The goal isn't more process; it's process that survives headcount growth without adding approval layers that kill velocity.

Quick Answer: Replace ad hoc judgment calls with three repeatable structures — a scoring framework for prioritization, a documented discovery cadence, and explicit decision rights — before headcount growth makes tribal knowledge impossible to scale. Keep everything else as lightweight as it was at Series A.

Why the Series A Playbook Breaks at Series B

The habits that work at Series A — a single PM (often the founder) making prioritization calls from memory, specs living in Slack threads, and discovery happening in whatever customer call is on the calendar — break down at Series B because the org can no longer fit inside one person's short-term memory.

At ten people, tribal knowledge is a feature: everyone hears everything, so context spreads for free. Growth-stage benchmark data — including OpenView Partners' annual SaaS Benchmarks report — has repeatedly shown headcount roughly doubling in the 12 to 18 months after a Series B close, with product and engineering usually growing fastest. Context that used to spread automatically now has to be deliberately captured, or three new hires build three different mental models of the same roadmap.

The instincts that got a first PM through the earliest days — the ones covered in Prodinja's first-time PM survival guide — don't disappear at Series B. They just stop being sufficient on their own. Melissa Perri's build trap, the pattern of measuring PM success by output shipped rather than outcomes achieved, gets worse as teams scale, because more people shipping without a shared prioritization logic just produces more uncoordinated output.

Marty Cagan's distinction between empowered product teams and feature teams is useful here. A feature team takes requirements from a single decision-maker and executes them; an empowered team owns outcomes and needs process — discovery cadence, prioritization logic, decision rights — to make good calls without asking permission every time. Series B is usually the point where a company needs to become the second kind, on paper as well as in spirit.

What Actually Changes Between Series A and Series B

Between Series A and Series B, five things change at once: headcount, the number of stakeholders with a legitimate opinion, the cost of a wrong prioritization call, the number of concurrent initiatives, and how far a PM sits from the founding conversations that used to carry all the context. Each change independently makes ad hoc process riskier.

The table below lines up the default pattern most teams fall into at Series A against what Series B actually requires — not as a mandate to overhaul everything overnight, but as a map of where the gap is widest.

None of this means Series A habits were wrong — they were correctly scaled to a ten-person team. The mistake is treating them as permanent rather than as a stage-appropriate default with an expiration date tied to headcount and stakeholder count, not to a calendar.

The Four Process Shifts Every Series B PM Needs to Make

Four shifts do most of the work: moving specs from verbal to written, moving prioritization from gut call to a repeatable score, moving discovery from opportunistic to cadenced, and moving decision rights from "ask the founder" to an explicit owner per decision type. Each one is a structure, not a bureaucracy — it should make decisions faster to defend, not slower to reach.

1. From Tribal Knowledge to Written Specs

A one-page written spec — problem, target user, success metric, and explicit non-goals — replaces the Slack thread as the source of truth, because a Slack thread has no version history and nobody can point a new hire at it in month three.

The spec doesn't need to become a 20-page requirements document. It needs to survive a re-read six weeks later by someone who wasn't in the room. At minimum, include:

• Problem statement — what's broken and for whom, in one sentence
• Target user or job — who this is for and what they're trying to accomplish
• Success metric — the single number that tells you it worked
• Non-goals — what's explicitly out of scope, so scope creep has something to point at
• Open questions — what's still unresolved, so it doesn't get silently assumed away

2. From Gut Call to a Repeatable Score

Prioritization stops being defensible the moment more than one person can plausibly claim to speak for the customer — which is exactly what happens once a team grows past the size where everyone sat in on the same conversations. That's why Series B teams need a scoring method that produces the same ranking regardless of who runs the numbers.

Three frameworks cover most of the ground, and they answer different questions:

RICE, popularized by Intercom's product team in a widely-cited 2016 write-up on how it scored its own roadmap, is best for the recurring "what goes in the next sprint" fight. The Kano model — originated by quality researcher Noriaki Kano in 1984 — answers a different question: not "how big is this," but "what kind of value is this," which matters when a team is deciding whether to invest in table-stakes parity versus a genuine differentiator. JTBD opportunity scoring, built on Clayton Christensen's jobs-to-be-done theory, answers a third question entirely: which underlying customer outcome is most underserved, before any specific feature is even on the table.

Using one of these consistently, instead of re-deriving a scoring logic from memory every planning cycle, is what makes a ranking defensible when a stakeholder pushes back on why their pet feature is ranked ninth.

3. From Opportunistic Calls to a Discovery Cadence

Weekly customer contact — the cadence Teresa Torres popularized in Continuous Discovery Habits — turns discovery from a fire-drill activity that only happens before a big launch into a standing input that continuously reweights the backlog.

At Series A, "talking to customers" often means whatever call happened to land on the calendar. At Series B, it needs structure: a standing weekly touchpoint, a shared repository of what was learned, and a method for turning conversations into ranked opportunities rather than isolated anecdotes. Two frameworks make this repeatable instead of ad hoc — mapping the underlying customer job using the approach in Prodinja's complete guide to jobs-to-be-done, and mapping where a customer's emotional highs and lows actually sit using the method in Prodinja's customer journey guide. Both give a growing team a shared vocabulary for what was actually learned, instead of a pile of disconnected call notes.

4. From Founder-as-Arbiter to Explicit Decision Rights

At Series A, the founder is the tiebreaker by default — usually because they're the only one with full context. At Series B, that same habit becomes a bottleneck, and worse, a quiet signal to the rest of the org that the PM's prioritization doesn't actually count.

The fix isn't cutting the founder out. It's making decision rights explicit — a lightweight RACI (Responsible, Accountable, Consulted, Informed) for the handful of decision types that recur: roadmap sequencing, pricing changes, and go/no-go calls on a launch. Prodinja's piece on the founder-PM relationship covers how this renegotiation usually needs to happen explicitly, not by attrition, since founders rarely notice they've become the bottleneck until someone names it.

What Not to Change: Protecting Speed While You Scale

Not everything should get heavier. The size of a spec, the number of approval steps before a small experiment ships, and the freedom to skip a framework for an obviously right call should all stay exactly as lightweight as they were at Series A — because speed is the thing Series B teams most often trade away by accident, not by decision.

A few things worth protecting on purpose:

• A one-page spec ceiling. If a spec regularly runs past one page, the process has drifted toward documentation theater, not clarity.
• A no-framework-required threshold. Small, reversible, low-cost changes don't need a RICE score — reserve scoring for genuinely competing, resource-constrained bets.
• A single approver for small experiments. Multi-person sign-off for a two-day A/B test is the single fastest way to make a team stop running small experiments at all.
• Direct customer access for PMs. Growth-stage orgs sometimes route all customer contact through a research or success team; that severs the discovery loop that makes prioritization defensible in the first place.

Prodinja's guide to building process without killing speed goes deeper on how to tell the difference between process that removes ambiguity and process that just adds a meeting — the distinction that matters most once a team is big enough to no longer notice it's making the trade.

Rolling It Out Without a Mandate: A 30-60-90 Day Approach

New process sticks best when it's introduced incrementally against real decisions already in flight, not announced as a companywide initiative on day one. A 30-60-90 day sequence lets a PM prove each structure earns its keep before asking anyone to adopt the next one.

1. Days 1-30 — Written specs on live work. Convert the next two or three in-flight initiatives to the one-page spec format. Don't retroactively document old decisions; prove the format on what's actually shipping now.
2. Days 31-60 — One scoring framework on the next planning cycle. Introduce RICE (or Kano, if the open question is feature category rather than ranking) for the next roadmap prioritization pass, and show the ranking alongside the reasoning so stakeholders see the logic, not just the output.
3. Days 61-90 — A standing discovery cadence and one explicit decision right. Stand up a weekly customer-contact habit, and negotiate one RACI — usually roadmap sequencing — explicitly with the founder, using the specific decisions that came up in the prior 60 days as the concrete cases to anchor the conversation.

This sequencing also matters if a company is bringing on a second or third PM during this window — Prodinja's guide to a new PM's first 90 days covers how a new hire's ramp-up is faster when they're inheriting a repeatable structure instead of reverse-engineering "how we decide things here" from Slack history.

For a solo or first PM doing all of this without a team to lean on, the hardest part usually isn't picking a framework — it's not having the bandwidth to rebuild one from scratch every planning cycle. Prodinja's Customer Jobs and RICE/Kano tools are built to give exactly that PM a repeatable structure to run ambiguity through, so scoring a backlog or mapping an underserved job doesn't mean reconstructing a framework from memory each time it comes up.

Key Takeaways

• Tribal knowledge stops scaling around Series B, not because the team got worse, but because headcount growth outpaces how fast context can spread informally.
• A one-page written spec — problem, target user, success metric, non-goals — replaces the Slack thread as the durable source of truth.
• Pick one scoring framework and use it consistently: RICE for ranking competing bets, Kano for categorizing value type, JTBD opportunity scoring for finding underserved needs before solutions exist.
• A weekly discovery cadence, not opportunistic customer calls, is what keeps prioritization grounded in real signal as the team grows.
• Decision rights need to be explicit, especially the founder's role, or the org quietly learns that the PM's prioritization doesn't actually decide anything.
• Protect speed on purpose: keep specs short, keep small experiments to a single approver, and reserve heavyweight scoring for genuinely competing bets.
• Roll new process out incrementally against live decisions, proving each structure on real work before asking the team to adopt the next one.