The Romans had two words for turning. Antevorta meant turned toward what is coming. Postvorta meant turned toward what has been. Both come from the verb vertere, to turn, which is still working in our language today, for example convert, revert, invert and version. It is why we talk about a product version at all, and why a post-mortem looks backward while a forecast looks ahead.
Roman prophecy needed both turns at once. Seeing only forward was guessing while seeing only backward was record keeping. Authority came from holding the two views together and knowing which way you were facing before decisions needed to be made.
Product managers (PMs) have the same pair of views. We turn backward in the post-mortem, when the launch is over. We turn forward in the forecast. The earliest place to do both is the problem statement and the goal statement, at the start of the Product Requirements Document (PRD), before anyone has committed a budget.
The uncomfortable sentence in a line extension PRD
For a line extension, the problem statement has to describe the customer's world with your current product still in it. That is the sentence teams skip, because writing it means documenting where what you already sell does not reach the customer's newer application.
Whether a project is truly a line extension is its own question (how that classification gets made too early). Once that call is made, the goal and problem statements are due.
Those two statements are what a Stage-Gate® review is supposed to judge. Robert Cooper built the Stage-Gate system around one idea: each Stage-Gate review is a go or kill decision, made against criteria, by people willing to kill a project. Line extensions rarely get that Stage-Gate review. They get a light version of it or may be an agile version, because everything about a line extension feels already decided.
For example, a key account asked for a different conjugated version of an antibody clone that was licensed exclusively, one that is well cited for western blotting and ELISA. The Stage-Gate review takes twenty minutes and questions go to price and pack size. What is genuinely new is the conjugation and purification process, how the conjugated antibody performs in an application it was never validated for, such as spatial biology, and how a segment that has never bought from us evaluates the product. Those factors are often skipped, because the Stage-Gate review focuses on the part everyone already knows: the antibody clone.
Six months later, validation runs long, so the team launches with data from the key account's tissue type only. Free samples go out to fill the gap, but without a problem statement nobody knows which labs should get them or what result would convince those labs. The data prove the claim for a few labs, and reorders are slow, because the launch answered the key account's question rather than the market's.
The two turns, side by side
What that twenty-minute Stage-Gate review lacked was two sentences, one looking back at the customer and one looking forward. The problem statement is the backward turn: it describes what the customer already lives with, which you can only learn by looking at what they do today. The goal statement is the forward turn: it describes a state that does not exist yet, in terms the customer could check once it does.
| Problem statement Postvorta, the backward turn |
Goal statement Antevorta, the forward turn |
|
|---|---|---|
| What it answers | What does this customer lose today, with the product we already sell? | What changes for them, in terms they could check themselves? |
| Built from | Application, loss, cost of doing nothing, current workaround | Baseline, target, and how the customer would verify it |
| It fails when | Your product name, format or feature appears in it | A competitor’s spec sheet would satisfy it too |
| At the Stage-Gate review, ask | Did this come from observing customers, or from what one account asked for? | Would everyone in the room agree on what result means we missed? |
| In development, ask | Does this change who the customer is, or what they lose? | Does this change what the customer can verify? |
| Prior to product launch, ask | Does the claim in the datasheet trace to the loss we documented in the problem statement? | Can the customer verify what this campaign promises? |
The last row is the one that pays you back: when the datasheet claims labs can skip labeling and validating the antibody themselves, that claim traces to the loss you documented, and the application team knows which experiment it has to run for the application note.
The turn backward
A problem statement describes the customer's world without your new product: who they are, what they lose today, and what it costs them to do nothing. For a line extension, that world contains your current product.
The problem statement is a different description from the concept statement. A concept statement gets you permission to investigate. A problem statement contains the conclusions from that investigation: the pain points that exist today. It is the customer evidence the Stage-Gate decision rests on.
An example problem statement:
Translational biology labs building spatial biology panels need every antibody in the panel to carry its own label, because all the markers are imaged together on one tissue section. Today they cannot use the antibody they trust for this target, because the clone is only sold unconjugated. They either label and validate it themselves, which costs weeks of technician time and irreplaceable tissue, or they buy a validated conjugate of a different clone from another supplier and lose comparability with the western blot and ELISA data they already have. Some leave the target out of the panel.
One test keeps a problem statement honest: read it and see whether your product, format or feature appears as the answer. If it does, you have written a solution and skipped the backward turn. The unconjugated antibody appears above only as part of what the customer copes with today.
The turn forward
A goal statement describes the change your new product or line extension commits to making in that world, in terms the customer could check. Not what you will build. What will be different for them, and how they would know.
An example goal statement:
Translational biology labs can add the antibody clone they already trust for this target to their spatial biology panel, so the tissue data are directly comparable with the western blot and ELISA results they already have from that clone, without the weeks they now spend labeling and validating it themselves.
The answers to two questions determine whether the goal statement has the right nuance. Would the customer recognize that as their win? And could a competitor's spec sheet satisfy it too? A specification any supplier can print is not a goal. A result the customer can verify in their own hands is. In this example, any supplier can ship a validated conjugate against this target. Only the exclusively licensed clone keeps the new spatial data comparable with years of existing results. Without an exclusive clone, look for what else only you can deliver, such as lot-to-lot consistency data that spans years of the customer's own experiments.
Three standards are worth applying to pressure-test the goal statement:
- Falsifiable: Itamar Gilad asks whether the goal could be proven wrong.
- Specific: Teresa Torres asks whether it names a specific segment and a specific unmet need.
- Echo: Melissa Perri asks whether it is a customer outcome or a roadmap item in disguise.
Then add Clayton Christensen's question, because a statement can pass all three and still be a spec: what is the customer hiring this product to do? In the above example, the customers are hiring it to see this target in tissue, in the same terms as the results they already trust.
Once both the goal and problem statements hold, they convert into requirements you can prove wrong, which is where the user requirements specification work begins.
Why this matters
I have been in the PM's shoes and wrote the light version of the PRD, and regretted the launch materials that resulted. The product positioning and value proposition were not as solid. The application note missed out on proving some key points.
Especially for a line extension, the value of the goal and problem statements is in how one is a reality check for the other. And equally important, the problem statement becomes a reality check for the marketing messages and sales tools going forward.
Your customers have already written the backward turn for you: in the workarounds they built around your current product. Ask and observe those first, and the forward turn writes itself.
Frequently asked questions
Sales already promised this product to a key account. How do I write a problem statement without looking like I am blocking the deal?
You are protecting the deal. Ask the account manager for thirty minutes with the customers (end users, and lab manager) who requested it, and write the statement from what those personas describe. If they say they had to drop a target from their panel, you now have a goal Sales can repeat and R&D can validate against. That is a stronger position than a promise nobody can test.
Does a problem statement for a product line extension admit our current product falls short?
Your product does its original job. However, the customer's application may have moved or the competitive situation may have changed or valuable insights came through technical or service support. Write about their new experiment rather than your old product's limits, and leadership reads it as an opportunity rather than a criticism.
How specific does the problem statement need to be before the Stage-Gate review?
Specific enough that someone outside the project can name the customer, the application and the loss after reading it once. Vague statements may survive the Stage-Gate review and then fail later, because every function fills the gaps with its own version of the customer. If you cannot yet say which application the customer is running, you likely need to go back into the field and speak with customers or watch them using the product (ethnography).
