Here's 3 simple examples from this week on how product work changes with AI.
1. Added a hypothesis which triggered Claude to look through my existing data and analytics to see if it could validate it. Played back findings and updated the hypothesis status to 'active'.
2. Mid research Claude suggests one of the insight would make great "on brand" content. Told it to put it in the content backlog.
3. Mid workflow I’m notified me of an "Automation opportunity" to create an agent that pulls data from GA and automatically flags changes to my key metrics - it also then built it for me.
BONUS:
I was just talking with a product team at a client about getting confluence and jira hooked up with the following workflow:
PM writes spec in confluence
→ it's extracted by AI as a md file
→ AI goes through the code base and the spec and determines the best way to slice the work
→ PM reviews → when approved pushes it as user stories into jira
→ engineers can pull md file and linked jira tickets to automate delivery (and they get to just work out of VS Code (no more going back to jira or confluence).
I’m a firm believer in reinventing yourself before your product. FYI this is the topic of my last newsletter post 👉 https://t.co/5WMguo9PXp
💥 exactly what the First 90 Days course was designed to do 👇
A 5/5 review and this nice email from someone who recently took the course (https://t.co/BSHBRLMB72)
Meet "RampUp"
A fictional company with a full data set and profile;
- Financials
- Product usage
- Customer feedback
- Employees
- etc
Eg. "Founded in 2021, it's raised $43m to solve employee onboarding but of late it's been struggling.”
This is the challenge that the product leaders joining this week's Product Strategy in Practice course are going to be solving.
Each participant will be given:
1. A brief
2. Access to the data through an AI Data Scientist who's able to get data on any question you throw at them.
3. 2x Customers (AI personas) who they can interview
All this would have taken me weeks - if not months - to pull together in the past.
And it wouldn't have been interactive!
Can't wait to run it! I've enjoyed experimenting with novel ways to leverage AI beyond just feeding it content.
There’s still a few spots if you’re keen to join and give it a try!
👉 https://t.co/ybcgeMNSr6
13 spots. Then it's gone.
We sold out both live cohorts last year, and we're almost there again.
Only 13 spots remain for Product Strategy in Practice March cohort. We kick off in 2 weeks!
There's still a window to get it expensed
If you've been sitting on it, now's the time.
Grab one of the 13 spots 👉 https://t.co/TUlqXs1dCA
Does prioritization feel difficult?
Perhaps it looks like this; spending hours in spreadsheets, completing complex formulas trying to score everything...
Or perhaps you feel like there's a capacity issues - if only we could increase our velocity...
None of these work.
Because they're not solving the underlying issue.
They're not prioritizing in layers from Vision → Strategy → Outcomes → Opportunities → Ideas
If any of this resonates, then this week's live stream is for you 👉 https://t.co/wUafsT3ExA
p.s. still the best meme on prioritization #tooreal 😂
(thanks work chronicles)
Does prioritization feel difficult?
Perhaps it looks like this; spending hours in spreadsheets, completing complex formulas trying to score everything...
Or perhaps you feel like there's a capacity issues - if only we could increase our velocity...
None of these work.
Because they're not solving the underlying issue.
If any of this resonates, then this week's live stream is for you 👇
https://t.co/v0bi3k4GLe
Thanks everyone who joined live 🙏 appreciate the shoutouts at the end, glad it was valuable!
Here's the recording for those who missed it👇 https://t.co/SAvxrclYRi
T-minus 48 hours until this week's live stream on 'You Don’t Need Another Prioritization Framework: Just These 4 Components'
Let's be real, you don't need another prioritization framework.
You're not going to find some magical framework that will solve everything.
Instead you need to learn how to prioritize from first principles - what does all these frameworks have in common? To break them down to the core concepts.
Once you understand those you can ditch the frameworks and finally prioritize effectively.
That's my goal in this week's live stream.
Do you understand prioritization well enough?
It might be worth joining!
We're nearly at 200 registrations.
See you there 👉 https://t.co/KwtNzxg5aQ
9 prioritization lessons I learned the hard way (ashamed to admit... the last two took me near 10 years to learn):
1. Prioritization isn't something that happens on your backlog... it's multi-step. You prioritize when you're defining your strategy and you prioritize all the way down to your day-to-day tasks.
2. Impact vs Effort only tells half the story. It's good enough for most things but as complexity increases factoring in things like Confidence and Urgency will change the way you look at things.
3. All prioritization frameworks can be broken down into 4 components: Impact, Effort, Confidence and Urgency.
4. Frameworks can help but they're work best when you have a strategy to anchor against. For example, 'Impact' should be impact on your outcomes which are defined by your strategy. Otherwise what are you defining impact as?
5. Secondly given 1. there's no single framework that will work across everything. Instead think of prioritization frameworks as tools in a toolbox. You need to find the right one for the job. For example, RICE only half-works for prioritizing opportunities because it's hard to define "effort" when there's no solution yet... other times cost of delay will be ideal or you need to factor in opportunity cost.
6. Most of the time you won't need any frameworks if you have an adequately focused strategy.
7. Be data-informed not data-driven. Just because something has a higher RICE score doesn't make it automatically the best thing to do. Treat data as an input and exercise judgement.
8. Not everything can be quantified. Some things are just worth doing.
9. Ignorance tax is paid anytime you choose something that has more unknowns. For example, starting a new idea vs improving what you have today. The new idea sounds nice but once you get into it you'll realise it's not as easy as it seems = ignorance tax. Moral of the story, choose the known > unknown.
Q: "I get that your roadmap should be a reflection of your strategy but what if I don't have a product strategy? How do I create a product roadmap then?"
Here's exactly how I tackle this scenario with a PM in the Product Mentorship on Product Pathways:
Step 1: 'Bring Out Your Dead'
I call this step 'bring out your dead' the idea is to go and gathering everything. From ideas, to features, user requests, opportunities, etc. Just pull them all into one place.
Step 2: Extract Narratives
Instead of jumping to prioritizing, go through the list and start to synthesize. Talk to each item, what is it, why do we need to do it, what is it related to, etc.
The idea is to start to extract narratives that explain intent behind the items. The outcomes and the problems they solve.
This is where you start to make the leap from laundry list to a roadmap that tells a story!
Step 3: Prioritise Narratives
Once you have narratives, sequence them. It's important that you prioritize the narratives themselves not the individual features. I'd recommend doing a simply Now / Next / Later.
Step 4: Map the Work
Now that you have your narratives in order. You have your backbone for the roadmap. In a way it's a rudimentary strategy.
Once you've got that, now you can start to map all those features and ideas that you collected in step one to the narratives.
If something no longer fits, it's a good reflection point on whether it's actually going to move the dial.
Note: if you prioritise the ideas first - which is what most people do - you end up with a laundry list that doesn't have cohesion. This way you can look at everything in the 'now' column and you have a story (narrative) as to why they're there.
Step 5: Add Outcomes
Finally, you can start to add outcomes to your roadmap. Ask yourself what success looks like. This could be at the individual item level, or at the narrative level (or both).
And voilà!
You now have a product roadmap that:
→ is strategic
→ tells a story
→ and is outcome-oriented
BONUS and you have the start of a product strategy!
===
📌 See this in action. Full live stream where I walked through this exact example: https://t.co/pxHIPSKsEQ
Q: "I get that your roadmap should be a reflection of your strategy but what if I don't have a product strategy? How do I create a product roadmap then?"
Here's exactly how I tackle this scenario with a PM in the Product Mentorship on Product Pathways:
Step 1: 'Bring Out Your Dead'
I call this step 'bring out your dead' the idea is to go and gathering everything. From ideas, to features, user requests, opportunities, etc. Just pull them all into one place.
Step 2: Extract Narratives
Instead of jumping to prioritizing, go through the list and start to synthesize. Talk to each item, what is it, why do we need to do it, what is it related to, etc.
The idea is to start to extract narratives that explain intent behind the items. The outcomes and the problems they solve.
This is where you start to make the leap from laundry list to a roadmap that tells a story!
Step 3: Prioritise Narratives
Once you have narratives, sequence them. It's important that you prioritize the narratives themselves not the individual features. I'd recommend doing a simply Now / Next / Later.
Step 4: Map the Work
Now that you have your narratives in order. You have your backbone for the roadmap. In a way it's a rudimentary strategy.
Once you've got that, now you can start to map all those features and ideas that you collected in step one to the narratives.
If something no longer fits, it's a good reflection point on whether it's actually going to move the dial.
Note: if you prioritise the ideas first - which is what most people do - you end up with a laundry list that doesn't have cohesion. This way you can look at everything in the 'now' column and you have a story (narrative) as to why they're there.
Step 5: Add Outcomes
Finally, you can start to add outcomes to your roadmap. Ask yourself what success looks like. This could be at the individual item level, or at the narrative level (or both).
And voilà!
You now have a product roadmap that:
→ is strategic
→ tells a story
→ and is outcome-oriented
BONUS and you have the start of a product strategy!
===
📌 See this in action. Full live stream where I walked through this exact example: https://t.co/pxHIPSKsEQ
Don't rely on a single product roadmap.
This is where I see a lot of Product Managers go wrong.
They overload their product roadmap trying to make it work for everyone and for every situation.
From dependencies, delivery timelines, releases, opportunities, solutions, alignment to high level goals, etc... you end up needing a PhD to read it.
As the adage goes; "if it's for everybody, it's for nobody"
It's then no wonder they're struggling to get buy-in.
And their messages aren't landing.
So if you to influence stakeholders, then you need to start treating your roadmap as a communication tool.
Start with the audience:
→ who am I presenting this roadmap to?
→ what information do they want and what don't they need?
→ what format would be best? (this is important because sending the CEO of a Fortune 500 company a link to Jira isn't going to cut it)
And tailor your roadmap to them.
Of course this doesn't need to mean you're recreating a new roadmap every time.
You'll find that you'll have 2-5 groups of audiences:
The most common I see are:
1) for executives
2) for external teams (eg sales, marketing, even a public roadmap)
3) a detailed version for product and engineering
4) public roadmaps for customers
Different audiences.
Each with different levels of information and formats.
Yes it's more work, but this can be the difference between influencing a stakeholder and getting bogged down into unnecessary details.
===
More on roadmaps:
📌 How to Build a Product Roadmap: 5 Steps From Features to Outcome Roadmap (REAL EXAMPLE): https://t.co/pxHIPSKsEQ
📌 Best Practices for Building Effective Product Roadmaps: https://t.co/zBQm0eYStI
Don't rely on a single product roadmap.
This is where I see a lot of Product Managers go wrong.
They overload their product roadmap trying to make it work for everyone and for every situation.
From dependencies, delivery timelines, releases, opportunities, solutions, alignment to high level goals, etc... you end up needing a PhD to read it.
As the adage goes; "if it's for everybody, it's for nobody"
It's then no wonder they're struggling to get buy-in.
And their messages aren't landing.
So if you to influence stakeholders, then you need to start treating your roadmap as a communication tool.
Start with the audience:
→ who am I presenting this roadmap to?
→ what information do they want and what don't they need?
→ what format would be best? (this is important because sending the CEO of a Fortune 500 company a link to Jira isn't going to cut it)
And tailor your roadmap to them.
Of course this doesn't need to mean you're recreating a new roadmap every time.
You'll find that you'll have 2-5 groups of audiences:
The most common I see are:
1) for executives
2) for external teams (eg sales, marketing, even a public roadmap)
3) a detailed version for product and engineering
4) public roadmaps for customers
Different audiences.
Each with different levels of information and formats.
Yes it's more work, but this can be the difference between influencing a stakeholder and getting bogged down into unnecessary details.
===
More on roadmaps:
📌 How to Build a Product Roadmap: 5 Steps From Features to Outcome Roadmap (REAL EXAMPLE): https://t.co/pxHIPSKsEQ
📌 Best Practices for Building Effective Product Roadmaps: https://t.co/zBQm0eYStI
There's no one way to do Product Strategy.
Because it's contextual.
Your context drives
→ the constraints
→ the problems to solves
→ the questions you need to answer
→ the choices you need to make
Eg. The product leaders I work with in government and not-for-profit organizations don't need to make pricing decisions, but you might.
However for those new to product strategy I know starting with a blank page or being told "it depends" is not helpful either.
So to make this practical I'd recommend starting lightweight with a one-pager - like this one: https://t.co/YcBlJ7o3Tc
And answer:
WHY = Vision/Winning Aspiration
WHO = Target Market
HOW = Unique Value Proposition/Differentiation
WHAT = Product Offering/Bets
WHEN = Distribution
+ Success Measures
This will be a small step from where you are today, rather than trying to do a giant leap.
Start here. Iterate and learn.
You’ll still have a long way to go building a detailed product strategy but it’ll be better than doing nothing because it seems to big and daunting.
BONUS: If you're more progressed in your product strategy journey. You can still use one-pagers as a communication tool. Add a link to your product strategy doc for those who want more information.
===
🎁 FYI I have just pulled together two templates, plus a bunch of real product strategy examples, all for FREE here: https://t.co/zlAYq5eaON
Bonus, you’ll also get a couple of emails and videos from me to help you level up your product strategy craft.
p.s. there’s 15 spots remaining in the upcoming Product Strategy in Practice course. Live cohort based (hence the limited spots) 👉 https://t.co/xiOLlafOxx
There's no one way to do Product Strategy.
Because it's contextual.
Your context drives
→ the constraints
→ the problems to solves
→ the questions you need to answer
→ the choices you need to make
Eg. The product leaders I work with in government and not-for-profit organizations don't need to make pricing decisions, but you might.
However for those new to product strategy I know starting with a blank page or being told "it depends" is not helpful either.
So to make this practical I'd recommend starting lightweight with a one-pager - like this one: https://t.co/YcBlJ7o3Tc
And answer:
WHY = Vision/Winning Aspiration
WHO = Target Market
HOW = Unique Value Proposition/Differentiation
WHAT = Product Offering/Bets
WHEN = Distribution
+ Success Measures
This will be a small step from where you are today, rather than trying to do a giant leap.
Start here. Iterate and learn.
You’ll still have a long way to go building a detailed product strategy but it’ll be better than doing nothing because it seems to big and daunting.
BONUS: If you're more progressed in your product strategy journey. You can still use one-pagers as a communication tool. Add a link to your product strategy doc for those who want more information.
===
🎁 FYI I have just pulled together two templates, plus a bunch of real product strategy examples, all for FREE here: https://t.co/zlAYq5eaON
Bonus, you’ll also get a couple of emails and videos from me to help you level up your product strategy craft.