Gtm Technical Product Pricing

Technical product pricing

Assess a technical product's value, cost, GTM motion, customer segment, and competitive alternatives, then recommend a pricing model, packaging thresholds, enterprise conversation structure, price-positioning signal, and price-increase path.

When to invoke

• "How should we price this developer tool?"
• "Should this be usage-based or seat-based pricing?"
• "Where should our freemium tier end?"
• "Help structure enterprise pricing."
• "Should we raise prices?"

Initial assessment

Collect these inputs before recommending pricing:

Value-ratio pricing

Anchor price to customer alternative cost rather than your internal cost. Enterprise buyers often compare your price to engineering time saved, risk reduced, downtime avoided, or revenue unlocked.

Value Ratio = Customer's alternative cost / Your price

Calculate alternative cost from hours spent on manual process × hourly rate × frequency; cost of building in-house as engineers × months × loaded cost; cost of existing tool + switching cost + productivity loss; or cost of not solving the problem such as incidents, downtime, or churn. Do not benchmark only against competitors; that anchors a race to the bottom.

Pricing model decision rules

A common winning structure is $500/month base + $0.05 per transaction, API call, task completed, or record processed. Use a platform fee for fixed costs and variable pricing for upside.

Does usage vary >5x between customers?
├─ Yes → Usage-based (or hybrid with usage component)
└─ No → Does value scale with team size?
   ├─ Yes → Seat-based
   └─ No → Can you measure customer outcomes reliably?
      ├─ Yes → Outcome-based (or hybrid)
      └─ No → Platform fee + feature-based tiers

Freemium thresholds

Find the production boundary. Free should serve hobbyists, learners, awareness, community, and content; it should not let production users avoid payment forever.

Set the free tier just below where production usage starts, such as 1,000 units/month free when production begins above that. Use these conversion triggers:

Enterprise pricing

Enterprise pricing is a conversation, not just a number on a page. Keep Contact Sales for unique requirements and value anchoring.

When a prospect asks cost: do not lead with a number. Ask about users, seats, units, cloud vs on-prem, compliance, support, and integrations; anchor to savings; then present three options: Good, Better, Best. Most buyers pick Better.

Price as positioning

If you price at $50/month while targeting enterprise, price undermines positioning. Price for the customer you want, not only the customer you have.

Price increases

Raise prices when value ratio is > 5x for most customers, win rates are above 40%, there has been no pricing pushback in the last 6 months, customers expand faster than expected, or competitors raised prices without losing share.

Is value ratio > 5x for most customers?
├─ Yes → Raise prices
└─ No → Are win rates > 40%?
   ├─ Yes → Price is not the problem; consider raising
   └─ No → Are you losing deals specifically on price?
      ├─ Yes → Do not raise; improve value or segment better
      └─ No → Something else is wrong: product, positioning, or sales

Raise without losing customers by grandfathering existing customers for 12-24 months, adding value to justify the increase, and using 5-10% annual escalator clauses in enterprise contracts. Communicate: "We're investing in [specific improvements]. To continue this level of investment, we're updating our pricing on [date]. Your current plan is locked in at your current rate until [grandfather date]." Do not apologize; frame it as investment.

Related primitives

Pricing examples and deal vocabulary

Use concrete pricing anchors when useful: a platform company charging 15K/year and raising enterprise to 45K/year. can be underpriced if the customer saves far more. Cost inputs may be per customer/user/unit; beware month-end sticker shock in usage pricing, already-discounted discount stacking, and enterprise bundles with nice-to-haves. Hybrid models combine usage/outcome economics, enterprise discovery asks for users/seats/units, and AI pricing may require variable-cost analysis. High-price infrastructure can be mission-critical rather than merely expensive.

Output template

## Technical product pricing recommendation — <product>

**Status:** recommended | needs data | blocked
**Product type:** API/platform | developer tool | SaaS | infrastructure
**GTM motion:** self-serve | sales-assisted | enterprise | hybrid

### Value and floor
- Alternative cost: $<amount> based on <method>
- Current or proposed price: $<amount>
- Value Ratio: <ratio>x (<interpretation>)
- Marginal cost floor: $<amount or unknown>

### Recommended model
| Component | Recommendation | Rationale |
| --- | --- | --- |
| Base fee | $<amount> | <reason> |
| Usage unit | $<amount>/<unit> | <reason> |
| Free tier | <threshold> | <production boundary> |
| Enterprise | <packaging> | <deployment/support/compliance logic> |

### Packaging and positioning
- Target customer: <segment>
- Price signal: <signal>
- Free-to-paid trigger: <usage/team/enterprise gate>

### Price-change plan
- Grandfathering: <12-24 month plan or none>
- Added value: <features/services>
- Contract terms: <annual escalator or discount guardrail>

Quality gate

• Product type, current pricing, GTM motion, cost structure, and alternatives were assessed or marked unknown.
• Value Ratio was calculated or the missing inputs were named.
• The pricing model choice follows the usage, seat, outcome, or hybrid decision rules.
• Freemium thresholds separate learners from production users.
• Enterprise pricing accounts for deployment, scale, support, and compliance.
• Price positioning matches the target customer segment.
• Any price increase includes timing signals, grandfathering, added value, and communication plan.

References

• Technical product GTM source
• Smit Patel