Don’t Follow Frameworks. Break them.

Hey I’m Ant and welcome to my newsletter where you will find practical lessons on building Products, Businesses and being a better Leader

You might have missed these recent posts:

- Analytics IS Part of the Feature, not Separate!
- Let's talk Dual Track: Continuous Discovery and Delivery
- I asked 40 product leaders ‘What is Discovery?’ Here’s what they said

---

Product work is rarely as neat as Outcome → Opportunity → Solution (and Teresa even says so in her book!)

"While many teams work top-down, starting by defining a clear desired outcome, then mapping out the opportunity space, then considering solutions and finally running assumption test… the best teams also work bottom-up. They use their assumption tests to help them evaluate their solutions and evolve the opportunity space.” - Teresa Torres, Continuous Discovery Habits

And that's not to say that techniques like OSTs (Opportunity Solution Trees), KPI trees, North Star Framework and Impact Maps are useless. 

On the contrary, they’re amazing!

But it’s important not to get stuck trying to follow these frameworks to the letter.

Product work is messy and most of the time when using these frameworks I inevitably go off script.

I might start with an outcome intending to build an opportunity solution tree only to realise that the outcome needs to be broken down first. 

Suddenly I now have a KPI tree merging into an OST.

Or like a recent client I’m working with, you might want to throw different user segments into the middle of your opportunity solution tree to segment that way.

And all of this is ok.

At the end of the day these are sensemaking tools.

And like any tool they need to work for you.

So in that spirit I thought I’d share some of the weird and wonderful ways I’ve gone off script with frameworks like KPI trees and OSTs.

1. Outcomes → Business Problem → Customer Problem → Solution

Don’t be fooled by how this looks, we didn’t start at the top and move our way down.

Instead we started at the bottom with that black post-it note only.

The Product Manager and I were working backwards from a new technology that was available and basically building a picture of what problems this might solve.

Now you could take a typical OST structure for something like this and work from solution up to opportunities and then to the outcome at the top. But through our conversation it started to make more sense to create a break between the customer and business problems.

Here’s another thing worth noting. 

We didn’t actually have those labels on the side as we workshopped this.

As coaching sessions often go, this was me asking questions like “what customer problems exist today?” and as we worked through the customer pain-points we started to uncover business problems as well - kind of the next layer, “so what?”

2. Problems → Outcomes → Solution → Experiments

Here’s another fun one. Similar situation. We were mapping back from the ‘initiative’ (yellow post-its).

Initially we worked up towards outcomes because they already had some expected outcomes (not so well defined as you can see).

Of course words like ‘speed’, ‘cost’ and ‘reduce complexity’ all sound nice but they’re not exactly specific.

So I drilled into them one-by-one; “what problems do you have today with speed?”

This gave us much more specific problems like the fact that things are currently batch processed and run as overnight jobs.

We then jumped all the way to the bottom and asked ourselves “what is the smallest thing we might do first?” (Green post-its)

From there we started to identify assumptions because our “smallest thing” needs to be tackling our riskiest assumptions!

3. Solution → Team Problem → Customer Problem → Outcome → Business Problem

Honestly this one started as an OST which then turned into this weird horizontal KPI/Value Driver tree. 

Our starting point was the outcome of ‘Higher Conversion’ (second from the right) and the solution on the left. 

What I was trying to achieve in the coaching session was connecting their OKR to increase the conversion rate to this big replatforming project that they had going on.

In other words, why did they believe they needed to replatform to improve their conversion rate? 

As you can see as we moved to the left, we again were making a typical OST by starting with customer opportunities like a “shorter application form” and the post-it note you can see on the far left which was to complete the process “in 60 seconds”.

However this still didn’t explain why we were replatforming.

We needed to bridge the gap. 

Through a line of questioning this led us to uncovering things like: 

• Being able to release quicker

• Building out experiment capabilities 

• Having greater data and insights

What I learned was they were dealing with a slow legacy platform which didn’t allow them to release frequently, run AB tests or even give them much in terms of data and insights.

So whilst they wanted to increase conversion, they were running blind (which is evident in the number of things labeled as ‘assumption’.

But this is a very different narrative. It’s not, replatforming will lead to a greater conversion rate. It’s that we need to move off our current legacy platform, so we can deliver faster, experiment and allow data to drive their improvements. 

Those capabilities will be what unlocks our ability to improve conversion. Otherwise we’re just taking shots in the dark hoping something will land.

This is why we ended up adding in something that I’ve never done before, which was ‘Team Problem’. 

Because from a value driver perspective those capabilities are inputs into solving those customers' opportunities.

Hence the strange and messy looking OST/KPI-Tree/Map-Thing.

4. Business Problem → Product Outcomes → Customer Benefits → Initiative → Test

This one is very similar to the one above and the first one. 

Key differences being that compared to the one above there’s no “team problem” in this scenario. No legacy platform or anything slowing us down.

In comparison to the first example (Outcomes → Business Problem → Customer Problem → Solution) we have one extra layer; ‘Product Outcomes’.

It’s also horizontal 😉

This customer → product → business mental model is one I use often and have written about before.

Whilst not perfect (what is?) I’ve found it a useful framing.

You can think about these as 3 'buckets' of outcomes:

Business,

Product,

and, User

The business outcome is to generate more revenue (not a great one, but keeping it simple for illustrative purposes)

The product outcome might be to increase retention.

The user outcome might be to "improve the experience of X."

There is then a hypothesis that binds them all together.

We then believe that if we can "make the experience of X better" (user outcome), it will reduce churn (product outcome), which will eventually translate into more revenue (business outcome).

“All models are wrong, some are useful.”

Whilst some people love to proclaim that frameworks are useless, they’re wrong and never represent reality, I want to be clear. I’m not in that camp.

Ok the title of this post was a bit up that alley and ‘clickbait’ like but I do mean it. 

Don’t (blindly) follow frameworks. Break them. Make them work for you.

But that doesn’t mean that frameworks aren’t useful or you should ditch them altogether.

It’s more nuanced than that.

Frameworks are great! They’re especially useful as a starting point. 

Note, starting point. Not end point.

What people get wrong is they view frameworks as a silver bullet (of course some people try to sell their frameworks that way). 

But they’re not.

I like the framing from the late Charlie Munger who often talked about building up this latticework of mental models in your head for ideas to hang off.

“What you need is a latticework of mental models in your head. And, with that system, things gradually get to fit together in a way that enhances cognition.” - Charlie Munger

Frameworks are just mental models.

And no mental model is going to be perfect, cover 100% of situations or work perfectly in your context.

So here’s my reframe. Frameworks are a great:: 

1. Starting point (so you’re not staring at a blank sheet and can get momentum)

2. Means to structuring your thinking (that latticework that Munger talks about)

3. A learning tool 

That last one is particularly powerful because if you begin to ask yourself questions like: 

• What problem were they trying to solve with this framework? 

• In what context did they create it, and in what ways is that different to my context?

• What can I see working in my context and not working?

• How might I adapt this to my situation? 

• Etc… 

Asking these types of questions helps you get down to first principles which will ultimately serve you much better in the long run!

Ok that’s enough for this week.

Apologies on the slightly longer than usual break between posts, I’ve been traveling for work which always throws out my schedule.

As always, thanks for the support, I hope this is valuable. 

If you do have some wacky adaptations to popular frameworks send them my way, I’d love to see them! (maybe we can do a part 2!)

---

Top Posts