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:

- Top 5 Challenges Product Managers Faced in 2024
- Product Discovery Should Speed Up Delivery, NOT Slow it Down
- Data-Informed NOT Data -riven

My day job is helping companies shift to a Product Operating Model.
My evening job is helping people in the Product Mentorship on Product Pathways.

I don’t like using the term “empowered” because it’s ambiguous.

Empowered to do what?

Are you empowered to expand your product internationally
Empowered to build a whole new business within your current org?
Build a new brand under a parent company?

Of course, empowerment doesn’t mean “do whatever you like” but therein lies the question:

What exactly are you empowered to do?

Team Objectives

I’m sure you’ve heard the LinkedIn product gurus tell you that the secret to empowerment is giving teams problems to solve.

(and yes, I’m fully aware some people throw me in that category, happy to take the mickey out of myself here 😅 but I also hope I’ve never been that unhelpful!)

And whilst this is technically correct, it falls into the same trap as ‘empowerment’.

For example, what do we mean by ‘problems’?

Most of you will immediately think of customer problems but what about business problems?

After all, AWS was born out of a business problem and even Teresa Torres recommends product teams to start with business value when building their Opportunity Solution Trees.

“An opportunity solution tree starts with business value (represented by the outcome) because when we create business value, we earn the right to serve our customer over time.” - Teresa Torres

And I wish it was as easy as business vs customer outcomes.

The reality is much messier.

Take John Cutler’s mandate levels for example.

John has nine levels here.

From ‘build exactly this [to a predetermined specification]’ all the way to ‘Generate [long-term business outcome]’.

So even a business outcome could be anywhere between:

Long-term business outcomes like revenue, brand reputation, trust, customer lifetime value, etc.
Or short-term version of those outcomes, like increasing revenue this quarter by x%.

And customer problems can also range from:

Exploring ways to make our product more ‘sticky’ for XYZ segment
To ‘solve this specific customer problem’.
And even down to ‘enable customers to do achieve X’

So which level should your team objectives be at?

The answer is, it depends.

But don't worry. I'm going to make this actionable because ‘it depends’ is never helpful!

High-Level Business Outcomes

Starting at the ‘top’ you have high-level business objectives.

These are great because there’s a lot of room for finding different ways to achieve them.

For example, you could increase revenue by”

launching a new product line,
optimizing pricing,
increase conversion rates,
find new distribution channels or acquire more leads,
improve retention
etc…

The list goes on.

But it’s not all upside.

With this comes a new challenge.

Given such a broad scope the team now needs to spend a lot of time exploring all the possible opportunities and deciding where to start.

*High level outcomes are broad which can be a double edged sword*

For some teams, this can create a paradox of choice.

For others, it could be beyond their capabilities. They may not know how to deal with this ambiguity or have the tools to research, explore, and assess opportunities.

And even for the ‘crack teams’ who are capable. A broad outcome means more ambiguity which means more time and work to make sense and determine a direction.

Spending more time exploring and assessing different opportunities works well when you have the luxury of time (and the capability).

But as many of my clients are grappling with right now. They’ve found themselves in a drastically different environment than a few years ago.

Rampant inflation, mass layoffs, and constrained spending mean that they’re operating in a more constrained environment.

The luxury of spending time exploring different avenues has passed.

Narrow Outcomes

Zooming in is necessary at times.

Particularly if you’re operating in a constrained environment - which many of us have found ourselves in now.

Sure, setting your objectives at a lower level might mean that you miss an opportunity or miss the ability for a team to innovate (although I challenge that because constraints are what drive innovation, not endless freedom).

But this is where you need to ask yourself:

do I have the time for the team to spend longer exploring and making sense of a broad space?
how much data/conviction do I have on solving this specific problem?
does that team have the capabilities to deal with the ambiguity and find the right levers?

To be clear, zooming in doesn’t mean you guess.

As leaders, we need to do the leg work.

We need to look at the data and make bets on where the highest leverage opportunities lie.

Here’s a real example from a founder I’ve been coaching:

Originally he had tasked the team with; “Maximize user success when onboarding.”

Very broad!

No surprise the founder was frustrated with the team. He felt they were making little progress and were going down rabbit holes that he didn’t think were the most impactful.

So I asked him, based on what he knows (data, experience, context, etc); what he believes is the most significant barrier to users completing onboarding?

He immediately replied, “Import! …we have a high failure rate during onboarding when users go to import their data.”

Great! What about if the team focused on reducing the number of failed imports?

This is a great example of zooming in and making the problem space more narrow for the team.

Have we disempowered them?

Well if your definition of empowerment is that the team should be able to choose what part of the product they work on, then yes.

But if your definition of empowerment is to be empowered between boundaries and those boundaries could be broad or narrow, then, no.

Narrow boundaries means less room to explore, which means smaller work.

It’s simply a ‘size’ thing.

Less space = smaller work = less time.

More space= bigger work = more time.

This is why when the operating environment becomes constrained we often get more narrow.

We want to be laser-focused on the things that we believe will have the highest impact.

We also don't have the luxury to go exploring other options. We need results today!

This often means making a decision based on what we already know and running with it.

Of course, the extreme version of this is telling the teams what to do - but I hope you (or your leaders) don’t end up there. There’s still a lot of room between ‘build this’ and ‘solve this narrow problem space’. Choose wisely.

Abstract Laddering

Now this isn’t an either or.

I’m not advocating for narrow outcomes over broad ones but I do advocate for sizing the problem appropriately to your context.

One tool that I find useful for testing whether I have set objectives at the right level is Abstract Laddering.

The way abstract laddering works is you put your original problem statement (outcome or team objective) in the middle and you ask yourself ‘why’ questions to move up and make the statement more broad.

Similarly asking ‘how’ questions to make the statement more concrete.

I like to reframe the problem two levels up and two levels down.

This gives me a broad range from high to low level.

I can then take a step back and look at the ladder and decide which of the 5 is the most appropriate level to focus on.

If necessary I’ll do this collaboratively and involve the team for example - where would they like to focus?

Business > Product > Customer Outcomes

The second tool that has proven to be helpful in the past and at numerous clients is to think about outcomes as 3 buckets:

Business Outcomes
Product Outcomes, and
Customer/User Outcomes

Now as I’ve already went through at the start with John Cutler’s Mandate Levels it’s far more complex than this. But.

If your company is struggling with even one or two of these, or they have no delineation between different types of outcomes and it’s all muddled together, then starting with these 3 categories can help.

A way you can use this is to reframe a product outcome as a business one - or to zoom in by reframing it as a user outcome.

If you do want to represent the ‘messy middle’ of these three buckets I’d recommend building out a KPI tree or tree like diagram.

I’m a big fan of doing these!

*KPI trees or similar are great for mapping things out and breaking the problem space down*

Conclusion

It turns out, defining good team objectives is hard.

It’s not as simple as following the OKR (objectives and key results) format. There’a lot more nuance.

Be careful of the trap of setting really high level broad objectives.

They have their place but giving them to a small team in a very large organisation is probably not the place. However, if you’re a small startup it might be.

Equally consider the constraints you may or may not have.

Do you have the luxury, the time to explore and give the team loads of freedom?

Or do you need them to be more focused and narrow?

Finally consider the skills that you have in your team - can they deal with a broad and ambiguous objective?

If not you may need to zoom in and make the space narrower for them.

p.s. if you’re looking for support to make 2025 the best year yet, join the Product Mentorship before the end of February and get $200 off (code MENTOR200)

*Get $200 off the Product Mentorship before the end of February! Use code MENTOR200*

Top Posts

Featured

Data-Informed, NOT Data-Driven

Being data-driven can be an awful trap.

We believe we’re collecting data that portrays an unbiased view of the world.

Data that will help us make the ideal decision.

After all, that’s what the data says, right?

Bad news. Your data is biased.

Prioritization & Urgency: Key lessons from John Cutler’s Prioritization Course

This post will make you rethink prioritization through the lens of urgency.

Lessons and reflections from John Cutler’s Effective Prioritzation Workshop.

Dual Track: Continuous Discovery & Delivery

Below you’ll find a write up on:

What is Dual Track (continuous discovery and delivery) and how does it work
Why you should move away from project discovery towards this model
The mindset that you need to make it successful
and common practices that I’ve found helpful

Breaking Product Discovery into First Principles

In this week's post you’ll find:

What is product discovery?
The 3 Core Components of Product Discovery
What the definition of done is for discovery
Why product discovery should help you STOP ideas
And who does product discovery

OKRs ≠ Strategy

Your OKRs don’t live in a vacuum.

Yet this is exactly how I see many organizations treat their OKRs.

They jump on the bandwagon and create OKRs void of any context.

Here’s what I see all the time…

Dealing with Stakeholders coming with Solutions, not Problems

Here's a hack I use to dealing with stakeholders coming with solutions, rather than problems.

Don't try to work backwards, work forward.

3 Product Vision Formats That Aren’t Boring!

I wrote a post a couple of years back on ‘How to craft your First Product Vision’ where I open with:

“There’s a lot of advice out there on how to write a good vision statement, many will point you to the popular ‘Elevator pitch’ format (among others), but personally I’ve never felt those frameworks were suitable for my final vision statement — you sure don’t see the likes of Telsa, Apple, etc using these kinds of formats for their vision statements, do you?”

Building Effective Product Roadmaps

Last week, over 300 passionate product people joined me live for a free webinar on ‘Building Effective Product Roadmaps’ (the recording is below).

I want to share the results of the polls I ran during the webinar and figured, why not do a summary of the key points too.

Let’s get into it!

Asking Better User Interview Questions

A comprehensive guide to conducting user interviews covering: 1) How to structure a user interview for maximum impact and 2) How to design better questions to elicit high-quality responses.

Why Most Product Managers Aren’t Great Storytellers

We are told that great Product Managers are great storytellers but the preaching often lacks actionable guidance on how to become good at storytelling. It’s time to change that!

OKRs vs KPIs: What’s the Difference?

KPIs = measures of health. OKRs = things we want to change.

Ditch Epics & User Stories and Focus on Outcomes

When I've helped organisations become more outcome/product orientated, more often than not, I've moved them away from 'epics' and 'user stories' and towards things like one-pagers, opportunities, hypotheses, etc. Why? Because they’re are better tools for facilitating outcome thinking and experimentation.

The Rise of Product-led Transformations

In 2019 an HBR article stated that of the $1.3 trillion spent on transformations, $900 billion was wasted. More interesting is that, Digital and Agile transformations alike are seldom seen in product-tech companies (e.g. Canva, Google, Amazon, etc). Moreover, one job search for ‘Scrum Master’ or ‘Agile Coach’ role, and you won’t find them at these companies either — why?

How to Kickoff Product Discovery like a Pro

A step-by-step guide (with templates) to level up your Product Discovery. A common question I get when I coach Product Managers is, "I know what I want to do discovery on, but how do I get started?" Although there are many ways to start discovery, I have two tools that are my absolute go-to for kicking off and structuring Product Discovery.

7 Different Product Roadmap Formats

There are many different types of roadmaps and different formats that roadmaps can take.

Here are a few different shapes a Product Roadmap can take. I hope this gives you some inspiration and perhaps even makes you rethink your current roadmap format.

‘Product vs Design vs Tech’: A Partnership, not a Battlefield

This is something that comes up often for me — I get questions like:

“What’s the difference between a Product Designer and Product Manager?”….All valid questions but they all have one problem. They are all coming from an individual perspective, not a team one