Framework
Platform features = Infrastructure that enables future features (APIs, foundations, systems) User-facing features = Direct customer value today
Example:
- Platform: Building an API so partners can integrate
- Feature: Building a new dashboard
Platform work has compounding value. Each additional integration is cheaper. Feature work has linear value. Each new feature is similar effort.
Prioritization Decision
| Scenario | Priority |
|---|---|
| Early stage, unproven market | Features (prove product-market fit) |
| Growth stage, proven product | Mix (platform + features) |
| Scale stage, mature market | Platform (consolidation + partners) |
| Downturn,cost concerns | Features (direct revenue impact) |
Actionable Steps
1. Decide on Platform Allocation
How much engineering goes to platform vs. features?
- Early: 10% platform, 90% features
- Growth: 30% platform, 70% features
- Scale: 50% platform, 50% features
2. Measure Platform ROI
Track: Cost to build integration #1, #2, #10. Does cost per integration decrease?
Key Takeaways
- Platform has compounding returns; features are linear. Early stage should skip platform work. Growth/scale stages should embrace it.
- Platform signals shift as you scale. Adjust your allocation accordingly.
- Under-investing in platform creates a debt ceiling. Eventually, you can't ship features fast enough.
The Platform vs. Feature Trap
Year 1: Early-stage SaaS company. You build features. Direct customer value. Revenue grows.
Year 2: Revenue growing, but customers want integrations.
- Customer A: "We need Salesforce integration."
- Customer B: "We need Slack integration."
- Customer C: "We need Zapier integration."
Old approach: Build each integration one-off (Year 2 = 3 integrations built, months spent)
New approach: Build API platform first (Month 1 = 2 weeks engineering), then customers/partners build integrations on top (Year 2 = 20 integrations, 0 engineering days)
Difference: Same outcome (3+ integrations), but platform approach pays dividends for years.
The trap: Early-stage founders prioritize features over platform. "Customers want features, not infrastructure." True, but...
The Platform Economics: Compounding vs. Linear
Feature Work (Linear Economics):
- Build Feature A: 4 weeks, $150K cost, $100K ARR
- Build Feature B: 4 weeks, $150K cost, $100K ARR
- Build Feature C: 4 weeks, $150K cost, $100K ARR
- Build Feature D: 4 weeks, $150K cost, $100K ARR
Cost per feature: $150K each. No leverage.
Platform Work (Compounding Economics):
- Build API Platform: 8 weeks, $300K cost (upfront investment)
- Partner integrates Salesforce: 0 weeks engineering, enables $200K ARR
- Partner integrates Slack: 0 weeks engineering, enables $150K ARR
- Partner integrates Zapier: 0 weeks engineering, enables $100K ARR
Cost for 3 integrations: $300K (for platform). Benefit: $450K ARR.
Math: Platform pays back in 8 weeks, then compounds.
The Allocation Framework by Stage
Stage 1: Early (0-500 customers, <$1M ARR)
Allocation: 90% features, 10% platform
Why: You're proving product-market fit. Features generate immediate revenue. Platform is premature.
Example allocation (10-person team):
- 9 engineers: Build core product features
- 1 engineer: Start thinking about API (but don't build yet)
Exceptions (build platform early if...):
- You're targeting platforms (e.g., Shopify apps)
- Ecosystem is core to your strategy (e.g., Slack apps)
Result: Fast revenue growth, product-market fit confirmed.
Stage 2: Growth (500-5K customers, $1-10M ARR)
Allocation: 60% features, 30% platform, 10% technical debt
Why: Market-fit proven. Customers want integrations / customization. Time to invest in reusable infrastructure.
Example allocation (30-person team):
- 18 engineers: New customer features, product differentiation
- 9 engineers: API, webhook system, SDKs, partner enablement
- 3 engineers: Technical debt paydown (database, infrastructure)
Platform priorities:
- Public API (so partners can build)
- SDKs (makes integration easier)
- Developer documentation
- Marketplace (so partners sell)
Result: Revenue compounds from platform economics. Customer acquisition cost declines (partners help sell).
Stage 3: Scale (5K-50K customers, $10-100M ARR)
Allocation: 40% features, 40% platform, 20% infrastructure/debt
Why: You're competing on ecosystem, not just core product. Platform is equal priority to features.
Example allocation (100-person team):
- 40 engineers: New customer features
- 40 engineers: Platform expansion, integrations, APIs, marketplace
- 20 engineers: Infrastructure, technical debt, security, compliance
Platform priorities:
- Expanding partner ecosystem
- Marketplace revenue (take % from partner revenue)
- Advanced customization (white-label, custom fields, etc.)
- Enterprise integrations (Salesforce, SAP, etc.)
Result: Revenue from direct customers + platform partners. Competitive moat from ecosystem lock-in.
Stage 4: Mature (50K+ customers, $100M+ ARR)
Allocation: 30% features, 50% platform, 20% infrastructure
Why: You're a platform company now, not a product company. Ecosystem revenue exceeds direct revenue.
Example: Salesforce, Slack, Shopify
- Half their engineering is on platform/ecosystem
- Half their revenue comes from App Store partners
- They've become a platform play
Real-World Case Study: Platform vs. Feature Allocation
Company: Workflow SaaS, $20M ARR
Q1 Decision: How to allocate 30 engineers?
Option A: 24 Features, 6 Platform (80/20)
- Benefit: +4 new features shipped (direct revenue impact)
- Cost: Customers still request integrations (manual engineering)
- Year result: $25M ARR (+$5M from features)
Option B: 18 Features, 12 Platform (60/40)
- Benefit: +2 new features shipped, API + marketplace built
- Cost: Initial investment, slower feature velocity
- Year result: $26M ARR (+$2M direct), + $4M from partners = $30M ARR total
Option C: 12 Features, 18 Platform (40/60)
- Benefit: Strong platform, many integrations
- Cost: Only +1 new core feature
- Risk: Customers might complain about feature slowdown
- Year result: $24M ARR (+$1M direct), +$6M from partners = $30M ARR, but angry customers
Decision: Choose Option B (60/40)
Rationale:
- Balance feature velocity (don't alienate customers)
- Invest in platform (unlock partner revenue)
- Net result: $30M vs. $25M (Option A) vs. $24M (Option C)
Lesson: 60/40 is the sweet spot for growth stage.
How to Justify Platform Investment to Leadership
CEO: "Platform work doesn't generate immediate revenue. Why are we investing?"
PM Response (with data):
- "Integration requests: 150+ backlog items."
- "Customer churn reason #3: 'Need Salesforce integration.'"
- "Platform investment payback: 12 months. By month 13, we get $5M ARR from partners, not engineering."
- "Scenario: Without platform, we hire 5 integration engineers (cost: $750K/year). With platform, we hire 0."
- "Decision: Invest $500K in platform (8 engineers, 6 months). Saves $750K/year in perpetuity."
Math: -$500K upfront, +$750K/year savings + $5M partner revenue. ROI: 1000%+ over 3 years.
Anti-Pattern: "Under-Investing in Platform"
The Problem:
- Year 1-2: We ship features, no integrations (fine)
- Year 3: Customers demand integrations. We build 1-off (expensive)
- Year 4: We realize we should have built platform (too late)
- Year 5: We're handcuffed. Want to build platform, but customers demand features
- Result: Stuck in feature hamster wheel, never escape
The Fix:
- As you scale, gradually shift allocation toward platform
- Don't wait until Year 5
Prodinja Connection
The hardest part of platform investment is justifying it to leadership. Platform payback is indirect and delayed — exactly the kind of trade-off Prodinja's RICE/Kano prioritization studio is designed to make explicit. You can score the platform bet and the competing feature requests on the same reach/impact/confidence/effort scale, letting the compounding, delayed nature of platform work show up in how you set impact and confidence, then re-rank live as leadership pushes back on the assumptions. Laying the platform case next to feature requests on identical terms is a more defensible way to walk into that budget conversation than a one-off spreadsheet built just for the meeting.
Key Takeaways (Expanded)
-
Stage determines allocation. Early (90/10), Growth (60/40), Scale (40/60), Mature (30/70) (features/platform).
-
Platform compounds; features are linear. Each new integration built on platform is cheaper than the first.
-
Measure platform ROI carefully. Cost per integration should decline over time. If it's not, platform isn't working.
-
Under-investing in platform creates a ceiling. You'll eventually be stuck building 1-off integrations, which doesn't scale.
-
Justify platform to leadership with ROI. "Platform investment costs $X, saves $Y in engineering, unlocks $Z in partner revenue."