Before there were product roadmaps, there was the ship Argo.
In Greek mythology, Jason learns that reclaiming his throne requires more than political manoeuvring. The Oracle tells him he must sail to the edge of the known world and retrieve the Golden Fleece from Colchis. The Fleece is not merely a trophy. It represents legitimacy, long-term security, and proof that Jason and his crew can accomplish something hard that others have failed to do.
Jason assembles a crew of specialists called the Argonauts. These are not random sailors. Orpheus brings music that can calm storms and lull monsters. Atalanta brings speed and precision. Heracles brings raw strength. Each crew member serves a defined purpose. They set out together toward a clear destination, across unknown waters, with limited supplies and no guarantee of success.
On paper, the mission is simple: sail from A to B, retrieve the Fleece, return home. In reality, the journey looks remarkably like a 12-18 month product roadmap in a life science tools company. There is always another island that looks interesting. Every stop involves tradeoffs in time, risk, and resources. The Sirens sing of urgent customer requests. The Clashing Rocks threaten anyone who hesitates too long on a decision. And if you say yes to every side quest, you never reach Colchis.
The problem is not planning 12-18 months out. The problem is treating that roadmap as a fixed contract while letting short-term noise crowd out long-term bets. Research suggests that companies with clear strategic roadmaps are significantly more likely to outperform their competitors, yet most Product Managers (PMs) report spending the majority of their time on reactive work rather than strategic initiatives. Your roadmap deserves better.
Below are three common traps PMs fall into, and ways to navigate past them.
When the Argonauts sailed past the Sirens, those creatures did not sing of danger. They sang of knowledge, of glory, of exactly what each sailor wanted most to hear. Orpheus saved the crew by playing his lyre louder than the Sirens could sing, giving the Argonauts something better to focus on.
In life science tools companies, the Sirens take a different form. They sound like this: "Could we support this exact tissue type for one pharma customer?" Or: "Our KOL (key opinion leader) wants this custom construct, it should be quick." Or: "This prospect will switch if we add two more markers to the panel." None of these requests sound harmful by themselves. Each one promises immediate reward. There are at least two dangers: (1) what they do to your portfolio when you listen to all of them and (2) should you build a product based on one customer's input.
A healthy roadmap spreads work across three horizons. Horizon 1 captures near-term improvements that many customers want, usually lower risk and faster to ship. Horizon 2 covers new workflows, new use cases, or adjacent segments that build on your current platform. Horizon 3 holds bigger moves like new product lines, new business models, or novel scientific capabilities. Horizon 1 keeps revenue and trust moving. Horizons 2 and 3 are where future growth and real differentiation live.
When every custom request floods into Horizon 1, the portfolio gets out of balance. Two things happen. First, Horizon 1 fills up with tiny, often narrow fixes. Second, Horizons 2 and 3 quietly shrink until they are practically empty. You are busy, but not really moving toward a "Golden Fleece outcome" for any specific customer segment. You have listened to every Siren, and now you are shipwrecked on a dozen different rocks.
You know you are in this trap when roadmap conversations start with "who asked for this" rather than "what problem are we solving," when most items are minor tweaks to existing products rather than meaningful new capabilities, or when R&D spends most of their time on one-off variants while competitors ship clearer platforms.
Like Orpheus, you need something better to focus on than the noise. Start by writing your 12-18 month view as a short list of problem statements, each tied to an ICP and horizon. For example: "Reduce friction in standard co-culture assays for immuno-oncology teams" belongs in Horizon 1. "Give CROs earlier, richer functional readouts from complex models" belongs in Horizon 2. "Create a new way to observe cell-to-cell communication in near real time" belongs in Horizon 3. Every idea must earn a spot by answering two questions: which ICP problem does this address, and which horizon does it belong in?
Next, define what qualifies for Horizon 1. Make a simple rule: Horizon 1 changes must address patterns across customers, not one-off needs. Strategic design partners can be exceptions, but exceptions should be rare and intentional. This keeps Horizon 1 focused on broadly valuable improvements rather than a grab bag of custom fixes.
Finally, keep your idea backlog separate from your roadmap. The backlog is where every idea and request lands. The roadmap is the limited set that earned a place across horizons. That separation gives you a clean way to say "yes, we heard you" without promising "yes, it is on the roadmap." The Sirens are still singing. You are just playing better music.
Avoiding the Sirens is one challenge. Knowing which charts to trust is another. The Argonauts had maps, but those maps were imperfect. They showed where others believed land existed, not necessarily where it actually was. The crew used the charts as guides while remaining alert to what the sea itself revealed. They understood that a chart is a hypothesis, not a promise.
A 12-18 month roadmap is meant to align your teams internally. Trouble starts when it becomes a promise to the outside world. This happens frequently in companies with broad portfolios of, for example, pathway antibody families, ready-to-use cell signalling kits, and luminescent or fluorescent reporter assays.
Picture a company that publishes a beautiful pathway map in a catalogue or webinar. Green nodes show currently available antibodies. Yellow nodes show antibodies in development. Orange nodes show planned assay kits coming next year. Inside the company, that map began as a planning view. Outside, it now looks like a commitment.
KOLs start designing studies around those "coming soon" nodes. Distributors tell customers they will be able to buy certain kits by Q4. Then a phospho-specific antibody fails validation and gets cancelled. A planned multi-target kit proves too noisy and must be redesigned. Operations raises red flags about supplying the full expansion. Suddenly you appear unreliable, even though the scientific decisions were sound. Your customers accept that not every antibody validates and not every kit behaves in every system. What frustrates them is when internal hypotheses are presented as external guarantees.
Use separate labels for "exploring" and "committed" work. Committed items cover the next one to two quarters and move forward only after R&D, QA, and operations agree the scope and timing are realistic. Everything else stays in exploring mode, organised by 12-18 month themes rather than promised delivery dates.
When speaking about distant work, talk about outcomes rather than SKUs. Instead of promising antibodies to every pathway node by Q4, say you are investing to give customers more complete pathway coverage with matched total and phospho pairs where they matter most. Same direction, less false precision.
Detailed, dated items belong in internal roadmaps and NDA conversations. Public catalogues and website sections should stay close to launches that are genuinely locked. A useful rule: if you would be very uncomfortable cutting or delaying something, be careful about presenting it externally as fixed.
Even with clear priorities and honest external communication, there is a third constraint that kills roadmaps: capacity. The Argo was a marvel of engineering, but it had limits. It could carry only so many Argonauts, so many supplies, so much weight before it became slow and unwieldy. Jason understood that the ship's capacity was a constraint to be respected, not a problem to be ignored.
On a slide, an 18-month plan with many launches looks inspiring. In practice, every new addition has hidden costs. There is validation, documentation, and training for each new SKU. There are more branches in inventory and forecasting. There are more troubleshooting scenarios for support and field application teams. There is old code, old scripts, and "temporary" workarounds that never get retired. When you ignore capacity and accumulated technical debt, the roadmap turns into a fantasy novel. Teams work late. Dates slip. Future development speed falls.
The symptoms are easy to spot. Engineers complain that every new feature takes longer than it should because they are working around legacy systems. Quality issues creep in because validation is rushed. The team is perpetually behind schedule despite working harder than ever.
Plan from real capacity. Sit with R&D, applications, QA, and operations and agree on a rough number of medium and large items per quarter. It does not need to be perfect. You just need a shared ceiling that everyone respects. When someone wants to add something new, the question becomes "what are we removing to make room" rather than "how can we squeeze this in."
Put platform and technical debt work on the roadmap explicitly. Roadmaps should include items like "harden analysis pipeline for higher throughput" or "consolidate legacy data formats." When these are visible, they can be prioritised and protected. When they are invisible, they always lose to something shinier.
Use a "stop, start, continue" review each quarter. Do not only ask what else you can add. Ask what you will stop or pause to free capacity. Ask what you will continue because it is clearly working. Ask which new bets have earned a spot and which stay in the backlog. This keeps the roadmap honest and breathable.
A healthy roadmap for life science tools has three characteristics. First, it balances work deliberately across Horizons 1, 2, and 3, with clear problem statements tied to specific customer segments. Second, it distinguishes between committed work for the next one to two quarters and exploratory themes for the 12-18 month horizon. Third, it respects team capacity by including platform work and using quarterly reviews to adjust rather than defend the plan.
This is how the Argonauts navigated. They knew their destination. They understood their constraints. They adapted their route when conditions changed. Your roadmap should do the same.
Jason's voyage succeeded because he maintained a clear destination, assembled a crew with defined roles, and cultivated the discipline to say "we cannot stop everywhere and still reach Colchis." Your job as PM follows the same logic. You need a framework to hear every voice without letting every voice steer the ship. That is what these three horizons provide: a way to organise incoming requests, protect long-term bets, and keep your team pointed at outcomes that actually matter.
Be the captain who knows when to explore a new bay and when to sail past it.