Product management and pricing flywheel for SaaS founders

Executive overview

Most SaaS founders do product management without calling it that — deciding what to build, in what order, and how to communicate it. As companies scale, those decisions require dedicated focus. The core challenge is not just building the right features, but tying pricing to the behavior that actually drives customer value.

Pricing anchored to a customer value flywheel creates expansion revenue that can offset churn and compound growth.

What product management actually is

• Product decides what gets built next, in what order, and how features interact with pricing and tiers
• Product marketing is the counterpart: product management listens to the market and builds; product marketing speaks to the market and tells stories
• At small companies, founders do both without naming it; the roles only need separating once the company grows past one person's capacity
• Non-technical founders who hire a developer without product skills often end up with no one making the critical decisions about what to build

When to hire your first product manager

• Rule of thumb: when you can afford to pay ~$120–130k/year for the role
• Rob's rule: rarely needed before $1M ARR; usually hired between $1–2M ARR
• Simple products may never need a dedicated PM; complex, multi-feature products need one earlier
• The same threshold applies roughly to a first head of marketing

The flywheel framework

A flywheel is a repeating pattern of customer behavior that becomes self-sustaining. The goal is to identify that pattern and price based on it.

Drip/email marketing example (three stages):

1. Integrate customer data — subscriber profiles, plan data, attributes
2. Send personalized messages — triggered campaigns based on that data
3. Influence recipient behavior — drive re-engagement, conversions, feature adoption

The flywheel closes when influenced behavior generates new data, prompting more sends. Pricing on the unit that scales with this loop (subscribers/contacts) means customers who succeed naturally pay more — creating expansion revenue.

How to build your own flywheel

• Start with your highest-paying or fastest-growing customer
• List the actions they take in your product on a recurring basis
• Distill those actions into a cyclical pattern of three to five steps — ideally three
• Each step must naturally lead to the next; if the story doesn't flow, revise
• Ask: could I charge based on this behavior in a way that feels fair to the customer?
• If the answer is no (e.g., charging per Google Doc search), pivot the flywheel until the pricing metric makes sense

Linking pricing to the flywheel

• If pricing is detached from the flywheel, you must optimise for retention and expansion separately — harder and less efficient
• Seat-based pricing rarely ties to behavior; customers who stay at one seat never expand
• Usage-based pricing works when the usage metric aligns with value — Segment initially charged per API call (engineers understood it, but buyers didn't), switched to monthly tracked users (MTUs), and conversion improved
• Intercom charges per successfully resolved AI chat — fair to customers, but expansion dynamics are still uncertain
• The metric must be understandable to the buyer, not just technically accurate

Pricing mistakes and edge cases

• Too generous pricing (unlimited everything as a selling point) caps revenue; customers expand but you don't capture any of that value
• Too many value metrics confuse buyers; compress to one, or at most two with a "fair use" caveat
• Switching pricing models on existing customers is high risk — Help Scout's move from seat-based to ticket-based pricing triggered significant backlash
• Mixpanel cycled between event-based and MTU pricing twice before reverting — the MTU model felt fair but couldn't generate enough revenue
• The right pricing is a balance: optimal for the business and acceptable to customers; finding both simultaneously is genuinely hard