The turning point involved user research — and a budget fight. Tell me about that.

I pushed for user research, and I had to fight for it. Twenty-five hundred dollars. That sounds trivial, but in a small startup, asking for budget to validate something everyone assumed they already understood was a hard sell.

The pushback was essentially: we know our users, why are we paying to confirm it.Then I made a decision I think mattered more than the budget itself. I refused to run the research on Figma mockups. Static screens tell you what people think they'll do. They don't tell you what people actually do. So I spent two weeks building a working prototype in Lovable — real data, real interactions, the whole thing clickable and live.

That distinction — between what people say and what people do — turned out to be the entire project. If I'd tested mockups, I'd have shown users a picture of the hierarchy and they'd have nodded and said yes, that makes sense, I'd click here.

And I'd have learned nothing. The prototype was the only thing that could have caught what happened next.I want to be honest that this wasn't pure methodological wisdom. Part of it was instinct, part of it was stubbornness. But it's the decision the whole story hinges on. You don't get the four-second moment if you're showing someone a screenshot.

What did you actually see when you compared how the two users worked?

Once I stopped defending the hierarchy and started watching, the difference between the two users became sharp. They were both ignoring the structure, but they were ignoring it in opposite directions.Gil is building a dataset from scratch.

There's no prior research on what he's investigating — he's generating the evidence. When he opens the system, he wants to slice across everything: give me all sessions where the paradigm is Stroop, the age is 25 to 45, the signal quality is acceptable. He doesn't know what he's looking for yet. The slicing is the research.

The clinician in Cyprus, Dr. Mavridou, is tracking individual patients through experimental treatment. Each patient comes in every few weeks. She wants one person's story — is this patient's P300 amplitude improving session over session, is the treatment working for them specifically.

She wants depth on one individual, not breadth across thousands.So I started thinking about it geometrically. Gil takes a horizontal cut — one slice across thousands of sessions. Mavridou takes a vertical cut — one person followed down through time. The researcher sees a catalog. The clinician sees a story. Same data, same system, two completely different modes of time. And critically, the same underlying action — both of them are slicing. Just along different axes.

Underneath the design problem was an organizational one — management wouldn't pick a user to optimize for. How did you navigate that?

That was the real constraint, and for a while I treated it as an obstacle. I went to management and said we have to choose — are we a research tool or a clinical tool. They said no. We need every customer, we're a startup, we can't afford to lose either market. I read that as cowardice at first.

Refusing to make a hard call.But the more I sat with it, the more I realized they weren't wrong. They genuinely couldn't afford to lose either customer. Telling a small startup to abandon half its market is telling it to die a little. The constraint was real, not lazy. So the question shifted from "how do I make them choose" to "how do I honor both without compromising either."

That forced me to be precise about what was actually non-negotiable. Two things. The first was user research — that's your eyes, you don't give those up. The second was the information architecture. Once the data layer is built, it's built. You can't ask the dev team to rebuild the database every time the UI shifts, and that schema wasn't even mine to trade away. It was the product manager's.

So I drew a line. I wouldn't compromise on research, and I wouldn't compromise the architecture. But the UI layer — the surface, the navigation, the affordances — that was flexible. That's where I had room to move. Knowing exactly what you're allowed to give up is, I think, half of working inside an organization.

There's a conceptual shift in here — moving from personas to something you call intent. What changed in your thinking?

The breakthrough was realizing I'd been asking "which persona matters more" when the question should have been "what action are they actually doing." Personas describe people — Gil is 38, has a beard, bikes to work, drinks too much coffee. None of that tells me what he needs when he opens the system at nine in the morning.


What tells me something is the sequence of actions he takes in the first thirty seconds. That sequence is repeatable. It's measurable. And crucially, it's portable — the intent "discover a pattern in unstructured data" applies to Gil, but also to any researcher doing that kind of work. The persona is locked to one person. The intent travels.

This is the difference that decided whether brain.space needed one product or two. As personas, Gil and Mavridou are irreconcilable — different people, different goals, pick one. As intents, they're almost the same. Both are slicing.


They just slice along different axes. That reframe is what made the whole thing designable.It also changed what I could measure. You can't put "is Gil satisfied" into analytics. But you can track whether someone completed a slicing operation, where they got stuck, how often they came back to a saved query. Personas are stories you tell yourself in a workshop. Intents are things you can actually build for and instrument.