Reworking the Business Goals page

Working through the Business Goals page this week and want to flag what we’re changing and why, since it touches how the whole Lead area reads. This area is still a mess of ideas that need shaping.

Here’s the thing the current page does well. It’s strong on proof. The three-layer KPI structure (Design → Product → Business), the twenty goals mapped to the nine pressures, the Quick Test, the three pitfalls. If you already have a goal in hand, the page tells you how to prove your work moves it. That part holds up.

The gap is higher upstream in how problems get set up.

The page assumes you arrive with a clean goal already named. In practice nobody does. Goals get handed to design and product in vague, opinion-driven ways. The loudest voice sets direction without defining what success looks like, and user needs fall out of the conversation. So there’s a step happening before the KPI work that the page never covers: how a fuzzy ask becomes a named goal you can actually map to.

That’s the front door, and right now the page doesn’t have one. It opens straight into the proof machinery.

What we’re adding:

An alignment section up top, before the three layers. The core idea is the board as a shared language. Five categories, twenty goals, on one surface. We need to get stakeholders and design to point at the same square before anyone gets into problem-solving mode. “Improve the onboarding” is an opinion. “We’re trying to attract new customers” is a goal you can map work to. The board is what makes that translation happen.

This also changes how the board itself reads on the page. Right now the twenty goals sit there as a reference list, a catalog. I want it to read as an interface, the thing stakeholders react to, not just a taxonomy we defined. Same twenty goals, different job.

Two things we want reactions on:

One, sequencing. I think the alignment section goes above the three-layer KPI structure, because naming the goal comes before proving it. But you could argue proof is the meatier contribution and should lead. Where would you put it?

Two, showing how adjacent blocks play into decisions. Business goals are one of 16 decision blocks, and the front-door framing pulls it toward its neighbors. User needs sits upstream of the alignment step. Workflows and Mapping sit downstream. we don’t want the page to become an island that re-explains those. How much should this page link out versus restate? Trying to find the line where it’s connected without being redundant.

I shared some broader ideas on LinkedIn and blog pieces from this week, so if you’ve seen those this is the architecture version of the same argument. Reactions welcome, especially on sequencing.

1 Like

Love this, I can already see how this might help our Glare AI skills evolve here. It gifts an agent with the power to support stakeholder alignment with their favorite human.

Alignment does feel like it needs to be at the top, it’s very important that we preface that that’s one of the core elements.

Here’s the current structure:

  • Why Business Goals Matter
    • The Three Layers of Goals - Design, Product, & Business KPIs
  • Goals And The Pressures They Support - Growth, Retention, User Exp, Efficiency, & Operations
  • Pitfalls
  • Quick Test

Feels like proof should be in the middle, not leading because it is a bit meatier, and definition comes first, but I could be wrong here.