gtm-technical-product-pricing by github/awesome-copilot
npx skills add https://github.com/github/awesome-copilot --skill gtm-technical-product-pricing在推荐定价方案前,请先了解:
模式:
平台公司,增长阶段。自推出以来定价从未改变。企业客户每年支付 15K 美元,而该产品为他们节省了超过 20 万美元的工程时间。
领导层的争论:"如果我们涨价,就会失去客户。"
实际情况:
将企业级定价从每年 15K 美元提高到 45K 美元。增加了专属支持、单点登录、审计日志来证明涨价的合理性。
失去:0 家企业客户。零。
获得:每个企业账户的收入增加了 3 倍。此外,留下的客户开始更认真地对待产品——采用率更高,内部支持者更多,扩展更多。
原因:
技术创始人将定价锚定在成本上("服务他们的成本是 $X,所以我们收取 $2X")。企业买家将定价锚定在价值上("这为我们节省了 20 万美元,所以 4.5 万美元很便宜")。
定价合理性检查:
为每个客户细分市场计算:
价值比率 = 客户的替代成本 / 你的价格
如果 价值比率 > 10倍 → 你定价严重过低
如果 价值比率 > 5倍 → 你定价过低(大多数初创公司处于此阶段)
如果 价值比率 3-5倍 → 健康的定价
如果 价值比率 < 3倍 → 接近天花板
如果 价值比率 < 2倍 → 你很昂贵(需要强大的差异化)
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
如何计算替代成本:
常见错误:
将你的价格与竞争对手比较,而不是与客户的替代成本比较。竞争对手会让你陷入竞相压价的境地。价值则让你锚定在客户实际节省的成本上。
模型 1:基于席位($X/用户/月)
适用场景:
失效场景:
模型 2:基于使用量($X/单位)
适用场景:
失效场景:
模型 3:基于结果($X/结果)
适用场景:
失效场景:
通常胜出的混合模型:
平台费(覆盖你的固定成本)+ 使用量/结果变量(随价值扩展)。
示例:500 美元/月基础费 + 每笔交易 0.05 美元(或每次 API 调用、完成任务、处理记录——无论你的价值单位是什么)。
为什么有效:
模式:
对于开发者工具来说,最难的定价决策是:你在哪里划清免费和付费的界限?
框架:找到生产边界
从不付费的免费用户没问题——他们创造知名度、社区和内容。问题是当生产用户从不付费时。
如何找到边界:
绘制你的使用量分布图:
使用量级别 | 用户类型 | 付费意愿
─────────────────────────────────────────────────────────────
<100 单位/月 | 爱好者/学习者 | 0 美元(从不付费)
100-1K 单位/月 | 副业项目 | 0-20 美元/月(可能)
1K-10K 单位/月 | 生产用途 | 50-200 美元/月(愿意付费)
>10K 单位/月 | 业务关键 | 200-2K 美元/月(必须付费)
将你的免费套餐限制设置在刚好低于生产使用开始的地方。 在这个例子中:每月 1000 个单位免费。
原因:爱好者和学习者保持免费(他们是你的营销引擎)。生产用户自然会达到限制并进行转化(他们有预算)。
三种免费转付费的触发机制:
1. 使用量限制(平台最常见)
2. 团队/协作门槛(工具类最佳)
3. 企业功能门槛(平台类最佳)
常见错误:
将免费套餐设置得过高("我们希望开发者喜欢我们")。如果生产用户没有达到限制,他们就永远不会转化。免费套餐的慷慨应该针对学习者,而不是生产用户。
模式:
企业定价不是你网站上的一个页面。它是一场对话。"联系销售"按钮之所以存在,是因为企业交易有独特的要求——而且你应该基于价值定价,而不是基于菜单。
企业定价变量:
1. 部署模式(自助云、专属云、本地部署、混合部署)
2. 使用规模(席位、API 量、数据量)
3. 支持级别(社区、标准、高级、专属)
4. 合规要求(SOC 2、HIPAA、FedRAMP、数据驻留)
企业定价对话:
当潜在客户问"成本是多少?"时:
常见错误:
在网站上公布企业定价。一旦你公布一个数字,那就是天花板——谈判只会从这个数字往下走。将企业定价保持为一场对话。
模式:
你的价格告诉买家你为谁服务。这既是定位决策,也是收入决策。
价格信号:
0 美元(开源 / 免费套餐):
20-100 美元/月:
500-2,000 美元/月:
5,000-50,000 美元/年:
100K+ 美元/年:
定位测试:
如果你定价 50 美元/月,但想要企业客户,你的价格正在破坏你的定位。企业买家将低价与低价值联系起来。你可能需要提高价格来吸引你想要的客户。
常见错误:
为你现有的客户定价,而不是为你想要的客户定价。如果你的路线图是企业级,就为企业级定价——即使这意味着今天会失去一些中小型企业客户。
时机信号:
如何提价而不失去客户:
1. 保护现有客户(12-24 个月)
2. 增加价值以证明涨价的合理性
3. 合同中的年度涨价条款
沟通方式:
"我们正在投资[具体改进]。为了维持这种投资水平,我们将在[日期]更新定价。您当前的套餐将按当前费率锁定,直到[保护截止日期]。"
永远不要为提价道歉。将其描述为对他们喜爱的产品的投资。
不同客户间的使用量差异是否 >5 倍?
├─ 是 → 基于使用量(或包含使用量组件的混合模型)
└─ 否 → 继续...
│
价值是否随团队规模扩展?
├─ 是 → 基于席位
└─ 否 → 继续...
│
你能可靠地衡量客户结果吗?
├─ 是 → 基于结果(或混合模型)
└─ 否 → 平台费 + 基于功能的套餐
大多数客户的价值比率是否 > 5 倍?
├─ 是 → 提价
└─ 否 → 继续...
│
胜率是否 > 40%?
├─ 是 → 价格不是问题,但考虑提价
└─ 否 → 继续...
│
你是否因为价格而输掉交易?
├─ 是 → 不要提价。改进价值或更好地细分市场。
└─ 否 → 其他方面有问题(产品、定位、销售)
基于在开发者平台和企业软件公司的定价工作,包括零客户流失的企业提价、区分爱好者和生产用户的免费增值门槛设计、合作伙伴定价模型,以及数百个企业交易周期中的定价对话。不是理论——是直接影响收入的定价决策模式。
每周安装量
155
代码库
GitHub 星标数
26.7K
首次出现
5 天前
安全审计
安装于
gemini-cli142
codex142
opencode142
cursor141
warp139
kimi-cli139
Before recommending pricing, understand:
The Pattern:
Platform company, growth stage. Pricing hadn't changed since launch. Enterprise customers paying $15K/year for a product saving them $200K+ in engineering time.
Leadership debate: "If we raise prices, we'll lose customers."
What actually happened:
Raised enterprise tier from $15K to $45K/year. Added dedicated support, SSO, audit logs to justify the jump.
Lost: 0 enterprise customers. Zero.
Gained: 3x revenue per enterprise account. Plus the customers who stayed started taking the product more seriously — higher adoption, more internal champions, more expansion.
Why This Happens:
Technical founders anchor pricing to cost ("it costs us $X to serve them, so we charge $2X"). Enterprise buyers anchor pricing to value ("this saves us $200K, so $45K is cheap").
The Pricing Sanity Check:
For every customer segment, calculate:
Value Ratio = Customer's alternative cost / Your price
If Value Ratio > 10x → You're massively underpriced
If Value Ratio > 5x → You're underpriced (most startups are here)
If Value Ratio 3-5x → Healthy pricing
If Value Ratio < 3x → Approaching ceiling
If Value Ratio < 2x → You're expensive (need strong differentiation)
How to Calculate Alternative Cost:
Common Mistake:
Comparing your price to competitors instead of to customer's alternative cost. Competitors anchor you to a race to the bottom. Value anchors you to what the customer actually saves.
Model 1: Seat-Based ($X/user/month)
Works when:
Breaks when:
Model 2: Usage-Based ($X/unit)
Works when:
Breaks when:
Model 3: Outcome-Based ($X/result)
Works when:
Breaks when:
The Hybrid That Usually Wins:
Platform fee (covers your fixed costs) + usage/outcome variable (scales with value).
Example: $500/month base + $0.05 per transaction (or API call, task completed, record processed — whatever your unit of value is).
Why this works:
The Pattern:
The hardest pricing decision for developer tools: where do you draw the line between free and paid?
The Framework: Find the Production Boundary
Free users who never pay are fine — they create awareness, community, and content. The problem is when production users never pay.
How to Find the Boundary:
Map your usage distribution:
Usage Level | User Type | Willingness to Pay
─────────────────────────────────────────────────────────────
<100 units/mo | Hobbyist/learner | $0 (never paying)
100-1K units/mo | Side project | $0-20/mo (maybe)
1K-10K units/mo | Production use | $50-200/mo (will pay)
>10K units/mo | Business-critical| $200-2K/mo (must pay)
Set your free tier limit just below where production usage starts. In this example: 1,000 units/month free.
Why: Hobbyists and learners stay free (they're your marketing engine). Production users hit the limit naturally and convert (they have budget).
The Three Types of Free-to-Paid Triggers:
1. Usage limit (most common for platforms)
2. Team/collaboration gate (best for tools)
3. Enterprise feature gate (best for platforms)
Common Mistake:
Setting free tier too high ("we want developers to love us"). If production users don't hit the limit, they never convert. Generosity in free tier should target learners , not production users.
The Pattern:
Enterprise pricing isn't a page on your website. It's a conversation. The "Contact Sales" button exists because enterprise deals have unique requirements — and because you should be pricing based on value, not a menu.
Enterprise Pricing Variables:
1. Deployment model (self-serve cloud, dedicated cloud, on-prem, hybrid)
2. Usage scale (seats, API volume, data volume)
3. Support level (community, standard, premium, dedicated)
4. Compliance requirements (SOC 2, HIPAA, FedRAMP, data residency)
The Enterprise Pricing Conversation:
When prospect says "what does it cost?":
Don't answer with a number. Answer with a question: "It depends on your deployment and scale requirements. Help me understand what you need."
Map their requirements:
Anchor to value before presenting price:
Present 3 options:
Common Mistake:
Publishing enterprise pricing on your website. The moment you publish a number, that's the ceiling — the negotiation only goes down from there. Keep enterprise pricing as a conversation.
The Pattern:
Your price tells buyers who you're for. This is as much a positioning decision as a revenue decision.
Price Signals:
$0 (Open source / free tier):
$20-100/month:
$500-2,000/month:
$5,000-50,000/year:
$100K+/year:
The Positioning Test:
If you price at $50/month but want enterprise customers, your price is undermining your positioning. Enterprise buyers associate low price with low value. You may need to raise prices to attract the customers you want.
Common Mistake:
Pricing for the customer you have instead of the customer you want. If your roadmap is enterprise, price for enterprise — even if it means losing some SMB customers today.
Timing Signals:
How to Raise Without Losing Customers:
1. Grandfather existing customers (12-24 months)
2. Add value to justify increase
3. Annual increase clause in contracts
The Communication:
"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]."
Never apologize for raising prices. Frame it as investment in the product they love.
Does usage vary >5x between customers?
├─ Yes → Usage-based (or hybrid with usage component)
└─ No → Continue...
│
Does value scale with team size?
├─ Yes → Seat-based
└─ No → Continue...
│
Can you measure customer outcomes reliably?
├─ Yes → Outcome-based (or hybrid)
└─ No → Platform fee + feature-based tiers
Is value ratio > 5x for most customers?
├─ Yes → Raise prices
└─ No → Continue...
│
Are win rates > 40%?
├─ Yes → Price isn't the problem, but consider raising
└─ No → Continue...
│
Are you losing deals specifically on price?
├─ Yes → Don't raise. Improve value or segment better.
└─ No → Something else is wrong (product, positioning, sales)
Based on pricing work at developer platforms and enterprise software companies, including enterprise price increases with zero customer loss, freemium threshold design that separated hobbyists from production users, partner pricing models, and pricing conversations across hundreds of enterprise deal cycles. Not theory — patterns from pricing decisions that directly impacted revenue.
Weekly Installs
155
Repository
GitHub Stars
26.7K
First Seen
5 days ago
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli142
codex142
opencode142
cursor141
warp139
kimi-cli139
PRD到实施计划转换工具:使用垂直切片法将产品需求文档分解为分阶段开发计划
3,500 周安装