Business Models & Business Casing

Master B2B, B2C, and PLG trade-offs and write business cases that de-risk product decisions before you build.

min

exercises

Upd. on

Apr 17, 2026

Start lesson quiz

Product Decisions & Trade-offs

Course

Product decisions don't happen in a vacuum. They happen inside business models that shape what is possible, what is profitable, and what is worth building at all. Understanding how your business makes money sits at the core of product work, not just in finance.

B2C products live or die by volume. High traffic, fast feedback loops, and algorithmic retention define the game. The real risk shows up after the install: keeping users past the first 24 hours. B2B products work differently. Contracts are large, sales cycles are long, and the person who signs the deal is rarely the person who logs in every day. Knowing which model you are in changes how you prioritize, what you measure, and what you build.

Between those two poles sits product-led growth, a hybrid model where the product sells itself through adoption rather than through a sales team. These models create trade-offs around pricing tiers and the line between self-serve and enterprise.

Writing a business case is how product managers convert ideas into decisions. Using inputs like LTV, churn, and conversion rate, a well-built case tests whether a bet makes sense before any code is written. Sensitivity analysis turns a static model into a stress test: what happens when the assumptions are wrong?

How business-to-consumer (B2C) products work

B2C product management runs on volume. Revenue comes from a large number of users paying relatively small amounts through subscriptions, in-app purchases, or advertising. Feedback loops are fast, data is abundant, and growth can scale without a sales team ever picking up the phone.

The critical risk is early abandonment, sometimes called the "Day 1 cliff." Think of a consumer app that acquires thousands of users from a campaign, only to watch most of them never return after their first session. No account executive calls to check in. The product experience alone must create the habit. That is why retention becomes the central product concern in B2C, driving prioritization more than any other metric.

This changes how prioritization works. Features that move retention metrics matter more than features that look impressive in a demo. A PM operating in B2C must be comfortable reading behavioral data quickly and placing fast, iterative bets rather than waiting on large, comprehensive releases.^[1][2]

Pro Tip! In B2C, getting users is just the starting point. Keeping them after their first session is where the real product work happens.

How business-to-business (B2B) products work

B2B product management runs on value. Fewer customers pay much higher amounts, typically through annual contracts negotiated by a dedicated sales team. Revenue is more predictable, but the feedback loop is slower and more political. The most important dynamic to understand is the Buyer vs. User gap. Consider an enterprise project management tool: the VP of Operations signs the contract, but the individual contributors who log in every day actually use it. The VP wants governance, reporting, and security. The contributors want speed, simplicity, and fewer clicks. Building features that impress buyers often frustrates daily users, and the reverse is equally true. A strong B2B PM learns to serve both without losing sight of either. Because deals are relationship-driven, product decisions carry reputational weight. Shipping a broken feature to a high-value enterprise client can damage trust in ways that a quick patch cannot fix. Release quality and communication matter more here than in B2C environments, where faster iteration is expected and accepted.

Pro Tip! Map your stakeholders per deal. The contract signer and the daily user often want different things from the same product.

Cannibalization risk in product-led growth pricing

Product-led growth (PLG) is a go-to-market model where the product itself drives acquisition, conversion, and expansion rather than a sales team. Users discover the product, adopt it individually or in small groups, and the business scales through that organic spread. Slack, Figma, and Notion grew this way, going from individual signups to company-wide contracts without a traditional sales motion.

PLG creates a specific pricing architecture challenge known as cannibalization risk. The free tier must solve a real problem well enough to bring users in, but the paid tiers must reserve enough exclusive value to make upgrading worth it. When a free tier is too powerful, it cannibalizes demand for the paid plan by removing the incentive to upgrade. When it is too limited, it removes the incentive to sign up at all. The PM's job is to draw that line deliberately.

Enterprise features typically withheld from free tiers include single sign-on, service level agreements, dedicated support, and administrative controls. These create a natural ceiling that nudges growing teams toward an enterprise plan without making the free experience feel deliberately broken.^[1]

Pro Tip! The free tier should solve the immediate problem. The paid tier should solve the permanent one.

Use a business case to test assumptions before building

The most common misconception about business cases is that they exist to get budget approved.

They do serve that function, but the more valuable purpose is self-testing. A PM who writes a business case is forced to make assumptions explicit, assign numbers to beliefs that might otherwise remain vague, and commit to the logic before the team spends any time or money.

This process often surfaces problems that would have been expensive to find mid-build. A feature that seemed obviously worth doing can look very different once the addressable audience is realistically scoped, the conversion lift is modeled conservatively, and the opportunity cost is on the table.

Think of it as the difference between pitching an idea and defending it. Writing the case is where PMs discover, privately and cheaply, whether an idea actually holds up. If it does, the case becomes the artifact that aligns the team. If it does not, the discovery happened before anyone burned two sprints on something the numbers never supported.^[2]

LTV, CAC, and churn as product inputs

Many PMs develop financial fluency late in their careers, often only after getting caught flat-footed in a business review. The 3 inputs worth learning early are:

Lifetime value (LTV) measures the total net revenue a customer generates across their entire relationship with the product. A higher LTV means the business can afford to spend more to acquire and retain each user.
Customer acquisition cost (CAC) is the average cost of acquiring a single customer through sales, marketing, and related efforts. A healthy LTV to CAC ratio is typically at least three to one. Below that, the business is spending more to acquire customers than those customers are worth.
Churn is the percentage of customers who cancel or stop using the product in a given period. Even a small difference compounds fast. A product retaining 95% of users monthly looks very different after a year from one retaining 90%, even though the gap seems small in any single month. PMs who understand churn at the feature level can make retention arguments with financial weight rather than just product intuition.

These numbers describe the current health of the business and model where it is headed, which is what makes them useful for deciding whether a product bet makes financial sense.^[3]

How to estimate product value with the business case equation

Before running detailed financial modeling, a PM can gut-check a product bet using a simple equation: (Volume x Delta x Value) > Cost. This structure forces 3 key estimates to be made explicit rather than left as vague assumptions:

Volume is the addressable audience, scoped realistically to the specific segment that will actually reach the feature, rather than rounded up to "all users."
Delta is the estimated lift from the change. A conservative 2% improvement in conversion rate is far more credible than an optimistic 50%.
Value assigns a dollar figure to that behavior change, often anchored by LTV.
The cost side includes more than the build itself. It includes the opportunity cost: what the team is not building while working on this feature.

When the left side of the equation exceeds the right under realistic assumptions, the case for building holds. When it does not, the honest answer is to deprioritize rather than inflate the inputs until the math agrees with the desired outcome.

Pro Tip! Use realistic deltas, not optimistic ones. A 2% lift that holds is more valuable than a 20% lift that never arrives.

Write the press release before building the product

The Amazon working backward method asks a team to write the press release for a product before a single line of code exists. The press release is addressed to customers and describes what the product does, why it matters, and what problem it solves. If the team cannot write a clear, compelling press release, the idea is not defined well enough to build.

This works because press releases require clarity in a way that internal documents do not. Vague thinking hides easily behind roadmap slides and technical specs. It cannot hide in a press release written for a customer who has no context. When a team struggles to write the press release, that struggle is the signal, and it is far cheaper to find that signal before the build than after it.

The method also shifts the stakeholder conversation. When executives review a press release or a one-pager rather than a feature spec, they react to customer value rather than debating implementation details. The question in the room moves from "how do we build this" to "should we build this at all," which is the question that matters most at the start of any significant product bet.^[4]