Skip to main content
ProductBrain uses a four-level hierarchy to structure product thinking. Every piece of work traces back through a logical chain to a business outcome.

The Levels

Goals, What’s the business outcome?

Goals are the top of the tree. They describe what success looks like for the business, revenue, retention, market position. Goals are not tasks or features. Example: “Deliver a usable bi-modal planning tool”

Needs, What persistent problem stands in the way?

Needs are the enduring problems your users face that stand between you and the goal. They don’t go away when you ship. You address them better over time. If something can be finished, it’s a bet or a job, not a need. Multiple needs can serve the same goal, and together they show the full surface area of what the goal demands. Example: “Users can model product strategy quickly”

Bets, What’s our bet on how to meet the need?

Each bet is a scoped hypothesis about how to satisfy a need. You might have multiple bets for the same need, that’s healthy. It means you’re exploring. Each bet carries a measure. How you’ll know if it paid off. Example: “Inline chat in side panel” (measure: users create 3+ nodes per session via chat)

Jobs, What’s the proof?

Jobs are not implementation tasks. A job describes observable proof that a bet is working. The label says what you’d see. The description says where to verify it.
Jobs are acceptance criteria. Verifiable checkpoints that prove a bet is being delivered. They are not a backlog. There is no doing → QA → done pipeline. A job is either proven or it isn’t.
Good job: “Price comparison shows for scanned barcode” Bad job: “Add API call to fetch prices”

How It Fits Together

The hierarchy creates a logical chain:
We need to [goal]. For that to work, [need] must be true. We’re betting that [bet] will get us there. We’ll know it’s working when [job].
This chain means you can always answer “why are we building this?” for any piece of work. And when priorities shift, you can trace the impact up and down the tree.

Why This Structure Matters

A flat task list hides your real situation. You’re always working on something. But are you working on the right thing? The tree makes the full landscape of bets visible. You can see which goals have active bets and which are being neglected. You can see where effort clusters and where it doesn’t. You will always have more bets than you can pursue at once. That’s normal. It means you’ve mapped the real scope of the problem. The tree’s job isn’t to make the list shorter. It’s to make the choice about what to focus on, and what to consciously defer, a decision you can see and defend, not one that happened by accident because you ran out of time.

What’s Not in the Tree

Tasks are standalone items that live outside the hierarchy, bugs, polish, ideas captured mid-flow. They appear in the Misc column of the Delivery Map. When you’re not sure where something belongs, capture it as a task and sort it later.