Luis, reading this hit way too close to home. My failed startup basically died because we built something “technically impressive” that nobody actually wanted to use. We had all the metrics showing success—except the one that mattered: genuine user adoption.
Let me share the design perspective that might be your missing piece.
Your 82% Adoption Might Be Fake
I know that sounds harsh, but hear me out.
At my startup, we had “80% adoption” of our B2B platform. We celebrated. Investors were happy. And then we started doing user interviews.
Turns out: Teams were using our platform because their CTO mandated it, not because it made their lives better. They’d use the bare minimum required, then route around it for anything complex.
Sound familiar?
Here’s the design systems parallel: We had 90% “adoption” of our design system at my current company. But when I ran user research, I discovered developers were:
- Copy-pasting components instead of using them properly (tech debt bomb)
- Using only 2-3 basic components out of 40+ available
- Building custom solutions when our components didn’t quite fit their needs
We had high adoption but low quality adoption. The platform wasn’t truly solving their problems.
The UX Research You’re Not Doing
Platform teams often make the same mistake product teams made 15 years ago: Build it and they will come.
No. Build the right thing and they will come.
Here’s what I’d do:
Interview your non-users (the 18%)
Why aren’t they using the platform? Common answers I’ve heard:
- “Too complicated for our use case”
- “Doesn’t support the specific thing we need”
- “We tried it but hit a wall and gave up”
- “Documentation assumes we know stuff we don’t”
These answers tell you whether you have a product problem, a documentation problem, or a training problem.
Interview your shallow users
Find teams using only 1-2 platform features. Ask:
- “Why haven’t you explored other features?”
- “What would you need to use more of the platform?”
- “What’s stopping you from going deeper?”
Interview your power users
Find the teams using 5+ features. Ask:
- “What made you adopt the platform so deeply?”
- “What was the tipping point?”
- “What features deliver the most value?”
This tells you what’s working and helps you double down on it.
Platform Adoption Is a UX Problem
I’m going to say something controversial: Your platform probably has terrible UX.
Not because your engineers are bad—they’re brilliant. But because they’re building for themselves (expert users) not for tired frontend developers at 3pm who just want to ship a feature.
Signs of poor platform UX:
- Documentation assumes advanced knowledge
- Error messages are cryptic
- No “quick start” guides for common scenarios
- CLI commands are hard to remember
- Platform requires reading 10 pages of docs to do basic tasks
Design system example:
Our adoption jumped from 12% to 54% in 8 weeks after we:
- Created “5-minute quick starts” for common patterns
- Rewrote error messages in plain English
- Built interactive demos in CodeSandbox
- Added visual examples (not just code)
- Created a “troubleshooting” section for common issues
We didn’t change the components. We changed the experience of using the components.
The ROI Metric You’re Missing: Cognitive Load
CFOs care about dollars, but developers care about how exhausting their job is.
Platform should reduce cognitive load, not just technical complexity.
Questions to measure this:
- “On a scale of 1-10, how mentally exhausting is it to deploy code?” (before vs after platform)
- “How often do you feel blocked by infrastructure issues?” (daily/weekly/monthly/rarely)
- “How confident are you that your code will deploy successfully on first try?” (before vs after)
We tracked this at my company:
Before platform:
- Exhaustion score: 7.2/10
- Feel blocked: 3.8 times per week
- First-deploy confidence: 42%
After platform:
- Exhaustion score: 3.1/10
- Feel blocked: 0.4 times per week
- First-deploy confidence: 87%
That’s the ROI story CFOs might not ask for, but it drives retention, productivity, and morale.
The Hero Stories You Need
David is absolutely right about case studies, but let me add the designer perspective: Make them visual and emotional.
Bad case study format:
“Team X used platform feature Y and reduced deployment time by Z%”
Good case study format:
“Team X was missing ship dates and morale was low. Every deployment was a 4-hour ordeal with manual steps and frequent rollbacks. After adopting platform deployment automation, they ship in 8 minutes with 98% success rate. Team lead Sarah says: ‘We went from dreading deployments to shipping confidently three times a day. This changed how our team works.’”
See the difference?
- Opens with the pain (CFOs understand pain)
- Shows the transformation (not just metrics)
- Includes human voice (makes it real)
- Ends with behavioral change (not just technical improvement)
Your 90-Day Plan Should Include Design Thinking
I’d add this to what Michelle, Keisha, and David suggested:
Week 1-2: Run empathy interviews
- Talk to 10-15 developers across different teams
- Don’t ask “do you use the platform?”—watch them actually use it
- Note: Where do they struggle? Where do they give up?
Week 3-4: Create developer personas
- Who are your users? (Not “developers”—be specific)
- Frontend devs vs backend vs fullstack vs DevOps—they have different needs
- What are their pain points, goals, and constraints?
Week 5-6: Map the user journey
- How does a developer go from “I need to deploy” to “successfully deployed”?
- Where are the friction points?
- What would make it delightful instead of just functional?
Week 7-8: Fix the top 3 UX issues
- Based on research, what are the biggest barriers to adoption?
- Often it’s: documentation, error messages, or onboarding
- Quick wins that dramatically improve experience
Week 9-12: Measure behavior change
- Are teams using more features?
- Are support requests going down?
- Are developers recommending platform to peers?
The Hard Question: Is Your Platform Actually Good?
I’m going to be direct because someone needs to say it:
82% adoption doesn’t mean your platform is good. It might just mean your developers are obedient.
Questions to diagnose:
- If platform usage were voluntary, would people still use it?
- Do developers talk positively about the platform in casual conversations?
- When you ask “what could we improve?”, do they have thoughtful answers or blank stares?
If developers can’t articulate what they’d improve, they probably haven’t engaged deeply enough to care.
The Startup Failure Lesson I Learned
At my failed startup, we had great metrics. We had happy investors. We had technical excellence.
What we didn’t have: Users who genuinely loved what we built.
They tolerated it. They used it because their boss made them. But they didn’t want to use it.
When our biggest customer churned, they were honest: “Your platform is technically impressive, but it doesn’t make our lives better. It makes them more complicated.”
That was the moment I learned: Adoption without enthusiasm is a ticking time bomb.
My Challenge To You
Before you fight for your platform budget, ask yourself:
Do your developers love this platform, or do they tolerate it?
If it’s “tolerate,” you have work to do beyond ROI metrics.
Go talk to your users. Not in a survey. Not in a Slack poll. Actually sit with them, watch them work, understand their world.
You might discover your platform is genuinely valuable and you just need better storytelling.
Or you might discover you built the wrong thing and need to pivot.
Both are better than defending a platform nobody truly wants.
What would happen if you made platform usage completely optional for 30 days and tracked what people actually use vs abandon?