Aeneas had waited seven years for a sign telling him to move. When it finally came, he didn't wait for a second one.
In Virgil's epic poem the Aeneid, drawn from Roman mythology, Aeneas lingers in Carthage with Queen Dido, having set aside his fated mission to found Rome. Jupiter notices the delay and sends Mercury down with a single, direct order: leave, now. Aeneas doesn't deliberate or wait for the warning to repeat. He orders the fleet to get ready that same day and is gone before Dido even learns why.
The rest of his story runs on patience; seven years of wandering and setbacks define him as much as any victory does. This moment is the exception: a warning severe enough to override it. Product managers (PMs) get a version of the same warning sometimes, just from a support ticket instead of a mythological god.
The problem: every early signal feels like it needs an answer today
I've lived the other version of this. Years ago, launching an ELISA-based assay, the team was already deep into the next product by week six. The early field reports, a lot-to-lot variability complaint here, a protocol question there, went to whoever happened to pick up the support ticket that week, which made it difficult to notice a pattern. That's not because anyone chose to ignore it. The PM owned it, and yet also had to pay attention to the next several products on the roadmap.
That's the trap. When a complaint arrives, there's no way to tell yet whether it's a one-off or the start of a real pattern. Treat every signal like an emergency and you burn a development cycle chasing noise. Treat every signal like it can wait for confirmation and you miss the one that couldn't.
The framework: patience with one named exception
Robert Cooper's Stage-Gate® model treats the period after launch as active monitoring against a fixed review cadence, typically 30, 60, and 90 days for a reagent or kit with a fast turnover cycle; considerably longer for an instrument or platform with a longer sales cycle and slower adoption curve, then quarterly after that. That cadence exists precisely to stop the loudest single voice from deciding the roadmap before the evidence is in.
The Stage-Gate model formalizes as a source of accountability, comparing actual results against original projections and gathering direct customer feedback after launch. And equally important, the post-launch review serves as a mechanism for continuous improvement of the process. In practice, running that review well means answering five questions.
The split matters because these two categories carry different risks of misreading. Internal checks draw on data the business already owns, sales figures, technical specs, whether a milestone was hit, so getting them right is mostly a matter of pulling the numbers and running a thorough analysis. External checks are noisier by nature: a satisfaction complaint or a lost account could be a real signal or could be one unhappy customer having a bad week, and that ambiguity is exactly the kind of judgment call this post's whole framework exists to help make. The internal questions are rarely where a business gets fooled. The external ones could be.
| Internal, checked against the company's own data: | External, checked against the market: |
|---|---|
| Is the product performing against its technical requirements? | Are customers satisfied/delighted? (Cooper) |
| Is the business tracking against its original business case projections? (Cooper) | How does the competitive position look? |
| What should the next generation inherit? |
Two of these deserve their own anchor, since it's easy to list them in a table and move on without ever coming back to them. "What should the next generation inherit" means capturing specific design decisions before anyone forgets why they mattered, the retest interval that turned out too conservative gets carried forward as-is, the seal material that wore early gets flagged for revision on the next platform, not rediscovered from scratch two years later. "How does the competitive position look" means checking whether a competitor's move since launch has quietly eroded the advantage the original business case assumed, a rival closing the exact gap your platform was built to exploit is a different kind of signal than a customer complaint, and it needs its own look during the review, not just a line item that gets nodded at and skipped.
Here's the case for patience…. A company launched a high-throughput sample preparation instrument platform and started tracking early adoption. Three sites reported a cartridge seal wearing out faster than expected, but only under sustained, multi-shift use, a duty cycle the original verification testing hadn't covered at that intensity. One data point like that isn't R&D's problem to sit with alone. While engineering checks whether the wear rate is a real defect or a one-off, the PM's job is what the three affected accounts experience in the meantime: are they told anything, is Sales prepared if a fourth site calls, and does the answer stay the same no matter what engineering eventually finds. Patience with the technical verdict is right when the worst case is already known and limited, a consumable wearing out faster than planned. Losing sight of the customer while that verdict gets sorted out is a mistake, no matter how the technical question resolves.
But patience has a named exception, and it isn't about frequency at all. It's about severity. If that same seal failure carried any risk to sample integrity or user safety, waiting for a second confirmed account stops being caution and becomes the actual risk. A single report of a severity-class failure doesn't get the thirty-day cadence. It gets escalated the day it's logged, evaluated against a different, faster clock, and the resulting decision gets made with n=1 as sufficient evidence, not as a placeholder for evidence still to come.
The same discipline applies to a commercial pattern, not just a technical one. Two territory losses attributed to price by a rep who genuinely believes it deserves a second look before it changes anything downstream, precisely because a single attributed cause, especially one as convenient as price, is the kind of signal easiest to accept without checking. The frequency clock runs on that one. Severity doesn't apply, there's no safety exposure in a pricing objection, so the patience side of the rule holds without exception here.
Here's the pushback worth taking seriously: what stops a team from citing "still gathering evidence" every review cycle, indefinitely, on a decision nobody actually wants to make? It would, if severity didn't force a faster decision when the stakes are high enough to justify one. The fix isn't infinite patience. It's a deadline, one review cycle, after which "still gathering evidence" automatically converts into a decision made with whatever evidence exists. Patience needs a deadline, or it's not patience, it's avoidance with better branding. Patience with a clock, and a named exception for anything severe enough to skip the clock entirely, is a defensible standard a team can actually run.
The takeaway
Aeneas spent seven years proving patience was the right default response. The one time Mercury appeared with a direct order, he didn't deliberate, because some warnings aren't asking for patience, they're telling you the window for it already closed. Post-launch review works the same way. Most signals deserve the full cadence before they change anything. The signals that carry real severity don't get that grace, and knowing which is which, before the evidence forces the answer on you, is the actual job.
