Skip to main content
ProductBrain’s core insight: a single dataset rendered two ways, with animated transitions between them.

The Boardroom and the Factory Floor

Strategic thinking and delivery execution are different cognitive modes. The risk is making strategic decisions from the factory floor. Or doing factory work when you should be in the boardroom. ProductBrain collapses this problem. The Planning Tree is the boardroom: what are we building and why? The Delivery Map is the factory floor: build the thing that was decided. But because they’re the same data, you’re never fully disconnected from one while working in the other. The strategic lens is applied during delivery, not instead of it.

Planning Tree (Strategy)

The tree shows why you’re building something.
Goal: Help shoppers save money
  └── Need: Compare prices across stores
       └── Approach: Barcode scan with live lookup
            └── Job: Price comparison shows for scanned barcode
Every node traces back to a business outcome. When someone asks “why are we building this?”, the tree has the answer. Follow any job upward through its approach, need, and goal. Use the tree when you need to:
  • Map out what you’re betting on
  • Check that work connects to business value
  • Explore approaches for a need
  • See the full strategic landscape

Delivery Map (Execution)

The matrix shows what you’re shipping and when. But its real power is in how it shapes the way you deliver.
Barcode ScanManual EntryAI Prediction
MVPPrice shows for scanEntry form worksNone
Phase 2Multi-store comparisonFavorites listPhoto prediction
Columns are approaches (your bets). Rows are iterations (your delivery slices). Cells are jobs (your proof).

Balanced progress, not serial completion

The natural instinct is to finish one thing before starting the next. The matrix shows you why that’s wrong. You don’t need to complete every iteration of Barcode Scan before starting Manual Entry. You ship just enough of each bet to validate it, the MVP row, then decide which bets deserve deeper investment based on what you learned. This means your iterations are a balanced portfolio, not a serial queue. Each release progresses multiple approaches by a small amount rather than one approach by a large amount. The advanced version of one bet can wait while you get a first version of another into users’ hands. No feature is ever “complete”. It’s just not high enough priority to progress further right now. The matrix makes that visible: you can see exactly how far each approach has been taken, in which iteration, and what remains. Use the matrix when you need to:
  • Plan what ships in the next iteration
  • Balance effort across multiple bets, not over-invest in one
  • See how far each approach has progressed across iterations
  • Decide whether to deepen an existing bet or start validating a new one
  • Track progress on delivery

The bridge: Approaches

Approaches are the node type that lives in both worlds. In the tree, an approach is a strategic bet hanging from a need. In the matrix, it’s a column header with jobs beneath it. This is why approaches carry both strategic metadata (Kano classification, measure) and delivery metadata (their child jobs carry iterations and status). The approach is the handoff point between the person setting the agenda and the person (or agent) delivering the work.

Switching between views

Toggle between views at any time. The data doesn’t change, only the layout. Goals and needs are visible in the tree but not the matrix. Jobs are visible in both. Approaches are the column headers in the matrix and branch points in the tree.

Tasks and the Misc column

Tasks (standalone items outside the hierarchy) appear in a Misc column in the Delivery Map. They’re visible alongside your structured work but clearly separated. A reminder that not everything fits the tree, and that’s fine.