Ant Murphy

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.

@ParvSondhi Write for myself (well technically target audience) always. Algo with change and you’ll alway be chasing it.

Do you write for the algorithm or do you write for yourself?

Observation: the AI era is better suited to people good at context switching. I've noticed this myself. I'm bouncing between different agents, multiple tasks in parallel... One finishes, I check it, kick off the next step, and jump to another. For example, I was in Pencil yesterday, a new AI design tool that lets you run 6 agents designing in parallel. Which meant I had 6 design threads happening at once. Plus I also had 2 Claude Code terminals running too... (no surprise; I hit my limits - a good way to be forced to stop lol) But I could physically feel the context switching and cognitive overload. And it's not just me. I've had this conversation with a few people now. I know some of it is my fault. But it's a subtle shift I don't think is getting enough attention. It also means we need to learn to get good at finding the balance. Where's that right level between too many parallel threads vs doing everything one at a time. It's a problem to solve. I worry in the interim the gap will widen between those who have the skills to manage this vs those still acquiring them. Anyways, weekend musing. Keen to hear your thoughts on it. Just me? === p.s. I'm considering running AI PM build day. It'll be in person (Sydney) and 100% hands on. The intent is for you to walk away with your own PM OS set up in Claude Code or CoWork. No slides or lectures. You'll go from 0 to PM OS in a day. If you're interested. Join the waitlist here 👉docs.google.com/forms/d/e/1FAI…

Give this a try and I bet it'll improve your influence (not clickbait, it truly did for me) 👉Reframe everything as questions👈 It might sound silly but there’s real science behind it. Researchers have studied what they call the Question-Behaviour Effect. Which shows that simply asking someone a question about a behaviour changes their subsequent behaviour more than telling them to. Asking > telling. As Daniel Kahneman's, author of Thinking Fast and Slow found, when you make a declarative statement that challenges someone, it triggers what he calls System 1; the fast, automatic, defensive response. But when you ask a question, you force System 2 engagement. The person has to actually think rather than react. Questions are kinda like a backdoor past our brain's defence system. When you tell someone they're wrong, their brain treats it as a threat. But when you ask a genuine question that leads them to spot a gap in their own logic they feel like they discovered it. This is the same idea as a common coaching technique known as socratic questioning - which is where I originally learned this strategy. The reason why this works is because it’s their idea. Their own conclusion. Or at least that's how they feel - you might have led them to it. This is why I always try to reframe things as questions as much as possible. Understanding this has been one of the single best influencing hacks I've learned. === My challenge to you is to build this muscle. The next time your in a meeting or having a conversation with a stakeholder, try to reframe any counter argument, challenge or anything that might trigger dissonance as a question - like; "Help me understand the logic behind..." "How would we handle the scenario where [X] happens?" What would need to be true for this to work?" "Tell me more about how you got to this conclusion." "What problem are you trying to solve?" As Rory Sutherland would frame; "Do you want to win arguments or solve problems?" Which means don’t try to be the smartest person in the room. Instead be the person who helps the room find the smartest answer. More in this today's newsletter 👉 antmurphy.me/newsletter/thi…

Insights have a used by date.

Ps if you want a simple way to run product discovery I share it in this video: youtu.be/0UpQS_bU2dk

A lot of teams have dressed detailed design up as “discovery” Here’s my quick litmus test: If you’re not stopping things as a result of discovery - you’re not discovering. Discovery is what the name suggests. Which means you’re stopping, pivoting and uncovering alternative ways to solve a given problem - you might even be discovering if that problem is worth solving. As a result the output of discovery isn’t detailed designs or specs. It’s a decision. A decision to; - proceed to building something small - try the next experiment - pivot - or bin it If you’re not doing these as a result. You’re not discovering. More than likely, the idea was already committed to. You’re just doing detailed design. That’s not discovery.

The output of discovery is a decision

Communicating Discovery Work

I've got a loom library of nearly 100 resume reviews for product managers around the world and if you watched them all, I basically say the same 3 things over and over again. So I made a video 👉 youtube.com/watch?v=VRk3lF… Now I can save 20 minutes and send them this instead 😅 Kidding! Sharing in case some of you find it helpful.

Discovery is about stopping bad ideas.

I blame spotlight for why I have zero file organisation and my desktop is a mess 😂

@_maxantonov The worst! Although maybe not too bad, it’s made me to go outside and touch some grass 😂 …maybe it’s a feature not a bug?

The day has arrived for the first time. Glad I'm running both Codex and Claude Code at the same time...super additive...so many ideas.

@ParvSondhi 🙌 legend haha

@ant_murphy Closest I can get you

My feed right now - I built this app - my agent built this app - my agents built these agents - launched a company that lets you talk to your agents - touch grass - designers are cooked - taste is key - my agents made a million dollars - how to automate TikTok - how to use claude - I built this app - my agent built this app - launched a company that lets you talk to your agents - my agents made a million dollars . . . . .

Most organisations do not pursue outcomes, they pursue certainty - or more specifically "the illusion of" Unfortunately uncertainty is one of the biggest causes of psychological stress... which sucks when you work in a space that has high uncertainty! Incentives makes this worse where leaders become fearful of losing their bonus, jobs or promotion. For those stuck here - here's two psychology based tactics for navigating this: 1. make it small: Ask to time box the exploration to 1-2 weeks. Will they say yes to a small bit of time before you come up with that plan? If it's small enough, the risk is low, they will likely say yes. 2. give choices: Offer the choice between a detailed plan of stuff you already have certainty over (which is not solving the biggest problem) which means we need to change the goal for the quarter or to keep the goal but have a less certain plan. Choices makes them feel in control and you shift the conversation back up to the right level of, 'what you're really asking is that we change the goal to something certain' - they then need to trade the goals off against each other. I have more tactics here: 📌 'How to deal with stakeholders coming with solutions not problems': antmurphy.me/newsletter/dea… 📌 'Nothing improved my influence more than this one concept': youtube.com/watch?v=4pKFA5… 📌 'How to Influence Stakeholders to buy-in to Product Discovery when it's not valued?': youtube.com/watch?v=9N4Xnl…

With so many Product Managers being treated as Delivery Managers a common questions I get is "who should own delivery on a product team?" Of course the answer is contextual but one of the biggest differences I see is how engineering is viewed. In the Product Manager = Delivery Manager world: Engineers are often viewed as order takers. ↳ The PM specs what to build. ↳ They build what's written down. Nothing more. ↳ (in some cases, even if it's wrong) However, in product companies engineering are co-owners of the product. They have a tonne of responsibility. They're responsible for feasibility. For technical quality. Making sure the architecture and solution design supports what customers want (desirability) and what works for the business (viability). And outcomes too! This means engineer largely owns delivery. But they don't do it alone. Here's a few questions; → Who gives estimates in your organisation? → Who communicates delivery timelines and progress? → Who manages dependencies? It is the Product Manager or Engineering? Both? Someone else? Now ask yourself; → Who should it be? → Who knows this stuff the best? → Who's the closest to the work? If you asked me for an estimate the first thing I'm doing is asking my tech lead 🙃 To be clear. 1. This does NOT mean Product Manager's hand delivery off to engineering. It's still a shared ownership. You need to be involved and understand delivery, especially to help with tradeoffs but your primary focus should be discovery and strategy. 2. Delivery is still a collective ownership but with an emphasis on engineering. I like to use the "Drive + Navigator" framing (post in the comments). Engineering is in the driver seat but design and product are still navigating! 3. This requires a) competency in the engineering team to do this, and b) the expectation that this is part of the role. 4. Note: I haven't covered how this changes when you do have dedicated 'Delivery Management' roles like Technical Program Managers or Delivery Managers. ...there a lot more on this topic but I'll leave it there. Keen to hear your experiences. Happy for you to disagree too.

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! 👉 productpathways.com/course/product…

What influence actually looks like

I spent the majority of my career with no idea what product strategy was. I thought what I was doing was strategy but if I was honest it was strategy theatre. So what is product strategy actually? I like Roger L Martin's framing: “an integrated set of choices...” But 'choices' can still feel ambiguous. So here's an attempt at making strategy more tangible: 1. A good strategy creates focus. Which means you should say NO more than you say YES. “every time you say yes, you sabotage a good strategy” 2. A strategy should eliminate work. 3. It should explain the WHY, WHAT, WHO and HOW 4. Good product strategies are detailed, they explain the rationale behind each decision. e.g. Tesla didn’t want to be a sports car company, they built the Roadster first because they knew their first car would be expensive no matter what, so why not build something you can charge a premium on and use the profits to fund R&D to lower costs. 5. Strategy has a theory (or as I like to call, a narrative) that sit behind your choices. e.g. we believe that the focus on sustainable alternatives will continue to grow by x% year-on-year, therefore we are…. [narrative + data + choice]. 6. A strategy is cohesive. It’s not a list of disparate goals or prioritising work. It’s about cohesive choices based on a set of narratives. Your product strategy must clearly articulate how you intent to over challenges and constraints. e.g. wanting to ‘hire the best people’, without being able to realistically pay top salaries, is just wishful thinking without a way to overcome that constraint. 7. Your product strategy must be backed by data but it also needs to project forwards. You must have a hypothesis about the future. Does your strategy explain the data and beliefs that sit behind your choices? 8. A product strategy isn't a 100 slide powerpoint. It's also not a short ambiguous single slide. There must be enough detail to answer why we have made the choices we did and how we intend to overcome challenges/constraints without becoming a novel. 9. If you can replace your product or company name at the top of your strategy, it's not a strategy. === p.s. to make this even MORE tangible - I've put together a couple of real-world product strategy examples 👉 productpathways.com/strategy There's also templates and extra resources to help you get started with product strategy.

"You Don’t Need Another Prioritization Framework: Just These 4 Components" buff.ly/gqGVeEO @ant_murphy