Product: What Exactly Are We Building?

It is a Tuesday, and Sofia has two documents open on one screen. The first is Daniel’s mandate: reduce churn from 18% back toward 9%. The second is Omar’s envelope: this much money, this minimum acceptable result, and a warning not to design something expensive to keep alive. Between those two documents and a working product sits her entire job.

By Friday, six people will have asked her to add just one thing. Sales wants an executive dashboard, marketing wants automated emails, and someone in leadership has seen a competitor demo real-time scoring. Each request is small and defensible. The fate of a 26-week project depends almost entirely on how often Sofia says no, and whether she writes the noes down.

What lands on Sofia’s desk

Daniel set the direction in module 2: churn is the priority, and the money follows it. Omar priced it in module 3, converting that ambition into a spending limit and a minimum churn reduction. Crucially, his envelope covers not just building the thing but keeping it running — a constraint that will quietly settle an argument about real-time scoring.

What has not been decided is anything you could hand to a builder. Nobody has said which customers the system watches, what it shows, where, or who acts on it — and nobody downstream can start until Sofia does.

What a product manager actually does

Executives describe outcomes; engineers build systems; between those two languages sits a gap that swallows unstated assumptions and features nobody needed built beautifully. Sofia closes it with one document — a PRD — saying what is being built, for whom, what “working” means, and what is explicitly not being built. She decides the boundary, then defends it for 26 weeks against people who each want to move it slightly.

The software on Sofia’s desk

Every tool on this desk is a device for having an argument before it gets expensive. Miro — an online whiteboard — is where Sofia maps what a customer success rep actually does on a Monday morning, because a feature that does not fit inside that morning will not be used however good it is. Figma turns the idea into a picture of the screen, and a picture can be rejected in an hour where a built product takes a quarter.

Confluence holds the requirements document itself, and it matters that it is a shared page rather than an email: the definitions written there — what counts as churn, what an alert must contain — are the ones the analyst, the data scientist and the engineers will all reuse. Then Jira breaks the agreed thing into tickets, each small enough to be owned and finished, which is also how scope creep becomes visible: new tickets appear, and the backlog stops fitting the sprint.

The three decisions Sofia makes this fortnight

One: which language is this sentence written in?

Sofia sorts every statement she has been given into five layers, because mixing them up is the commonest way a requirements document goes wrong.

A business goal is what the organisation wants to be true: cut annual churn from 18% toward 9%, or protect $2m of recurring revenue this year. Goals contain no implementation; they are why the project is funded.

A user need is what a specific person is trying to accomplish, described from inside their week: as a customer success manager, I need to know which renewals to spend my limited hours on. A need does not mention software.

A product feature is the thing that exists because of the need: a daily ranked list of at-risk accounts, with the top reason beside each. This is the first layer you could draw.

A technical requirement is a condition the built thing must satisfy: scores must land inside the CS platform the team already uses, and refresh within 24 hours of new usage data arriving. These constrain how it is built, not what it does.

A metric is how you will know: percentage of flagged accounts still customers 90 days later. It belongs to whoever is later asked whether this worked.

The test Sofia uses takes four seconds: ask who would act on the sentence. The board acts on goals. A user acts on needs. A builder acts on features and technical requirements. An analyst acts on metrics. If two people would read the same sentence and act differently, it is written at the wrong layer and needs splitting.

Two: where the MVP line goes — and what is on the other side of it

Minimum viable product is one of the most abused phrases in business, routinely taken to mean a rough draft of the whole roadmap — everything present, nothing finished. It means the opposite: the smallest complete loop of value, small enough to ship and honest enough to teach you whether the idea works.

Sofia finds the loop by asking what must be true for a single customer to be saved. Something must score the accounts, a human must be given a reason they can act on, that human must be able to act, and the system must record what they did. Anything outside that loop waits for a later release, however good it is.

So four things go in: the daily ranked list inside the CS platform, a top-reason explanation beside every account, one-click intervention logging, and a weekly email digest of newly high-risk accounts. The logging is the one people question and the one Sofia will not trade — it is the only reason Nadia can measure anything in module 12.

The refusals are more interesting. Real-time scoring goes because churn moves over weeks — leavers’ logins start sliding roughly 10 weeks before they cancel — so a score updating within seconds tells you nothing a nightly one does not, while roughly tripling the infrastructure cost that Omar’s envelope has to carry. Automated retention emails go on two grounds: governance would stop them, and they remove the one person with the context to know that Hale & Porter’s August dip is a law firm on court recess, not a customer walking away. A win-back module for already-cancelled customers goes because it is a different product wearing similar clothes — different data, different audience — and would eat half the envelope.

Those refusals get a page of their own, with reasons — the most valuable page in the document, because it is the only part still working for Sofia in month four, when someone reopens the emails question and she can point at a sentence instead of re-fighting the argument.

Three: which signals the system is allowed to watch

The last decision looks the most technical and has the longest reach. Sofia names four behaviours the system will watch: falling login frequency, dropping core-feature usage, unused licensed seats, and failed or late payments. She rejects marketing email open rates and customer social media activity.

The principle separating the two lists is leading versus lagging. A lagging signal moves with the outcome or after it — a cancellation notice predicts churn perfectly and is useless, because by the time it arrives there is nothing to do. A leading signal changes before the customer decides. Every signal Sofia keeps must pass two tests, both yes: does it move before the decision, and can we act on it when it does? Juniper Health has two failed payments and 12 of 50 seats ever used — early, visible now, pointing at an obvious conversation.

Email open rates fail more subtly: measurable, good for a chart, almost no help in predicting whether a business renews a $24k contract. Social media activity fails on every axis — trendy, invasive, and something Elena in governance would strike out anyway. Interesting-but-late and measurable-but-inert are the two failure modes, and both are seductive because both produce numbers. Support tickets were the hardest cut — Corvex Manufacturing’s 23 tickets since March are exactly the signal Sofia wants — so she notes them as first reserve.

Then the fact that makes this decision so heavy. Priya, the data scientist in module 8, can only build a model from signals somebody chose to collect. A behaviour nobody instrumented in month one is not a weak or expensive feature in month five; it is an absence. Sofia is not choosing four metrics. She is writing the vocabulary Priya is allowed to think in, months before anyone opens a modelling tool.

Where this goes wrong

The first is requirements written as solutions. A PRD full of sentences like “build a dashboard with drill-downs” reads as admirably concrete — concrete about the wrong layer. The team delivers exactly what was asked and nobody’s behaviour changes, because no user need was written down to check it against.

The second is an MVP that is secretly the entire roadmap. Everyone agrees to be minimal in principle, each stakeholder protects one exception, and the “first release” becomes 14 features across three teams. The signature is a missing or empty out-of-scope page: a document with nothing on its refusal list has not made decisions, it has written the wishes down neatly.

What Sofia hands on

The deliverable is the PRD: MVP scope with acceptance criteria, four early-warning indicators, an explicit out-of-scope list, and metric definitions everyone downstream must reuse rather than reinvent. It goes to two desks at once. To Maya, the Customer Success Lead in module 5, it carries a definition she must test against reality — an actionable alert means account, risk level, top reason, suggested next step — and a request to label a sample of accounts. To Ben, the Data Analyst in module 6, it carries the same definitions and signals, so what he measures in the history matches what the product watches in future.

Sofia’s covering note to both is short: Before anyone models anything — Maya, tell us what churn actually looks like from the front line. Ben, tell us what the data says. Same definitions, please.

What they inherit is a vocabulary: four signals, one loop, one definition of “at risk”, one out-of-scope list. Everyone after this desk builds inside those lines, mostly without asking who drew them.

Spot the decision

Read each situation and decide what a product manager should do, then tap a card to flip it and check.