Part 2: The Room Has Failed the User Research Test

// build without them, and you've already failed + technomancer tuesday soft launch

/* Today’s oracle: The Room, Reversed.

Myopic rooms produce flawed results. In today’s article, I will be using a product management method called storywriting. Stories are the translation layer between user problems and net new functionality and fixes.

Technomancer describes a person who blends magic or supernatural forces with advanced technology. Technomancer Tuesdays lean hardest into the bridge between the technical and the human. */

---

In product management, talking to your users isn’t optional. It’s the foundation of everything that ships. Build without them, and you’ve already failed.

Somehow, we’ve normalized building institutions, policies, and technology without the people they’re designed to serve in the room. We call that a diversity problem. I call it a failure. It’s a user research problem. Who are you building for? If the room doesn’t reflect the answer, the room has failed. If the room reflects the answer, but the room is one-dimensional, the room has failed because the perception of who is needed is flawed — not by moral standards, but by the same professional standards we already hold ourselves to in product and technical spaces.

The Failure Is Never Dramatic

It rarely looks like a villain. Nobody sits in a meeting and decides to exclude anyone on purpose. It looks smaller than that, and quieter. A feature nobody asked for. A policy written for a user who doesn’t exist. A tool that solves the builder’s problem instead of the user’s needs, because the builder was the only perspective in the room for the discussing and decisioning.

In product management, we have a name for skipping this step: we call it building on assumptions instead of research. We know what happens next. The thing ships, and it’s wrong in ways nobody predicted, because nobody who would have predicted the weak spots was ever asked.

The Room That Almost Shipped Broken

At a former company, I sat in a meeting where we were preparing to deploy a new digital ordering platform. It hadn’t been tested at the operational level. Not with restaurant associates who would have to use it. Not with the store ops or tech ops teams who’d actually have to support it. I asked a simple question: had we tested this with the operators?

The room went quiet. The answer was no. At that time I was leading the frontend digital ordering product, but my background is in operations and emergency response. A value I brought to the room based on my experience.

We were moving forward anyway, which meant a brand-new digital platform would have to integrate cleanly with an older point-of-sale, menu and pricing system on launch day, untested. I asked partly because that’s how my mind works, and partly because I’d come up through operational roles earlier in my career and knew exactly what could go wrong at the seam of two technologies expected to just work. So we got on a call with store ops. We found real problems with how products and menu items were configured. Then we tested in an actual restaurant, and found more — menu items displaying incorrectly on the point-of-sale system and on the employee-facing kiosk. All of it got fixed before launch, because someone asked the question first.

For context: I was the only Black person in that room who worked in tech, product, or brand and one of the only women. The room was mostly male, mostly white, an outsourced Ukrainian development team and a small group of onshore Asian representatives. If I hadn’t been in that room, I don’t think anyone would have asked. And I am certain the deployment would have gone out broken, on a project with real money and real risk behind it, for a multi-billion dollar global organization.

As a [front counter associate], I want [the ordering platform tested in my restaurant before launch] so that [the menu and pricing actually work when a customer places an order].

That’s the whole discipline, reduced to one sentence. It isn’t complicated. It’s just often skipped in the rooms where the decisions are made.

Everything Is a Product

Here’s the reframe I actually want you to take from this: everything is a product, whether anyone in the room is calling it that or not. An app is a product. A support system is a product. A wellness program, a community strategy, a school policy, a course built for students of technology, a nonprofit intake process — all of it is something built for someone, meant to be used by someone, and every discipline that governs good product development applies whether or not the word “product” ever gets said out loud.

You don’t need the title to use the tools. A user story is nothing more than a sentence that forces clarity: who is this for, what do they need, and why. In plain terms:

AS A [the person this is actually for]
I WANT [what they need it to do]
SO THAT [the actual outcome they’re after]

You could run this against a support hotline, a diversity initiative, a wellness retreat, or a piece of software, and the sentence would still hold. It’s not a developer’s tool. It’s a clarity tool, and clarity is available to anyone willing to ask the question before they build, especially those building rooms where decisions are made.

As a new member of this community, I want to see people who look like me already in the room, so that I trust this space was actually built with me in mind.

If a room can’t produce a sentence like that honestly, it’s worth asking why.

IN the Room Isn’t the Same as AT the Table

There’s a second kind of room failure, quieter than the first, and it’s the one I actually think about most. A room can have the right people physically present and still fail, if presence isn’t the same as power. Someone in the room to observe isn’t the same as someone in the room to decide. Someone consulted after the direction is already set isn’t the same as someone sponsored to help set it.

I’ve been in rooms where I was the right voice at the wrong altitude — present, but not positioned to actually change the outcome, or, even worse, changing the outcome required a fight that often didn’t pay off. That’s its own kind of user research failure, just one level up: leadership skipped the step of asking whether the people they’d already included had any real authority to shape what got built.

If you’re building a room right now, the question isn’t only “who’s in it.” It’s whether the people in it are sponsored, employed, and consulted, or just present. Those are three different levels of inclusion, and only one of them actually changes what ships. What if one seat creates big change, or big cost savings in avoided failed starts? Imagine how that compounds as more voices multiply and coalesce.

The Question Costs You Nothing to Ask

I’m not going to hand you a list of examples of who got this wrong, because that’s not really the point, and it lets you off the hook too easily by making this about someone else’s room instead of yours. So here’s the actual ask.

Sit down with whatever you’re building or leading right now. A product, a program, a policy, a cohort, a class, a company. Ask the same question I asked in that meeting, or just ask the question to yourself if you haven’t quite found your voice: have we actually tested this with the people it’s for? Not “would they probably be fine with it.” Tested. Present. In the room, in the process, before launch, and most importantly sponsored, employed, and consulted.

If the honest answer is no, you already know what to do next. It’s the same thing product management has always asked of good builders. Go find them. Go meet them where they are.

This is the first real dive into a series I’m building on this idea. Next, we go deeper into the mechanics — how failure shows up in the actual layers of the technology stack, not just the room around it. After that, we bring it together into something usable: a way to actually apply this to your own room, and fix what you find.

Are you sitting in these types of rooms today? Next time, I will share another room where decisions are being made without input from the voices that matter.

// build without them, and you’ve already failed.

---

Between Code & Conscience is written by Crystal A. Chubbs — founder, technologist, and The People’s CTO. I write about building technology that doesn’t extract from the people it serves.

More: The People’s CTO · Circuit + Soil

---

What you can do to support this week

» I’d like to start a conversation.

This is the first real dive into a series I’m building on this idea.

// tell me about a room. yours, a city council meeting, a staff meeting, anywhere that didn’t reflect who it was supposed to serve. reply and tell me about it.

» Read the first part of the series.

---