Platform Teams Need Designers and PMs, But Most Orgs Can't Afford It—Practical Strategies for Small Teams?

vp_eng_keisha · March 22, 2026, 10:43am

Okay, I’ve been reading this whole thread and there’s consensus emerging:

UX matters more than tech stack
Platform PMs and designers are valuable
Product thinking drives adoption
Competition creates accountability

But here’s the practical reality: Most platform teams are 2-4 infrastructure engineers who can’t afford dedicated Platform PMs or designers.

So what can resource-constrained teams actually DO about platform UX without big product/design hires?

The Constraint We’re All Working With

Let’s be honest about the typical platform team:

Typical setup:

2-4 engineers with infrastructure background
Report to VP of Engineering or CTO
Measured on uptime and deployment frequency
No dedicated PM or designer
Expected to serve 50-150 developers

Budget reality:

Startup <100 engineers: Can’t justify dedicated Platform PM
Midsize 100-300 engineers: Maybe 1 PM shared across teams
Only large orgs >500 engineers: Can afford full platform product team

My Question to This Community

What can small platform teams do to improve UX without full product/design hires?

I’m considering these approaches:

Option 1: “Borrow” Design Resources

Partner with product design team for 10% time (4 hours/week)
Designer helps with portal UX, mental models, decision trees
Cheaper than full hire, but is 4 hours/week enough?

Option 2: Train Engineers in UX

Send platform engineers to UX courses
Read books (Don’t Make Me Think, Design of Everyday Things)
Practice with cognitive walkthroughs
Can engineers develop enough UX sense to avoid major mistakes?

Option 3: Hire Technical Writers

Technical writers understand structure and clarity
Cheaper than designers (~$100K vs $140K)
Can improve docs, onboarding, mental models
But don’t typically do UX design

Option 4: External Consultants

Hire consultant for initial UX audit (3 months, ~$30-50K)
Get roadmap of improvements
Implement internally
Use findings to justify future PM hire

Option 5: Partner With Product Teams

“We’ll build deployment platform if you help us design it”
Product team has designers who can consult
Creates mutual value exchange
But are product teams willing to invest time?

What’s Worked at Our EdTech Startup

We’re at 80 engineers, so right in that “can’t afford full Platform PM” zone.

Here’s what we tried:

Q1-Q2: Paired 1 platform engineer with 1 product designer for 2 weeks

Designer taught: mental models, user research, basic UX principles
Engineer applied it to platform portal redesign
Result: 3x better than pure engineering-led, not perfect but usable

Q3-Q4: Platform engineer rotation through product teams

Each engineer spends 1 week per quarter shadowing product team
Experiences platform as user
Returns with empathy and insights
Cost: 1 week per quarter = 2% capacity
Return: Massive improvement in adoption

Ongoing: Platform office hours every Friday

Developers drop in with questions
Platform team learns what’s confusing (free user research)
Builds relationships and trust
Also tracks Slack questions as proxy metric

Result: Platform adoption went from ~40% to ~75% in 6 months, without hiring PM or designer.

But I’m Curious What Others Are Doing

For small platform teams: How are you approaching product/UX thinking without dedicated hires?

For those who’ve scaled this: At what point did you hire a Platform PM? What was the tipping point?

For designers/PMs: If platform team approached you for part-time partnership, what would make that compelling vs. annoying?

I’m convinced you don’t need perfect UX—you just need to avoid the worst mistakes. But I’m trying to figure out the most leveraged way to do that with constrained resources.

Looking for practical strategies that small teams can actually execute.

eng_director_luis · March 22, 2026, 10:43am

@vp_eng_keisha - Facing the exact same constraint. Here’s what’s actually working for us.

Shadowing Sprints: Highest ROI Technique

Your rotation idea is spot-on. We do something similar:

“Shadowing Sprint” (1 week per quarter per engineer):

Platform engineer spends full week with product team
Doesn’t build platform features during this time
Just observes how developers use (or struggle with) platform
Takes extensive notes, doesn’t help (hardest part!)
Documents top 10 friction points

Sprint after shadowing:

Team reviews friction points
Picks top 3 most impactful
Implements fixes that sprint
Measures adoption improvement

Why this works:

Builds empathy better than any training
Discovers real problems (not theoretical ones)
Engineers see why UX matters firsthand
Cost: 1 week per quarter = 2% capacity
Return: Adoption improved 40% → 70% over 2 quarters

Platform Office Hours: Free User Research

We copied this from your playbook:

Every Friday, 2-4pm: Platform Office Hours

Developers can drop in with:

Questions about how to use platform
Problems they’re hitting
Feature requests
Complaints

What we learn:

Recurring questions = poor documentation
Same confusion from multiple people = UX problem
Feature requests = gaps in platform capabilities
Time spent per developer = platform complexity metric

Side benefit: Builds relationships. Developers see platform team as helpful partners, not distant infrastructure team.

Practical Techniques That Don’t Require Design Skills

1. Cognitive Walkthroughs (Free, Powerful)

Watch developer try to complete task with platform
Don’t help them
Just observe and take notes
Where do they get stuck? Where do they give up?
Fix those friction points

2. “5 Whys” for Platform Friction

Developer complains about platform
Ask “why?” 5 times to find root cause
Usually reveals UX problem, not technical problem

Example:

Dev: “Deployment is too slow”
Why? “Because I have to wait for approval”
Why? “Because I don’t know how to self-approve”
Why? “Because docs don’t explain approval process”
Why? “Because docs assume I know what ‘deployment gate’ means”
Root cause: Terminology not explained, docs assume knowledge

3. README-Driven Development

Before building feature, write the README
How would developer discover this?
How would they use it?
What questions would they have?
If README is confusing, feature design is probably wrong

Low-Cost Resources for Engineers Learning UX

You mentioned books. Here’s what actually helped our team:

Books (total: ~$100, 2-3 weeks reading time):

“Don’t Make Me Think” by Steve Krug (UX fundamentals, 200 pages)
“The Design of Everyday Things” by Don Norman (mental models, affordances)
“The Mom Test” by Rob Fitzpatrick (user research, asking good questions)

Courses (~$200/year per person):

Interaction Design Foundation (comprehensive, affordable)
Practical UX for developers

Practice:

Cognitive walkthroughs (free, do weekly)
Usability testing (watch people use your platform, don’t help)

Total investment: ~$300 + 20 hours/engineer learning time.

Compare to Platform PM: $200K + 6 months ramp time.

My Recommendation: Start Small, Prove Value, Scale

Months 1-3: Shadowing + Office Hours

Implement shadowing sprints
Run weekly office hours
Track Slack questions as metric
Cost: Minimal. Just time reallocation.

Months 4-6: Fix Top Friction Points

Use insights from shadowing
Implement top 3-5 improvements
Measure adoption change

Months 7-9: Add Lightweight Design Partnership

If adoption improved, approach product design team
Ask for 10% time (4 hours/week) for 1 quarter
Designer helps with portal information architecture
Platform team prioritizes design team’s infrastructure needs (value exchange)

Months 10-12: Make Business Case for Platform PM

Use data from previous 9 months
Show adoption improvement (40% → 70%)
Quantify productivity gains
Argue: “We proved product thinking works. Now we need dedicated capacity.”

This sequence proves ROI before asking for budget.

Keisha, your rotation approach is genius. Copying it immediately.

maya_builds · March 22, 2026, 10:43am

@vp_eng_keisha - Love that you’re asking about realistic constraints! Too many discussions assume unlimited budgets.

Design on a Budget: What Actually Works

First: Don’t try to hire a designer. Partner with your existing design team.

The Pitch to Design Leadership

Wrong pitch: “Can we borrow a designer sometimes?”
Right pitch: “Platform affects all product teams. Deserves design investment.”

Propose: Designer allocated 10% time (4 hours/week) for platform UX in exchange for platform team prioritizing design team’s infrastructure requests.

This creates mutual value exchange, not one-way favor.

What 10% Designer Time Can Accomplish

Month 1-2: Information Architecture

Designer audits current platform portal
Identifies structural issues (not visual polish)
Creates sitemap showing how developers should navigate
Defines “golden paths” for common tasks

Month 3-4: Decision Trees

For each platform capability, create decision tree
“I want to deploy” → Answer these questions → System guides you
This is 80% of the value, requires no visual design

Month 5-6: Onboarding Journey

Map new developer’s first week with platform
Identify confusion points
Create step-by-step guide
Test with actual new hire

Result: Platform goes from “technically good” to “actually usable” with just 4 hours/week of design time.

Free/Cheap Resources for Engineers

Luis mentioned books. Here are specific resources that helped engineers on my team:

Books (~$80 total)

“Don’t Make Me Think” (Steve Krug) - UX fundamentals, very practical
“The Mom Test” (Rob Fitzpatrick) - How to do user research without designer
“Mapping Experiences” (Jim Kalbach) - Journey mapping for non-designers

Online Learning (~$39/month)

Interaction Design Foundation - Comprehensive UX courses
Practical UX for Developers (various platforms)

Free Techniques You Can Do Tomorrow

Cognitive Walkthroughs:

Pick a task (e.g., “Deploy new service”)
Watch colleague try to complete it
Don’t help them. Just observe.
Note every point where they hesitate or get confused
Fix those points

5-Second Tests:

Show platform portal screenshot for 5 seconds
Ask: “What is this page for?”
If they can’t answer, your information hierarchy is wrong

First-Click Tests:

Give developer a task: “You want to deploy. Where do you click?”
If they don’t click right place immediately, your navigation is wrong

These cost zero dollars. Just time.

Real Example: Design System UX Improvement

We did this with our design system (which is platform for designers):

Before (engineer-designed):

Homepage listed all components alphabetically
Developers had to know component names
No guidance on which component to use when
Adoption: 40%

After (10% designer time for 2 months):

Homepage organized by use case: “Buttons”, “Forms”, “Feedback”, “Navigation”
Each section has decision tree: “Need a button? Primary or secondary? With icon?”
Guides you to right component
Adoption: 85%

Designer’s time investment: 8 hours/week for 8 weeks = 64 hours total
Result: Doubled adoption, dramatically reduced support questions

Same approach works for platform engineering.

My Practical Recommendation

Phase 1 (No budget, just time):

Run cognitive walkthroughs weekly
Track Slack questions (proxy for UX problems)
Have engineers read “Don’t Make Me Think” (200 pages, 1 week)

Phase 2 (Small budget: ~$500):

Sign up for Interaction Design Foundation ($39/month)
Buy key books
Run structured user research with 5 developers

Phase 3 (Proven value, ask for designer time):

Approach product design lead
Show data: “We improved adoption 40% → 60% with basic UX fixes”
Ask for 10% designer time to go from 60% → 80%
Offer value exchange: prioritize design team’s infra needs

Phase 4 (If designer partnership works, go for PM):

Use combined data from UX improvements
Make business case for dedicated Platform PM
By this point, you have ROI proof

The Key Insight

Platform engineers can learn enough UX to avoid major mistakes. You won’t create perfect experiences, but you’ll create usable ones.

Perfect is the enemy of good enough. Most platforms just need to be “not confusing”—that’s already a huge win.

Keisha, happy to share our design system improvement playbook. Lots of parallels to platform UX.

product_david · March 22, 2026, 10:43am

@vp_eng_keisha - Let me add the business case perspective for getting budget.

Framing the ROI for Leadership

The challenge isn’t that Platform PMs/designers aren’t valuable. It’s that leadership doesn’t see the cost of NOT having them.

Here’s how to make the invisible costs visible:

Document the Productivity Tax

Current state math:

50 engineers using platform
Poor platform UX wastes 2 hours/week/engineer (conservative)
100 hours/week wasted = 2.5 FTE
At $150K average salary = $375K/year in hidden productivity loss

Proposed state:

Hire Platform PM at $200K or partner with designer at ~$50K/year (10% time)
If UX improvement reduces friction by 30%, saves $112K/year
If by 50%, saves $187K/year
PM pays for itself in 18-24 months through productivity alone

But this undersells it because it doesn’t capture:

Velocity: faster shipping = faster revenue
Retention: good DX reduces turnover (each engineer leaving costs ~$100K to replace)
Innovation: developers spending time on features, not fighting tools

The Pilot Approach to De-Risk Investment

If leadership won’t approve $200K Platform PM, propose pilot:

Phase 1: 3-Month Consultant Audit (~$30-50K)

External Platform UX consultant
Interviews 10-15 developers
Audits platform, documents friction points
Delivers roadmap of improvements

Phase 2: Implement Recommendations Internally

Platform team executes roadmap
Tracks adoption improvement
Measures productivity gains

Phase 3: Use Data to Justify Full-Time Hire

“Consultant found $375K/year productivity tax”
“We implemented fixes, adoption improved 40% → 65%”
“Full-time Platform PM will maintain gains and find more opportunities”
Much easier sell with concrete data

Alternative: Contractor Before FTE

6-Month Contract Platform PM (~$100-120K):

Lower commitment than FTE
Prove the value
Convert to FTE if successful
Walk away if doesn’t work

We did this at my startup. After 3 months:

Adoption: 30% → 65%
Developer satisfaction survey: 2.8/5 → 4.1/5
Slack support questions: 40/week → 12/week

Leadership immediately approved FTE conversion.

Making the Case to Product Design Team

Keisha asked how to make designer partnership compelling vs. annoying.

Wrong approach: “We need help making our platform pretty”
Right approach: “Platform affects all product teams. Design investment here multiplies across org.”

Value Exchange Proposition

What platform team offers design team:

Prioritize design team’s infrastructure needs
Build tools that make designers more productive
Give design team influence over developer experience org-wide

What design team offers platform team:

10% designer time (4 hours/week)
Information architecture expertise
User research skills
Decision tree / mental model design

Why this works: It’s partnership, not favor. Both teams get value.

Measuring Success

Track these metrics to show design partnership is working:

Before designer involvement:

Platform adoption: 40%
Support Slack questions: 35/week
Time-to-first-deploy: 2 days

After 3 months with 10% designer:

Platform adoption: 60%
Support questions: 18/week
Time-to-first-deploy: 4 hours

Share these results with:

Design leadership (shows impact of design investment)
Engineering leadership (justifies future Platform PM)
Product teams (demonstrates platform team is improving)

My Sequenced Recommendation

Quarter 1 (Prove product thinking works):

Shadowing sprints (Luis’s suggestion)
Office hours (Keisha’s approach)
Cognitive walkthroughs (Maya’s free technique)
Track metrics: adoption rate, support questions

Quarter 2 (Scale with design partnership):

Approach design team with value exchange
10% designer time for information architecture
Implement decision trees and golden paths

Quarter 3 (Build business case):

Document productivity savings
Show adoption improvement
Survey developer satisfaction
Calculate ROI

Quarter 4 (Request budget):

Propose contractor Platform PM (de-risk with 6 months)
Use Q1-Q3 data to justify
Frame as “We proved this works, now need dedicated capacity”

This sequence:

Starts with zero budget
Proves value incrementally
Uses data to justify investment
De-risks with contractor before FTE

Most leadership teams will approve this path even if they won’t approve upfront Platform PM hire.

Keisha, the key is making the invisible costs visible. That’s what unlocks budget.

cto_michelle · March 22, 2026, 10:43am

@vp_eng_keisha - Adding the strategic lens on when to invest in platform UX at different company stages.

Platform UX Investment by Company Size

Too many companies either invest too early (waste) or too late (cultural damage). Here’s my framework:

Startups <50 Engineers

Platform team: Usually doesn’t exist yet. Engineers self-service.

UX investment: None. Not worth it yet.

Why: At this stage, platform is minimal (maybe shared CI/CD config). Engineers talk to each other directly. Overhead of formal platform UX exceeds benefits.

Exception: If you’re building developer tools as product, then UX matters from day one.

Growing 50-150 Engineers

Platform team: 2-4 engineers emerge to handle shared infrastructure.

UX investment: Platform engineers learn basic UX themselves.

Approach:

Shadowing/office hours (Keisha’s & Luis’s approaches)
Cognitive walkthroughs (free, high-value)
Books/courses (~$500/year per engineer)
10% designer partnership if you can negotiate it

Why: Full Platform PM not yet justified by team size, but UX problems start appearing. Self-service approach (engineers learning UX) is right level of investment.

Risk: Platform team builds technically excellent but unusable tools. This creates cultural debt that’s expensive to fix later.

Scaling 150-300 Engineers

Platform team: 4-8 engineers, maybe splitting into sub-teams (CI/CD, observability, etc.)

UX investment: Part-time Platform PM (50%) or full-time Platform PM.

Why: At this scale, poor platform UX costs $300-500K/year in productivity. Platform PM pays for itself.

Approach:

Start with contractor (6 months, de-risk investment)
Convert to FTE if successful
PM owns adoption metrics, user research, roadmap prioritization
Engineers still build, but with product guidance

Critical threshold: This is when you MUST invest in Platform PM or accept ongoing productivity tax.

Enterprise 300+ Engineers

Platform team: 10-20+ engineers, multiple sub-teams, clear product areas.

UX investment: Full platform product team (PM + Designer + Technical Writer).

Why: Platform serves hundreds of developers across dozens of teams. UX complexity justifies dedicated roles.

Team structure:

1 Platform PM per 100 engineers served (e.g., 400 engineers → 4 Platform PMs)
1 Designer per 3-4 PMs
1-2 Technical Writers for documentation
Engineering ratios depend on platform complexity

At this scale: Platform team functions like internal product company.

The Timing Mistake Most Companies Make

Too early: Hire Platform PM when team is 30 engineers
→ PM has nothing to manage, ends up doing IC work, leaves frustrated

Too late: Wait until 200 engineers and platform adoption crisis
→ Cultural damage done, developers don’t trust platform team, harder to recover

Right timing: Invest when you hit inflection points:

50 engineers: Platform engineers learn UX
100 engineers: Add 10% designer partnership
150 engineers: Hire part-time or contractor Platform PM
200 engineers: Convert to full-time Platform PM
300+ engineers: Build full platform product team

ROI Changes by Scale

At 50 engineers:

Platform PM cost: $200K
Productivity unlock: Maybe $150K (50 engineers × 3% efficiency × $100K avg salary)
ROI: Marginal, probably not worth it

At 150 engineers:

Platform PM cost: $200K
Productivity unlock: $450K (150 engineers × 3% efficiency × $100K avg salary)
ROI: Pays for itself in first year, strong return

At 300 engineers:

Platform PM cost: $200K
Productivity unlock: $900K (300 engineers × 3% efficiency × $100K avg salary)
ROI: 4.5x return, no-brainer investment

This is why timing matters.

The Cultural Investment Question

Beyond ROI, there’s cultural dimension:

Investing in platform UX signals:

We care about developer experience
Internal tools matter as much as external products
Platform team is service org, not infrastructure silo

Not investing signals:

Developers should just figure it out
Platform team builds for ops, not for developers
Developer productivity isn’t a priority

These cultural signals compound over time.

I’ve seen companies lose excellent engineers because internal tooling was frustrating. That’s $100K+ per engineer to replace, plus institutional knowledge loss.

My Recommendation for Keisha’s Situation

You’re at 80 engineers. Right in the “too early for Platform PM, but UX matters” zone.

Immediate (Q1):

Platform engineers learn UX (books, courses, shadowing)
Office hours + cognitive walkthroughs
Track adoption and support questions

Near-term (Q2-Q3):

10% designer partnership (prove value of design thinking)
Measure improvement in adoption

Medium-term (Q4 or next year):

When you hit 100-120 engineers, hire contractor Platform PM
6-month contract, prove ROI
Convert to FTE if successful

Long-term (150+ engineers):

Full-time Platform PM + consider designer
Build platform as product organization

This phased approach matches investment to company stage and proves value incrementally.

Keisha, you’re at exactly the right stage for the “learn UX yourself + designer partnership” approach. Platform PM can wait until 100-120 engineers.