Module 1.3: Platform as Product

Discipline Module | Complexity: [ADVANCED] | Time: 55-65 min

Prerequisites

Before starting this module:

Required: Module 1.2: Developer Experience Strategy — DX measurement and golden paths
Required: Module 1.1: Building Platform Teams — Team structures and hiring
Recommended: SRE: Service Level Objectives — Defining measurable targets
Recommended: Some familiarity with product management concepts

What You’ll Be Able to Do

After completing this module, you will be able to:

Design a platform product strategy with clear user personas, value propositions, and success metrics
Implement product management practices — roadmaps, backlogs, user research — for internal platforms
Build feedback loops that continuously align platform capabilities with developer needs
Evaluate platform ROI by measuring developer productivity, time-to-market, and infrastructure efficiency

Why This Module Matters

At a financial services company in 2021, the infrastructure team was proud of their work. They had built a Kubernetes platform with custom operators, a service mesh, progressive delivery, and automated certificate management. It took 18 months and 8 engineers. They called it “Project Atlas.”

When they presented it to development teams, the first question was: “Can I deploy my Flask app with it?” The answer was: “Well, you need to write a custom resource definition, configure the Istio virtual service, set up the certificate issuer, and then…”

The room went quiet. The development teams went back to their AWS Elastic Beanstalk setup.

Project Atlas was an engineering project, not a product. Nobody had asked developers what they needed. Nobody had tested whether the abstractions made sense. Nobody had defined what “success” looked like beyond “it works.” The team built what was technically interesting, not what was genuinely useful.

Treating your platform as a product means starting with your users’ problems, not your team’s solutions. It means doing user research, prioritizing ruthlessly, measuring adoption, and iterating based on feedback. This module teaches you the product management practices that make the difference between platforms developers love and platforms developers avoid.

The Product Management Mindset for Platforms

You Are Not a Service Bureau

Many platform teams operate in one of two modes:

Mode 1: The Technology Project

Platform team decides what to build based on technical interest
Success = “it works”
Priorities set by the team or their manager
No user research
“If we build it, they will come”

Mode 2: The Service Bureau

Developers file requests, platform team executes
Success = “tickets closed”
Priorities set by whoever screams loudest
User research = reading tickets
“We’ll build whatever you ask for”

Both modes fail. The Technology Project builds things nobody needs. The Service Bureau never builds strategic infrastructure because it is always reactive.

Mode 3: The Product Team (what you want)

Platform team discovers and validates problems through research
Success = adoption rate, developer satisfaction, time-to-production
Priorities set by impact analysis and user data
Regular user research and feedback cycles
“We’ll solve the problems that matter most”

The Product Trio for Platforms

In product management, the “product trio” is:

Role	Responsibility	Platform Context
Product Manager	What to build and why	Platform PM: prioritization, roadmap, user research
Designer	How it looks and feels	Platform DX lead: APIs, CLIs, docs, portal UX
Tech Lead	How it works	Platform tech lead: architecture, implementation

The uncomfortable truth: Most platform teams have a tech lead but no product manager and no designer. This is like building an external product with only engineers. You can do it, but the product will reflect engineering preferences, not user needs.

If you cannot hire a dedicated platform PM, designate someone on the team to own the product function. This person:

Talks to developer teams weekly
Maintains the platform roadmap
Prioritizes based on data, not gut feel
Says “no” to requests that don’t align with strategy
Measures adoption and satisfaction

User Research for Internal Platforms

”But Our Users Are Just Down the Hall”

The most common excuse for skipping user research is proximity. “We don’t need formal research — we talk to developers every day.”

This is wrong for three reasons:

Selection bias: You talk to the developers who come to you. These are the power users and the loudest complainers. You never hear from the silent majority.
Solution framing: When developers come to you, they bring solutions (“I need a bigger database”), not problems (“My queries are slow”). User research uncovers the real problems.
Confirmation bias: Informal conversations reinforce what you already believe. Structured research challenges assumptions.

Research Methods for Platform Teams

Method	Effort	Insight Quality	When to Use
Developer shadowing	High	Very high	Quarterly: sit with a developer for 2 hours and watch them work
User interviews	Medium	High	Monthly: 30 min structured conversations with 5 developers
Surveys	Low	Medium	Quarterly: quantitative trends and NPS tracking
Usage analytics	Low	Medium	Always-on: track what features are used, what’s abandoned
Support ticket analysis	Low	Medium	Monthly: categorize and count request types
Dogfooding	Medium	High	Ongoing: use your own platform for your own development

Developer Shadowing: The Most Underused Method

Sit next to a developer for 2 hours. Don’t help. Just watch and take notes.

What to observe:

Developer Shadowing Notes - [Date] - [Developer Name/Team]
═══════════════════════════════════════════════════════════

Workflow observed: [what they were trying to do]

Time log:
  00:00 - Started task: [description]
  00:05 - Opened [tool/doc]. Searched for [what].
  00:08 - Couldn't find what they needed. Asked colleague on Slack.
  00:15 - Got answer. Switched to [different tool].
  00:22 - Hit error: [description]. Googled it.
  00:30 - Found workaround in old Slack thread.
  ...

Friction points (where they struggled):
  1. [description]
  2. [description]

Tools used: [list]
Context switches: [count]
Time waiting for things: [total]
Times they said "I wish..." or "This should be easier": [count and quotes]

Do this with 3 different teams per quarter. You will learn more in 6 hours of shadowing than in 6 months of assumptions.

Structured User Interviews

Run 30-minute interviews with this script:

Opening (5 min):

“Tell me about the last time you deployed something to production.”
“Walk me through your typical day when you’re building a new feature.”

Exploration (15 min):

“What’s the most frustrating part of your development workflow?”
“If you had a magic wand, what would you change about our internal tools?”
“Tell me about a time you worked around our platform instead of using it.”
“What do you spend time on that you think should be automated?”

Validation (5 min):

“We’re thinking about building [feature X]. Would that help you?”
“How would you prioritize these three improvements: [A], [B], [C]?”

Closing (5 min):

“Anything else we should know about your experience?”
“Can I follow up with you next month?”

The most important rule: Listen more than you talk. If you are talking more than 20% of the time, you are doing it wrong.

Roadmapping and Prioritization

The Platform Roadmap

A platform roadmap is different from a product roadmap in three key ways:

Dimension	Product Roadmap	Platform Roadmap
Time horizon	Quarters	Halves or years (infrastructure changes are slow)
Flexibility	Can pivot quickly	Hard to pivot once infrastructure is deployed
Dependencies	Feature teams depend on you	AND you depend on feature teams to adopt
Success metric	Revenue, engagement	Adoption, satisfaction, reliability

Roadmap Structure

┌────────────────────────────────────────────────────────┐
│              PLATFORM ROADMAP - 2026                    │
├────────────────────────────────────────────────────────┤
│                                                        │
│  NOW (This Quarter)           NEXT (Next Quarter)      │
│  ─────────────────           ──────────────────        │
│  • Self-service DB            • Multi-region support   │
│    provisioning               • Cost dashboards        │
│  • CI pipeline speed          • Secrets rotation       │
│    (target: < 5 min)            automation             │
│  • Improve deploy             • Service mesh           │
│    rollback UX                  (evaluation)           │
│                                                        │
│  LATER (H2)                   EXPLORING                │
│  ──────────                   ─────────                │
│  • Multi-cloud                • WebAssembly runtime    │
│    abstraction                • AI-assisted ops        │
│  • Automated capacity         • Edge deployment        │
│    planning                     support                │
│  • Developer portal                                    │
│    v2                                                  │
│                                                        │
└────────────────────────────────────────────────────────┘

Key principles:

Now: Committed work with clear scope. Teams can depend on this.
Next: Planned but flexible. High confidence, details may change.
Later: Strategic direction. Subject to change based on learning.
Exploring: Ideas being evaluated. No commitment.

RICE Prioritization

RICE is a scoring framework that helps you prioritize objectively:

Factor	Definition	How to Estimate
Reach	How many developers are affected?	Count of teams/developers per quarter
Impact	How much will it help each developer?	3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence	How sure are you about reach and impact?	100% = high, 80% = medium, 50% = low
Effort	How many person-months?	Engineering estimate

RICE Score = (Reach x Impact x Confidence) / Effort

Example prioritization:

Initiative	Reach	Impact	Confidence	Effort	RICE Score
Faster CI pipelines	200 devs	2 (high)	80%	2 months	160
Self-service databases	80 devs	3 (massive)	80%	3 months	64
Service mesh	200 devs	1 (medium)	50%	6 months	16.7
Custom Kubernetes operator	20 devs	2 (high)	100%	4 months	10

In this example, faster CI pipelines wins by a wide margin. Service mesh — despite being technically interesting — scores low because of uncertain impact and high effort. The custom Kubernetes operator serves only 20 developers, making its reach too low to justify prioritization.

Impact Mapping

Impact mapping connects business goals to platform initiatives:

WHY (Goal)                 WHO (Actor)        HOW (Impact)           WHAT (Deliverable)
────────                   ──────────         ──────────             ─────────────────
Reduce time              → Developers       → Deploy faster       → Faster CI pipelines
to production              Product teams      Self-service infra     Service templates
by 50%                     New hires          Faster onboarding      Dev portal + docs

Reduce                   → SRE team         → Fewer incidents     → Automated rollback
production                 On-call devs       Faster recovery        Better monitoring
incidents by 30%           Platform team      Prevent bad deploys    Deploy guardrails

When RICE and impact mapping disagree: RICE is tactical (what to build next). Impact mapping is strategic (what to build this year). Use impact mapping to set the direction, RICE to sequence within that direction.

Success Metrics for Platform Products

The Metrics That Matter

Metric	What It Tells You	Target
Adoption rate	Are teams choosing your platform?	> 80% of eligible teams
Time-to-production	How fast can a team ship?	< 2 hours for new service, < 30 min for changes
Developer satisfaction	Do developers like using it?	NPS > 40, satisfaction > 4/5
MTTR	How fast do you recover from failures?	< 1 hour for platform issues
Self-service ratio	How many requests need human intervention?	> 90% self-service
Onboarding time	How fast can a new developer be productive?	< 3 days from laptop to first deploy
Platform reliability	Is your platform trustworthy?	> 99.9% availability
Support ticket volume	Is your platform easy to use?	Decreasing month over month

Leading vs Lagging Indicators

Leading (predict future success)	Lagging (confirm past success)
Feature usage within first week	Adoption rate at quarter end
Developer NPS trend	Developer retention rate
Support ticket resolution time	Support ticket volume trend
Time-to-first-deploy for new teams	Overall time-to-production
Documentation page views	Self-service ratio

Track leading indicators weekly, lagging indicators monthly. If leading indicators are trending down, you have time to course-correct before lagging indicators confirm the problem.

The Anti-Metric: Feature Count

Never measure platform success by features shipped. A platform team that ships 20 features nobody uses is less successful than a team that ships 3 features everyone adopts. Features are output. Adoption is outcome.

Marketing Your Platform Internally

Why Marketing Matters

“Good products sell themselves” is a myth. Even internal products need marketing because:

Developers are busy and do not read announcements
Switching costs make inertia powerful
Bad first impressions create lasting resistance
Word of mouth is slow for infrastructure tools

Internal Marketing Tactics

Tactic	Effort	Impact	Notes
Weekly changelog	Low	Medium	Email/Slack: what changed this week, with before/after examples
Internal blog posts	Medium	High	Deep dives on how a feature solves a real problem
Demo days	Medium	High	Monthly 30-min live demos of new capabilities
Champions program	High	Very high	Identify advocates in each team, give them early access
Migration success stories	Medium	High	”Team X migrated and reduced deploys from 30 min to 3 min”
Office hours	Low	Medium	Weekly drop-in session for questions and feedback
Slack channel	Low	Medium	Active channel where platform team is responsive
Metrics dashboard	Medium	High	Public dashboard showing platform value (deploy speed, reliability)

The Champions Program

The most effective internal marketing is peer recommendation. A “champions program” formalizes this:

How it works:

Identify 1-2 developers per major team who are enthusiastic about the platform
Give them early access to new features
Include them in design reviews
Train them to help their teammates
Recognize them publicly (shout-outs, swag, whatever your culture supports)

Why it works:

Developers trust peers more than platform teams
Champions provide distributed support, reducing platform team load
Champions give you embedded user research
Champions create social proof (“if Team X uses it, it must be good”)

Common Mistakes

Common Mistake	Why It Happens	Better Approach
Building features without user research	Engineers assume they know what developers need	Interview 5+ developers before starting any major initiative
Measuring success by features shipped	Feature count feels productive and is easy to track	Measure adoption rate, developer satisfaction, and time-to-production instead
Skipping internal marketing	”Good products sell themselves” mindset	Treat every launch like a product launch: changelog, demo day, champions
No product manager on the platform team	Leadership sees platform as “just infrastructure”	Hire or designate a PM; without one, engineering preferences drive priorities
Treating all feedback equally	Loudest voices get priority regardless of impact	Use RICE scoring to prioritize by reach, impact, confidence, and effort
Building for power users only	Power users give the most feedback and are easiest to reach	Shadow average developers; the silent majority has different needs
Roadmap driven by leadership pet projects	Senior leaders push “strategic” initiatives without data	Require concrete business justification and show trade-offs explicitly
Never killing projects	Sunk cost fallacy and fear of admitting mistakes	Set clear success criteria upfront; kill projects that do not meet them

Did You Know?

Gartner predicted that by 2026, 80% of large software engineering organizations will have platform teams acting as internal providers of reusable services and tools. But they also predicted that most will fail to deliver measurable value because they lack product management discipline.

The concept of “internal customers” dates back to the 1980s (Kaoru Ishikawa’s quality management work), but most internal platform teams still don’t treat their users as customers. They treat them as captive audiences who have no choice. This mindset produces bad platforms.

Stripe’s developer experience team applies the same product rigor to their internal tools as they do to their external API. Internal tools go through design reviews, user testing, and beta programs. The result: Stripe consistently ranks as one of the best engineering organizations to work at.

According to McKinsey’s 2023 developer survey, organizations with dedicated platform product managers see 23% higher developer satisfaction and 31% faster time-to-production compared to organizations where platform teams set their own priorities.

Knowledge Check

Question 1

What are the three operating modes for platform teams, and why does “Mode 3: Product Team” outperform the others?

Show Answer

Mode 1: Technology Project — team builds what’s technically interesting. Fails because it ignores user needs.

Mode 2: Service Bureau — team executes whatever developers request. Fails because it is reactive, never builds strategic infrastructure, and priorities are set by whoever is loudest.

Mode 3: Product Team — team discovers and validates problems through user research, prioritizes by impact, and measures success through adoption. Outperforms because it ensures you build the right things (user research), in the right order (prioritization), and know whether they worked (adoption metrics).

Question 2

Why is developer shadowing more valuable than surveys for platform user research?

Show Answer

Developer shadowing reveals problems developers don’t know they have or can’t articulate. When you sit and watch someone work, you see: context switches they’ve normalized, workarounds they’ve automated, time spent waiting that they don’t track, and friction they’ve stopped noticing. Surveys only capture what developers are aware of and can put into words. Shadowing also avoids the “XY problem” — developers asking for solutions (survey responses) rather than describing problems (what shadowing reveals). Both are valuable, but shadowing provides qualitatively richer insights for a platform team trying to reduce friction.

Question 3

Calculate the RICE score: A feature affects 150 developers, has high impact (2), 80% confidence, and requires 4 person-months of effort. Should you build it?

Show Answer

RICE = (150 x 2 x 0.8) / 4 = 60. Whether you should build it depends on what else is on your backlog. A RICE score of 60 is moderate — compare it against other initiatives. If your top item scores 200, this one should wait. If nothing else scores above 40, this is your best bet. RICE is for relative prioritization, not absolute go/no-go decisions. Also validate the assumptions: is the reach really 150? Is the impact really “high”? Low confidence (50%) would drop the score to 37.5.

Question 4

Your platform has 90% adoption, but developer satisfaction is 2.5/5. What’s happening?

Show Answer

High adoption with low satisfaction usually means one of: (1) Mandatory adoption — developers are forced to use the platform and resent it. (2) No alternatives — developers use it because there is nothing else, not because it is good. (3) Legacy lock-in — migration costs are too high to leave, but the experience is poor. (4) Good enough but frustrating — the platform solves the core problem but has poor UX, slow performance, or bad documentation.

The fix depends on root cause: if it is mandatory adoption, you need to invest in UX until satisfaction rises (mandated platforms that developers hate become political liabilities). If it is poor UX, do user research to find the top friction points and fix them. Either way, 2.5/5 satisfaction is a serious problem that will eventually lead to shadow IT, workarounds, and attrition.

Question 5

A senior engineer on your platform team wants to build a custom Kubernetes operator that would solve a problem for 5 teams. RICE score is low (15). How do you handle this?

Show Answer

Have a transparent conversation grounded in data. Share the RICE analysis and explain why higher-scoring items take priority. But also listen — there may be context RICE misses (maybe those 5 teams are the highest-revenue product teams, or maybe the problem is blocking a critical initiative). If the engineer has a compelling case, adjust the Reach or Impact scores accordingly and re-evaluate. If RICE still says no, explain the trade-off clearly: “Building this means not building [higher RICE item]. Are we okay with that?” This is also a career development moment — if the engineer is frustrated by not working on technically interesting projects, address that separately from prioritization.

Question 6

What is a “champions program” and why is it the highest-impact internal marketing tactic?

Show Answer

A champions program identifies enthusiastic developers in each team, gives them early access and training, and empowers them to advocate for and support the platform within their own teams. It is highest-impact because: (1) Developers trust peers more than platform teams. (2) Champions provide distributed, context-rich support. (3) Champions give you embedded user research. (4) Social proof (“Team X loves it”) is more persuasive than any demo. (5) It scales — 10 champions across 10 teams extend your reach without growing your team. The investment is giving champions early access, including them in design reviews, and recognizing their contributions.

Question 7

Scenario: You have a platform roadmap with 4 items. Leadership wants to add a 5th (multi-cloud support) that has a low RICE score but is “strategic.” What do you do?

Show Answer

Do not simply accept or reject. Instead: (1) Ask leadership to articulate the strategic value in concrete terms — “strategic” is not a reason; “we need multi-cloud to close a $10M customer deal” is. (2) Show the trade-off explicitly: “Adding multi-cloud means delaying [item X] by 3 months. Here’s what that costs in developer productivity.” (3) If the strategic case is compelling, add it — but with explicit scope and success criteria. “We’ll build multi-cloud support for [specific use case] and evaluate in 3 months.” (4) If the strategic case is vague (“we might need it someday”), push back with data. RICE exists to prevent exactly this kind of priority distortion.

Question 8

Why should platform teams never measure success by “features shipped”?

Show Answer

Features shipped is an output metric, not an outcome metric. A platform team that ships 20 features nobody uses has delivered zero value. What matters is: (1) Adoption — are developers using what you built? (2) Satisfaction — do they like using it? (3) Efficiency — did it make them faster? (4) Reliability — did it make their services more stable? You can ship one feature that transforms developer productivity or twenty features that collect dust. Feature count incentivizes building more, not building better. It also incentivizes splitting work into small features to inflate the count. Measure outcomes (adoption, satisfaction, time-to-production), not outputs (features, PRs, lines of code).

Hands-On Exercises

Exercise 1: Platform Product Canvas (45 min)

Complete this canvas for your platform (or a platform you plan to build):

┌────────────────────────────────────────────────────────┐
│                 PLATFORM PRODUCT CANVAS                  │
├────────────────────────────────────────────────────────┤
│                                                         │
│  USERS                     PROBLEMS                     │
│  ─────                     ────────                     │
│  Who uses our platform?    What problems do they have?  │
│  •                         •                            │
│  •                         •                            │
│  •                         •                            │
│                                                         │
│  ALTERNATIVES              VALUE PROPOSITION            │
│  ────────────              ─────────────────            │
│  What do they use today?   Why is our platform better?  │
│  •                         •                            │
│  •                         •                            │
│  •                         •                            │
│                                                         │
│  KEY METRICS               UNFAIR ADVANTAGE             │
│  ───────────               ────────────────             │
│  How do we measure         What can we do that nobody   │
│  success?                  else can?                    │
│  •                         •                            │
│  •                         •                            │
│  •                         •                            │
│                                                         │
│  CHANNELS                  COST STRUCTURE               │
│  ────────                  ──────────────               │
│  How do users find and     What does the platform cost  │
│  adopt the platform?       to build and run?            │
│  •                         •                            │
│  •                         •                            │
│  •                         •                            │
│                                                         │
└────────────────────────────────────────────────────────┘

Validation: Share the canvas with 3 developers. Ask: “Does this accurately describe your experience?” Revise based on feedback.

Exercise 2: User Interview Practice (40 min)

Conduct a mock user interview with a colleague (or a real one if you have access to a developer team):

Preparation (10 min):

Write down your 3 biggest assumptions about what developers need
Create 5 open-ended questions designed to validate or challenge those assumptions
Prepare a notepad for observations

Interview (20 min): Follow the interview script from the “Structured User Interviews” section. Record key quotes.

Synthesis (10 min):

Interview Synthesis - [Date]
════════════════════════════

Top 3 pain points mentioned:
  1. [quote + context]
  2. [quote + context]
  3. [quote + context]

Surprises (things I didn't expect):
  1.
  2.

Assumptions validated:
  [+] [assumption] — confirmed by [evidence]
  [-] [assumption] — contradicted by [evidence]

Actions:
  1. [what to investigate further]
  2. [what to change based on this interview]

Exercise 3: RICE Prioritization (30 min)

Take your current platform backlog (or create a fictional one of 8-10 items) and score each using RICE:

Initiative	Reach	Impact	Confidence	Effort	RICE

After scoring:

Sort by RICE score
Compare with your current priority order
Identify the biggest discrepancy (something you ranked low that RICE ranks high, or vice versa)
Discuss: Is RICE right, or is there context RICE misses?

Exercise 4: Internal Marketing Plan (30 min)

Create a 90-day marketing plan for your platform’s next major feature:

Feature: [name]
Target audience: [which teams]
Launch date: [date]

Pre-launch (30 days before):
  Week 1: [ ] Identify 3 champion teams for beta
  Week 2: [ ] Beta launch with champions
  Week 3: [ ] Collect feedback, iterate
  Week 4: [ ] Create success story from beta team

Launch (week of):
  [ ] Blog post with problem/solution narrative
  [ ] Demo day presentation
  [ ] Slack announcement with key metrics
  [ ] Documentation published
  [ ] Migration guide ready

Post-launch (60 days after):
  Week 1-2: [ ] Office hours for early adopters
  Week 3-4: [ ] Publish adoption metrics
  Week 5-6: [ ] Champions help next wave of teams
  Week 7-8: [ ] Retrospective: what worked, what didn't

Success criteria:
  [ ] X teams adopted within 30 days
  [ ] Developer satisfaction > Y/5
  [ ] Support tickets < Z per week

War Story: The Platform That Saved Itself With Product Management

Company: B2B SaaS company, ~600 engineers, 45 services

Situation: The platform team (8 engineers) had been building for 2 years without a product manager. They had a sophisticated CI/CD system, a Kubernetes abstraction layer, and an observability stack. But adoption was stagnating at ~50% of teams, and the CTO was questioning the team’s value.

The intervention: The company hired a platform product manager. Her first 30 days:

Week 1: Discovery

Interviewed 15 developers across 8 teams
Shadowed 3 developers for 2 hours each
Analyzed 6 months of support tickets
Reviewed platform usage analytics

Key finding: The platform’s biggest problem was not missing features. It was that the 50% of teams who had not adopted were not even aware of what the platform offered. The team had never done internal marketing. Features existed but were undiscoverable.

Second finding: The features developers wanted most were not what the platform team was building. Developers wanted faster CI (averaging 18 minutes), easier rollback (currently a manual 7-step process), and better documentation. The platform team was building multi-cloud abstraction.

Week 2-3: Strategy

Created a platform product canvas
Built a RICE-prioritized roadmap
Killed the multi-cloud project (RICE score: 8. Faster CI score: 240)
Defined success metrics: adoption rate, time-to-deploy, NPS

Week 4: Execution kickoff

Launched a weekly changelog (Slack + email)
Created a champions program with 6 developer advocates
Started a monthly demo day
Began work on CI speed (18 min → target 5 min)

Results after 6 months:

Adoption: 50% → 78%
CI pipeline time: 18 min → 6 min
Deploy rollback: 7 manual steps → 1 command
Developer NPS: 12 → 48
Support tickets: Down 40%

Business impact: The CTO went from questioning the team’s existence to expanding it by 4 headcount. Two product teams attributed faster feature delivery directly to platform improvements. Estimated productivity gain: 15% across adopting teams.

Timeline:

Month 0: PM hired
Month 1: Discovery and strategy
Month 2: Quick wins (changelog, champions, docs)
Month 3-4: CI speed improvement
Month 5: Rollback UX improvement
Month 6: Measure results, plan next cycle

Lessons:

Product management transforms platform teams: The same 8 engineers delivered dramatically more value with product direction
Discovery before delivery: 30 days of research prevented months of wasted work (multi-cloud)
Marketing is not optional: If developers don’t know about your platform, it doesn’t exist
Measure adoption, not features: Features shipped means nothing; adoption means everything
Kill projects ruthlessly: The multi-cloud project was 4 months in. Killing it was painful but correct

Summary

Treating your platform as a product means applying the discipline of product management to internal infrastructure. This includes user research (shadowing, interviews, surveys), strategic prioritization (RICE, impact mapping), clear success metrics (adoption, not features), and intentional marketing (champions, demos, changelogs).

Key principles:

Start with problems, not solutions: User research before engineering
Prioritize by impact: RICE over gut feel or technical interest
Measure adoption: The only metric that proves platform value
Market internally: If developers don’t know about it, you didn’t build it
Kill projects: If RICE says no, stop — even if it is technically interesting
Hire a product manager: Or designate someone to own the product function

What’s Next

Continue to Module 1.4: Adoption & Migration Strategy to learn how to drive adoption of your platform and manage migrations from legacy systems.

“The best internal platform is one that developers choose to use, recommend to peers, and miss when it’s gone.”