How do you build a bull case for a new product line in 2027?
PULSEKNOWLEDGE LIBRARY
A bull case for a new product line is a written, falsifiable argument that a specific customer segment will pay a specific price for a specific outcome, at volumes your existing motion can reach. Build it from bottom-up demand evidence, unit economics, and named leading indicators — then state exactly what would prove it wrong.
What a bull case actually is and why it matters in 2027
A bull case is not optimism. It is the strongest *defensible* version of the upside, written down with its assumptions exposed so that other people can attack them. The distinction matters because most new product line proposals die of one of two opposite failures: they are either a slide of hockey-stick projections with no underlying logic, or they are so hedged that nobody can tell what the company is actually being asked to believe.
The useful working definition: a bull case is a chain of claims, each one testable, that ends in a revenue number. "There are roughly N accounts in our installed base with characteristic X. Our win rate on adjacent expansion offers has historically run in the 20-35% band. At a list price of P with typical discounting of 10-20%, the reachable first-year figure is somewhere between A and B." Every clause in that chain is something a skeptic can check. That is what makes it a case rather than a wish.
Why this is sharper in 2027 than it was five years ago comes down to three shifts. First, capital discipline stuck. The 2022-2024 correction did not fully reverse; boards that got used to asking "what is the payback period" kept asking. A new product line now competes for funding against buybacks, against paying down debt, and against the safest option of all — doing nothing and protecting margin. Second, buyer consolidation is real. Procurement functions at mid-market and enterprise buyers have spent several years cutting tool sprawl, which means a new product line has to either displace something or attach to a renewal you already control. Third, the AI wave has compressed the credibility of feature-level differentiation. Claiming "we have a model-powered X" is not a bull case, because so does everyone; the case has to rest on distribution, data, workflow lock-in, or economics that a competitor cannot copy in two quarters.
There is also an internal reason to write one properly. A new product line consumes the scarcest thing a company has, which is attention. Engineering attention, but more importantly go-to-market attention — the same reps, the same marketing calendar, the same customer success capacity. RevOps sits at the center of that tension because it owns the quota model, the territory design, the CRM object structure, and the forecast that the new line will distort. If the bull case is not built with RevOps in the room, it will produce a number that the field cannot physically deliver, and the shortfall will be blamed on execution rather than on arithmetic that was wrong at the start.

The bull case also has a companion obligation. You write the bull case, and then you write the bear case with the same rigor, and you name the observable events that would move you from one to the other. A bull case without a stated kill condition is marketing. A bull case with one is a decision instrument. The single most valuable sentence in the whole document is usually the one that begins "we will stop if, by month nine, we have not seen…"
The step-by-step process for building the case
The sequence matters. Most teams build the case backwards — they start with a market size and work down, which produces a number nobody believes and which cannot be audited. Build it bottom-up instead, so every layer is grounded in something you already measure.
Step one: write the demand hypothesis as a single sentence. Name the buyer by role, the pain by symptom, the current workaround, and the trigger event. "VP of Field Operations at 200-1000 employee HVAC contractors, who currently reconcile technician revenue in spreadsheets, and who feel it acutely when they add a second branch." If you cannot compress it to one sentence, you do not have a hypothesis, you have a category.
Step two: gather bottom-up demand evidence before you build a model. This is the step teams skip and it is the one that decides whether the case is real. Sources in rough order of signal strength: lost-deal reasons in your own CRM where prospects asked for the capability; support and success tickets requesting it; win/loss interview transcripts; the actual number of customers who have built a workaround; competitive displacement notes; and only then, third-party analyst sizing. Twenty-five structured customer conversations will teach you more than any market report. Record how many of those conversations produced an unprompted mention of the pain versus a prompted "would you want this" — the prompted yes is nearly worthless, because people agree to hypothetical features at very high rates.
Step three: build the segment and the reachable base. Split total addressable into three concentric rings. Ring one is your own installed base that fits the segment definition — you can count this exactly from CRM, so there is no estimating. Ring two is your addressable-but-not-customer set, reachable through your existing channels. Ring three is everyone else, which requires new distribution and should carry a heavy discount in the model. Most credible first-year bull cases live almost entirely in ring one.

Step four: price it against the alternative, not against your cost. Establish what the buyer spends today on the workaround — hours of labor, a point tool, an agency, or the cost of the errors. Price as a fraction of that number. Then run a willingness-to-pay check in live conversations, not surveys.
Step five: model the funnel with your own conversion rates, degraded. Take your existing rates and apply a haircut, because a new line always converts worse at first. A reasonable starting posture is 60-75% of your baseline win rate and 1.3-1.6x your baseline sales cycle for the first two or three quarters, improving as enablement and references accumulate.
Step six: cost the whole load, not just engineering. Include go-to-market, support, and the opportunity cost of the reps' time.
Step seven: name the leading indicators and the review gates. Pick three to five metrics observable well before revenue.

Step eight: write the bear case and the kill conditions. Then circulate both together.
The output of this sequence is short. A strong bull case is typically five to eight pages plus a model: one page of hypothesis and evidence, two pages of segment and pricing, two pages of financials, one page of risks and kill conditions, one page of the operating plan for the first two quarters. Anything longer is usually hiding a weak link under volume.
Costs, timelines, and the ranges to plan against
Ranges here are directional planning anchors, not benchmarks — your own historical data always beats a generic figure, and the point of stating a range is to force the conversation about which end of it you are assuming and why.
The case-building effort itself. Building a rigorous case for a new product line is typically four to eight weeks of part-time work from a small cross-functional group: a product lead, a finance partner, a RevOps analyst, and someone from sales who actually carries a bag. Compressing it below three weeks usually means skipping the customer conversations, which is precisely the step that carries the signal. Stretching it past ten weeks usually means the group is trying to resolve uncertainty that can only be resolved by shipping something.

Time to first revenue. For a line sold into your existing base through your existing motion, first paid customers commonly land two to four quarters after the decision to fund. For a line requiring a new buyer persona, a new channel, or a new compliance posture, plan on four to eight quarters and expect the back half of that range. The single biggest driver of the difference is whether the buyer is someone your reps already have a relationship with.
Time to meaningful contribution. "Meaningful" usually means the line is a visible slice of the forecast rather than a rounding error. Two to three years is a common honest answer for a genuinely new line. A case that shows material contribution in year one is almost always either a repackaging of something you already sell — which is fine, but say so — or an assumption error.
Cost structure to model. Build cost is the number everyone quotes and the least reliable one. The costs that get underestimated, roughly in order of how often they are missed:
- *Sales enablement and ramp.* Reps need training, certification, demo environments, objection handling, and reference accounts. Budget real hours, and remember that every hour a rep spends learning the new line is an hour not spent on the line that currently pays the bills.
- *Support and success load.* New products generate disproportionate ticket volume for the first several quarters. If your support team is sized to steady-state ratios, a new line breaks that ratio.
- *RevOps and systems work.* New SKUs, new price books, new CPQ rules, new CRM fields and objects, new order forms, revenue recognition treatment, new dashboards, new territory and quota logic. This is frequently a multi-month workstream on its own and it is almost never in the original estimate.
- *Marketing and content.* A new line needs its own positioning, site pages, case studies, and a demand program. Reusing the existing brand helps but does not eliminate the cost.
- *Opportunity cost of attention.* The hardest to quantify and often the largest. If a rep splits time across two lines, both usually underperform in the transition period.

Unit economics to state explicitly. Name your target gross margin, your customer acquisition cost, your payback period, and your expected retention, and say where each number came from. Say plainly whether the new line's economics are better, worse, or comparable to the core business, because a line with structurally worse margin can still be right — if it defends the core, opens a segment, or raises retention — but that argument has to be made out loud rather than buried.
Attach rate versus standalone. If the line is sold into the existing base as an attach, model the attach rate as a percentage of eligible accounts per quarter and be conservative early. If it is standalone, you are effectively funding a startup inside the company and the timeline and cost assumptions should look like one.
Staged funding. The strongest financial framing is not "fund the line" but "fund stage one." Stage one buys evidence: a small number of design partners, a working slice, and a defined set of learnings. Stage two funds the go-to-market build only if stage one's gates were cleared. This converts a large irreversible bet into a series of smaller reversible ones and dramatically improves the odds that the case survives contact with reality.
Where teams get it wrong
Top-down sizing as the foundation. A large market figure multiplied by a small assumed share is the most common structural error. It is unfalsifiable, so it cannot be argued with, so it teaches nobody anything. The fix is the ring model above: count what you can count, estimate only what you must, and label every estimate.
Confusing interest with demand. Prospects say yes to hypotheticals at very high rates because it costs them nothing. Real signal comes from behavior — a signed letter of intent, a design partner agreement, a deposit, a budget line already allocated, or the observable fact that they built an expensive workaround. Weight your evidence by what it cost the customer to produce.

Assuming the existing motion transfers. "Our reps will just sell it too" is the assumption that kills the most new lines. If the new product has a different buyer, a different cycle length, or a different deal size, it needs different sellers or at minimum different comp treatment. A rep with a large quota on the core product will rationally spend near-zero time on a small new line unless the compensation plan makes it worth their while — and designing that plan without over-rotating is a genuinely hard RevOps problem.
Ignoring cannibalization. If the new line overlaps the existing one, some revenue will move rather than add. Model the substitution explicitly. A line that mostly cannibalizes can still be correct if it defends against a competitor or improves retention, but that needs to be the stated argument rather than a discovery made two quarters in.
No kill conditions. Without pre-committed gates, projects persist on sunk cost. Write the gates before you start and put dates on them.
Single-scenario modeling. One number implies false precision. Present three: a conservative case, an expected case, and the bull case, with the specific assumption differences between them named. Reviewers trust a range far more than a point.

Optimism embedded in the operating plan. Hiring plans, quota assignments, and marketing spend built on the bull case rather than the expected case create a cost structure that only works if everything goes right. Fund to the expected case; keep the bull case as upside.
No named owner. A product line with three part-time sponsors and no single accountable owner drifts. Name the person before funding.
Skipping the systems work. Deciding to launch and then discovering that CPQ cannot quote the SKU, that the comp plan cannot pay on it, and that the forecast cannot segment it is a routine and entirely avoidable stall. Bring RevOps in during the case-building phase, not at launch.
Treating the case as a one-time artifact. The document should be revised as evidence arrives. A case that has not changed after six months of learning has not been read.

Decision framework: when to pursue, stage, or stop
Not every plausible bull case deserves funding, and the framework for deciding is mostly about strategic fit and reachability rather than the size of the number. Four questions, asked in order, resolve most cases.
Does it reach the same buyer? If yes, your distribution advantage is real and the case can lean on it. If no, treat the effort as a new-market entry with new-market timelines, costs, and failure rates — and price that risk into the decision.
Does it defend or extend the core? A line that increases retention or blocks a competitor from a beachhead carries strategic value beyond its direct revenue. Say so explicitly and, where you can, quantify the retention effect. A line that is merely adjacent and interesting has to stand on its own economics.
Is the evidence behavioral or stated? Behavioral evidence — money spent, contracts signed, workarounds built — justifies moving to a staged commitment. Stated interest alone justifies further discovery, not funding.

Can you run a cheap decisive experiment first? Often you can: a concierge version delivered by humans, a landing page with a real pricing page and a measured conversion rate, a paid pilot with three design partners, or selling the outcome as a service before building the product. If a cheap experiment exists, run it before writing a check — the experiment is usually a better use of the same eight weeks than another modeling revision.
The framework's real function is to force the argument into the open. Most bad funding decisions are not made because someone ran the wrong analysis; they are made because the strategic claim — "this defends the core" or "this reaches a new buyer we want" — was never stated plainly enough to be challenged. Make it plain, and the analysis usually resolves itself.
What to present, and to whom
The document and the conversation are different artifacts, and conflating them wastes both.
For the executive team, lead with the decision being requested and the amount. Then the one-sentence hypothesis, the three strongest pieces of evidence, the three-scenario range, the full cost load, the gates, and the kill conditions. Executives read for the risk structure, not the upside — they want to know how much this can cost if it fails and how quickly you would find out.
For finance, the model matters more than the narrative. Every assumption on its own line, sourced, with the sensitivity analysis showing which two or three assumptions actually drive the outcome. Almost always, one or two inputs — usually attach rate and price — dominate everything else, and making that visible focuses the entire review on the things that matter.

For sales leadership, the questions are about their people. What is the comp treatment, what is the quota impact, which segments get it first, what is the ramp plan, and what happens to the core number while reps learn the new thing. A case that has not answered these will not survive the first quarterly business review.
For RevOps, the systems inventory: SKUs, price book, CPQ rules, CRM schema changes, forecast category treatment, revenue recognition, territory and quota logic, reporting. Get the estimate in writing during the case phase; this workstream is routinely the thing that slips a launch by a quarter.
For the board, if it goes that far, keep it to a page: the strategic rationale, the staged commitment structure, and the specific evidence that would trigger stage two or a stop. Boards fund discipline more readily than they fund ambition.
Circulate the bull case and the bear case in the same document, and give the bear case equal production quality. A team that argues honestly against itself earns credibility that no amount of confident projection can buy — and the argument you make against your own case is usually the one that determines whether the product line survives its first hard quarter.
Related questions
How long should a bull case document be?
Five to eight pages plus a financial model. One page of hypothesis and evidence, two of segment and pricing, two of financials, one of risks and kill conditions, one of the first two quarters' operating plan. Longer usually signals a weak link buried under volume.
Should the bull case include a bear case?
Yes, always, and at equal rigor. Circulate them together with named conditions that would move you between them. A bull case without a stated kill condition is a marketing document rather than a decision instrument, and reviewers know the difference.
Who should own building it?
A small cross-functional group with one accountable owner: product lead, finance partner, RevOps analyst, and a quota-carrying seller. Four to eight weeks part-time. The seller's presence is what keeps the funnel assumptions honest.
What evidence is strongest?
Behavioral evidence, weighted by what it cost the customer to produce: signed letters of intent, paid pilots, allocated budget, and expensive workarounds customers built themselves. Stated interest in surveys or discovery calls is nearly worthless because agreeing costs nothing.
How do you size the market credibly?
Bottom-up, in three rings: your own installed base that matches the segment (countable exactly from CRM), your reachable non-customers, and everyone else. Discount the outer rings heavily. Top-down market size times assumed share is unfalsifiable and teaches nobody anything.
FAQ
How do you build a bull case for a new product line in 2027?
Start with a one-sentence demand hypothesis naming the buyer, the pain, the current workaround, and the trigger. Gather bottom-up evidence from your own CRM, support tickets, and roughly twenty-five structured customer conversations. Size in concentric rings starting from your countable installed base. Price against the buyer's current alternative. Model the funnel with your own conversion rates, degraded for newness. Load every cost including go-to-market and rep opportunity cost. Then name the leading indicators, the review gates, and the conditions under which you would stop.
What is the difference between a bull case and a forecast?
A forecast is your expected outcome and it drives hiring, quota, and spend. A bull case is the strongest defensible upside scenario, used to decide whether an opportunity is worth pursuing at all. Fund the operating plan to the expected case and keep the bull case as upside. Teams that build their cost structure on the bull case create an organization that only works if every assumption lands, which is the fastest route to a painful correction.
How conservative should the first-year numbers be?
Apply a real haircut to your existing conversion rates — commonly 60-75% of baseline win rate and 1.3-1.6x baseline cycle length for the first two or three quarters — because a new line always converts worse before enablement and references accumulate. Then present three scenarios rather than one, with the specific assumption differences named. Reviewers trust a stated range far more than a single confident number.
What if the new line cannibalizes the existing one?
Model the substitution explicitly rather than hoping it is small. A cannibalizing line can still be the right decision when it defends against a competitor, improves retention, or moves customers onto a better long-term economic footing. What matters is that the argument is made deliberately and out loud during the case-building phase, rather than discovered as an unpleasant surprise two quarters after launch.
Why does RevOps need to be involved early?
Because RevOps owns the machinery the new line runs on: SKUs, price book, CPQ rules, CRM schema, forecast categories, revenue recognition treatment, territories, quotas, and reporting. That workstream frequently takes months and is almost never in the original estimate. Bringing RevOps in at launch instead of during case-building is one of the most common reasons a funded product line slips a full quarter before its first invoice.
When should you stop instead of pushing through?
When a pre-committed gate is missed and the reason is a broken assumption rather than a fixable execution problem. That distinction is why gates must be written before work starts — after the fact, every miss looks like an execution issue. If by your stated date you have not seen the behavioral evidence you named, stop and document what disproved the case, so the next team does not rebuild the same argument.
Sources
- https://hbr.org/2019/09/the-4-types-of-innovation-and-the-problems-they-solve
- https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights
- https://www.bain.com/insights/topics/growth-strategy/
- https://web.stanford.edu/class/msande271/onlinetools/LeanCanvas.pdf
- https://www.strategyzer.com/library/the-business-model-canvas
- https://a16z.com/how-to-think-about-pricing/
- https://www.svpg.com/product-strategy-overview/
- https://openviewpartners.com/blog/
- https://www.bcg.com/capabilities/innovation-strategy-delivery/overview
Related on PULSE
- How do you price a new product line against an existing one?
- How do you design a comp plan for a new product launch?
- How do you model cannibalization between two product lines?
- How do you run a design partner program before general availability?
- How do you set quota for reps carrying two product lines?
- How do you decide when to kill an underperforming product line?









