Why Your Platform Features Aren't Being Used

I’ve watched platform teams spend months building features nobody uses. The code is clean. The architecture is elegant. The adoption is zero.

The problem isn’t the engineering. It’s that they built the wrong thing.

Most platform teams optimise for technical sophistication over user value. They make assumptions about how users should interact with the system, get fixated on that vision, and when adoption is low, blame the users for “not getting it.”

But platforms don’t succeed because they’re technically impressive. They succeed because users choose to adopt them.

The Trap: Building for Imagined Users

Platform teams often design for an idealised user who doesn’t exist — someone who reads documentation thoroughly, understands the system architecture, and uses features exactly as intended.

Real users are messier. They’re under pressure. They’re learning while shipping. They have mental models shaped by previous tools. They want to solve their specific problem right now, not understand your elegant abstraction.

When you build for the imagined user, you end up with features that make sense to you but confuse everyone else.

Listen to How They Actually Work

Listening isn’t about surveys or roadmap meetings. It’s about:

Watching how they use the platform. Not how you think they should — how they actually do. Where do they get stuck? What do they skip? What workarounds have they invented?

Coffee chats and casual conversations. The best insights come from informal conversations, not formal feedback sessions. People tell you different things when they’re not in “give feedback” mode.

Being present when things go wrong. Failures reveal truth. When something breaks, people tell you what’s actually hard, what they don’t understand, and what they’ve been struggling with silently.

This takes time. It’s easier to build what’s interesting to you than to invest weeks understanding what users actually need. But that investment is what separates platforms people love from platforms people tolerate.

The Feature We Almost Didn’t Build

A VFX artist came to me frustrated. They were trying to render a 16k stereo image through our platform, and it kept failing. The renders were too large for the system to handle in one pass.

I could have said “that’s not a supported use case” or “you should break up your work differently.” Instead, we sat down together and figured it out.

We developed a slicing algorithm that rendered smaller sections of the image, then stitched them back together. It solved their immediate problem.

That feature became the main rendering method used for all shots at the studio. Not because I predicted it would be important — but because I listened to one user’s real problem and we solved it together.

That pattern has repeated itself many times. The features users actually adopt often aren’t the ones you thought would be most valuable.

Three Ways to Do the Same Thing

One thing I learned from an HCI class years ago: the most successful platforms usually have three ways of doing the same operation.

Not because redundancy is good design — but because different users think differently.

Some want a GUI. Some want a CLI. Some want an API. Some want config files. These days, one of those ways is often how AI agents interact with the feature.

Platform teams make assumptions about “the right way” to do something, then get frustrated when users don’t follow it. But there is no single right way. There are multiple valid mental models, and your platform should accommodate them.

Making Users Feel Heard

Here’s what actually works:

Acknowledge the problem, even if you can’t fix it immediately. “Yes, that’s frustrating, here’s why it works that way, and here’s what we’re thinking about” goes further than “that’s not a priority right now.”

Close the loop. When someone gives you feedback and you act on it, tell them. “Remember that issue you mentioned? We shipped a fix.” People notice when their input leads to change.

Invite them into the process. Beta features, early access, design reviews. Give people ways to shape the platform before it’s set in stone. They become invested in its success because they helped build it.

Give credit publicly. When you ship something that came from user feedback, say so. It signals that you’re actually listening — and it makes the next person more likely to speak up.

The Payoff

When you build this way, users become advocates. They tell other teams about the platform because they trust it. They suggest improvements because they believe you’ll listen. The platform evolves with real needs, not imagined ones.

And here’s something platform teams often miss: this approach is faster, not slower. Building the wrong thing wastes more time than listening ever will. You’ll throw away less work. You’ll rebuild less. You’ll spend less time evangelising features nobody wants.

If you’re building a platform and feeling disconnected from users, try this:

1. Sit in on another team’s standup or planning session — don’t speak, just listen
2. Ask someone to “show me how you do X” and watch without correcting them
3. When you ship something from user feedback, say so publicly

The best platforms aren’t the ones with the most features. They’re the ones that solve real problems for real people.