Consus was the Roman god of the grain store. Ceres grew the harvest; Consus guarded it once it was put away. His name likely comes from the Latin verb condere, to store or hide. His altar lay buried beneath the Circus Maximus and was uncovered only for his festival, the Consualia. The lesson is simple: a full grain store feeds no one while it stays sealed.
Product Managers (PMs) in life science tools sit on the equivalent of a grain store. Before launch, you interviewed customers and wrote their needs into the product requirements document (PRD). R&D translated those user requirements into functional requirements, and you watched development verify and validate each one. That harvest is in. However, most of it is still underground, in internal documents such as the PRD and the verification and validation reports.
Your webpage describes the specs, not the needs
The product launch content is usually written from the specification sheet: maximum flow rate, pressure rating, fraction collector capacity. Those numbers are answers, but customers arrive with questions. A lab manager evaluating a chromatography system does not ask for a flow rate. She asks whether her two-step purification can run overnight in the cold room without anyone watching it.
When the product webpage cannot answer, she asks a colleague, a forum or an AI tool instead. Increasingly, it is an AI tool. In a 2026 survey of 150 scientists in biopharma, contract research organizations and diagnostics, 45% use public AI tools through personal accounts, and 81% trust their suggestions only when they can see the evidence behind them (Sapio Sciences via R&D World). The evidence they want already exists: it is the verification and validation data in your development reports. It never reached the product webpage because launch content is built from the spec sheet, and the spec sheet keeps the numbers but drops the needs and the test data behind them.
Content gaps are traceability gaps
You already have a document that keeps all three together. Most development teams keep a traceability matrix that links each need to its requirement and to the test that verified or validated it. The logic comes from Quality Function Deployment, now an international standard (ISO 16355-1:2021), which maps customer needs to the engineering characteristics that meet them. It is the same translation from voice of customer to specification that PMs make in every PRD (From Siren Songs to Specifications).
What the traceability matrix lacks is the last link: the prospect. The decision at stake is which questions your product webpage answers before a prospect goes elsewhere: a competitor's application note or a call to your field application scientist (FAS). Get it wrong and the FAS spends visits answering questions development settled a year ago. Or the prospect shortlists a competitor whose webpage answered them.
Add one column to that traceability matrix: where the prospect finds it. For most research use only (RUO) products, the answer should be the product webpage. For OEM and diagnostics customers, it may be the technical file you send under a confidentiality agreement. This approach helps the PM connect all four links (the need, the requirement, the evidence and the public answer) so the prospect gets the answers they need.
A worked example: a benchtop protein chromatography system
Here is how the dots connect for a benchtop chromatography system for protein purification, 18 months after launch. Every need came from pre-launch customer interviews, and every need was verified in development or validated at alpha sites.
| Need (the scientist's words) | Requirement | Verification or validation evidence | Where the prospect finds the evidence | Fix needed |
|---|---|---|---|---|
| "Run my two-step purification overnight without me." | Automated multi-step methods with column switching | 20 of 20 unattended 14-hour runs completed at alpha sites | Development report only | Publish the evidence |
| "Keep my fractions clean between samples." | Fraction collector delay volume of 50 µL or less | Carryover below 0.1% in verification testing | Spec sheet lists "delay volume: 45 µL" | Explain the number |
| "Protect my protein if a column clogs." | Pre- and post-column pressure sensors with automatic flow reduction | Flow reduced within one second of a pressure alarm | Brochure says "pressure monitoring" | Prove the claim |
| "Use the columns I already own from another vendor." | Standard fittings and an editable column library | 12 third-party columns tested | Test report; field application scientists answer on request | Publish the evidence |
| "A new postdoc can run it within a day." | Method templates and a guided method builder | Alpha users ran their first purification a median of 2.5 hours after installation | Webpage says "intuitive software" | Prove the claim |
| "Run it in our 4°C cold room." | Rated operation from 4 to 30°C | Pressure and flow accuracy within specification at 4°C | Spec sheet lists "4 to 30°C" with no performance data | Explain the number |
| "Meet our data integrity requirements." | Software option with audit trail and electronic signatures | Validation package completed with two pharma alpha sites | Software datasheet, with validation package download | None needed |
| "Sanitize it without taking it apart." | Automated clean-in-place method using 0.5 M sodium hydroxide | 50 sanitization cycles with no seal failures | User manual, behind customer login | Publish the evidence |
Composite example. The Fix needed column shows what it takes to get each answer onto the product webpage.
All eight needs were validated before launch. Here is how much of that evidence a prospect can find on the product webpage today:
- One need appears with its evidence: data integrity.
- Two appear as a number without its meaning: a 45 µL delay volume with no mention of carryover below 0.1%, and "4 to 30°C" with no performance data at 4°C.
- Two appear as a claim without proof: "pressure monitoring" (flow drops within one second of an alarm) and "intuitive software" (first purification in a median of 2.5 hours).
- Three appear nowhere: the overnight run data, the 12 tested third-party columns and the sanitization results. They are still in the grain store.
This example assumes the needs column was written down before launch and is still current. Often neither is true, and that is where synthetic customers earn their place.
Where synthetic customers earn their place
A grounded synthetic customer panel does two jobs in this extended matrix. Grounded means AI personas built from your own win and loss notes and FAS visit reports (why grounding matters).
- Rebuild the needs column when it was never written. Many PRDs jump straight from an R&D lead's notes to specifications. A panel grounded in those notes and reports restates the needs in customers' words, so you can trace them to test data you already hold.
- Refresh it after launch. Needs drift. Every six months, feed the panel what has come in since: new support tickets, FAS visit reports and win and loss notes. Then ask: "What would you need to know before switching from the system you use today?" A new need becomes a new row. If core facilities start asking whether several labs can share the system with separate user accounts and usage logs for chargeback, that row needs a requirement, evidence and a public answer.
Treat the panel's output as a hypothesis. Confirm the top five needs with prospects or existing customers before you rewrite anything.
Run the test on your last launch
With the needs column complete and current, you can run the test. Open the PRD from your most recent launch. For each user need, write down the evidence and where a prospect would find it today. Mark each row with the one fix it needs: publish the evidence, explain the number or prove the claim. Start with the rows marked Publish the evidence. The evidence exists and has passed technical review, so publishing it costs an afternoon of writing, not a new study.
Here is what one fix looks like. Before: "Delay volume: 45 µL." After: "Delay volume 45 µL, so carryover between fractions stays below 0.1%."
Then keep the matrix current. Make the "where the prospect finds it" column a required item at your launch readiness Stage-Gate® and update it at each six-month post-launch review.
Open the grain store
Consus guarded the harvest, but it fed Rome only when the store was opened. Your needs analysis is that harvest: validated, verified and filed in the PRD and test reports while the product webpage lists specifications. Only the PM knows what is in the store, so only the PM can decide what to bring out first.
It's not about what we want to say. It's what they need to hear, and the evidence is at your fingertips.
Frequently asked questions
Marketing owns the webpage. Isn't this their job?
Marketing owns the words; you own the link between need and evidence. Hand them the matrix and let them write the copy, starting with the Publish the evidence rows as a short "Will it work in my lab?" section. Before you hand it over, ask your development lead to sign off on publishing the test conditions, because published data needs the same technical review as any claim. In the chromatography example, the column list, the overnight run data and the sanitization results then take an afternoon to write up.
Our PRD lists specifications, not user needs. Where do I start?
Work backward from the specifications. For each one, ask the synthetic panel what problem a scientist would need it to solve, then check those needs against five recent FAS visit reports. Where the panel and the reports agree, write the need down. Where they disagree, the reports win.
What if some evidence is confidential or unflattering?
Publish the conditions, not the raw report: which columns were tested and how long the unattended runs lasted. If you stay silent, someone else explains your product. An October 2026 analysis of more than 200,000 AI answers found 86% of citations came from sources outside the brand's own website (LEOPRD via B&T).
