Your coworkers are users too

What three research projects taught me about building internal infrastructure that answers concrete needs

Ten years in, Alan had grown into something new: more countries, more products, more teams. The internal infrastructure that held everything together (payments, messaging, front-end foundations) had been built the right way for its time. Each product team owned their stack, moved fast, and shipped. It worked well, until the scale shifted and the debt started compounding.

That's why Alan funded a Platform team in 2026: to build internal services and foundations which product teams could seamlessly use to stop maintaining their own and enable Alan's scale.

I switched scopes from researching Alan's B2B customers to researching the people who'd actually be using our services: engineers, PMs, ops, marketers. The question I got most often was: "You research our users' problems, so what are you doing on the platform team?"

And it demonstrates one thing that seems common in many companies: internal teams rarely get treated like users. Their problems are assumed to be obvious. Their needs are inferred from Slack messages. Their workarounds are mistaken for satisfaction.

So my answer: I've been doing the same thing as before. Research as a practice. Figuring out what to build, what not to build, based on user needs and problems.

Below are three projects from our first months. We're too early to claim results, but in each case research fed our roadmap for the next year or more.

Our B2B dashboard, used by HR teams, started as a tool for smaller companies and has grown well beyond its original shape. Every new country launch was duplicating front-end code to move fast. That speed came at a cost: maintenance ballooned, and UX consistency across countries started to drift. Operating in 4 countries, we couldn't keep paying that tax. We knew the symptoms but wanted to understand which problems were the real priority before scoping the work.

What surfaced wasn't really a component problem. It was an accountability gap.

We created a cross-platform front-end team focused on UX foundations (product shells, navigation, headers, filtering, loading patterns) with a target modular architecture where features can be easily plugged in. 

What success looks like:

Each product team had its own way to send messages to our end users (emails, push, in-app, SMS), with no shared system across teams. We had problems mapped but no sense of priorities, and we suspected we'd missed some.

The research surfaced something I'd seen before: a system that nobody complains about, because everyone has built their own workaround.

Taken together, these gaps risked eroding user trust over time and quietly undermining the value of what we're building.

We created a team responsible for outbound communication to build reliable and transparent messaging foundations. What success looks like:

We had identified the opportunity to build a Member CRM: a central layer for user data governance that would be the foundation for UX personalization. Before building, we did research to figure out how to approach the problem and test the use cases with the teams who'd actually rely on it.

What the interviews showed was simpler: don't build a cathedral nobody would visit yet. Personalization wasn't even a priority for the teams that would have used it. They had more critical problems to solve, and weren't mature enough yet to leverage that kind of layer. Product teams didn't face data discoverability problems; they were building what they needed for their own use cases. Non-product Alaners did struggle with discoverability, but a CRM wasn't the right answer to that.

So we didn't build it, not yet. The data team picked up the discoverability problem from a different angle, working from the foundations we already had. We saved months of platform effort and redirected it to problems teams actually have. The cathedral isn't off the table forever. The bricks we're laying now are exactly what it will need to stand on when we're mature enough for it.

It's deceptively easy to think you know your internal users. You sit next to them. You've heard them complain. But the workarounds they've built are invisible until you watch them work. The accountability gaps go unnamed until you ask.

So treat them like users. Run the interviews. Anyone can do this. What matters is that someone does, and that the answers change the roadmap.

Up next: research for our future AI Platform. More soon.