Product pricing strategy for product managers

Price = Cost + Markup. The most straightforward approach — you know your costs and you add a margin. Simple to understand and defend, but ignores the value delivered to the customer. Common in manufacturing, rare in SaaS. If your software costs $0.01 to distribute but saves customers $10,000 a year, cost-based pricing leaves most of that value uncaptured.

Price based on what competitors charge. Easy to understand and easy to communicate to stakeholders. The danger is blindly following competitors into a race to the bottom, or anchoring your price to a competitor who is wrong about the market. Useful as a sanity check — not as a primary strategy.

Price = a percentage of the value delivered to the customer. If your product saves a sales team 10 hours per week at $100/hour, a $200/month price is capturing 2% of delivered value — very defensible. The most sophisticated and profitable approach. Used by the best SaaS companies. Requires deep understanding of your customer's economics, which is why it is hard and worth doing.

One price, all features. Extremely simple to understand and communicate. Customers never feel nickeled-and-dimed. The downside: you leave significant money on the table from power users who would pay much more. Works best when your user base is homogeneous.

Price scales with team size. The most common B2B model because it aligns with how companies think about software costs and grows naturally with your customer. The risk: customers hide usage or resist adding seats. Watch for 'seat hoarders' who share logins.

Pay for what you consume. Aligns cost directly with value — customers only pay when they get value. Growing fast, especially in infrastructure, APIs, and AI. Creates a land-and-expand motion: customers start small and spend more as they grow. The challenge is revenue predictability.

Three or four plans with different feature sets. The most common SaaS model because it serves multiple customer segments simultaneously. Requires careful packaging — which features go where determines who buys which tier. The packaging decision is as important as the prices themselves.

Core product free, premium features paid. Dramatically lowers the barrier to adoption and creates viral loops when free users invite others. Harder to monetize than it looks — conversion rates from free to paid are typically 2-5%. Works best when free users deliver value to paid users (virality) or when the product sells itself through use.

✓Freemium works when

• The product has genuine viral loops — free users invite others, creating natural distribution
• Conversion to paid is natural — users hit a limit that clearly justifies upgrading
• The free tier is genuinely useful, not a crippled demo
• The marginal cost of serving a free user is close to zero

✕Freemium fails when

• The free tier is too good — users get what they need and have no reason to upgrade
• The free tier is too limited — users leave before experiencing the product's value
• The viral loop is absent — free users do not bring in more users
• The cost of serving free users is high — freemium becomes a subsidy program

Put the most-wanted features in the tier you want customers in

If your goal is to get customers onto the Pro plan, the features they most want should live there. Putting those features in Enterprise means you will fight every upgrade conversation.

Create a clear upgrade trigger

The best packaging creates a moment where a user thinks 'I need Feature X, which is in the next tier.' That moment should feel natural, not punitive. Users should feel excited about upgrading, not coerced.

Do not add features to higher tiers just because you can

Locking features behind a paywall only works if those features create real upgrade incentive. Putting a rarely-used setting behind a paywall creates friction without revenue. Be deliberate — every tier gate should have a clear rationale.

Match tier names to customer identity

Starter / Pro / Enterprise is more than naming — it tells customers who each tier is for. Customers self-select based on how they see themselves. A solo founder does not want 'Enterprise' even if the feature set fits.