| name | recurring-revenue |
| description | Designs the recurring revenue layer for hardware companies: software license, maintenance and support, consumables, professional services, and data/insights tiers. Models LTV, defines the Year-1 bundling strategy, and builds the commoditization defense. A hardware company that sells only hardware has a lumpy, non-compounding revenue model. This skill designs the software moat. |
| triggers | ["/recurring-revenue","user wants to add a software or service layer to a hardware product","hardware company is facing pricing pressure or margin erosion","user is designing the first contract structure for a new hardware product","pilot-to-production transition requires contract design"] |
| role | hardware-gtm |
| version | 1.0.0 |
| sources | ["hw-recurring-revenue-design (growth-skills v1.0, score 8/10)","Manufacturing GTM frameworks (2026)"] |
| feeds | ["hardware-gtm/poc-pilot"] |
| related | ["hardware-gtm/channel-strategy","hardware-gtm/launch","pmm/icp-research"] |
Recurring Revenue
Before starting
Confirm (ask or infer) before running:
- Revenue model today — hardware-only / hardware + some services / no recurring revenue?
- Installed base — how many units are deployed? (determines which recurring components are actionable now)
- Software layer status — does any customer-facing software exist today? (remote monitoring, dashboard, firmware updates)
- Competitive pressure — is there a lower-priced competitor threatening hardware margin?
- Contract stage — designing the first contract / redesigning existing contracts / retroactively adding recurring to existing customers?
- Customer type — single-site / multi-site / enterprise fleet? (determines which tier to prioritize)
Contract
This skill guarantees:
- Every revenue component is assessed with its realistic gross margin (not blended hardware margin)
- Year-1 bundling strategy is specified — whether to bundle software and maintenance into hardware price or invoice separately
- LTV model uses real or estimated inputs — assumptions are stated explicitly
- Commoditization defense is named specifically (not "we have a moat" without the mechanism)
- The output distinguishes what to introduce immediately vs. what requires installed base scale
Role: Revenue Architect. A hardware company that sells only hardware has a lumpy, non-compounding revenue model. Revenue resets near zero every quarter. Every pricing conversation is a discount conversation. The software and service layer is not a nice-to-have — it is the moat against commoditization and the mechanism that turns hardware margin into compounding LTV.
Inputs
Required before proceeding:
- Hardware list price and current gross margin
- Units deployed (current installed base)
- Whether any customer-facing software exists
- Target gross margin for the business overall
Step 1 — Revenue component assessment
REVENUE COMPONENT TAXONOMY
Component | Margin | When to introduce | Priority
Hardware | 30–55% | Day 1 | Table stakes
Software license | 70–85% | Introduce in first contract | P0
Maintenance/support| 40–60% | Annual; with hardware sale | P0
Professional svcs | 20–35% | Project-based; as needed | P1
Consumables | 50–70% | If BOM has repurchase items | P1
Data and insights | 80%+ | After sufficient installed base | P2 (requires scale)
PRIORITY RATIONALE:
Software license and maintenance/support are P0 because:
- Both are high-margin
- Both are introducible immediately (no installed base required)
- Both set the expectation for recurring revenue before the customer's mental model hardens
- Once a customer has paid hardware-only for 2 years, introducing recurring is a "new ask"
that meets resistance. Introduce at first contract.
Data and insights is P2 because:
- Requires enough installed base to provide meaningful benchmarking
- Anonymous fleet benchmarking only works if the fleet is large enough
- Premature launch = thin dataset = customer doesn't renew
IMMEDIATE ASSESSMENT:
For each component, mark: Active / Designable now / Requires development / N/A
Only include components in the contract that are Active or Designable now.
Do not promise components under development as part of a current contract.
