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. We hit a wall, there's resistance. The Stakeholder can't understand why they need to give a problem, when they have this amazing solution idea (after all it's an awesome idea, right?)

So instead of trying to work against their thinking, go with it.

Driver + Navigator

This is one of my favourite models to encourage collaboration and bring clarity to the messy nature of product work.

Rather then having your typical RACI or accountability framework, map out:

🚗 Who is ‘driving’? and
🗺️ Who is ‘navigating’? For example, let's take a look at the product process through the lens of the product trio.

At the start we're prioritising, setting the strategy and deciding on what to focus on. During this phase, it's typically led by the PM - they would therefore be the ‘driver’.

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. We hit a wall, there's resistance. The Stakeholder can't understand why they need to give a problem, when they have this amazing solution idea (after all it's an awesome idea, right?)

So instead of trying to work against their thinking, go with it.

Product vs Design vs Engineering

I’m regularly asked questions like:

“What’s the difference between a Product Designer and Product Manager?”
“There seems to be a lot of overlap between Design and Product Management? Who does what?” All valid questions but they all have one problem.

They are coming from an individual perspective, not a team one.

Energy Management > Time Management

About 18 months ago I made the switch from only managing my time to managing my energy.

5 changes I've made:
- Focus sprints
- Better sleep
- Exercising later in the day
- Work right away
- Scheduling everything in my calendar 1️⃣ About 18 months ago I started doing 1.5 hour focus sprints.

The notion was based on the neuroscience of ultradian cycles - which is essentially the internal body clock.

Our ultradian cycles are 90 minutes. Meaning that the max we can concentrate is 90 minutes.

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

Don’t try to work backwards, work forward."

Let me explain.

No doubt you’ve been in this situation before. A stakeholder has come back from a conference or read one of the latest Forbes article and they’re pumped to jump on the latest trend.

And you’re now being asked the implement it.

But it’s pretty clear that it’s a solution looking for a problem.

Most Product Managers are terrible story tellers because they don't have any scaffolding.

We all have great stories on our product already.

We just need a way to firm it up.

Here is a structure I use regularly.

I call it "Building a narrative top-down, bottom-up"

/1 🧵 ⬇️ Top-down:

Starting at your product vision you can create a narrative/story all the way down. It looks something like this:

To realise [VISION]
Our strategy is [XYZ]
We'll focus on [OUTCOME X]
By solving [OPPORTUNITY Y]
Through building [X]

/2

*UPDATED* Product Discovery activities by risk.

Product Discovery is elusive and tricky to put down on paper because the activities you do is largely driven by what kind of risk you have.\

/1

🧵👇 💰 Viability Risk:
- Market Analysis
- Market sizing
- Segmentation
- Competitor Analysis
- Perceptual Mapping / Positioning Research
- Customer interviews
- Business modeling
- Price Testing
- Forecasting
- Kano Analysis
- Analytics
- etc

/2

One week ago, I got a call from a friend at 10pm at night.
7 hours later I was on an international flight 🛫

I got a text on Saturday night from a friend who runs a training business

Sensing the urgency in his voice I replied and he immediately called.

/1 What had happened was the trainer had pulled out 24 hours before they were scheduled to start.

This was the first of several courses with a new client and was not the first time this person had cancelled. They had already rescheduled this training once before.

/2

Here are 8️⃣different Product Roadmap formats:

⏰ Timeline Roadmap (❌ best to avoid where possible)
🗺️ Now-Next-Later
🚀 Release Roadmap
🎭 Theme Roadmap
🌳 Tree Roadmap
🌟 Outcome Roadmap
❤️ Customer Journey Roadmap
💭 Dream Mapping (thanks @squadformers!)

👇🧵/1 1) ⏰ Timeline Roadmap

First up, is the most common and controversial…
the ‘Timeline Roadmap’.

Timeline Roadmaps are common because of their dates. They're similar to project plans and can give a false sense of certainty about when something will be delivered.

/2

Tools I use as a Solopreneur to create content, tools, templates, videos (Youtube Channel buff.ly/3G7kJgn) and my online courses at @ProductPathways.

🧵👇

#BuildInPublic

/1 @ProductPathways 🎨 Graphics and templates:

@canva for stock videos, graphics and for making canvas' like this one 👉 buff.ly/41WSh9z

Canva is also great to create those carousel style linkedin posts.

I also use Keynote occasionally for content (+1 for carousel style posts).

/2

Asking better questions in your 1:1s 👥

Here's a list of prompting questions I compiled for the Stakeholder Management Essentials course on @ProductPathways to help you have better conversations in your Stakeholder. 1:1s. I use these questions regularly.

What would you add? @ProductPathways -What makes one-on-ones the most valuable for you?
-What are your current focus areas?
-What are your current concerns about this initiative / feature / opportunity / product?
-What’s top of mind?
-What are some things you’d like to discuss?

Great Product Managers don't say ‘no’ a lot.

Instead, they provide clarity and context so stakeholders can say ‘no’ to themselves.

🧵👇

/1 'No' without context can damage relationships and lose buy-in.

Instead a better way is to provide clarity and context so that stakeholders come to the 'no' conclusion themselves.

/2

OKRs vs KPIs

Really the difference is often how you want to define them because really they’re just labels.

But how I like to use them are:

KPIs = baseline health
OKRs = things we want to change

/1 OKRs are the things we’ve chosen to ‘change’ (either be improve, reduce, achieve, etc)

KPIs are the indicators that we monitor to ensure that things are running smoothly.

You need both.

/2

Don't scale agile.

Descale the work and organisation instead.

One of the best books on building an agile organisation is not what you'd expect.

But 'Team of Teams' is a bible for building a resilient and adaptive organisation.

Here's serveral enablers from the book 👇

/1 🧠 Share consciousness

Leaders must cultivate a shared consciousness across the organisation.

This is achieved through extreme transparency and sharing of information. As well as a shared purpose.

/2

A common question I get asked it "how often should I be engaging with customers?"

Short answer: as frequent as it is effective for you.

What do I mean by that?

Gathering more data and input is just noise if you can't act on it.

🧵/1 When I work with product teams one of the first things I assess is their learning cycle:

- How fast are they learning?
- How fast can they adapt as a result?
- How effective is their learning?

Your learning cycle is going to dictate ur cadence with cust more than anything.

/2

Pre-Mortems are one of the most underused tools in your #ProdMgmt toolkit.

Unlike Post-Mortems which most are familiar with, rather than waiting until the end when everything has already gone wrong. A Pre-Mortem is done at the start of a project or item of work.

/1 During a Pre-Mortem the team and relevant parties will seek to predict what might go wrong and then work backwards to identify ways in which they could mitigate those things from happening.

A framework I like to use to facilitate Pre-Mortems is the matrix above.

/2

Sick of Jira?
Struggling to manage your Product Backlog?
Lost in the vastness of your backlog?

Here are 8️⃣different ways to organize your Product Backlog 🧵👇

(including templates) 1️⃣ User story Map

User Story Maps are a great way to quickly build out your backlog for the first time, it’s also a powerful tool for release planning.

For more mature products I’ve often split my user story map by customer archetype, JTBD and even problem spaces.

Acquisition vs Activation:

Acquisition is when you get them on board

But activation is when you get them to use your product in a meaningful way.

It’s worth understanding the difference.

A 🧵 (incl. inactive vs disengaged users)

/1 Each product will define this differently.

eg. I had a FinTech client that was tracking DAU however, how many ppl check their bank acc daily? Not many. MAU would be more applicable - better: understand cust behaviour and define how to measure the behaviour you want to see.

/2

Q: "If only the most important Product Backlog Items are prioritized at the top anyways. Who cares if you have an infinitely long Product Backlog?"

The first problem is that things change.

👇👇

1/ Market, customer, business needs and priorities change over time. The product changes too.

Something that was put on the backlog even 6 months ago can quickly become obsolete. Not to mention something that was added years ago - how likely is that to still be relevant now?

2/

Paradoxes of Prod Mgmt (*brain dump)

♥️ Solve customer problems vs 🎯Achieve biz goals
🛠 Good enough vs 🤩Amazing experience
💪 Confident vs 🤷‍♀️Uncertain
🎨 Creativity vs 📦Reality
🔨 Pragmatic vs 🚀Ambitious
💡 Invention vs 🧰 Maintenance
🕰 Short-term vs 🛣 Long-term

/1 📈 Growth vs 🔒 Retention
📊 Data vs 🤔Intuition
✅ 'Come up with ideas like you're right' vs ❌ 'Test them like you're wrong'
🏋️‍♀️ Challenging the team vs ⚔️ Protect the team
🏆 Give credit vs 🙋‍♀️Take responsibility for failures
💯 All responsibility vs 👌Zero authority

/2