Hers's a tactic I use when Stakeholders come with solutions, NOT problems.
Don't work backwards, work forward.
What do I mean by that?
Commonly when a stakeholder comes w/ a solution we try to get them to work backwards to the problem.
But for some this is a stretch.
Observation from coaching over 100 product managers around the world; most PMs are stuck trying to stack rank a 200+ item long backlog thinking that's the job. When really it's the final yard. 80% of prioritisation happens upstream through your product vision,ย strategy, outcomes and customer opportunities.
This plays into other dynamics I see often:
- Roadmaps that are laundry lists of features
- Backlogs that don't include opportunities
- Key results that are also laundry lists of outputs
- Little to no discovery, insight or data.
I get why this happens, so this isn't a "you're doing it wrong" post. There's a lot of inertia in organisations and having conversations at those higher levels is hard - especially when the CEO says "it's all no. 1 priority"
In those scenarios it definitely becomes a skill to influence up.
I share more on this and what to do in my latest newsletter post: https://t.co/jJshVXJdmN
"Sometimes the most valuable thing you can do is stop prioritising the work and start prioritising the logic that determines why the work exists in the first place."
๐๐๐
Full credit to Jason Humberstone from a repost to one of my Linkedin posts.
The best product leaders I know are close to the details. They do this so they can avoid the 'iceberg of ignorance' where only ~4% of frontline problems are known to top management.
This doesn't mean they micromanage. It's about being close to coach, course correct and unblock.
It's hard to make the right decisions if you don't know what's actually happening on the ground, the challenges and constraints.
7 more habits of highly effective product leaders ๐ย https://t.co/5d8QlS2osm
p.s. I don't think it'll be 2 years (longer reason why: https://t.co/5WMguo9PXp) but I do think it'll happen.
It might be closer to that time horizon for you given your customers (I assume most of your customers are solopreneaurs and small to medium businesses).
I say that because individuals always adopt things first, then small businesses (startups), then the SME's join, finally 10+ years later enterprises come to the party - and government/institutions.
Now overlay that with the diffusion of innovation, you'l still have laggards and late majority who will still want a UI. I even got it in the comments on my post about not looking at dashboards anymore on LI. But they might not be your customers - but they'll be someone's customers and hence UI/UX will still be around just not so dominate as today.
My 2 cents. I might be wrong though. Can't predict the future.
This is happening real time for my business too - https://t.co/DBF3IkCg0P
I don't look at dashboards anymore for example. I haven't in months. Because I can get a much richer picture in Claude with everything connected. I also have agents set up to push insights and data to me.
If you go back to first principles and ask what job does a dashboard solve, it's either;
a) I have a question I need answering
or b) I'm looking for insights/trends/opportunities
AI has opened the door for new solutions to those jobs - better solutions for me.
p.s. my newsletter is with Kit but I was this ๐ค close to using Beehiiv instead. Been a fan, have followed you and the company for a while. This could be enough to make me make the switch.
I don't look at dashboards anymore.
The dashboards are still there (I have Mixpanel, GA, and have a few other tools that have dashboards) but I haven't opened them in months.
Instead Claude manages it all for me.
If I have a question or want to know something - I just ask;
โ "Which post drove the most sign-ups?"
โ "How are people finding my newsletter?"
โ "What topics are my audience the most interested in?"
And alerts and insights are surfaced to me without needing to open anything.
I share this not because I'm trying to scare you into thinking AI is going to take your job... I share this because it's something all product leaders need to be thinking about right now.
I've been speaking with a lot of product leaders who are worried about the 'SaaSpocolypse'.
A common concern is that AI allows anyone to build their product - so why pay for it.
That's true until it breaks at 3am and the founder is now the one fixing it rather than focusing on their own product. That piece of mind, loss in focus and time is actually the main reason why people pay for products in the first place.
But where I think the SaaSpocolypse is justified is my dashboard example.
Tools today are built for humans.
A dashboard is the perfect example of that. It's visual and everything about it was built for human eyes.
But we're heading to future where it will be humans + agents.
And that's what you should be thinking about.
How do we adapt to a human + agent world.
I haven't cancelled any of those subscriptions because I still need to get the data somehow but if I can't or if there's a better more rich way for my agents to get the data then I'd switch.
===
p.s. if you want to get hands on with Claude Code and build something like this for yourself. I'm running a AI Build Day for PMs in Sydney on the 26th June to help you do just that. Limited spots ๐https://t.co/pzLSWRD4xx
Great product leaders obsess over clarity
They ensure their team are clear on:
- What their role is
- What theyโre empowered to do vs not
- Where and how to ask for things
- Their career path
- Values, principles, expectations
- What we mean by certain terms
- The vision, strategy, context
- etc.
This might seem like a no-brainer but I'm sure you've had roles where expectations were fuzzy, promotions vague, or responsibilities unclear - how did that affect your performance?
Low clarity leads to waste, teams spinning their wheels, misalignment and all kinds of issues that could otherwise be avoided.
And don't underestimate the effort that this takes.
There's a lot of time spent communication, clarifying and creating things like role competency matrix's.
Leadership isnโt passive. Itโs not about โdelegating everythingโ. Itโs active, shaping work through clarity.
โControl, we discovered, only works with a competent workforce that understands the organizationโs purpose. Hence, as control is divested, both technical competence and organizational clarity need to be strengthenedโ โ L. David Marquet, Turn the Ship Around
7 more habits of highly effective product leaders ๐ย https://t.co/5d8QlS2osm
Product Discovery has two modes:
1. Exploring
2. Exploiting
Most teams I work with are great at exploiting. They're really good at optimising what they already have/know. eg make the onboarding flow better, improve churn, come up with a solution for X, etc.
But few teams are really good at exploring.
Exploring what's possible. Gathering insights that shape the strategy and uncover untapped opportunities (potentially whole new products!)
More on what this looks like and how๐
I worked with a product leader once who would share her notes at the end of every executive meeting.
A straight copy and paste. No editing nor reframing the message.
It's a great example of leading with "context over control".
7 more habits of highly effective product leaders ๐ย https://t.co/5d8QlS2WhU
When was the last time you spent a day with your customers with no agenda?
No prototype.
No research questions.
No assumptions to test.
Just observe, be curious and see what you learn.
We're often trained as product teams to optimise what they already know - to "Improve onboarding", "reduce churn" go answer this research question.
And it's all important work (and should be the bulk of you discovery efforts)
But there is something that's often missed when we obsess over this too much.
Exploring.
Exploring what's possible.
Finding problems you didn't even know existed.
Uncovering new opportunities and even potentially new product lines.
In 1991, James G. March published a paper called "Exploration and Exploitation in Organizational Learning" where he showed that organisations have to balance exploring new possibilities with exploiting old certainties, and most fail because they over-index on the latter.
Which is why I opened with; "When was the last time you spent a day with your customers with no agenda?"
When was the last time you spent some time exploring.
As James G. March and others have found, you need to do both.
๐ https://t.co/jJshVXJLcl
What a month May was ๐ฎโ๐จ
I just sent out my monthly newsletter for @ProductPathways and it made me realise how much work happened behind the scenes last month to make June a BIG month!
3 major events happening in June:
1. Final Product Strategy cohort for 2026 (kicks off 3rd June!): https://t.co/ybcgeMNSr6
2. AI Build Day for PMs: https://t.co/pzLSWRD4xx
3. Product Leaders Dinner the night before
Pumped!
I'll see several of you at the Product Strategy cohort on Wednesday...
and then a bunch at dinner...
and the AI build Day later this month!
๐๐๐
5 signs you're prioritising at the wrong level:
1. Your backlog is 100s of items long
2. You're trying to prioritize in spreadsheets
3. When two stakeholders ask for completely different things, you can't say which matters more.
4. You're debating which is more valuable but nobody can point to an outcome you're striving for
5. The work in your backlog has no obvious relationship to each other.
Prioritisation needs to happen in layers:
Vision โ strategy โ outcomes โ opportunities โ solutions.
Each filtering the next.
Trying to prioritise at the solution level without everything above will feel impossible.
The fix isn't a spreadsheet or another prioritisation framework, it's working your way back up these levels.
===
If any of this resonated, here's some resources that might help:
- Prioritization Happens In Layers: https://t.co/AcA9AcVeoa
- You Donโt Need Another Prioritization Framework: https://t.co/ryDntVjwTc
- You Don't Have a Prioritization Problem, You Have a Strategy Problem: https://t.co/wiiDqMDL2A
For the last 6+ months I've heard the same thing from Product Managers trying to get hands on with AI; "I can't find the time"
And I get it. Because AI, especially setting yourself up with something like Claude Code, isn't something you can do in 15-30 minute blocks here and there.
It's something that you really need to clear a couple of days for.
So being the product person I am, I wanted to find a great solution to this problem.
I decided to teamed up with Elizabeth Griffiths, GAICD and we're pumped to announce our first AI Build Day for Product Managers in Sydney on June 26th ๐ย ๐ https://t.co/pzLSWRD4xx
This has been in the works for a while now (months!) we've been doing discovery and really trying to take all the learnings that Elizabeth has had from running her AI build days in Byron to make this the best it can be.
What you can expect on the day:
โ for starters; no distractions. Finally get a day to just focus on getting hands on with AI
โ Accelerated learning. Learn in a day what would have taken you a week.
โ Hands-on, practical โ we'll actually build and get you set up and running together
โ Small numbers with a high coach-to-participant ratios so you'll get plenty of guidance and 1-on-1 support.
โ Private support channel post the day for ongoing support.
โ and a follow-up Zoom 3 weeks later. What got stuck. What's next.
If you've been wanting to go deeper with AI but haven't had the time or structure, this is worth a look.
I don't look at dashboards anymore.
The dashboards are still there (I have Mixpanel, GA, and have a few other tools that have dashboards) but I haven't opened them in months.
Instead Claude manages it all for me.
If I have a question or want to know something - I just ask;
โ "Which post drove the most sign-ups?"
โ "How are people finding my newsletter?"
โ "What topics are my audience the most interested in?"
And alerts and insights are surfaced to me without needing to open anything.
I share this not because I'm trying to scare you into thinking AI is going to take your job... I share this because it's something all product leaders need to be thinking about right now.
I've been speaking with a lot of product leaders who are worried about the 'SaaSpocolypse'.
A common concern is that AI allows anyone to build their product - so why pay for it.
That's true until it breaks at 3am and the founder is now the one fixing it rather than focusing on their own product. That piece of mind, loss in focus and time is actually the main reason why people pay for products in the first place.
But where I think the SaaSpocolypse is justified is my dashboard example.
Tools today are built for humans.
A dashboard is the perfect example of that. It's visual and everything about it was built for human eyes.
But we're heading to future where it will be humans + agents.
And that's what you should be thinking about.
How do we adapt to a human + agent world.
I haven't cancelled any of those subscriptions because I still need to get the data somehow but if I can't or if there's a better more rich way for my agents to get the data then I'd switch.
===
p.s. if you want to get hands on with Claude Code and build something like this for yourself. I'm running a AI Build Day for PMs in Sydney on the 26th June to help you do just that. Limited spots ๐https://t.co/pzLSWRD4xx
Great product leaders stay close to the work. Not to micromanage, but to be able to coach, course correct and unblock.
7 more habits of highly effective product leaders ๐ https://t.co/5UwoyIT0Iy
FYI I'm co-hosting an AI build day in Sydney on June 26th ๐ย https://t.co/pzLSWRD4xx
Hands-on, practical โ actually building things together, not just talking about AI. Capped number to keep the group small and the coaches-to-participants ratio high.
If you've been wanting to go deeper with AI but haven't had the time or structure, this is worth a look.
Two questions you should be able to answer for every product metric you track:
1. What are you trying to learn?
2. What will you change as a result of this metric?
There are 1,000s of things you can measure but measuring for measurement sake isn't helpful. Metrics must drives decisions.
Here's two recent examples:
1. Product Manager at a startup was asking me about increasing MAU (monthly active users). Their founder had decided that MAU was going to be their North Star metric.
Q: "What are you trying to learn?"
PM: Unsure. The only times customers engage with us are when they want to update their details, change policy or make a claim.... I guess they don't have a reason to engage with us regularly.
Q: "What change will you make as a result?"
PM: I guess none. Because we wouldn't want users to changing policies too often and claims means something went wrong.
(Side bar: Now it would be a totally different story if you had a strategy to increase retention by trying to solve underserved user needs that would require regular actions. This is exactly what one of my clients are doing right now!)
2. A new engineer manager wanted to start tracking every team's velocity.
Q: "What were they trying to learn?"
EM: To understand how the teams are performing.
Q: "What change will you make if the team's velocity was low? or high? or what about if it bounced up and down (as it typically does)?"
EM: Not sure. I hadn't thought about that.
If you're going to go through the effort to track something, be clear on why and what actions you intend to make as a result. Otherwise you're probably adding more noise than signal.
FYI I'm co-hosting an AI build day in Sydney on June 26th ๐ย https://t.co/pzLSWRD4xx
Hands-on, practical โ actually building things together, not just talking about AI. Capped number to keep the group small and the coaches-to-participants ratio high.
If you've been wanting to go deeper with AI but haven't had the time or structure, this is worth a look.
FYI I'm co-hosting an AI build day in Sydney on June 26th ๐ย https://t.co/pzLSWRD4xx
Hands-on, practical โ actually building things together, not just talking about AI. Capped number to keep the group small and the coaches-to-participants ratio high.
If you've been wanting to go deeper with AI but haven't had the time or structure, this is worth a look.
OKRs are a lagging indicator. You can't rely solely on them.
What you need is a chain of measures all reinforcing each other.
โ Experiments: are we heading in the right direction? (days to weeks)
โ Solutions: does the feature change behaviour? (weeks)
โ Opportunities:ย does the behaviour change solve the user need? (weeks to months)
โ Outcomes: does that change in user behaviour impact our OKR? (months to quarters)
If you wait for the OKR to tell you what's working, your feedback cycle is too long.
It's also not going to give you the level of detail you need.
It won't tell you:
- which experiments are working vs not.
- which solutions actually moved the needle.
- etc.
Here's how Senior PMs links this altogether ๐https://t.co/dwKX2GZn8h