# GTM technical product pricing Human Guide

## What This Is For
Helps technical product teams design pricing by clarifying product type, charge metrics, packaging, buyer segments, and pricing experiments. It gives the agent a clearer input/output frame for go-to-market work: what context to ask for, what decisions to make, and what usable artifact to return.

Use this as a human-readable version of the GTM technical product pricing agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions.

## When To Use This
- Use this when you need a repeatable process for GTM technical product pricing.
- Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt.
- Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact.

## When Not To Use This
- Do not use this when you only need a quick factual answer.
- Do not use this when the work depends on private data you cannot share with the assistant.
- Do not use this as a replacement for legal, compliance, financial, or medical review.

## What You Need Before Starting
- The goal or business outcome you want.
- The audience, customer segment, or market context.
- Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance.
- Constraints such as tone, length, channel, deadline, region, or approval requirements.
- A clear definition of what a good final answer should look like.

## Step-By-Step Workflow
1. State the job clearly: "Use the GTM technical product pricing guide to help me with..."
2. Add context: audience, goal, offer, channel, source material, and constraints.
3. Ask the assistant to identify missing inputs before producing the final output.
4. Have the assistant follow the skill-specific guidance below.
5. Review the result against the final checklist and ask for revisions where needed.

## Skill-Specific Guidance
- **Product type**: API/platform, developer tool, SaaS application, infrastructure?
- **Current pricing**: What do you charge now? How long has it been this way?
- **GTM motion**: Self-serve, sales-assisted, enterprise, or hybrid?
- **Cost structure**: What's your marginal cost per customer/user/unit?
- **Competitive landscape**: What do alternatives cost? (Including "do nothing")
- Hours spent on manual process × hourly rate × frequency
- Cost of building in-house (engineers × months × loaded cost)
- Cost of existing tool + switching cost + productivity loss during transition
- Cost of *not solving the problem* (incidents, downtime, churn)
- Value scales with number of users (collaboration tools, communication)
- Usage is relatively uniform across users
- You want predictable revenue

## Decision Points And Nuance
The original skill emphasizes: Initial Assessment, Core Frameworks, The Price Increase Nobody Noticed (You're Probably Underpriced), The Three Pricing Models (And When Each Breaks), Freemium Threshold Design (Where Free Ends and Paid Begins), Enterprise Pricing (The Conversation, Not the Number), Pricing as Positioning Signal, When and How to Raise Prices, Decision Trees, Which Pricing Model?.

Use these questions to steer the work:
- What is the intended audience or buyer?
- What source material must be preserved?
- What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion?
- What examples represent the desired quality bar?
- What should the assistant avoid?

## Common Mistakes
- **Competitive landscape**: What do alternatives cost? (Including "do nothing")
- Free users who never pay are fine — they create awareness, community, and content. The problem is when *production users* never pay.
- <100 units/mo | Hobbyist/learner | $0 (never paying)
- >10K units/mo | Business-critical| $200-2K/mo (must pay)
- 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*.
- Volume discounts should never go below cost to serve + 40% margin
- **Don't answer with a number.** Answer with a question: "It depends on your deployment and scale requirements. Help me understand what you need."
- Never apologize for raising prices. Frame it as investment in the product they love.

## Copy-And-Paste Prompt
```text
Use the GTM technical product pricing human guide.

My goal:
[Describe the business outcome]

Audience:
[Describe who this is for]

Context and source material:
[Paste notes, examples, links, or existing copy]

Constraints:
[Tone, length, channel, timeline, must-include items, must-avoid items]

Before producing the final output, ask me for any missing information that would materially improve the result.
```

## Final Checklist
- [ ] The output matches the original goal.
- [ ] The audience and context are reflected in the answer.
- [ ] Important constraints and source material were preserved.
- [ ] The assistant made the relevant decisions explicit.
- [ ] The final artifact is ready to use, review, or hand to the next person.

## Source
This guide was generated from the github/awesome-copilot skill entry for `gtm-technical-product-pricing`.

## Source Skill Notes
These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic.

# Technical Product Pricing


## Initial Assessment

Before recommending pricing, understand:

1. **Product type**: API/platform, developer tool, SaaS application, infrastructure?
2. **Current pricing**: What do you charge now? How long has it been this way?
3. **GTM motion**: Self-serve, sales-assisted, enterprise, or hybrid?
4. **Cost structure**: What's your marginal cost per customer/user/unit?
5. **Competitive landscape**: What do alternatives cost? (Including "do nothing")

---

## Core Frameworks

### 1. The Price Increase Nobody Noticed (You're Probably Underpriced)

**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:**

- Hours spent on manual process × hourly rate × frequency
- Cost of building in-house (engineers × months × loaded cost)
- Cost of existing tool + switching cost + productivity loss during transition
- Cost of *not solving the problem* (incidents, downtime, churn)

**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.

---

### 2. The Three Pricing Models (And When Each Breaks)

**Model 1: Seat-Based ($X/user/month)**

**Works when:**
- Value scales with number of users (collaboration tools, communication)
- Usage is relatively uniform across users
- You want predictable revenue

**Breaks when:**
- Power users and casual users get same price (casual users churn)
- Product value doesn't scale with seats (one admin configures for 1,000 users)
- Customers consolidate seats to reduce cost (usage goes up, revenue doesn't)

**Model 2: Usage-Based ($X/unit)**