There are two complaints I hear all the time.

The first comes from product leaders: "Büşra, you have to help me. My teams spend time and resources building, but it doesn’t move the needle. Nobody delivers on the goals."

The second comes from their teams: "We built exactly what we were asked to build. If the needle doesn't move, that's not on us."

Both are right.

John Cutler calls this disconnection the messy middle, the place where strategy and execution are meant to overlap, but usually don't. Instead, it looks more like a no man's land where good intentions go to die. Bringing structure to that messy middle is a big part of what I do in my consulting practice.

My approach is based on a simple belief: outcomes are the glue between the strategic and the tactical. They connect the direction a business wants to go with the things a team actually builds. But most teams either skip that glue completely, or they think they've got an outcome when what they've actually written down is an output.

Another thing that doesn’t help is that orgs tend to think of this kind of work in iterations. Double Diamond at the start, Scrum in the middle, Build-Measure-Learn at the end. Neat little phases, one after the other. But that’s not how real work unfolds. There's always a strategic direction humming underneath everything, and you're constantly moving back and forth, not marching forward through tidy stages.

So instead of phases, I think in loops between three things: direction, discovery, and feedback loops. I consolidated that approach into something I call the AIM framework - Align, Identify, Measure.

AIM: Align, Identify, Measure

AIM is a framework for connecting business goals, user outcomes, and product ideas, so that strategy, discovery, and delivery talk to each other end to end. It also helps you see what to measure, and where, so your decisions are based on evidence.

Align

The first step is to align on direction and define what you are trying to achieve.

But instead of starting with why (sorry Simon Sinek), I suggest you start with who. If you want to do real product work, you have to understand your market first, and that market is the who. It's why I insist on segmentation as much as I do.

Once you’ve identified the actor, ask: what is the main outcome we want to achieve for them? Choosing those people, and committing to that outcome, is itself a strategic decision. "We will focus on these people, and we'll help them do X, so that we hit this business goal."

If you’re familiar with my work, you will notice that I have borrowed the wording from Impact Mapping: Goal and Actor, and then the Actor’s Outcome they want to achieve. But you could use target group and problem to solve if you wish, or another wording that reflects the WHO and the strategic opportunity that you're chasing, or in Marty Cagan's words: give your teams a problem to solve.

Identify

Align was a decision. Identify is where you go and find out whether it holds.

This step should do two jobs:

The first is to work within the outcome you committed to and stress-test whether it actually holds. That outcome was a strategic bet, not a fact.

Also, in product work, we lean heavily on user research, and do far too little market research, even though that’s often where the biggest signals live. Between the two, you may discover that a different segment or need would move the goal more effectively than the one you originally chose. When that happens, it’s evidence that the original alignment needs to be revisited.

The second job, once the outcome still holds, is to explore how to achieve it. This is where problem space exploration and solution shaping happen in parallel. A tool like the Opportunity Solution Tree earns its place here, helping you move from outcome to opportunities to potential solutions without collapsing too quickly into delivery. The goal is not to pick a feature, it’s to find something you can actually test and build.

Measure

I’m “the metrics lady”, so obviously I suggest you make everything measurable. That way, you can get feedback loops, run experiments, iterate, and tell the difference between an assumption and something you actually have evidence for. So, put a metric and a number wherever you aim (pun intended) for a goal or outcome. Add an assumptions-tag and discuss experiments with a measure and a line drawn in the sand whenever there is an important assumption to test.

A note on sequencing: measuring doesn’t happen only at the end. You should have measurable outcomes before you start thinking about solutions. So treat the M as something running throughout, not a final step. And it isn't only outcomes you measure: assumptions are scattered all the way through, so there's something worth testing at almost every point.

A word of warning, because people always ask: don't mistake this for a causal model. AIM won't hold up if you pressure-test it against your analytics the way a proper metric tree would, and it isn't trying to. Its job is to organise the work, make the mess in the room visible, and give you more relevant conversations about how the pieces connect.

It also doesn't run in a straight line. You'll move from Identify back to Align, from Measure back to Identify, round and round, as you learn.

Connect it to the frameworks you already use

Did you notice above when I said "a tool like the Opportunity Solution Tree?" That was on purpose. AIM is framework-agnostic, it sits on top of whatever you already use in your organisation.

You can plug in OST, Impact Mapping, or Pains, Gains and Jobs from the Value Proposition Canvas, for example. KPI trees, OKRs, outcome-based roadmaps… they all have a home somewhere across Align, Identify and Measure.

Roman Pichler, who was writing about product management before most of us had heard the term, saw me connect the OST and Impact Mapping to align strategy and discovery in a talk and said he liked how I connected the dots this way, and he didn't thought of it this way before. That makes me even more confident this framework is worth sharing.

But there’s more proof.

The first example comes from my husband. He works in data teams, and like most engineering-minded teams, they live at the solution level. They know what they want to build, though they can’t always pinpoint why.

In two companies already, he took a proposed solution and worked through it with his team, backwards:

“This is the solution. To create which effect? For which outcome? For whom? In service of which goal?” Impact mapping in reverse, essentially. Then he added the missing piece in the middle: "We don't actually know this solution will deliver that outcome. Let's go and check." So they ran some analysis, talked to people, and came back with a far better conversation than the one they'd started with. The feedback he got afterwards is the kind of thing that keeps me going: "Now we finally understand why we're doing what we're doing, and how it all fits together."

The second example is a story I’ve told in full over on LinkedIn, so here I'll just give you the short version. Two product managers, Simon and Lane, came up after one of my talks: they'd introduced Opportunity Solution Trees, but couldn't get them to connect to their business metrics. This is exactly the link AIM is built to provide.

Conclusion

There’s no certification for AIM, no rollout plan, or approved way of doing it. It’s a framework, not a rulebook: it gives you the structure (Align, Identify, Measure) and leaves you to plug in whatever methods you already trust to work each part.

The point of this approach is to get the people who set the strategy and the people who build the product into the same conversation, and to make the reasoning behind your bets visible. You're not going to be able to prove that every solution moved the business needle. Sometimes that's only possible with very well-designed experiments, and sometimes it isn't possible at all. But you can trace your bets through the chain of assumptions and signals they were built on, and see whether they're moving things in the direction you expected.

Keeping this in mind, I received the feedback that the AIM acronym is very well chosen because it's easy to remember, conveys the message very well, and helps to connect the dots towards the target we’re aiming for. Thanks for this feedback, dear Arne Kittler.

If you too give this a try, I’d love to hear where it helped and where it failed. My inbox is open!