Talk it through with Aurelius
Library›Aurelius›The problem
Aurelius · Work & Leadership
Knowledge + Guidance

Are we building what people need, or just what we want?

You did not set out to serve yourself. No one does. It happens slowly — a feature you were proud of, a design you fought for, a roadmap that quietly bent toward what impressed you rather than what helped anyone. This is not a moral failing. It is what happens when skill goes unchecked. Notice what you are actually asking. Not "are we good people" — that question flatters you and changes nothing. Ask instead: in the last month, how many decisions were made because a user asked for them, and how many because they were interesting to build? Count honestly. You already suspect the answer. You cannot do this alone, and you should not try to. One person checking their own motives will always find reasons to trust them. A team checking each other will not. This is why you do this work together — not as a group therapy session, but as a standing discipline, the way you'd check a budget.

◆ How this problem reads on the two dials
GuidanceKnowledge
More coaching
Some to learn
1:1 with AureliusWith others (a Pod)
Some one-to-one
Practise with peers
The team already knows the ideal; what they lack is a working method to catch themselves, so the page leans toward concrete practice over explanation.
How the two dials adapt to you →
What’s really going on

Ask, before you ship anything: who is this for, and what did they ask for? If you cannot name the person and the need, you are serving your own idea, not them. Make this question routine, not occasional. The habit of asking is the only real safeguard you have.

🔒 What you’ll build togetherUnlock by starting
A moveBefore your next planning meeting, have each person write down who the next three features are for — a specific person, not a persona. Compare notes out loud.
A movePick one shipped thing from the last quarter. Ask the team: did a user ask for this, or did we think they'd want it? Answer without softening it.
A moveAssign one person each sprint to argue against the roadmap — their job is to ask "whose idea is this serving" about every item.
A moveSet a standing rule: no feature ships without one sentence naming the user's actual problem, written by someone other than whoever designed it.
A moveOnce a month, ask users directly whether the thing you built solved what they came to you with. Not whether they like it — whether it worked.
PractiseWhose Idea Was It · a Pod of 4 · 30 min

What changes unlock by starting

  • A team habit of naming the user and the need before building, not after.
  • Fewer decisions driven by what's interesting to build versus what's needed.
  • A standing check — built into your process, not dependent on memory or mood.
  • Less defensiveness when challenged, because the question is now routine, not personal.
One object, two jobs: a public answer to a real problem, and — the moment you start the chat — Aurelius’s live plan for your version of it.