This Backend Knows You Better Than You Know Yourself

An onboarding questionnaire is the most underrated part of a personal product, because it is the moment the app decides whether it actually understands you or just collects your email. Think about how a dating app like Tinder or Hinge lives or dies on how well it reads you: a shallow profile gives you shallow matches. My personal growth game has the same problem. If it does not deeply understand your desires, fears, and challenges, it cannot hand you quests that actually move your life forward. So after my user story mapping session, I stopped building the app and built the engine that reads the user first. Here is how I designed it, the pivot that made it work, and the psychology engine underneath.

Why this matters

Most builders personalize on nothing. They ship an onboarding that asks for a name and a goal, then pretend the product knows the person. After fifteen years in product management and a parallel career as a trained body psychotherapist, the pattern I see in the founders I coach is the same: the understanding step gets treated as a form to get past, so everything downstream is generic. This is user research with the label filed off, and it deserves the same rigor. The right time to design how you understand the user is before you write the app, because every quest, every recommendation, every nudge the product ever makes is only as good as the read it started with. Get the read right and the rest of the product has something true to stand on.

#1: Build the thing that understands the user before you build the app

The instinct when you have a vision is to start building the app. I had the vision for a personal development game, a Tamagotchi crossed with a hero's journey, and I sat down to map it out. Forty minutes into the story mapping session I stopped, because the map kept pointing at the same missing piece. I could design every screen, but none of them worked without one thing: knowing what the person in front of me actually wants, needs, and struggles with.

So I did not build the app. I built the engine that reads the user. The questionnaire is not a step before the product. For a product whose entire job is to hand you the right quest at the right time, the questionnaire is the product, and everything visible on top of it is delivery.

The pattern I see when I coach founders is that they build the delivery layer first because it is the part they can show people, then they bolt understanding on afterwards and wonder why the personalization feels hollow. The order is backwards. The portable rule: if your product has to understand a person to be useful, the understanding engine is the first thing you build, not the last.

#2: You love the heroes whose want and need are secretly your own

To read a person through what they love, I first had to answer a question I had never had to make concrete: what makes a hero a hero, and why do you fall for some and not others?

Every hero starts with something missing. Harry Potter has no parents, a bad start, an enemy he does not yet know. The story is never only about what the hero wants. It is about what they need, the closure or the love or the security they are actually short of. The whole arc is the gap between those two closing in front of you.

People rather level up characters in computer games than their own lives.

That is the line that started this whole project, and it is why the mirror matters. You do not fall for heroes at random. You fall for the ones whose challenges and desires are the ones you carry. My favorite show is Suits, and my favorite character is not Harvey Specter, it is Louis Litt, because his journey is the one that moves me most. When I noticed that, I also noticed the part of me that is always judging, defending, standing in a courtroom, and the show suddenly read as a mirror of something inside me. The character you cannot stop watching is telling you what you are working on. The portable rule: the fiction a person loves is not a preference, it is a self report they did not know they were giving.

#3: Ask for the stories, not the hero

My first version of the questionnaire asked the obvious question: who is your hero? It is the wrong question, and this is the mistake I would undo if I started again.

A hero can be anyone. Superman, Iron Man, your neighbor, your teacher, your father. That is beautiful and it is useless to an engine, because I cannot pull any data about your neighbor. There is nothing public to read, no dramaturgy to analyze, no character arc to compare against. The answer is real and completely unworkable.

The fix showed up while I was vibe coding the questionnaire and kept catching myself quoting the same shows. Suits. Ted Lasso. So I flipped the question. Instead of the hero, ask for the container: which series, films, and books do you love, and which character inside them. Everyone consumes stories, those stories are public, and a language model already knows every arc in them, so free text plus the reason you love a character is richer than any hero picker I could build.

Question	Answer space	Can the engine read it?	Why
Who is your hero?	Anyone, including private people	No	No public data, no dramaturgy, nothing to analyze against
Which stories do you love?	Films, series, books, games	Yes	Public arcs the model already knows, plus your reason for loving them

The portable rule: when you design an input, do not ask for the answer you want. Ask for the answer you can actually read.

#4: Read the feeling, because it names the need under the want

The sharpest question in the whole questionnaire is not about goals. It is about how you would feel once you reached the goal. That question separates what a person wants from what they need, and the two are almost never the same.

If someone tells me the goal will make them feel in control, or strong, I can tell you that is not the real target. Feeling strong and in control is something most people learn as children in order to survive, not something a settled adult is actually reaching for. The need underneath it is security. As a body psychotherapist, the thing I watch for is exactly this gap: the stated want is real, but the feeling attached to it points at an older need that the goal is standing in for. A goal to build a company with a thousand employees is not wrong. The question is whether the engine underneath it is ambition or an unmet need for safety, because the two want very different quests.

This is also where I set a hard boundary. The engine reads the need, but the app never overrides the person with it. It offers quests and perspective-shifting questions, and you decide whether to take them. It does not push, it does not diagnose you to your face, and it does not set your path. You define the process. The portable rule: capture the feeling, because the feeling names the need, but let the person keep the wheel.

#5: Analyze each signal on its own, then merge into one profile

Under the ten questions sits an engine built in layers, and right now it is not app code at all. It is a set of prompts running through Claude Code.

Each channel of information gets analyzed on its own, without the analysis of one channel seeing the others. Birth data is a soft, opt-in lens: if you give me a birth date I can compute numerology or a sun sign, but I compute what is computable in code and only let the model interpret it, so it cannot hallucinate a chart. It is considered and never weighted heavily. Characters and games get their own prompts, because a story you watch and a game you become are different kinds of evidence. Goals get one prompt. Then a final prompt, the one I call the meta prompt, takes all of those separate reads and merges them into one overall profile.

Layer	What it reads	Prompts
Birth data	Gender, birth date, optional spiritual lens, computed not guessed	opt-in lens
Characters	Series, films, books, the character you love and why	4
Games	What you play and what it does for you	3
Goals	What you chase, and how you would feel reaching it	1
The final merge	All of the above, combined into one profile	1

That profile is a one-time reading I call T0, saved once and never touched again, because it captures the start of the journey. From there a living state updates every time you finish a quest or journal, while the app keeps looking back at T0 to remember where the hero began. I ran it on myself first and the output knew more about me than I did, then I ran it past friends who all said the same thing. Reading each channel separately is what makes the final profile trustworthy: when several independent reads of the same person land on the same core, you know it is real and not an artifact of one clever prompt. The portable rule: analyze each signal on its own, then merge, and trust the point where the separate reads agree.

What is next

The questionnaire is live, and you can try it inside the interactive build at the engine map. Fill it out, because the more real answers I get, the better the engine gets. Next I connect the four layers to the database and the spiritual APIs, and start turning the T0 profile into actual quests, which is where the product finally becomes a game instead of a very deep intake form. If you are building something that has to understand a person before it can help them, this is the exact problem I work on inside my product coaching, the read before the build. Subscribe so the next episode lands when the quests come alive.