Senior Product Manager / Lead Product Manager

I just figure out what needs to be solved in what order, build relationships and get to work.

• 7 years as an Analyst (revenue, pricing, data science).
• 7 years in Product (travel ecommerce, media, fintech).
• Worked in growth, platform & core product roles.

I'm interested in GenAI, search, b2c.

George Nurijanian

PMs (especially juniors) should use Claude Code for the simple reasons that

- it will make you more comfortable with the terminal and git, erasing a lot of the anxiety about those "scary" tools engineers use
- you won't learn product sense, but you will get into the mind of shipping real stuff, not those Lovable prototypes that don't impress anyone. touch the metal (to a degree), don't play in the sandbox. so you'll be well ahead of your peers even if you haven't yet built a breakthrough product
- you'll be surprised how many great ideas you'll start to get, from automating workflows to trying new AI skills and building apps. if you were in a rut, it'll get you out of it
- and the cool thing is that THESE IDEAS WILL BE POSSIBLE. you won't just get an idea and be stuck dealing with implementation details! CC can do it all honestly
- install great product development plugins like compound-engineering (find more at prodmgmt.world/claude-code) -- they will help you think through product decisions, it's like pairing with an engineer who won't sneer at you for asking questions
- if you get access at work, omg even better. but honestly $100-200 for a magical genie in a bottle that can do anything on your computer is dirt cheap and it will get cheaper i think. you earn enough, stop being cheap
- if you bought into the anti-AI hype, try to apply inversion for a moment. what if these slop peddlers on X who are talking about AI all day... what if they are right? upside is uncapped, downside is minimal, this is a perfectly asymmetric bet. it's Pascal's wager in new clothes. it's a better bet to believe than to not believe.

Daily product management tips & tools • Get my Product Management System, stop worrying about work • See what’s inside ↓

Open article: Claude Code for Product Managers by prodmgmt.world

Junior PM: I feel like I'm doing PM wrong. Our company doesn't work like anything in the books.

Senior PM: Which books?

Junior PM: Cagan. Ries. All of them. They talk about empowered teams and continuous discovery. We have none of that.

Senior PM: And this makes you feel like you're failing.

Junior PM: Constantly. I keep trying to implement these frameworks but they never stick.

Senior PM: Have you asked yourself who those books were written for?

Junior PM: For product managers. Obviously.

Senior PM: No. Those books describe how things worked at specific companies, during specific eras, with specific leaders.

Junior PM: But they're best practices.

Senior PM: They're case studies dressed up as universal truths. 

Junior PM: So the books are wrong?

Senior PM: The books are accurate. For those companies, at that time. Your company is neither of those.

Junior PM: So what am I supposed to do? Ignore everything I've learned?

Senior PM: Read the book. Note the principle. Then look at your actual company.

Junior PM: Look for what?

Senior PM: What works here. Not what should work. Understand the problem, don't jump to the solution - same advice as you would get about solving your customer problems, just turned inwards.

Junior PM: That feels like giving up.

Senior PM: It's the opposite. You stop being a student applying theory. You become a scientist running experiments.

Junior PM: But how do I even know what works if I've never seen good product management?

Senior PM: Watch who ships. Who actually gets things out the door.

Junior PM: Ok, yes, I can think of a few examples.

Senior PM: There you go. Study them. What do they do differently?

Junior PM: They never wait for permission. They build small things, show people, and suddenly it's real.

Senior PM: You just described better product management than most books.

Junior PM: But I thought we needed proper discovery. User research. Evidence.

Senior PM: You need to understand constraints. Know why something is hard. Detect when someone is hand waving.

Junior PM: That's it?

Senior PM: That's more than most PMs ever learn. The books give you vocabulary. Your company gives you reality. Your job is to bridge them.

Junior PM: So I should stop feeling bad that we're not like the companies in the books?

Senior PM: Those companies mostly don't exist anymore. Or they've changed so much the authors wouldn't recognize them.

Junior PM: That's oddly comforting.

Senior PM: The PM influencers on LinkedIn describe scenarios that happened at maybe ten companies total. Everybody else is figuring it out as they go.

Junior PM: So what's the actual job then?

Senior PM: Observe what works at your company. Contrast it against the literature. Build your own hypothesis about how to ship things.

Junior PM: That sounds harder than just following a framework.

Senior PM: It is. But it's the only thing that actually works.

I lowkey predict product roadmaps will look nothing like they do today by 2028

- quarterly planning cycles will compress to monthly or less
- "features" disappear as units of work, replaced by outcome targets agents ship against continuously
- the roadmap itself becomes a live dashboard of experiments running, not a Gantt chart of what's coming
- PMs stop thinking in terms of narrow slices of the products/features they own and start shipping complete experiences
- orgs will compete for compute the way they once competed for engineering talent
- the quality of the specs will still matter, but more so for how well the agents can execute them
- product ops will merge into devx and will have access to agentic traces looking for automation opportunities

a new era is starting.

every PM building new products should watch this (1.5 hrs)

Mihika (Figma) shares how to go from idea → company-wide hype → shipped product

I distilled 12 actionable insights, but watch the whole video:

No alternative text description for this image

The PM plugin is telling

Ten Anthropic-verified plugins at launch. Product Management alongside Productivity and Marketing.

That's where Anthropic sees the highest-value enterprise use cases in 2026.

For PMs, this has `/write-spec` for PRDs, `/roadmap-update` for stakeholder comms, `/synthesize-research` for discovery synthesis, `/competitive-brief` for market intel, `/metrics-review` for product analytics.

I'll be testing this out to see how it stacks up against other alternatives shortly, but I already know this won't be as in-depth as my library of skills (https://lnkd.in/gC_dM6Gf)

Most PMs don't use Claude Code at all.

Meanwhile, there are PMs using it to run their entire product workflow - from strategy docs to engineering tickets.

Here are 6 ways to actually use Claude Code as a PM:

1. Prototyping (the obvious one)

Build working MVPs in hours instead of weeks of cross-functional coordination.

But this is where most PMs stop. They treat it like a fancy wireframe tool.

2. Product strategy docs

Point Claude Code at your user research, competitive analysis, and metrics.

Ask it to draft your strategy doc. It sees connections across documents that you miss when switching tabs.

The output needs editing. But you're editing instead of staring at blank pages.

3. Order of operations consulting

"I have these 12 things to do. What order makes sense?"

Claude Code can read your project context, see dependencies, and suggest sequencing that accounts for blockers you forgot about.

It's like having a principal PM on call to gut-check your priorities.

4. Research synthesis

15 user interviews sitting in transcripts.

Claude Code processes all of them in minutes, surfaces patterns, contradictions, and quotes you'd miss after interview fatigue sets in.

Do this while research is fresh - not 2 weeks later when you've forgotten half the context.

5. PRD drafting

A decent PRD draft in 10 minutes instead of 2 hours.

Give Claude Code your user problem, success metrics, and constraints. It generates the structure.

You spend time refining the thinking, not formatting sections and remembering what template to use.

6. Complete workflow automation

User research to PRD to stakeholder slides to engineering tickets.

One continuous session. Each output feeds the next.

This is where Claude Code stops being a tool and becomes a junior PM who never gets tired and has perfect memory.

The common thread across all of these: Claude Code works better when it has context.

Feed it your actual docs. Point it at your real files. Let it see the full picture.

That's when it stops being a chatbot and starts being useful.

i compiled 11 must-read articles on AI agents I have read and favorited in my Reader app

had to filter for the last 3 months, even that feels old-ish
heck, 50% is by Anthropic, go figure 🤷 

here's the full list:

1. https://lnkd.in/eRGB77qm

2. https://lnkd.in/e8X9rZvK

3. https://lnkd.in/efbEpPUa

4. https://lnkd.in/egTxPZbY

5. https://lnkd.in/eAcRsTJj

6. https://lnkd.in/efXKxcaS

7. https://lnkd.in/ey58piNy

8. https://lnkd.in/ex-MAeVp

9. https://lnkd.in/ektus5Fi

10. https://lnkd.in/ei46yMEd

11. https://lnkd.in/eR96xPMK

Open article: A Guide to Claude Code 2.0 and getting better at using coding agents by sankalp.bearblog.dev

A Guide to Claude Code 2.0 and getting better at using coding agents

I've been reviewing product opportunity selection decisions from product teams (including my past work) and I keep seeing the same mistake. Let me share what separates the best from the rest:

1. Most PMs kill their best opportunities before exploring them. They ask "how hard is this to build?" during opportunity selection. That question is poison.

2. When you estimate effort before committing to an opportunity, you're not evaluating the opportunity. You're evaluating the first solution that comes to mind. These are wildly different things.

3. RICE and ICE frameworks train you to weight effort heavily. This makes sense for solution prioritization. For opportunity selection, it introduces solution bias before you've explored the solution space.

4. A team I know rejected "help users find relevant content" because engineering estimated 6 months for a personalization engine. A different team committed to the same opportunity without asking about effort. They found a 2-week solution with manual curation that solved 80% of the problem.

5. The second team separated opportunity selection from solution selection. They committed to the customer problem first, then found creative ways to solve it cheaply.

6. Constraint-driven creativity only happens when you've already committed. "We must solve this with minimal eng resources" produces better solutions than "is this worth our eng resources?"

7. Another filter that catches hidden problems: every opportunity must be solvable independently without touching sibling opportunities. If you can't address opportunity A without also fixing B, you've smuggled in a solution assumption.

8. Most "opportunity statements" are actually themes or outcomes disguised as opportunities. Real opportunities are tied to a single moment in the customer journey. This prevents boil-the-ocean thinking.

9. Speed matters more than accuracy in early opportunity selection. Accept conservative mid-scores for missing data and flag the gaps. Getting to assumption testing in week 1 teaches you more than three weeks of "better" analysis.

10. Customer satisfaction should be deliberately under-weighted in your scoring. Pain alone doesn't make something worth doing. Strategic fit predicts long-term defensibility. High-pain, low-fit opportunities are traps.

11. Your first opportunity selection will be wrong. The goal is to learn why it's wrong, not to avoid being wrong. Perfectionism in opportunity selection is just analysis paralysis with a fancier name.

If you want a prompt that implements this exact framework with distinctness filters and scoring weights built in, I put together a collection of 180 AI prompts for every stage of product work:

I spent a day testing Anthropic's PM plugin through a complete workflow - research synthesis to PRD to stakeholder update. 
                                                         
The outputs look professional. They fail every reality test.                                                                                  
                                                                                                                                                
But that's not the point. The plugin gives executives permission to ask "why do we need so many PMs?"                                         
                                                                                                                                                
What individual PMs do about this matters more than plugin quality.                                                                           
                                                                                                                                                
Full test results:

https://lnkd.in/ecqq5Smk

Claude Code is for technical work:

- debugging across 6 files to track down a state management bug 
- refactoring a component that touches 12 different imports                                                       
- git operations when I need to see which files changed                                                              
- anything where I need the full codebase context                                                                  

Claude Cowork is for admin work:   

- filling out forms in PDFs
- editing DOCX files                    
- cleaning up Downloads folder (drag, rename, delete)

https://lnkd.in/ekzNWdXg

RICE and ICE frameworks optimize for the wrong thing.

They treat roadmap items as independent. Ship highest score, then next, then next.

But your roadmap is a system. Each item changes conditions for every other item.

Better question than "what's most valuable next?": What creates the most leverage for everything that follows?

- Best starting point is often NOT the highest-priority item - it's the foundational piece that makes everything else easier
- Some "low priority" items are root causes driving multiple high-priority outcomes
- Map which items have outgoing influence vs incoming effects
- Fix one driver and three problems disappear

Same items, different sequence. The team sequencing for reinforcement ships faster because each item makes the next one easier.

I codified this sequencing methodology as an AI skill for Claude Code or a prompt for ChatGPT. Transforms unstructured task lists into momentum-generating sequences using interrelationship diagrams.

Open article: 180+ AI skills that turn real product work into repeatable workflows by prodmgmt.world

180+ AI skills that turn real product work into repeatable workflows

How many great product ideas have you had that died because you couldn't build them?                                         

• Claude Code (my preference, not sponsored) eliminates the implementation gap                                                                              
• You get an idea → you can prototype it that afternoon                                                                      
• No more "I wish we had a tool that..." - just build it                                                                     
• No more waiting on eng bandwidth for simple automations                                                                    
• Start here: prodmgmt.world/claude-code                                                                                     

The best PMs I know ship things, so ship. It doesn't really matter what, don't overthink it.

While on a break I made:

- a BookTok to Goodreads PWA that helps me add books from images to my queue
- updated my personal site nurijanian. com with a lot of new content and most importantly 4 different styles that randomly rotate
- made lockinfocus. app for focusing before a deep work session using Andrew Huberman's insights
- made a better tab manager for Chrome that helps me sort my tabs by domain and even chat to the tabs with AI and sort them based on my stated goals
- gamified my goals with a personal dashboard that uses Supabase as backend

these apps will never be monetized or even public, but I made them just because I wanted to

now I am working on 2 new actual products:

- a car rental vertical SaaS that capitalises on my yield optimisation background
- an onboarding software that explores what an AI-first/mobile+web synced onboarding tool would look like

the sky is the limit

You're the most productive PM I ever met... and you're too busy copy-pasting between ChatGPT sessions to notice you rebuilt the same context many times over                    
                                                                                                                                                                                          
Most PM work is this loop: refine a process, explain it to ChatGPT, explain it again to Claude, explain it to your team, explain it again because you forgot the details. Same explanation, reconstructed from memory every time.                                                                                                                                      
                                                                                                                                                                                          
The issue isn't individual skills or Custom GPTs. Those are single-shot tools. The unlock is chained workflows where each step feeds the next automatically.                            
                                                                                                                                                                                          
Example ↓

everyone working with AI coding tools should watch this (41 mins)                                                                                                                       
                                                                                                                                                                                          
Geoffrey Huntley and Dexter Horthy break down the real architecture behind Ralph Wiggum loops - why the official plugin isn't it, and how to actually build AI coding workflows that work
                                                                                                              
I distilled the key techniques, but you need to watch them debug this live:

https://lnkd.in/eU3zeFH4

how AI has changed PM work, from an old-school PM on Reddit

less labor now, more speed

glad pre-AI PMs are embracing this so well, not enough cases like this

prodmgmt. world now supports .md files you can use with AI agents

grab the prompts, load them into Claude Code as skills
now you have an army of product managers doing your bidding

some of my favorite use cases:

- impact sizing the specs you're developing with AI
- researching users (assumptions, interviewing, analysis)
- product thinking (via Negativa aka inversion is my favorite)

collecting my favorite resources that I personally use with Claude Code as a PM

+ the guides I've written and the people who post about Claude Code on X

Bookmark it -- updating it daily!

🤾 prodmgmt.world/claude-code

🎯Anthony Murphy

Product Coach, Writer & Speaker | I help product people, leaders and companies do product better | Occasional Cat Herder 🐈

Highlights...
- Founded 4x businesses. Still running 2x of them
- International keynote speaker
- Startup Advisor
- ProdPad Approved Partner
- Medium top writer and recognised in the top 0.1% of writers globally for engagement
- Youtube (https://youtube.com/@productpathways)
- Newsletter (https://www.antmurphy.me/newsletter)

-----

WHO I WORK WITH
Product Managers, Product Leaders and founders. 
As well as companies wanting to be more product centric.

*FYI I'm industry agnostic. I've worked across Fintech, Health, AI, 3D Graphics, Crypto, Government, Media, Insurance and even Agriculture!


HOW I CAN HELP
For Individuals:
🔸FREE: Newsletter (https://www.antmurphy.me/newsletter) and Template Library (https://www.productpathways.com/resources)
🔸Self-paced courses: https://www.productpathways.com/courses
🔸Mentorship and 1-on-1 Coaching (https://www.productpathways.com/mentorship)

For Companies:
🔹Consulting and Advisory
🔹Private Workshops and Training
Get in touch here or email coaching@antmurphy.me

Product Coach

I help Product Managers, Product Leaders, teams and organisations do product better.

Get in touch if you're:
- Wanting help to become more product-led
- Want an outside review/assessment on your current product capabilities
- Looking for internal coaching/training for your product teams
- Need help to scale through building repeatable product processes, instilling best practices, assisting with hiring and growing their product teams

Don't break down big initiatives, break down the outcome first!

This is a big mindset shift for some product teams, but once you've mastered it you won't approach product development the same. 

Rather than breaking down large ideas/initiatives into small increments.

Start by breaking down the outcome first.

Break it down small enough for the team to influence and then define the work to fit the outcome, not the other way around.

For example;
Go from something big like "increase revenue" 
→ Down to something small like "reduce TTV (time to value) from 3 minutes to <1 minute from sign up"

This is how you focus a product team and create leverage.

The hypothesis would be something like this;

"if we can improve TTV then we'll have an increase in active users. We know that 80% of active trial users convert to paid in 14 days. Therefore if we get more active users, we increase trial-to-paid conversions... thus increasing revenue"

You can see how this is a very different way of thinking and approaching things vs coming up with this grand redesign and next-new-big-thing to win more customers.

To me, this is how you 'think big, work small'

👉 Recording of a talk I did on the topic: https://lnkd.in/gTGi5Yux
👉 Part 1 & 2 newsletter posts I did on the topic: https://lnkd.in/gFPa_cMw and https://lnkd.in/gP_HrrQ5

Ant Murphy

Product Coach & Founder of Product Pathways - Helping companies shift to the product model and product people improve their influence & impact 🚀

We usually think in additive terms.

Building the next feature, the next 'big bet', or expanding into a new market.

It's always adding more...
Because more is better, right?

There's been a few analysis now showing anywhere between 60-80% of feature are rarely to never used... but it's not just waste.

There's also such thing as 'negative value'

Sometimes more = worse ❌

More complexity = more noise = harder to use...

And you can add the opportunity cost in there. 

Whilst you are working on that next shiny thing, you could have been fixing those widespread issues.

So whilst you're all planning Q1 and 2026 - and probably have a long list of stuff you're planning to add - what will you remove?

When was the last time you removed a feature?
or sunsetted a underperforming product?

It's why I'm a big fan of creating a 'NOT doing' list.

In fact, I've started to compile a library of real product strategies and you'll see in some of them, they have a NOT doing section (you can access the library here: https://lnkd.in/gmFQE5Sq)

Because strategy is as much about choosing what you're not doing, as what you are.

Otherwise you'll end up with a product that's a bit like these tv remotes 🙃
Or maybe you'll throw AI at the remote to solve it... either way, good luck!

Here’s why you don’t you see roles like BAs, Scrum Masters, Release Managers, etc in product companies (and why traditional enterprises need them).

First this isn’t supposed to be a throw shade post, it’s for those who haven’t been exposed to this way of working and are thinking “that couldn’t possibly work” 

🔸PM feeds engineering → Product, design, and engineering collaborate to define work together
🔸PM writes all tickets → Engineers write their own tickets
🔸Everything falls on PM’s shoulders → Engineering leaders take the load for delivery
🔸Low trust = high communication overhead → High trust from stakeholders reduces communication burden
🔸Manage numerous dependencies → Dependencies are or eliminated
🔸Competing priorities. Low cohesion → High alignment and fewer conflicting goals
🔸Big bang releases → Deploy, release, and launch are decoupled 
🔸Large 12 month initiatives → Think big but work small
🔸Every decision needs 15 meetings to satisfy everyone → ok with inconsistency to move faster


A couple more, plus I explain each of them further in today’s newsletter 👉 https://lnkd.in/giH8uZdN


One last thought:
A common theme across all of these is ‘cognitive load’.

The more burden and cognitive load you put on a team, the more people you need to manage everything.

So for those leaders (and future leaders) reading this, I leave you with this reflection:

What are you currently doing to reduce cognitive load for your team?


P.s. and please don't interpret this as product companies being perfect in any way. They’re not. You often trade one challenge for another (eg dependecies for the stress of not having a job if the funding round doesn’t close) 

I've seen enough companies to know the ‘grass is never greener’. 


Hope this is helpful for some of you!

Open article: How product companies operate without BAs, Scrum Masters, Release Managers, etc — Ant Murphy by antmurphy.me

How product companies operate without BAs, Scrum Masters, Release Managers, etc — Ant Murphy

5 Predictions for Product Management in 2026:

1. AI Powered product management is fast becoming the norm.

2. Throwing AI at everything will stop. Building AI products has turned out harder than we thought. Most didn't produce a ROI. Companies will be more intentional going forward.

3. Focus on profits over growth. The macro-economics and the increase uncertainty will see companies become more focused on being sustainable.

4. Product roles will continue to blur and companies will experiment more with new roles and team make ups.

5. Product teams will get smaller. We'll see the ratios between product:engineering close - perhaps 1:1 even.


What did I miss? Keen to hear your thoughts! 

===

Full deep dive 👇 
https://lnkd.in/gK4eiate

Open video: How Product Management is Changing in 2026 (backed by data) on youtube.com

How Product Management is Changing in 2026 (backed by data)

Too many companies are stuck in a 'death by quarters' cycle.

Every quarter there's a new OKR. Which makes it impossible for teams to plan ahead as they have no idea what's going to be the OKRs for Q2... in the end, we're all just blindly marching ahead, one quarter at a time.

More often than not, this is because they're only thinking about OKR → Work

The problem with this is OKRs alone don't explain; 
- why this OKR?
- why now?
- what's next? 
- how does this ladder up to something bigger?
- how does this OKR connect to that OKR?
etc...

Ultimately the company struggles with clarity. 
They're unable to plan ahead.
Everything feels like a prioritisation problem; "if only we had a rank list of enterprise initiatives" 

But really what they're missing is strategy. 

As Richard Rumelt frames it in his book 'Good Strategy Bad Strategy':

"Executives who complain about "execution" problems have usually confused strategy with goal setting."

So whilst OKRs exist in the strategy layer, they're not the same.

Without strategy, OKRs are hollow.

And remember, like good products, if tools like OKRs aren't solving a pain-point in your organisation they're destined to fail. They're a solution looking for a problem.

Answering “Where to play?” and “how to win?” isn't a strategy. 
It's wishful thinking.

What most people miss about Roger L Martin’s Playing to Win is they focus only on those 2 questions...

But the full framework is actually 5 questions!

Your “Where to play?” and “how to win?” is only valuable if you can execute on it.

Which means you MUST also identify the Capabilities and Enabling Management Systems you need to make your strategy happen.

Otherwise you just have a wish-list.

Or as Roger L Martin’s put it "a fantasy, not a strategy."

All 5 make a winning strategy👇

“If you can’t identify a set of Capabilities and Management Systems that you currently have, or can reasonably build, to make the Where to Play and How to Win choice come to fruition, it is a fantasy, not a strategy.” - Roger L Martin

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://lnkd.in/gwgzd_Ss

Got so many registrations for this week’s live stream that I hit my plan limit 😬

I think this officially makes it my biggest live stream yet!

Poor strategy leads to setting poor outcomes at the top of your OST...
⬇️
Which makes it hard to do product discovery effectively...
⬇️
Which means you don't have quality insights and data to inform your product strategy...
⬇️
Which makes building a quality product strategy hard...
⬇️
And so on...
🔄

You can't A/B test your way to product-market fit with only 10 users...

0→1 product development needs a different approach.

Whilst the textbook is common practice it has to fit your context. 

Until you have scale those types of quantitative techniques (surveys, AB testing and fake door tests) aren't going to work. 

Instead you need to prioritise quality over quantity.

Which means indexing on qualitative techniques like user interviews and observations.

This is why finding a handful of target users who you can co-create with is such an effective approach for startups.

Remember the goal isn't to come up with the ideal product from day 1. 
No one achieves that.

It's to start somewhere, get feedback and iterate.

You could say this was the whole lean startup and MVP approach...
But I like to avoid labels. The principle and reasons why the principle exists are what's important.

=== 

Don't worry. I've made this mistake too 👉

Open article: Product mistakes I won't repeat in 2026 — Ant Murphy by antmurphy.me

Product mistakes I won't repeat in 2026 — Ant Murphy

Kicking 2026 with a bang 💥

Update: we're at 380+ registrations... so close to 400 🤏

5 most common product management mistakes from 100+ coaching sessions and working with dozens of product teams around the world last year👇


1. Neglecting Exploratory Discovery

This was a big one. I saw too many teams focus entirely on what I call exploitative discovery.

In a nutshell, product discovery has two modes:
- Exploring
- Exploiting

Most teams I worked with in 2025 were great at exploiting, but few spent time exploring.

In other words, they were really good at optimising what they already have/know: e.g. Improve the onboarding flow better, improve churn, come up with a solution for X, etc.

But I saw few teams also invest in exploring what's possible. 


2. Not Going Deep Enough

Far too many product managers and trios stopping at the surface level.

They’d jump to a conclusion far too quickly.

You can think of it like going to the doctor with a headache and being given aspirin.

Yes that’s a logical solution to the problem but an experienced product manager would go deeper. They would investigate what caused the headache in the first place and try to solve that.


3. Internal vs External Communication

Products are unique in the sense that they exist both internally as something we develop and externally as something that serves the market.

This means as a product manager you need to manage both:
- Internal communication
- External communication

And both interact with each other to make it harder!

It's far too easy to be sucked into the internal side because it feels urgent and like the “worlds on fire”.

But the problem with neglecting the (right) market side is inevitably the two will drift and become disconnected. And how the product is being communicated to the market vs what it actually does becomes misaligned.


4. Starting with Disagreement

It's far easier to influence someone if you start at a point of agreement and work toward disagreement, than the other way around.

Yet far too often I see product managers go to pitch something but they start at a point of disagreement.


5. Treating 0-1 Discovery the same as Mature Products

Popular discovery methods like surveys, 404 tests, AB testing, etc don't work for 0→1.

And that's because in 0→1:
- You don’t have users yet, so there’s little to no analytics
- You don’t have the scale needed for surveys or feedback forms to be meaningful
- And you don’t have the numbers required for statistical significance experiments like AB testing

Instead of chasing scale and quantity, you need to prioritise depth.

That usually means leaning more on qualitative techniques like:
- Observing users
- User testing
- User interviews


BONUS I've also included MY 5 biggest mistakes too👇

What Product Managers should double down on, drop and learn in 2026. Based on actual data. 📣 Quick announcement: First live stream of 2026 is this we

Open article: Product mistakes I won't repeat in 2026 by Ant Murphy • 14 min read

"Here's a stat that might blow your mind;

The number of independent agents in the US has grown from 45,000 in the late 90s to more than 105,000 in early 2020, before the pandemic — that's more than a 230% increase! (reference '​The Jolt Effect​').

"Revenues were also up significantly, with nearly one-third of all trips booked via travel agents." - The Jolt Effect

In fact, ​predictions​ are that in person travel agents will see their market share grow (yes you read that correctly — GROW!) by 5% before 2026, over taking online travel agents (OTAs) which will respectively see their market share shrink by 1%.

I know what you're thinking, surely that can't be true!

But here's the thing.

Assuming that the internet would replace travel agents is a very transactional way of thinking about the problem space.

Yes the internet has surely disrupted the industry and has had a profound impact to our lives (which I believe AI will too) but just as many assumed it would replace travel agents (and other industries) when that hasn't been the case.

Great products aren't the result of this line of thinking. 

Instead, they're the result of going deeper.

Getting past the functional level and down to the real user emotions.

Yes the internet provided a better alternative for the functional elements of travel agents (i.e. booking flights and accomodation) but it could not replace the ​intangible elements​.

Things like:
- Trust
- Reliability
- Authenticity
- Peace of mind
- Service and care
- Dealing with complexity
- Tailored advice and recommendations
- and of course, time!

Exceptional product people know this. They dig for these motives. 

That's not to say that there isn't a place for a more convenient functional alternative — there is — but great product people wouldn't be under the illusion that it would replace the whole market because they know human behaviour is far more complex."

====

Except from my top post of 2025 👇

Open article: Great Product Managers Go Deeper — Ant Murphy by antmurphy.me

Great Product Managers Go Deeper — Ant Murphy

taplio

The Battle

George Nurijanian

🎯Anthony Murphy

Followers

Posts

Engagements

Likes

Performance ScoreGeorge Nurijanian's LinkedIn Performance

Performance Score🎯Anthony Murphy's LinkedIn Performance

Ready to grow your LinkedIn presence?

taplio

The Battle

George Nurijanian

🎯Anthony Murphy

Followers

Posts

Engagements

Likes

Performance Score.css-goub6s{font-size:var(--chakra-fontSizes-md);font-weight:500;color:var(--chakra-colors-gray-600);display:block;margin-top:var(--chakra-space-1);}George Nurijanian's LinkedIn Performance

Performance Score🎯Anthony Murphy's LinkedIn Performance

Ready to grow your LinkedIn presence?

Performance ScoreGeorge Nurijanian's LinkedIn Performance