In all seriousness, despite the talk of doing product “properly” or adopting various product operating models, product management as a practice remains uncertain, poorly defined, and as hard to get right as ever. Even so, there’s plenty to be optimistic about, and I’ll continue to help where I can.

Here’s a catch-up on what I’ve been working on, and a note at the end on how you can help shape where this newsletter goes in 2026.

Working With Me

Here are some of the things I’m doing with teams at the moment, primarily with B2B product organisations where product management is still emerging. My work focuses on helping organisations understand what good product practice looks like in reality, building capability across teams, and advocating for product management as a discipline rather than a role:

• Fractional Product Leadership: Working directly with teams to reboot product management within an organisation, or to set the function up from scratch. Ideal if product management has lost credibility, or you need product leadership now without the commitment of a full-time CPO.

• Organisational Assessments: Understanding how the organisation really works through interviews with key stakeholders, identifying the root causes of the biggest blockers, and proposing a practical action plan to address them. Ideal if you suspect the issues are structural and want to avoid entrenching bad habits as you scale.

• Team Workshops: Working with teams on product fundamentals or deep-diving into specific areas such as storytelling, stakeholder management, and AI. Ideal for teams bored with performative sticky notes and leaders frustrated by generic training that doesn’t translate into changed behaviour.

• Product Leadership coaching: Working 1:1 with product leaders to strengthen their decision-making, influence, and effectiveness within complex organisational contexts. Ideal for new or emerging product leaders balancing the need to be taken seriously at the top table while continuing to support and develop their teams.

Drop me a line if you’d like to discuss working together. I also offer free fireside chats for product teams if you’re looking to provoke better conversations about how product management works in your organisation.

Popular Podcast Episodes

Many of you will have signed up for this newsletter because of the podcast. Hopefully, you’re still listening to them wherever you get your podcasts or watching on YouTube!

In case you missed them, here are some of the most popular episodes from 2025:

• - Product Managers Need to Understand the Language of Money

• - The TRUTH About Large Language Models and Agentic AI

• Martin Eriksson - Most PMs Aren’t Good At Strategy - Enter The Decision Stack!

• - We Should All Prioritise Product Delight!

And, as a treat, here are some of the most popular episodes ever:

• - Transforming your Organisation to the Product Operating Model

• - Survive the Feature Factory by Applying Product Thinking to Product Thinking

• - The Role of Product Management on Truly Agile Development Teams

• - Escaping the Build Trap with Product Operations and Strong CPOs

New Cohort of “Reboot Your Sales Relationship”

I’ve been working with my buddy Saeed Khan for a while now, trying to help B2B product managers make things just a little bit better. We have a new cohort of “Reboot Your Sales Relationship” starting 19th January, 2026, so if you’re struggling to make a dent with your sales team, check it out and sign up.

Free Live Events

I’m continuing to run free live events, primarily in London, to support the local product management community. Here are a couple coming up in January:

• One Knight at the Pub, with special guest - 15th January, 2026

• “Product Delight” UK book launch, starring - co-hosted by me and ProductTank London - 20th January, 2026

You can also find these, and other UK-wide product management events, on my free UK Product Events page.

My Ask For You

This newsletter began as a way to share podcast episodes, evolved into more of a blog, and now sits somewhere between the two. I appreciate you continuing to read it, but I don’t receive much feedback. If you have thoughts - good, bad, or indifferent - I’d welcome them. I remain committed to supporting the product community, so let me know what resonates (just hit reply, or email jason@oneknightinproduct.com), and I’ll do my best to focus more there.

Thanks, and onwards!

Sign up to come along, or get the recording afterwards.

I spend a lot of my time working with companies that are trying to build better product management teams - often organisations that have never had strong product cultures and now consider their product teams to be underperforming. Sometimes, they’re completely right, and sometimes there are external factors, but in any case, the frustration is there.

In these situations, every so often, a company leader will say something like this:

“Our PMs suck. Let’s fire them all and get better ones. We need to raise the bar.”

It’s an understandable urge, borne of frustration, but I believe it’s generally the wrong approach and unlikely to deliver good results.

The Myth of the “Bad Product Manager”

We’ve all read Ben Horowitz’s “Good Product Manager/Bad Manager” and had a good old chuckle at the idea that PMs are the CEO of Product, but there’s actually some pretty good stuff in there. My issue with the good/bad framing is that it oversimplifies the issue. I believe:

• Very few product managers truly “suck” or are “bad”… they can certainly have weak spots in their game, but these are generally learnable.

• Many organisations accumulate poor-fit PMs over time, driven by unclear expectations or an unclear understanding of what product managers do for a living.

• Often, organisations suffer from weak or rotating product leadership and put limited thought into structured career development. The result is undersponsored product teams with no clear measures of success.

• Sometimes, the culture and mindset of an organisation’s leaders explicitly push back against and penalise “good” product management, simply because no one understands what that means, and all they have is lingering frustration that their customer-facing product isn’t very good (and not getting better).

There’s no malice at play here, simply the sum total of a succession of decisions made with the best of intentions over months or years. Leaders become frustrated at the lack of progress, without any real ideas about how to make it better. Eventually, the pressure builds, and they end up with the urge to:

• Fire the product leader (and get a new one, maybe more technical! Or more commercial! An industry expert! Something, something, AI)

• Fire the entire product team and hire some hot shots from somewhere else who’ll do the job properly.

Now, to be fair, I’ve seen the first one more than the second one, but I have seen the second one, and had to work hard to advocate against it.

But why?

Expectations are Fair Enough, But They Have To Be Fair

It’s absolutely fair to hold your team to high standards. No team is perfect, and everyone can improve. On the other hand, it’s very common for there to be no defined standards at all, and “holding the team to high standards” is more or less like trying to read tea leaves.

A common approach here is to codify some standards, to drive performance and let people know what is expected of them. This is an excellent idea that gives clarity to both sides of the relationship. But one thing I’ve seen is that leaders try to set a new standard, then immediately try to fire people who don’t meet it, without ever giving them a chance to step up. In my opinion, this is clearly unfair. You can’t fire someone for not meeting a quality bar that you never set.

How To Set The Standard Properly

In my opinion, there’s a good and an evil way to do this. Let’s focus on the good way:

• Set the new standards

If clear standards haven’t existed historically, it’s often worth bringing in external perspectives to help shape what “good” looks like going forward, rather than falling into a different version of the same trap. Personally, I prefer to defer to the experts on these matters. Two frameworks that I’ve seen and used are Petra Wille’s “PMWheel” framework and ’s “PM Competency Toolkit”. The benefit of using these is that they have been created and tested by credible, experienced product people who have put a lot of deep thought into these topics. Leverage that thinking, adapt it if needed, but don’t just build one from scratch.

• Measure the team against them

Both of these frameworks include assessment tools, which you can use to get the ground truth scores for your team. You can either run these as self-assessments, manager assessments, or ideally, some combination of the two. Feel free to combine 360 feedback from colleagues, but bear in mind that many colleagues may not have a strong idea of what good product management looks like.

• Come up with an improvement plan

If there are areas where an individual, or even the whole team, comes up short, then it’s time to set up some form of improvement plan. This could involve individual mentoring or coaching, group training workshops, or even hiring different product people to model exemplar behaviours to the rest of the team. Ultimately, whilst it’s entirely fair to expect people to be self-starters and improve themselves to some extent, you need to be a stakeholder in their success.

• Measure the improvement on an appropriate timescale

Now, as mentioned before, it’s both OK and fundamentally desirable to have a high-performing product management team, whatever that means in your context. Just because you shouldn’t take the nuclear option immediately doesn’t mean you don’t have to take action at some point. The key point here is around timescale; is this a hair-on-fire problem, or can you take a more measured approach? Whether your “timescale” is 3 months, 6 months or 5 years is up to you.

Personally, I recommend at least three months as a good starting point… You should be able to see directional improvement in that timescale and either adapt the plan or double down (but be careful of performative “I’ve made progress!” optics over real progress).

• Keep the people who meet the standards/move people on who don’t

Obviously, if your improvement plans are paying off, then it’s all good; you can just keep improving people. I’d recommend periodically reviewing your standards and ensuring that they remain fit for purpose. This is the good news scenario.

The bad news scenario is when someone either won’t or can’t meet the new standards you’ve set. Maybe they’re a poor fit for the company, or the company is a poor fit for them. Maybe what the company needs has changed, and they’re not up for the new reality. I’ve seen well-intentioned and passionate product people who have suffered their way through mismanagement after mismanagement, and have no motivation left to improve. I’ve also seen product managers who are simply not suited to the type of company they are in.

These are all sad stories, and we have to remember that there are people behind every one of them. Luckily, most business leaders do not take these decisions lightly. But, whatever happens with regard to those who don’t make it, you simply must ensure that they’re treated with respect and given the support they need.

Performance management is tough, and these conversations are hard. Sometimes it feels like the easiest thing is just to flip the table and start again. I genuinely can’t imagine a worse way to do it, given the disruption it’ll cause to work-in-progress, and the message it leaves to the colleagues that are left behind. Treat your people fairly, assess them reasonably, and give them a chance to sharpen their game where it’s needed. And remember, even great product people can fail in a broken system.

If the issues in this article sound familiar and you’d like help with your product management team, book a free advisory call with me, and we’ll explore what’s really going on… and how to move it forward.

We ran this survey to get to grips with what is really going on in B2B Product Management, and investigate ways we could help. We’re still analysing the data, but Saeed has written a great post about some of the key findings so far. You should read it: Initial Findings from the 2025 State of B2B Product Management Survey.

I’m not going to reproduce the whole article here. Still, I wanted to write some quick thoughts about one of the most interesting findings from the data so far: The massive disconnect between how B2B Product Leaders feel they’re doing and how B2B Individual Contributor Product Managers feel their leaders are doing.

We asked the question in two ways, depending on the respondent’s role. We asked leaders to rate how much they agree they do these things, and ICs to rate how much they agree that their leaders do these things:

1. Sets a clear vision and product strategy aligned with company goals

2. Aligns teams around shared goals and priorities

3. Enables effective prioritisation across teams and product areas

4. Fosters ownership, decision-making, and a customer-centric culture

5. Removes cross-functional blockers and advocates for the product org

6. Invests in people through mentorship, feedback, and career development

Saeed’s article goes into the data in more detail, but this meme sums up the key themes across all of the categories we tested:

TL;DR - Across the board, B2B Product Leaders think they’re doing pretty well in all of these areas, but B2B IC PMs are not convinced. The difference is stark, and they can’t both be right.

So What Gives?

From my personal perspective, there are three possible explanations:

1. B2B Product Leaders are doing a bad job, and they don’t know it

Product leadership is hard, and many of us have worked for companies as far from “product-led” as possible. There are sales-driven feature factories abound, companies are installing “industry expert” strategy people to lead product teams because they over-value subject-matter expertise, and maybe these people aren’t doing the job very well. Obviously, all leaders are constrained by their context, but it is very curious that, even if they’re not doing it very well, they still think they are.

2. B2B Product Leaders are doing a GOOD job, but they aren’t demonstrating it to their team

If a tree falls in the forest and there’s no one around, does it really make a sound? B2B Product Leaders may well be doing the best job possible within their circumstances. Maybe they’re advocating for their product management team, pushing as hard as possible for product strategy and evidence-led decision making. Still, somehow they’re not showing their teams the results. Now, I might argue that communication and storytelling are essential parts of a product leader’s repertoire, but is it a messaging problem?

3. B2B IC Product Managers have unreasonable expectations, or don’t know what a good job looks like

Product leadership isn’t just “Product Management But More”, but a fundamentally different job from building products. You’re not building products anymore, you’re building product teams, product cultures and product portfolios. Even in good companies with good leaders, there’s often an “iceberg effect” where only some of the work someone does is visible, and you assume that they’re not doing anything else of any merit. Maybe B2B Product Leaders are doing the best they can in the context they’re in!

In reality, so far at least, we don’t have the data to really dig into the underlying, fundamental drivers of this disconnect. I do, however, find it fascinating and am curious to investigate more. My immediate general feelings are:

• Product Leaders need to do a much better job of setting expectations within their teams and communicating with them openly and well.

• IC Product Managers need to do a much better job of understanding the constraints of their business context and, indeed, the business they work for.

I’d be curious to hear your take!

We’ll be doing much more analysis of the data in due course and will shortly be releasing a free PDF report. If you would like to check the results so far, or sign up to get the report emailed to you when you’re done, do remember to check out Initial Findings from the 2025 State of B2B Product Management Survey, or just put your email address in here.

In the meantime, do feel free to reach out if you have any questions about how to improve Product Management in your organisation. I offer free fireside chats for teams, as well as paid workshops, coaching, assessments and fractional leadership. Hit me up for a call if you need me.

As part of my job, I speak to a lot of product people as well as startup and scale-up leaders. Now, if you follow a certain set of accounts on social media, you may think that everyone’s still really excited by “AI” and that LLMs are one release away from becoming sentient and automating everything. But, in my experience, a lot of people are simply tired of AI.

Now, don’t get me wrong, I’m not saying they’re tired of doing useful things with AI, or think that it’s useless, but they’re tired of the constant, endless stream of “This Changes Everything… Again!” LinkedIn posts, unverifiable claims of magic from the machines, and a sneaking suspicion that they’re using entirely different LLMs than the people writing these articles.

Yet, on the other hand, business leaders and boards are still obsessed with the question “So... what’s our AI strategy?”

That one question has sent many a product team on a six-month death march to build useless “AI” features that add limited to no value to users. Rather than fixing core issues with their products, they’re adding chatbots that probably make it harder for users to do whatever it was they wanted. Company after company is being pressured to “just plug in an LLM”, put “AI-powered” or “Co-pilot” on the web page and call it innovation. And then wonder why it’s not working when everyone’s doing the same thing.

This is the AI Hype Hangover. It’s forcing good, well-meaning product managers to make bad product decisions, and we need to cut through the noise.

The “Should We Invest In That AI Initiative?” Matrix

When the next “something, something, something… AI” initiative lands on your desk, don’t jump straight to a shiny solution like an “AI Product Manager”. But equally, remember the urgency from business leaders and boards isn’t just panic - you do need to find a solution.

So, just ask two questions (eagle-eyed spectators will realise that you should ask these questions about anything, because there’s no such thing as AI strategy, just strategy!):

Does this solve a real, painful user problem?

This is the same question product managers have asked, or should have been asking, for their entire careers. Product people’s entire job is to ensure that we’re solving a real problem in a great way that delivers returns for our business.

Can anyone build this, or is it unique to us?

This is the business strategy question. Now, it’s a perfectly fine strategy to copy everyone else if you have some other edge, but to misquote The Incredibles, “If everyone’s super for wrapping an LLM into their product, then no one is”.

Asking these questions lets you plot against a handy quadrant and helps you to sort the vanity from the sanity.

• The “Vanity Feature” / AI-Washing (Low Value, Low Defensibility): This is the “Hype Checkbox.” It’s “Chat with our Mascot.” It’s built for a screenshot, not a user.

• The Gimmick (Low Value, High Defensibility): This is the engineer’s pet project. It’s technically brilliant, and may be integrated with your product’s special sauce, but it doesn’t solve a problem anyone cares about. It’s a “so what?” feature.

• The Commodity (High Value, Low Defensibility): This is the real trap. It’s somewhat useful - think “AI-suggested email replies.” But it’s a commodity. It’s built on a generic API, and your competitor probably launched it last week.

• The Differentiator (High Value, High Defensibility): This is where you solve a painful user problem in a way only you can.

The “Vanity Features” and “Gimmicks” are a tax. They are the price you pay to the Hype Gods to get the board off your back. You should treat them as such: minimise the cost, and don’t for a second mistake them for a strategy.

The “Commodities” are your defence. You build them to stay in the game. You build them because you have to, just to maintain credibility. They are your table stakes.

But the “Differentiators”? Those are your offence. Concentrating here is how you can win.

To be honest, you may need some kind of portfolio approach here, and the percentages will vary from company to company. Maybe half your time goes on table-stakes features, with the rest split between differentiators and a little AI-washing for marketing. Whatever the mix, do it deliberately… and know what you’re building, and keep your users at the heart of your decision-making, not tech for tech’s sake.

Productized is an extremely well-regarded Product Management conference hosted in the wonderful city of Lisbon, Portugal. I was actually supposed to speak at it a couple of years ago, but I got sick and ended up in the hospital instead. Fast forward two years, and I was speaking on stage instead of attending my best friend’s wedding. Life truly has a sense of humour!

I spoke about one of my favourite topics - “Product Management Isn’t Like The Books”, which really boils down to the following:

• There are too many books out there, and too much content in general

It seems like everyone’s writing a book these days! So far, I have resisted the urge, but I don’t get a free pass either because I’m contributing to the content overload through my podcast, newsletter, LinkedIn and everything else I do. There’s too much content, and I remain convinced that more people are writing about things than there are things to write about. I don’t know how people decide what to pay attention to anymore.

• People read these books and get depressed or demotivated because they’re not doing it like that

These books paint halcyon visions of a Better World where, if you just follow these frameworks or copy these companies, then everything will work out for you. You’ll be a Good Product Manager working for a Good Product Company. If you don’t follow all of these principles and do all of these things, you’re a Bad Product Manager working for a Bad Product Company.

• But that’s not really what the authors are trying to say

Most of these authors will be, and have been, quite honest about the fact that all of this stuff is hard. Maybe they got to do the things they wrote about in the books a handful of times, or even only once. But when they saw it work, it really worked, and they thought they’d better write it down and try to get other people to do it. But they had plenty of disappointments, too. On the other hand, a book has to take a position; otherwise, who’s going to buy it?

• Better is better than not better; don’t let the perfect be the enemy of the good

It’s easy to look at the Better World described in these books and lose heart. But there are always things that can be changed. Sometimes, you have to buckle up for the long haul and get comfortable with incremental change. We build products like this, and we can build product cultures like this - by fixing the next most important thing that’s holding you back, demonstrating success, and continuously prioritising for impact. And yes, “Minimum Viable Improvement” was a tongue-in-cheek choice, although I kind of like it.

Now, there is a school of thought that this is too slow, and that it might result in hitting a local maximum, i.e. you’re not going as far as you could go. That might be true, but I’ll take a local maximum over a local minimum any day of the week.

Overall, the conference was an amazing experience, and it was great to meet new friends as well as catch up with old ones. There were some fine talks, and they should all soon be available on Productized’s YouTube Channel.

Here were the other main stage speakers, and what they spoke about. I’ve linked to any podcast interviews that I’ve done with them, so you can go listen while you’re waiting for the videos:

• Radhika Dutt - Creating Change Together
  (Check out our three podcast episodes together!)

• Pippa Topp - Connection and creativity in the age of AI

• - Building products people love, not just use
  (Check out our recent podcast episode on the topic)

• - The Product Shift

• Bruce McCarthy - How to set direction while embracing uncertainty

• Chui Chui Tan - Think global, act local: building products that thrive across cultures
  (Check out our podcast episode)

• - Untrapping product teams: simplify the complexity of digital products
  (Check out our two podcast episodes together)

• - Empowered to succeed: decision-making in product

• (me!) - Product Management Isn’t Like The Books

• - Business cases are stories about money
  (Check out our two podcast episodes together)

• Blagoja Golubovski - Roadmap to revenue: Redesigning product orgs for the AI era

Usual LLM rules apply: It’s just a language model, so double-check anything important, but I’ve had fun playing with it! Give it a try and let me know how you get on.

Ah, to be a product manager! You’re the CEO of Product! You get to make all the big calls. You get to be strategic. You get to “just say no” when people come up to you with silly ideas. You’re the final boss of your product.

That’s a great story, but we all know it’s generally a fiction. We know that companies are complicated, that everyone has an opinion, that you don’t get to “just say no” to your CEO (the actual CEO of Product) and that, very often, a product manager is left implementing someone else’s plan in a system that cares very little about “proper” product management.

The “it depends” product review meeting

This can lead to a behaviour that I’ve observed in many teams that I’ve worked with. Frankly, it’s something I’ve been guilty of myself earlier in my career. Very often, product managers appear afraid or unwilling to make any recommendation at all.

Imagine the scenario. You’re in some kind of product review meeting, which goes something like this:

Product Manager: OK, well, we’ve been looking at our options, and we’ve narrowed them down to 5

CEO: Great! Let’s hear them!

Product Manager: *explains all of the options in excruciating, chronological detail*

CEO: OK, so which one are we doing?

Product Manager: *looks at feet*

CEO: OK, Option C it is!

Later on, the product manager complains that they didn’t want to do option C at all, that they’re a victim of the HIPPO effect, and they’re just working in a feature factory. And so the product management world turns.

Why are product managers afraid of making recommendations?

Although this example is simplified, I’ve seen this exact conversation play out in real life. Here are a few common reasons why it happens:

• Lack of an appropriate mindset

The product manager simply doesn’t think it’s their job to recommend anything. Maybe they’ve been explicitly told it’s not their job. Maybe they’ve still got PTSD from previous roles where they were told it’s not their job.

But it’s not just their mindset but the collective mindset of the entire organisation. If there’s a lack of psychological safety, or everyone’s mired in politics and unclear decision-making authority, it can be hard for anyone to want to stick their neck out.

• Lack of evidence or confidence

In complicated companies, product managers may lack the confidence to make a judgment call simply because they don’t have enough information. Perhaps they don’t have enough direct evidence or lack direct access to customers. Or, on the flip side, there could be a tendency towards analysis paralysis; there’s always that one next piece of evidence to collect.

When it comes to confidence, there could be a lack of desire to make a bet or a need to “gild the lily” on any new initiatives. There could also be an element of imposter syndrome at play, either intrinsic (people feel like imposters themselves) or extrinsic (people have repeatedly been told they’re imposters).

• Current product trauma

While it’s true that product managers can be influenced by their previous roles, they can often be influenced by their current roles. If they’ve been explicitly, publicly shot down every time they put forward a recommendation, they’re going to stop putting forward recommendations. That’s more of a survival strategy than anything else.

In extreme situations, this strategy is justifiable. But it’s important to ask why people are being shot down. Is it a toxic, unreasonable boss who wants everything their way, or is it a long-suffering leader who is tired of half-baked plans and unconvincing rationale?

In any case, the net result is the same: Disempowerment. But it’s hard to argue that you’re being overridden if you never made a recommendation in the first place.

The art of making recommendations

Making a recommendation doesn’t always mean that you always get your way, but not making a recommendation means that you’re giving away your chance to influence decision-making. You need to show up with a point of view. Here are some things to try next time:

• Explore your options

Making a recommendation only makes sense if you can prove that you’ve considered several options. If you want to be taken seriously, you need to explore these options ahead of time and be able to speak to their pros and cons. Just because you think there might be a best option, it doesn’t mean you shouldn’t map out the alternatives.

• Gather your evidence

Evidence is a product manager’s best friend. Ideally, you’ll have direct access to customers, but you should also take signals from as many places as possible: Customer success feedback? Sales feedback? Something from an article the CEO shared on Slack? Take it all!

Weigh things appropriately, of course (I remain fond of Itamar Gilad’s Confidence Meter). If you don’t have decent evidence, how could you get more? And, how big is the bet anyway? Smaller bets don’t need as much evidence, but they still need some.

• Build your coalition

In my recent post about the product management ombudsman, I wrote about finding allies. This is especially important in low-trust environments where product management is not seen as being in the driving seat. Ensuring that you have people from other teams onboard can help you be seen as a good collaborator, as well as help defuse any obvious objections. It’s also a great source of additional evidence.

• Present the options well

You still need to present all the options to leaders. This helps give them confidence that all angles have been covered. It’s a great way to show the evidence you’ve gathered, the pros and cons you’ve considered, and the confidence you can show that this is the way ahead. Ensure that you don’t get bogged down in technicalities and avoid rabbit holes. Keep it simple and to the point.

• Make your recommendation

Your goal with your presentation is to give a fair hearing to a variety of options, show the evidence about why things are or are not a good idea, and close with a strong, rational argument.

Even with the best rationale, your recommendation may get overridden. This is frustrating, but consider why this has happened. Was your evidence lacking? Can you get your leadership team to explain why they leaned that way? Can you get them to share the business context or evidence behind their decisions? Depending on the leader in question, you may need to be careful with your wording, but you’re perfectly within your rights to get more context from them.

Ideally, you end up working on the things you believe are the right things. If you don’t, it’s your job to own the new decision now. No complaining that it’s “the CEO’s stupid initiative” or “we’re only doing this because of Customer X and it’s dumb”. You touch it, you own it. Do your best product management work and try to work out what you need to do to get buy-in next time.

Ultimately, no one else is going to be able to advocate for what you think is right better than you. Yes, you’ll get overridden from time to time. Yes, sometimes that’s exactly what your leadership wants. But I recommend advocating for it anyway. Product managers should do their best to avoid becoming passive bystanders to their own work.

Find out more

The perennial problem: A lack of respect for our craft

I was recently involved in an interesting discussion with a UX professional on LinkedIn. We discussed the problem of non-UX leaders not understanding the benefits of proper UX practices. Although this particular discussion was about UX, I’ve seen similar thoughts and complaints expressed by various product managers over the years, so I’m going to take the opportunity to talk about it in a product management context.

It’s no secret that product people often complain that their leadership team just doesn’t “get it”. We have all these best practices, mindsets, frameworks and a fundamental product management craft. Champions of this craft write books, speak at conferences, sell courses and expensive consultancy services. Their work is evidenced by the fact that the very best companies work like this, and the promise that your company will be more successful if it does the same.

But what do we see instead?

The story for many product managers is somewhat different. Instead of working like the best, they’re sitting squarely with the rest, suffering from:

• A complete ignorance and/or suspicion of these ways of working

• Marginalisation of product management teams

• An intense resistance to change for change’s sake

• A constant demand for proof of return on investment

One of the things that came up in my recent discussion was that, like many true believers, the person is tired of being made to advocate for the way things should be. There was also a general feeling that this is “an industry problem” that needs “industry solutions”, rather than the tireless advocacy of exhausted practitioners. For the record, I am sympathetic to this frustration!

The Industry Problem… Wait, What “Industry”?

Again, it’s an incredibly common problem that many business leaders don’t “get product management”. If it weren’t such a common problem, we wouldn't have so many people (including people like me) trying to fix it. But, when we think about asking for industry solutions, it does beg the question, “Which industry are we talking about?”

Consider the definition of an “industry”:

“The aggregate of manufacturing or technically productive enterprises in a particular field, often named after its principal product, e.g. the automotive industry, the steel industry”

This implies some degree of coherence. But, what coherent industry are we a part of? The SaaS industry? The product management industry? Are we members of an industry at all?

If we’re thinking about a coherent industry, we might ask ourselves, “What are some characteristics of an industry that wants to enforce rules, standards or best practices?”. We might expect an overseeing industry body or regulator that:

• Sets standards (and possibly certification requirements)

• Has some form of escalation process or an ombudsman to handle complaints

• Enforces penalties on industry organisations that don’t adhere to these standards

Ombudsman (n) - a person who investigates and attempts to resolve complaints and problems, as between employees and an employer or between students and a university.

But what do we have in the context of product management? We have a vast array of very different companies that have evolved to their current state through a combination of:

• The background and biases of their founders

• The commercial and competitive pressures of their markets

• The average of all the working practices of every person they’ve hired

A lucky product manager works for a company where companies work more or less like the “industry” best practices. Of course, many product managers are in a very different situation, where product management is ill-understood by an organisation populated by people who’ve never worked with a well-functioning, empowered product team, and have no implicit grasp of why that would be better than how they work today.

Remember, most companies aren’t designed… they just happen. There’s no industry ombudsman to complain to, and no one is coming to save us, because we’re not all part of the same industry.

So, what do we do?

So, if no industry ombudsman is coming to save you, you have a couple of options. You can give up or try to be an agent of change. But, remember, you’re not going to change an industry, because there isn’t one. However, you can change one company at a time, or give it your best shot at least.

Now, sometimes, external pressure can increase the urgency of change. For example, if the company is not performing well, the board can exert pressure from above to shake things up. Where board members are product-savvy, they may pressure the CEO to implement sweeping changes as their patience runs out. That said, many boards often approach these problems solely from a financial perspective, so you can’t always rely on that to help you change how you work. You should take advantage of that situation if it arises, though.

Otherwise, here are some ways to try to make a case:

Get off your ideological high horse

I’ve fallen into this trap before, trying to persuade non-product leaders of the awesome power of product thinking, almost entirely justified by the fact that… well, it’s product thinking. But that just sounds like I’m reading books at them.

There’s also a vocabulary problem here. We can advocate for experiments, hypothesis-based development, MVPs, outcomes over outputs and all the rest. But these words are our words and might as well be Klingon to a non-product audience.

It doesn’t mean you shouldn’t advocate for those things, but try to find a common vocabulary that resonates with your audience.

Get agreement on the problem before pushing for a solution

The worst way to advocate for change is to propose that the company invest time and money in solving a problem that no one believes the company has.

We product people certainly believe that good product management practices will deliver superior results, and there are probably many changes you want to make to get closer to those practices.

But it’s important to map these changes back to solutions to problems your leadership already cares about. You can’t agree on solutions if you can’t even agree on the problem you’re solving. Leaders care about problems like “our churn is too high” or “our sales are stagnating” rather than “our product team isn’t doing enough discovery”.

Of course, we believe that doing more discovery will help with those business problems, but we need to frame it in that way explicitly.

Don’t be scared of trying to prove ROI

It’s not just about mapping your efforts to problems that the leadership cares about, but also having ways to prove that your ways of working are worth investing in. This is something that many product people shy away from and, in many cases, struggle to articulate.

It’s especially problematic for internal-facing products, or anything stuck behind a sales team that will often take full credit for product revenue (the only One Metric That Matters for most companies).

That said, product teams are expensive! Product teams should make an impact! If you can’t at least give a qualitative description of how good product practices will benefit the company, what do you expect a business leader to say in return?

Find trusted, cross-functional allies

In many companies, it feels like the product management team is well down the pecking order. In some companies, it feels like their opinion isn’t respected at all. In cases like these, it’s important to find allies within the organisation to bolster your own advocacy.

In most product companies, there will be people from other teams, like Sales, Marketing or Customer Success, who have worked in other, better-functioning organisations. These people can be valuable allies to help you make your case to a sceptical leadership team who are tired of hearing all this “book talk”.

It doesn’t mean you’re guaranteed to get your way, but don’t underestimate the power of a united front in selling the message.

Be prepared to lose the battle to win the war

Rome was famously not built in a day. I’m sure that if you wrote down all the ways your company could be “better at product”, there’s a big list of improvements you want to make.

It’s tempting to try to think that you have to stand your ground on all of these at the same time, because that’s what the books say, and how can you possibly be a “proper” product team if you don’t do all these things?

But change is a process, and you don’t have to fix everything at once. Sometimes you have to be prepared to give up ground in one area to ensure that you don’t burn all your credibility in one go. You still want to get invited to meetings and be seen as a trusted partner, rather than an inflexible fundamentalist.

This doesn’t mean you have to give up; simply be savvy and choose the right time to go all-in.

Bonus Tip: Get External Help

Now, of course, this is the sort of thing a consultant like me would say (and I’d be delighted to chat!). That said, getting an external perspective from a qualified someone with a wider perspective, whoever it may be, is an excellent way to build support for change.

This can be a consultant who conducts an assessment of your organisation’s strengths and weaknesses, or a coach who can help you make a case and deliver the right kinds of changes. Even if they end up saying the same things that you were already saying, take the win. The most important thing, after all, is that the changes happen.

Now, to be clear, there are companies out there willing to change, and there are companies out there that will resist all changes tooth and nail. And, actually implementing changes can be fraught with difficulties (I talked about ways to approach this in this article recently).

Not all companies will want to work the way you want to work. An important consideration is whether there is any appetite to change at all, and whether any of the things you can’t change are showstoppers for you and are preventing you from doing the job you want to do.

Does this post resonate with you? Do you disagree? What have you tried in the past? Feel free to hit me up in the comments!

Book a call

I’ve observed something a few times while helping companies up their product management game. It’s a common behavioural pattern that leaves product managers scrabbling to please their CEO, while ironically leaving the CEO complaining that the product team aren’t delivering on their goals. In a transparent attempt to try to make me look clever, I’m going to give it a Latin name: Conditor ex Cathedra.

Wait, what?

“Ex Cathedra” is a Latin term from the Catholic Church. I’m not an expert on Catholic dogma, despite having been baptised a few hours after my birth due to a life-threatening birth defect (“Here’s 10 things choanal atresia taught me about B2B SaaS!”). That said, I know enough to know that, in the Catholic Church, the Pope speaks with ultimate authority on matters of faith and morals. Whatever the Pope says goes.

But, wait, surely that’s not right, because the Pope says lots of things, and what if he (it’s almost always a he) is just thinking aloud? Well, luckily, the Catholic rulebook has this covered, and it’s indeed true that the Pope does not always speak with ultimate authority on matters of faith and morals, only when speaking ex cathedra (literally “from the chair”). To put it another way, the Pope’s word is only law if proclaimed officially. Otherwise, it’s just chit chat, and people can ignore it if they want, or maybe even disagree with it.

Ok, enough dogma, what does this have to do with product management?

Come on, you can probably guess…

Indulge me…

Ok, so I’ve seen variations of this in meetings more than once (Note: I’m using “CEO” here, but it could also be any other founder or business leader):

Product Manager: “We’re on track to deliver on our Q1 plan, and here’s our latest update on our metrics”

Distracted-looking CEO: “Great, great, looks good. Hey, I’ve been thinking - I was chatting to Big Client X the other day and they said they are experimenting with AI/blockchain/<insert cool tech here>. Have we looked into getting that in the product recently?”

Product Manager: “Well, we’ve not been focusing on it recently because of Reasons X, Y and Z, but we can definitely take a look into it”

CEO: “Great! See you next update”

What happens next? The product manager goes back in a panic to their team, and things start moving fast.

The roadmap gets reshuffled, and two engineers start working on a spike. If the team are lucky enough to have direct access to customers, they start grilling them on how they could use this new tech. If not, they start ploughing through feedback from the sales and CS teams to see if they can build a case. The things they were working on start to slip, because this new thing is way more important now. It must be… the CEO said so!

Except… the CEO was just spitballing. They weren’t asking you to work on that thing at all, at least not just because they said so. CEOs are always having interesting discussions with customers, industry people and other CEOs. They’re passionate about this stuff! They love getting involved, but this was just a chat for them. Or, in some cases, they just love to be provocative to keep people on their toes or check that they’ve thought about stuff (this can sometimes manifest itself in quite unpleasant ways, so keep your eyes open if it’s the general modus operandi).

Predictably, come the next product review, the first question the team are going to get from the CEO is “Why haven’t we met the goals we were aiming for? What the hell is going on with the team!?”

Is the CEO Speaking from their Chair?

The most important thing to do as a product manager in this situation is… nothing, well not to start with anyway. When dealing with senior stakeholders, it can be incredibly tempting to try to react in the moment, floundering your way through a stuttered speech to try to look like you’ve got everything covered. I’m going to say that this probably works 0% of the time and that, if you don’t have an answer, you’re better off saying, “That sounds interesting! Let me get back to you after we’ve discussed it as a team”.

But, that doesn’t mean you have to derail everything for something the CEO might have forgotten they mentioned by the next time they see you. The best next step is to leave it for a few days and sit on your hands. Then, raise it with the CEO - or your boss if you don’t have easy access - and ask the key question: Is this actually more important than what we’ve already committed to? Very often, the answer will be “no!”

If it’s a yes, then try to get some context from them… why is this important now? We agreed this other stuff was more important before, so are there any factors that we’re not considering, or any evidence that we haven’t taken into account? There’s no point being confrontational or abrupt, but it is always worth asking the questions.

The conversation can go several ways, but it’s likely to end up somewhere on this scale:

• Oh, that? Let’s not worry about it, I was just thinking aloud.

• Actually, can we look at it in Q3? It’s not urgent, thanks for checking!

• Is there any way we can fit this in and get at least some kind of MVP going?

• Look, I told you to drop everything and do it! Why isn’t it done yet?

• We’ve already committed this to a customer or the board, and they think we’ve already done it.

Of course, you know your CEO better than I do, so adapt your response to their personalities, and try to remember what happened last time you pushed back. Some CEOs very much lead by decree.

Will we always win the argument?

Well, it’s not really about winning an argument. Your job as a product manager is to help your organisation make the very best decisions for the business and its customers, based on evidence, and to ruthlessly prioritise for impact. But it’s not your business, and sometimes you have to lose the battle to win the war.

To Product Managers (and Product Leaders): Do your best to cool down any in-the-moment, ad hoc ruminations, go back and discuss them a few days later with a clear head, and try to get as much context as possible. If you do have to change your plans, own it and don’t start complaining about the boss or calling it their initiative. It’s your initiative now.

To CEOs (and other founders): Try to be aware of the effect your words have on your employees, and the status you often have in their eyes. You may not be biblical in stature, but your words hold weight, and you need to make sure it’s clear when you’re making a proclamation versus just trying to get involved in the cut and thrust.

PS - Semper Ex Cathedra Conditor Est? = “Is the founder is always from the chair?” or “Is the founder always speaking with authority?” - with apologies to any Ecclesiastical Latin scholars.

Take Survey

A couple of short weeks ago, I found myself giving talks at two events in the same week. Thursday was a ProductTank in Cardiff, but on Monday, I was speaking at a conference in Amsterdam. I was privileged to share the stage with Marty Cagan. You’ve probably heard of that guy, right?

Marty took the stage and held court for over an hour, talking about all his favourite topics and never flinching from a question. Before and after his talk, he was bombarded with fans asking him to sign copies of his book or grab a selfie with him. Some keyboard warriors on the internet may unfairly complain about him these days, but there’s no denying his star power in product management circles.

Which is why it stung a bit halfway through his talk, he dismissed the exact approach I was planning to present at ProductTank on Thursday as something that just doesn’t work!

Now, to be clear, Marty didn’t know what I was talking about in Cardiff in a few days time, or probably that it was happening at all. He was simply responding to an audience question about product transformation. His response did get me thinking about my life choices, though, as well as thinking about product transformation in general, though. Let’s dig into it.

On “Product Transformation”

When considering product transformation, it’s important to define what we’re transforming into. What is a product transformation? What’s it for, and does everyone need to transform? Obviously, Marty’s book Transformed goes into this a lot (and my podcast interview with Marty, too).

From my perspective, I’ve started boiling it down to 4 key areas (with a non-exhaustive list of sub-areas called out):

1. How Are Decisions Made?

Is there a product vision and strategy to guide decision-making? Are decisions made reactively based on who shouts loudest or the next biggest deal in the sales pipeline, or are they made proactively based on evidence? Is the product management team responsible for deciding things, or just for implementing someone else’s decisions?

2. How Is The Product Built?

How is the work scoped and delivered? Are the product, engineering and design teams fully involved as equal partners in the product development process? Is the work done in the shortest possible cycles appropriate for the company and its customers? Is there sufficient transparency so people understand what’s coming up? Are technical deployments independent of customer releases? Is engineering work managed by the engineering team itself?

3. How Is The Product Released?

How does the product get into the hands of customers? Are the product management team in lockstep with the marketing and sales teams, and have they informed any go-to-market and sales activities, or did they just throw some features over the wall and move on to the next thing? Are the product management team involved in pricing and packaging decisions? Do they even know how the product is sold?

4. How Is Success Measured?

Does the product management team define success and guard metrics ahead of time? Do they have observability so they can track what happens after things are released? Do they proactively monitor these metrics to understand the impact of the work they’ve done and use it to feed into the next decision-making cycle?

There’s actually a fifth, all-encompassing element, which is the importance of alignment. It’s no good doing all this good work if no one knows what you’re doing: The decisions you’ve made, why you’ve made them, and how those decisions are panning out. I’ve spoken to enough leaders in enough organisations to realise that this is the most crucial part of all - it’s hard to run an effective product organisation if you’re constantly being bombarded by escalations, queries and random requests. It’s almost always the lowest hanging fruit when going into an organisation.

Why is change hard?

If transforming into a perfect product organisation were easy, everyone would have done it by now. This stuff is really hard, and anyone who says it’s easy is trying to sell you a pack of Notion templates. But, on the other hand, why’s it hard? Surely, people should be able to read about this stuff in some good books, see sense and get on with it?

Obviously not. There are a bunch of cognitive and organisational biases that get in the way. Every company out there has evolved a working culture over time that is the sum total of the pre-existing biases of every employee, and especially of the leadership team. Status quo bias is an obvious contender here. Fear comes into play. Fear of change, but also a fear of a loss of control or a fear that this stuff won’t work here. Organisations have a gravity, or rather a spring-loaded tension - the more pressure you try to exert, the more pushback you can get.

It’s also fair to say that, very often, product leaders are terrible at selling the message about why the change is a good thing. They resort to quoting books without making a strong case. They can then get frustrated and increasingly bitter when people don’t listen, eventually stymying their chances of making any changes at all.

So, how do we do it?

There are many ways to skin a cat, but here are 4 ways that you might go about trying to transform into a “proper” product organisation:

1. Just Give Up

No law says you have to be a product organisation, and plenty of decent companies aren’t. If every instinct of the founders is to turn the handle and churn features out while getting constantly randomised by incoming feature requests and side-quest one-off builds, that’s cool. I wouldn’t want to work in “product management” for that type of company, but I guess there is a certain excitement to it. The problem isn’t so much that companies stick with this, but that they stick with it while expecting the benefits of being a product company.

2. The Big Bang Theory

Let’s go to the other extreme and just change everything at once! Rip off the Band Aid, gut all of the old teams, implement new operating models, probably fire a few people and bring in some hot talent from Amazon (although not from the Amazon when they were the same size as your company, of course).

I personally don’t see this as an appetising transformation project in just about any scenario. Even if you can get past the ill will, political infighting and sabotage attempts, trying to change everything at once is an incredibly risky move. It’s unlikely to pay off in the timescale that you want it to, and just leave a tangled mess of a company hanging out the back of it.

Maybe it’s a valid approach as a last resort emergency solution, but if you have time, avoid it.

3. Apply Product Management to Product Management

This involves taking a horizontal approach and building a backlog for change. The idea here is that it’s too risky and difficult to change everything at once, especially when there is suspicion or lack of buy-in from the leadership team, so start small.

It’s kind of like taking a product management prioritisation approach to product transformation: Identify the biggest limiting factor, break it down into smaller, valuable increments and deliver impact in those areas step by step.

You’re not going to transform the entire company overnight, but if you can make sustained, compounding changes, then you’ll be surprised where you end up, and generally with no broken bones. On the other hand, the pace of change can be slower, and you may not see immediate, exceptional results.

4. The Golden Team

This is the vertical approach. Rather than taking a step-by-step approach and fixing one thing at a time, you create an exemplar team - either hired in, formed from members of other teams, or an existing team that you want to change.

The goal here is to do all the things “properly” in that team. Everything. It’s a limited surface area, so you’re not risking the entire company on something that might not work, but you’re also able to demonstrate the awesome power of product thinking in an enclosed fashion.

In theory, this can allow you to deliver outsized results and get permission to start implementing this approach in other teams. On the flip side, it can cause discord inside the other teams (“why can’t we work like that?”). There’s also a risk that, if it doesn’t work out, you’ve shot your shot and missed.

What’s the right answer?

Well, the approach that Marty prefers, and called out in his talk, was “The Golden Team” model. He explicitly doesn’t believe that the iterative approach works.

For reference, my talk in Cardiff a few days later was called “Applying Product Management to Product Management” 🫠

So who’s right? Well, I would never go against the Jedi Master, but I do feel that each approach can work in different circumstances. Marty’s point was that, if the clock is ticking and you need to show results, iterative change is not going to cut the mustard. You’ll run out of time before you’ve delivered the true benefits, and the leadership team will give up on you.

It’s a compelling point, and I’d perhaps refer to it as answering the top-down transformation question. Maybe the leadership team are explicitly driving the need for transformation. Perhaps they’re curious after speaking to some CEO friends, or their investors have been pressuring them. Whatever the instigation, they want to see results, and they want them soon. In this case, you absolutely need to show results as quickly as possible, and the golden team approach is almost certainly the best option. It’s also a fantastic option to try if you’re creating a new zero-to-one initiative with no baggage and few barriers.

On the other hand, what if no one’s telling you to change? I often speak with leaders of companies who are conscious that something is wrong, but “product transformation” is the last thing on their minds. They just want everything to be the same but better. There are almost certainly talent gaps and perhaps no obvious candidates to fill a golden team, or budget to hire anyone.

If it’s a bottom-up transformation effort, where you’re trying to advocate for things to be better and the pressure is coming from your side, you can probably afford to take a more measured approach. This doesn’t mean you can’t take a big swing if you see the opportunity, but that you are more likely to make sustained progress if you don’t upset the apple cart, and that any changes in the right direction are better than no changes in the right direction.

You could, of course, also try elements of both: Create a golden team while iterating changes with the rest of the organisation, which means that they’ll have less distance to travel if the exemplar team does its job and gets you the wider buy-in you need.

It’s become a bit of a cliché to say “it depends” to every single product management problem, but it really does depend. It’s important to assess the appetite for change, the urgency that is being felt, the timeframe you need to deliver it in, and the pain being felt on the ground before choosing a method that you believe will work in your particular circumstance.

I’d love to hear your stories of trying to implement change! Drop a comment or send me an email if you have a story of any of this stuff working well for you, or crashing and burning.

I’m also going to take this opportunity to basically sponsor my own newsletter. Here’s some stuff you can do with me!

• I’ve got a handful of coaching slots available as we enter 2025. If you’re a product leader looking to make an impact in your organisation or you’re a senior PM looking to make that step up into product leadership, let’s have a chat and see if I can help you.

• Saeed Khan and I are continuing our two-man push to make product management teams work more effectively with sales teams. We are running another Maven cohort of our well-received “Working with Sales” course, as well as a more affordable self-paced option for those who don’t want live sessions. Check out both options here.

• Berliners! I’m coming to Berlin in January for a handful of events and I’d love to see you there. Come to the pub, join our leadership lunch, or hear my predictions for 2025. Check out the events and register here.

Right - let’s get on with it (oh, and remember to subscribe to this newsletter if you haven’t already!)

Subscribe now

It’s 2025 and the AI hype is stronger than ever

I wasn’t originally planning to write about AI again, after my last post on the subject. That said, ever since I started back on LinkedIn after Christmas, the AI hype has been strong. I don’t know if it’s because the algorithm is showing me different stuff, or because people are talking about it more, but it’s getting exhausting.

The hype is primarily focused on the fact that 2025 is going to be the year where amongst other things:

• Product management is going to die because developers can just crank out requirements with LLMs now.

• This is lucky because software development is going to die because LLMs can generate code faster than humans.

• User interface design is going to die because we can just scribble stuff on a napkin and get an LLM to generate working prototypes (including dark mode if we’re lucky).

• But UX people are still out of luck because user research is also going to die because of “synthetic respondents”.

• Management is going to die (because what the heck do managers do anyway?) and we’ll just have “super individual contributors” running the show.

• But not for long, because employment itself is going to die, and we’ll just have HR teams managing AI agents that do all the work.

• But don’t worry, because SaaS is going to die (thanks, Satya!) because everything’s agentic now, and we don’t need applications.

According to many commentators, this is all now inevitable because the pace of change in AI is exponential. Apparently, everything’s getting better all the time and we’re going to have AGI (Artificial General Intelligence) by summer. Did you hear that the latest OpenAI model scored 88% on a benchmark you’d never heard of before you read the news article about it? It’s just a matter of time before we’re all doomed.

Is any of this stuff true?

In a word, who knows? We’re one announcement away from every single sceptic being proved wrong. But, you can’t plan your future based on vibes, and so far, most of the hype comes from certain groups of people:

• By far the largest group of hype-mongers are the people who stand to make money from the hype (or are trying to recoup their investment). This is inevitable (see also: crypto) and also fairly easy to spot.

• You also have people who are just generally techno-optimists and want this stuff to work, and I get that. Having worked on AI solutions in the past, I’m already blown away by the strides that have been made so far. On a purely technical level, I want this stuff to work. It’s exciting!

• Inevitably, you have people who don’t really know what they’re talking about but have consumed so much hype from the first two groups that they want it to be true too. Not because of the technology itself per se, but because the idea of “number go up” is incredibly attractive to them.

These people write incessant thought pieces about the inevitability of major disruption. Anyone who questions any of it is a “Luddite” or a “laggard” or “has their head in the sand” or they’re simply “an AI hater”.

Whatever these systems can eventually do, and however good they eventually get, they’re certainly not there yet (although they’re still really good compared to what came before!). Even the new “almost human-level AI” OpenAI model has not yet been released to the public and we have to take a lot of it with a pinch of salt. There are also people who are suspicious that OpenAI has taught to the test. Even if they didn’t, benchmarks are often the solace of people who want to prove that their system is good at everything when, in real life, you’re not working on benchmark exercises. In the meantime, where is GPT5? Where is AGI?

When it comes to “AGI” itself, the definition has always been muddy, but OpenAI has been lowering the bar. They are now defining it as when they “develop AI systems that can generate at least $100 billion in profits” - which is both insufficient as a technical answer (there are many ways to try to generate $100 billion in profits) and unsatisfying even from a business perspective (since OpenAI is years away from turning a profit at all). It’s a long way from the sentient superpower that we were all promised and the human-level reasoning that we appear no closer to achieving.

Working with what we have today

Meanwhile, people are still trying to make the best out of a variety of, let’s face it, functionally identically LLMs. None of them can be relied upon to give a straight answer, and they’re just as confident whether they’re talking nonsense as they are when they’re bang on the money. They can give the appearance of reasoning because everything is very nicely typeset and polite and sprinkled with big, trustworthy words. Frankly, it still feels like magic to me watching these systems crank out text.

On the other hand, it doesn’t take long for them to reliably break down. Try this test: Take a subject that you’re very expert in and start asking detailed questions about that thing. I did this with DOOM 2 as an example, and it was soon merrily inventing false details about the game and the monsters within it. So why would I trust it not to make stuff up about stuff I don’t know about (say, the migratory habits of an African swallow)?

That said, it’s easy enough to poo-poo whether these things reason just because it doesn’t feel like they do. Anyone can be sceptical of anything, and they’ll often be right by default. But Apple went one step further and published a paper on how the illusion of reasoning is just that, an illusion, and what looks like reasoning is just LLMs regurgitating stuff that’s appeared in their training data set. One might argue that Apple only put this paper out because Apple Intelligence is terrible and they need an excuse, but at least they’ve done the work.

The three things I use LLMs for most are transcript summarisation, spitballing, and general research. I thought transcript summarisation was a godsend because who has time to read all their meeting notes, right? Well, one day, when I did have time, I decided to go back and double-check to make sure ChatGPT hadn’t missed any nuances.

Spoiler alert: It had! I’ve now given up just using summarised transcripts on their own, and make sure I jot down key points that I think are important live on the call. I work with clients with complicated problems… I don’t want an LLM to average those out or miss something important. Do you really trust an LLM not to miss something important?

For the other two use cases, LLMs so far remain undefeated, because you actually have to do some work with them to dig into the topic you’re investigating, and there’s no real expectation that you’ll just fire and forget. Using them to explore the space around something, giving me jumping-off points for further investigation (always verify your outputs!), and maybe identifying missing connections between concepts can be a real accelerant. But, you still have to do the work to get good results.

But, if we have to verify everything that comes out of an LLM, and the outputs are so unreliable, are we really going to see the death of all those different types of jobs as claimed? How does that even work?

When good enough is good enough

Actually, it doesn’t matter whether it’ll work or not, because people are going to try anyway. When budgets are tight (but expectations remain higher than ever) and when the hype is as noisy as it is right now, people are going to try to do it anyway. And, to some extent, that’s fine. There are plenty of use cases where people are prepared to sacrifice human-level quality for stuff that’s “good enough”. And, this is assuming that they were getting human-level quality from their human employees! After all, drinking a glass of dirty water is better than dying of thirst.

So, how do you survive and thrive as a product manager in this AI-hyped world?

Well, firstly, don’t keep your head in the sand. These tools are here and the genie is out of the bottle. Learn about them and understand them. When I say “understand”, I don’t mean get down and dirty with the ins and outs of transformer architectures and big data pipelines, but learn what they can and can’t do, and how far they can be trusted. This is crucially important for two different use cases:

• The tools you use to help you make an impact in your job

• The tools you put into your products to help your customers

I don’t care if you call yourself an “AI Product Manager” or not (OK, I do care a little bit) but keep your focus not on the ins and outs of the technology but on the use cases it unlocks and whether you’re using the best tool for the job. Find ways to test small before you invest big. Be curious, but keep your eyes open and your judgment sound. Ultimately, make sure your work delivers value to you, your organisation and your customers.

The current hype cycle isn’t just hype - there are real, tangible benefits that people are getting out of these tools. You can too. But know the limits and check your work. Stay informed, but you need to look beyond the headlines and the incessant hyping of people who, lest we forget, have a vested interest in all of this stuff. Make sure you’re not being hoodwinked and do your best to be the translation layer between reality and those in your organisation who have been sucked into it.

I want to get two things out of the way before we continue:

1. I use generative AI on a daily basis and find it an indispensable tool for getting “stuff” done.

2. I realise that it will be very ironic if I’m wrong about all of this stuff and you’re reading this 6 months from now from the comfort of your Matrix-style human mulching cylinder.

Let’s get into it. Feel free to subscribe before you scroll!

Subscribe now

There's been a lot of chatter recently about the rise of generative AI, and the impact it’s going to have on everyone’s jobs:

• We don’t need developers anymore because LLMs can write code for us!

• We don’t need designers anymore because LLMs and diffusion models can make wireframes for us!

• We don’t need product managers anymore because LLMs can write our requirements and even our strategies for us!

These are extraordinary claims, and extraordinary claims require some evidence. So, is this true? We have Sundar Pichai claiming that 25% of Google’s code is “AI-generated”, and if you can’t trust the CEO of a company desperate to catch up with the AI market, who can you trust? Even that claim is caveated with the fact that human engineers are still reviewing (and presumably fixing) the generated code. I’ve also seen claims from Google insiders that the “AI-generated code” is no more than glorified autocomplete and boilerplate. Now, to be clear, this is still useful, but I don’t think Google will be firing all of its engineers any time soon.

OK, but what about product management? Well, here are some of the areas in which LLMs have been touted as revolutionary for product managers:

• Summarisation and categorisation of meetings and research interviews

• Synthetic respondents for user interviews (!)

• Creating product visions and product strategies

• Producing requirements documents and tickets for engineers

There are, of course, plenty of tools looking to satisfy all of these needs, with more coming every week, as well as established tool vendors rushing to get as many AI features into their legacy products as possible. But, are these tools really going to kill product management?

The Disadvantages of Generative AI

I’ve been working on and with AI products since way before they were cool. I’ve built my fair share of AI models to try to work out what they can do. I’m even working through a book called Build a Large Language Model (From Scratch) right now. I say this to try to emphasise that I love playing with this tech. But, we do have to remember one central fact:

LLMs can output very convincing, intelligible, nicely typeset text, but they fundamentally have no idea what they’re talking about.

Now, my buddy was a guest on my podcast once, and said something to the effect of “It doesn’t matter if they don’t know why they’re picking the words they pick, as long as they’re the right words”. Outcomes over outputs, baby! And, there’s something to this, but you’ve got two basic choices:

1. Trust but verify - accept that LLMs are going get it kind of right but the output needs to be checked and moulded by a human with actual expertise.

2. Don’t use any expertise - just trust that you’re going to be lucky and that you’re never going to roll snake eyes.

The paradox of overreliance on LLMs is that you either know how to do the work yourself (and LLMs speed you up) or you don’t know how to do it but the output looks kind of fine, so you just go with it. The latter case has the added advantage that you never even have to learn how to do things!

My fundamental belief is that, for anything important, generative AI should be used for inputs, not outputs. Like, sure, use DALL-E to make a fun picture of a robotic overlord for a newsletter, but is that the standard you want to set for your actual work? I’ve yet to see a single compelling output from an LLM that I would be happy to put in front of a customer or use unmodified for anything important.

Or, to put it another way… I speak restaurant German, have listened to all of Rammstein’s albums and can easily recognise German text if you show it to me. But, I wouldn’t ask an LLM to write me an important document in German and then just send it. So why would I use it to produce a strategy if I don’t know how to make one myself?

But, Surely It’s Going To Get Better?

Well, maybe. There are compelling arguments that LLMs are already peaking, and that throwing more computational horsepower isn’t going to help. There’s already talk of model collapse because they’ve already exhausted the publically available content (which, by the way, is awash with AI-generated slop, causing the models to “eat themselves”). There’s talk of using hyper-specific LLMs rather than generalist ones, which might eke out some performance gains, but what if LLMs are already roughly as good as they’re going to be? Now, obviously Sam Altman is saying we’ll have AGI by 2025, but wouldn’t you say that if you needed people to keep investing in your company?

There’s also another snake in the grass - the fact that these models are insanely expensive to train (for increasingly marginal returns) and the computing resources needed to run them are crazy. has written a bunch of very detailed articles about the amount of money needed to keep these things running, and how companies like OpenAI need constant investment (in the order of billions of dollars) to keep their lights on. Now, I’m very sure people will keep pouring money in, but how long before they want to see a really big return? This is notwithstanding the various lawsuits being filed against AI companies for misuse of copyrighted materials. No one knows where they’ll end up, but they’re not stopping any time soon.

None of this makes using LLMs for product management bad per se, but are LLMs going to get better enough to kill product management?

Who’s Going To Kill Product Management?

For all the talk of product management being dead, there sure still seems to be a bunch of product managers out there, and the product manager job market is picking up too. But, there are still a lot of people saying that product management is going to go the way of the dodo.

The problem here is separating reality from hype. Anyone who’s used an LLM to do anything important will know that this stuff can be inconsistent, being up incorrect facts or just be so… vanilla. That’s barely surprising when we consider that these models are able to generate convincing text based on the sum total of existing human knowledge but are fundamentally unable to reason.

Now, I’ve seen articles saying that LLM-generated strategies were rated (by panels of product people) as higher quality than human-generated strategies. On its surface, this is compelling, but dig deeper and you find that these often aren’t strategies at all, but just a list of features that you could build (all of them obvious). Personally, I come away from these types of discussions more concerned that product managers seem to be pretty bad at strategy than that LLMs are good at it.

But, here’s the thing, it doesn’t actually matter if this stuff is any good if people think it’s good. The narrative that we can automate everything via generative AI is already out there. Many business leaders really have no idea what “product management” even is (and quite a few are pretty bad at strategy too). If they boil product management down to a bunch of mechanical tasks that can be easily automated, then they’re going to be very keen to reduce that cost.

But, that’s not what product management should be. LLMs can’t sit in a meeting with ’s Gary from Sales and resolve a debate over prioritisation (certainly not in a way that would change anyone’s mind). LLMs can’t negotiate scope or get someone to disagree and commit. LLMs can’t empathise with users. LLMs can’t come up with truly novel “blue ocean” strategies. LLMs can’t make judgment calls. Of course, in many organisations, product managers also don’t get to do these things, but LLMs aren’t going to solve that either.

This leads me to the belief that it’s not AI that’s going to kill product management, nor even product managers using AI that is going to kill it for those who don’t. If anyone’s going to kill product management, it’s influencers (often trying to sell courses or AI tools) persuading cost-cutting leaders that it can be killed and helping fulfil their own prophecies.

Falling in Love with Generative AI

I want to be crystal clear that I love using generative AI, I use these tools every day and I think all PMs should be using them too. I use Gen AI as a brainstorming partner, an idea generator, and a research buddy, as well as for automating some routine tasks. I already can’t imagine going back to the way things were.

But, I still have to use my brain. The best product managers use AI to complement their abilities, not to replace their judgment, creativity, or decision-making. If we can use LLMs to buy us more time for the things we should really be spending our time on, then that’s a beautiful thing. That said, human oversight is more crucial than ever in an LLM world.

PS - here are all the podcast episodes you’ve missed since my last newsletter!

• Episode 227: Commercialize! Get your Productized Services to Market (Eisha Armstrong, Author of "Commercialize")

• Episode 226: Solving the Growth Equation to Derive Product/Market Fit (Andy Budd, Author of "The Growth Equation")

• Episode 225: Jas Shah's Hot Take - Product Management isn't as Glamorous as People Think (Jas Shah, Fintech Product Consultant)

• Episode 224: Victoria Sakal's Hot Take - You're Either Paying the Research Tax or the Stupid Tax (Victoria Sakal, Growth, Strategy & Research Leader)

• Episode 223: Boluwaji Alepaye's Hot Take - Western Product Teaching Doesn't Work in Nigeria (Boluwaji Alepaye, Product Manager @ Moniepoint)

• Episode 222: How to Present Yourself (And Why You Should) - Danielle Barnes & Christina Wodtke, Authors of "Present Yourself"

Ah, product management! That wonderful intersection of the ephemeral concepts of “business” and “users” and “technology”. The subject of so many books, talks, blog posts and podcasts. Such an essential role for any organisation looking to build winning products and solve our users’ most important jobs to be done.

So why’s it so darned hard to get a straight answer about what a product manager should actually be doing?

The Elusive Definition of Product Management

I used to ask “the barbeque question” on my podcast, which goes something like:

“Imagine you’re at a barbeque and meet some random stranger. You get talking and they say they’re a lawyer (or whatever) and ask you what you do for a living. How do you answer?”

The question has stumped even quite well-known product management thought leaders and influencers, simply because there’s no one right answer. There’s no ISO standard definition for a product manager. Which makes defining what a good one looks like pretty tricky (although some have tried).

Some people like to try to come up with a definitive definition. They might talk about the somewhat intangible concept of “product sense”. They might talk about “outcomes over outputs” or “user-centricity”. These words are all great, and I believe in them, but the simple fact is that product management doesn’t exist in a vacuum. However we define ourselves, others will have expectations of us based on factors we can’t easily control:

• The context of our company (B2B, B2C, B2G etc).

• The biases of the founders and other leaders within the organisation

• The types of customers we sell to and the markets we serve

• The types of products we sell, and whether they’re part of a product/service mix

• The overall maturity of the organisation and its products

All of these combine to create a muddled picture, where our leaders and colleagues might have a very different view of what we should be doing, and this can cause tension.

The Different Territories of Product Management

Many people try to define product management by its practices; the way the work is done. There are many, many books about how to do product management “properly”, written by people who have seen the best and worst of product management (and written down the best). Generally speaking, these books are all broadly aligned on the general principles of good product management. I also guarantee that the vast majority of your colleagues haven’t read them.

The “territories” we believe we should be active in include, but are not limited to:

• Developing a product vision and supporting product strategy

• Gathering evidence and feedback first-hand from real customers

• Deciding which problems and opportunities to solve

• Generating and evaluating solutions

• Prioritising use cases and making necessary trade-offs

• Building products that demonstrate continuous value

• Launching and releasing products to market, and tracking their success

We want to do all of these things and do them cross-functionally, collaborating across the business and especially with our “product trios” of developers, product managers and designers. We want to be empowered, lead product decision-making and be seen as strategic partners to the business.

Many product managers are disappointed about how much of this they actually get to do, primarily because many business leaders believe the role of product management is:

• Take orders from the sales team

• Write up a nice product requirements document and some tickets

• Check-in with the developers (or “speed up delivery”)

• Tell “the business” when stuff is done and they can sell it

How is a product manager expected to do a good job in these circumstances? What does a good job even mean?

The True Measure of a Product Manager: Product Success

Many product managers are guilty of preaching “outcomes over output” as a mantra and then start focusing incredibly hard on the way we do the work (or are prevented from doing it) rather than the results of the work. We concentrate on the “outputs” (the processes we follow) rather than the outcomes (the success of our product). Ultimately, a product manager is only successful if their product is successful.

What does “product success” look like? Well, consider the stakeholders of a typical B2B product:

They’re all pretty self-explanatory but, for the record:

• Business - The people you work for! Success here looks like recurring revenue, retention, growth and profit.

• Customers - The people who buy your product. In B2C, these will probably be your users too, but in B2B they may be entirely different and have different motivations. Success here looks like solving all the use cases for their business, regulatory compliance, a fair price and making the economic buyer look good.

• Users - The people spending time using your solution. Success here looks like having a product that solves their problem well, is easy to use and makes their lives better in some way.

Precisely where product managers focus in this triangle varies per company, and often within a company too, depending on business goals at a particular time. There’s no right or wrong in these decisions; it’s all about choices. But these choices need to be made and product managers need to understand what is expected of them, and what success looks like in their context.

And then do whatever is necessary to achieve that success.

Does This Mean Best Practices Don’t Matter?

No, not at all! It simply means that they’re less important than creating a successful product. We live by “outcomes over outputs” so we must die by “outcomes over outputs”! It doesn’t matter how well we execute product management practices, how well we collaborate, the quality of our PRDs, how many user interviews we did this week or whether our burndown is a nice gradient if the product is not successful.

The reason the product “best practices” matter is that they’re the best hypotheses we have about how to deliver successful products. They are, however, not immutable. No two companies work the same, even the Big Tech firms that are touted as the best of the best. These processes, methodologies and working norms are there to serve us and our product. They’re not performative.

There’s another important factor, of course, which is that these ways of working tend to make work… well, bearable. Working in a psychologically safe, collaborative environment with a clear strategy and evidence-based decision-making just feels better. Few people want to work in a toxic, top-down organisation that treats them like a resource. I strongly believe in the principles behind good product management, and that people should aspire to live up to as many of them as possible.

But, if you do all that and your product is not successful, can you really say you’ve succeeded as a product manager?

Wrapping Up

In the end, a product manager is only truly successful if their product is successful, and their product is only successful if it delivers value to all its stakeholders.

As product managers, we should:

• Focus on delivering user, customer and business value

• Be willing to adapt our processes based on our unique context

• Prioritise outcomes over outputs in our ways of working as well as our products

Are you doing everything you can to make your product successful?

I’ve been rather lazy with my newsletter writing recently, so there are far too many podcast episodes to list out here and double the size of the email. Check out the podcast website, or the YouTube channel if you want to go deep on Customer Success with Nick Mehta from Gainsight, Stakeholder Management with Rina Alexin from Productside or nail your LinkedIn game with Ivana Todorovic from AuthoredUp. And much more besides!

• Firstly, I spoke to Greg Prickril about how AI is going to change everything for product managers, and how we need to be getting stuck into it right now if we don’t want to be left behind. [YouTube] [Podcast]

• I also spoke to Bjarte Rettedal, who believes that these AI models are so potentially dangerous that we need clear regulation around them, and ideally have them under public ownership. [YouTube] [Podcast]

• Last but not least, I spoke to Andy Walters, an AI consultant who believes we’re soon going to be living in an AI-Assistant-First-World, and we talked about what that means for the future of employment. [YouTube] [Podcast]

• We’re starting the next cohort of “Working with Sales - Masterclass for B2B Product Managers” in a couple of weeks. Reviews from the first cohort are stellar! If you’re a B2B product manager looking to reboot your relationship with the Sales team, check it out (and use code NEWSLETTER for a tasty discount).

• If you’re not ready to commit to taking that course, why not check out our FREE lightning lesson “Handling Sales Feature Requests for B2B Product Managers”? Sign up now and attend online or watch the recording later!

Ok, let’s talk about pricing (but remember to subscribe to this newsletter if you haven’t yet!)

Subscribe now

The Pros and Cons of Being a Low Budgie-t Solution

Ok, I’ll cut the cheap “cheep cheep” budgie jokes…

I've chatted to a few people recently about product pricing. Some people have been saying they’ve been told that being the cheapest solution is a great strategy and can give you an edge over the competition. Now, these things can be true, but there are some caveats and watch-outs, so let’s get into it.

On the one hand, it makes sense, right? With the cost of everything rising, and budgets more constrained than ever, offering a solution at a lower price point means people will come and buy more of your thing. Yay, revenue!

Some Different Ways to Price a Thing

There are a few common ways to price a thing, whatever that thing is. In this example, let’s assume it’s some kind of SaaS subscription product and you’re going to charge X units of your local currency per month. But, how do we define X?

Cost Plus: We work out how much it costs us to make the thing (which, because it’s software, primarily consists of fixed costs plus stuff like employee salaries and our cloud hosting). This is our floor price, so we add a bit of margin on top and charge that.

Competitor-Based Pricing: We look at how much our competitors charge for a similar offering and charge similar to them, or a bit less to try to attract people to our solution. We could even charge a lot less if our competitors are big, established companies that have been rinsing their customers for years.

Value-Based Pricing: We work out how much value our customers get from your solution. How much is solving the problem we solve worth to them? What would it cost them to solve it if we didn’t exist? How price-sensitive are our customers? Will they pay a premium? Let’s charge that!

The general advice you’ll get from pricing experts is that Value-Based Pricing is the Holy Grail. And why shouldn’t people pay a fair price for the value they’re receiving? You’re leaving money on the table if you charge them a lower price than they’d be prepared to pay.

But, on the other hand, undercutting competitors is a known strategy and it’s fair to say that people like cheaper things and you’ll probably be able to get them to buy them, as long as they solve their problems well enough. They should also have lower expectations (in theory... although some people do seem to expect the world for 9.99 a month).

How Low is Too Low?

I spent a long time in the market research industry and one of the things we did often for clients was some variation of Van Westendorp pricing research. This, broadly speaking, asks questions like:

• At what price does this product start to feel expensive?

• At what price is this product so expensive you wouldn’t buy it?

• At what price does this product start to feel like a bargain?

And, crucially:

• At what price does this product start to feel so cheap that you start to doubt its quality?

Ultimately, if you price your product so low that people think it’s too good to be true, you may end up scaring people away, because they think the solution couldn’t possibly be suitable for their needs.

Defending Against the Competition When Price is Your Only Advantage

When you start out and are basically a small fly on the back of your established competitors, you have the advantage of anonymity and can build a business without too much hassle from them. Eventually, though, you’re going to start to get noticed, especially if you start taking substantial amounts of revenue from those competitors.

The problem with a low price being your only advantage is that you run the risk of being undercut by larger competitors who are prepared to lose money to put you out of business. If you’re starting to look inconvenient, don’t be surprised if they cut their prices for a little bit, especially if they’re making money from other product lines too.

And it’s not just the big players… there are always going to be smaller competitors and new entrants trying to find new, cheaper ways to do things. Maybe you’ve literally gotten the price down to the bare minimum and it’s not possible to do it cheaper. But are you sure about that?

You also run the risk of supermarket-style price wars, where you all end up gravitating to the lowest possible price point and are operating at such a razor-thin margin that it's difficult to invest in the future. We’re not selling cans of beans here.

By all means, be cheap if it helps you in your market, but I'd still recommend building an actual differentiator if you don't want to be disrupted in due course. Ultimately, if you can't answer the question "What would I do if someone charges 5 dollars below me for basically the same service?" then you need to work out the answer to that question!

If you enjoy my content and want to keep in touch, here are some ways you can do that:

• Follow me on LinkedIn

• Join my Slack group

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions (although I’m considering a cheap, paid tier). In any case, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!

• My podcast interview with David Pereira about his new book “Untrapping Product Teams”.

• May Wong’s hot take interview about how product management is a team sport, and we have to succeed together rather than concentrating solely on what PMs bring to the table.

• Here’s a recent interview I did on Henry Latham’s podcast about building a podcast and an audience from scratch.

• Saeed Khan and I have opened a new cohort of “Working with Sales - Masterclass for B2B Product Managers” that starts in September - if you’re a B2B product manager looking to turn Sales from adversaries into partners, check it out (and use code NEWSLETTER for a tasty discount).

• I’m doing an August pub meet-up with special guest Melissa Appel (co-author of the new book “Aligned”). Sign up here if you want to come along! We’ll have freebies!

• Speaking of events, I’m also running a free directory of in-person UK product events. Check it out here if you want to know what’s on.

• Oh, and do remember to subscribe to my YouTube channel

Why Product Owners Don’t Get Invited to Parties

You don’t have to look too far on social media these days to see some product think-fluencer complaining about “Product Owners”, and you do start to wonder whether POs get invited to parties anymore.

Some of the complaints you might hear:

• Product Owner isn’t a Job Title, it’s a Role In Scrum

• Product Owner work should just be done by Product Managers

• Product Owners are just Jira backlog monkeys

• Product Owners are glorified Business Analysts

• Product Owners are all going to get fired because of AI

Now, to be fair, even I’ve got caught in this loop before (you can consider this article the sound of me refining my opinions in public). And, to be fair, I can certainly understand where some of these sentiments come from. As a product leadership consultant, I work with lots of different types of teams, but if I walk into a company with loads of Product Owners then I’ll definitely notice it and go “Hmm!”

But, the thing I’ve been thinking about recently is that this isn’t really the Product Owners’ fault, and maybe people should stop telling them that they’re useless to their faces.

What is a Product Owner?

So, what is a Product Owner? Well, again, there is some justification that it’s “a role in Scrum”. After all, this is what the Scrum Guide says:

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team”

It goes on to say:

“The Product Owner is also accountable for effective Product Backlog management”

A ha! Case closed right? They are backlog monkeys! But, wait, it also says:

“For Product Owners to succeed, the entire organization must respect their decisions.”

Now, to be honest, there are many Product Managers who would love to work for a company that respects their decisions, but there’s definitely an element to the Scrum definition above and beyond just sorting tickets in Jira. And, of course, this doesn’t even go into whether teams are even using Scrum (or using it properly) at all.

Side note: I would follow this up with a definition of “What is a Product Manager?” but, of course, there isn’t a standard definition of a product manager, which is why we all mumble into our drinks when we’re asked about it at parties.

“Product Owner” as a Job Title

Something that occurred to me the other day is that in most domains an “Owner” outranks a “Manager”. If I “own” a business then a manager is my employee, not my boss! By this logic, the “Product Owner” should be the Alpha and Omega of the product, and the “Product Manager” a subordinate charged with day-to-day management duties. Of course, this is not how it pans out in most companies that bother to make the distinction.

The general pattern is:

Product Manager (n) - the person who gets to do all the strategy stuff, talking to customers and negotiating with stakeholders.

Product Owner (n) - the person who gets a pile of business requirements dumped on them by the product manager and told to write them up and put them in the right order for the development team to work on.

In some companies, the PO team doesn’t even report to the product organisation and is seen as an offshoot of the tech team. I’ve also heard of companies that have a third tier of “Product Strategist”, which seems to be a smellier smell than having PMs and POs to be honest.

So, Product Owners suck, right?

Not so fast!

What people are trying to say when they start banging on with “Product Owner is a job title” is something along the lines of: “We believe this should all be one role. Splitting it into two is less efficient than splitting vertically. We need to make sure there aren’t too many hand-offs between commercial and tech teams”.

And, you know, I basically agree with all of those points! But, it often comes out sounding more like “Product Owners suck! They’re all going to get fired and they don’t deserve to have jobs and they probably have poor personal hygiene too. Down with Product Owners! If you’re a Product Owner, I hope you fall into a pit”.

What’s a Product Owner to do in this situation?

In defence of Product Owners

We need to mind our language and consider the impact of our words. Why?

• Individual Product Owners can’t just change their job title or responsibilities on their own, even if they want to.

• Product Owner positions can be a great entry point into a broader product management role… you get to learn how software is made and (hopefully) have a “proper” Product Manager to learn from.

• Companies that hire Product Owners are probably pretty far from “proper” product management practices and there are bigger problems to sort out than people’s job titles.

• These people are just doing their jobs! Blaming Product Owners for being Product Owners is like blaming salespeople for trying to sell stuff.

• Many Product Managers are doing exactly the same “Product Owner” work for their companies anyway while looking down on people with accurate job titles.

• On the flip side, some non-tech Product Managers can suck at doing the product owner stuff, and they need people to do that for them.

Now, I know that (most) people aren’t trying to name and shame individual Product Owners. But going out with blanket statements that demean a profession is not a helpful move given that you have, broadly speaking, two types of Product Owners:

• Product Owners that are quite happy “just” being Product Owners

• Product Owners that aspire to be “more” than Product Owners

We should help to support the latter! This could be a training or coaching thing, or maybe a wider systemic change for the company they work for. Hopefully, these Product Owners can find constructive ways to push for change and take opportunities as they arise.

But we should respect the former. Am I worried that their job is going to get taken by AI? Sure, but no more than I’m worried about anyone’s job getting taken by AI. That’s not even to say that AI would do a particularly good job, but I don’t think that’ll stop business leaders trying and we’re already seeing designers and developers under threat.

All in all, let’s just remember: Words have meaning, people have feelings, and only the Sith talk in absolutes.

If you enjoy my content and want to keep in touch, here are some ways you can do that:

• Follow me on LinkedIn

• Join my Slack group

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions (although I’m considering a cheap, paid tier). In any case, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!

Today we’re going to go deep on an important question but, first of all, here’s some content for you to bookmark and catch up on:

• My podcast interview with Aakash Gupta about the product leadership job hunt.

• Dean Peters’ hot take interview about some of the further root causes of “Instagram-ification of product management” (here’s John Cutler’s take on the same).

• Dave Ballantyne and Duena Blomstrom recently interviewed me on their People AND Tech podcast. We chatted about how developers and product managers should be the best of friends rather than reverting to silos, and much more. Remember to also check out this interview with Duena on my podcast.

• Here’s the recording of my recent Lightning Lesson with Saeed Khan on the topic of handling sales feature requests (free, but email address required). You can also check out our upcoming cohort course on working with sales teams!

A message from the sponsor

This issue of the newsletter is kindly sponsored by June.

June is the Customer Analytics platform for B2B SaaS companies 💜

It’s a free and simple way to launch your product, understand your users and reduce churn.

With June you can:

• Get auto-generated reports focused on how companies use your product

• Track and understand feature usage to prioritize development

• Get weekly updates on high-risk accounts

• & much more

Check them out at https://tinyurl.com/yszhdznf and Meet Your Customers 😃

So… can every sales-driven organisation be transformed?

I was chatting to Rich Shnieder on my Slack community recently and he posed this simple-looking question.

Here's a philosophical question for you... Do you believe that every sales-driven organisation can be transformed to being product-led, or are some businesses just always destined to be sales-driven?

My first answer was “No!” - but then I had some follow-ups, so let’s dig into them:

What does "Being Product-Led” even mean?

Like many buzzwords these days, the very concept of “being product-led” means different things to different people. Here are some ways I’ve heard it be used:

• The Product Management team is in charge of everything

We have an empowered product management team and any decision that isn’t made directly by them, based on data insights and direct customer discovery, is automatically invalid! If the founders of the company or, heaven forbid, the sales team make a request then the product team gets to “Just Say No”. Anything else just means we’re in a feature factory. I’ve had versions of this precise complaint from product teams before.

• The only thing we have to sell is a product so I guess we’re product-led

We say we’re product-led because that’s the only thing that we have to sell, so we’re de facto product-led. It doesn’t matter how we decide what to build, or who we decide to build it for, we have a product. Job done. Actually, we do have to customise the implementation for some customers and naturally, they all have custom integrations they need. Oh, and if we have to do some services to prop it up we can just hide that service revenue as recurring revenue to keep our investors happy. And, actually, it is recurring because we never stop having to throw humans at individual problems.

• Product-Led Growth (with or without Product-Led Sales)

Product-led Growth (PLG) is probably the thing that most non-product people think about when they think about “being product-led”. This is the deceptively simple idea that products should be able to sell themselves, through mechanisms like freemium models, exceptional self-service onboarding and very quick time to value.

Product-led Sales (PLS) is an extension of this concept into large accounts (who might want a big enterprise deal), where you still acquire people through a PLG motion but use the data from your acquired users to identify those larger prospects that might use the product enough to be worth sending salespeople after.

So what does a “sales-driven” company look like?

The original question asked about transforming “sales-driven” companies into being “product-led”. So what are some clichés about sales-driven organisations?

• Short-term Revenue Obsession

We might worry about OKRs and user experience and retention and feature usage metrics, but the One Metric that Matters in a sales-driven organisation is revenue. Not just any revenue, but this quarter’s revenue. If we don’t get the big deal over the line before the end of the month, it’s next quarter’s revenue, which means we’ve failed.

• Large Deals and Long Sales Cycles

Salespeople are expensive and, whilst some may enjoy spending their time chasing low-value accounts, they’re generally incentivised to go for big accounts. It makes sense, right? Not only are these accounts worth more money but they’re also likely to be impressive logos for the website. The downside is that large deals tend to mean long sales cycles, which means more chances for things to collapse (and more panic to stop them doing so).

• Throwing Everything at Whales

“Whales“ are huge prospects that can make a massive impact on topline revenue, simply due to the size of contracts they are prepared to sign and the budget that they have to spend. As mentioned, they’re also incredibly attractive as proof points and case studies, so there’s some additional benefit for future sales deals. On the other hand, big companies have big demands. They might also rely on procurement-led purchasing with their dreaded list of checklist features. Don’t have feature X? Better build it otherwise you’re not getting to the next round!

• No Feature Request is Too Small

Because we need to do whatever we can to secure revenue, we often get dragged into sales conversations directly or told to build things that are of marginal value to our entire customer base. Product managers like to see themselves as the “Needs of the many” type of people who concentrate on sustainable, scalable future growth. They ask questions like: “Why can’t the sales team just sell what we have?”, “Why does every single new customer contract come with a bunch of ‘special’ requirements?” or “Why did we only find out about them after the contract was signed?" Meanwhile, they keep having to build the features anyway.

• Product Management Team Seen as Short Order Cooks

All of this can lead product managers to feel disempowered and unable to fulfil the “management” part of product management. What chance do we have of defending a product strategy or making good, evidence-based prioritisation decisions if we can’t even defend our roadmap for a quarter without some new demand blowing it up? Our job is simply to do our best to fit everything in and prioritise by either revenue or the volume of the person shouting the demand.

So, what’s a “product-led” company?

When I interviewed Marty Cagan about “Transformed” recently, he said that he discourages the use of the term “product-led” when it comes to talking about transformation. I happen to strongly agree. Partly, this is because of the constant confusion between having a PLG business strategy and a sales-driven business strategy (but still selling a product). The latter does presuppose some behaviours like the clichés above, but does it have to? Surely this is more of a spectrum than a binary?

Let’s keep the term for now and say that some key characteristics of a “product-led” company are:

• The needs of the many outweigh the needs of the few

• We prioritise long-term goals over short-term revenue

• We build based on evidence rather than opinion

• The product management team has a voice at the table

This doesn’t mean that the product management team gets everything its own way. But at least we’re in the room, having good discussions and being seen as partners in the long-term success of the company rather than order-takers being buffeted around on the waves of whoever the sales team speaks to next. And we’re listened to, rather than overridden on every single sticking point.

Can “sales-driven” companies be “product-led”?

It depends. No, really!

Part of this reminds me of my old post about Product versus Service companies and how everything’s a spectrum (BTW, used a much nicer version of my chart in her newsletter).

The simple question is… what type of company are we? How are we set up? What do we value? How did we get here? What type of industry do we serve and with what type of product? What are the company’s growth ambitions? What do the investors want?

I recently ran a poll on LinkedIn asking “Which is larger? Your sales team or your engineering team?”. As of the writing of this article, there are still a couple of days left, but look at the results so far:

37% of companies have a sales team larger than the engineering team! How much do you think these companies are set up to be “product-led”? Maybe some of them are, but overinvestment in sales teams means that it’s quite likely that go-to-market expansion will outpace the ability of the product team to provide a product that serves that market well.

So much of this is driven from the top. If the company has been set up by service-minded people, possibly with deep industry expertise but limited product experience, it can be hard. No matter what you try to do on a day-to-day basis, there’s always the threat of a sales team escalation to a sympathetic CEO who just thinks everything should be easy and fast. On the other hand, the best business leaders are the ones who know what they don’t know. They’ve hired product managers and product leaders to look after the product side of the house. They need to trust them.

But, how to engender that trust? You can’t just wave a book at them or talk in buzzwords and catchphrases. You need to engage with them on their level and speak their language. My top tip is always to “find something they already cared about before you started talking to them, and frame it in those terms”. You’re probably not going to persuade a quarterly-revenue-obsessed business leader with talk of OKRs, experimentation or discovery.

Your job as a product manager is to prove to them that there’s a high likelihood of your methods providing superior results to a sales team spraying and praying. The best way of doing that is to build as much capital with your leadership team as possible, do a good job, not be seen as an obstructionist, ride the waves, and take the opportunity of any Overton Windows… those moments where things break that help move the idea of “change” from unthinkable to sensible.

Some companies are highly unlikely to change. This is due to a combination of the mindset of leaders, the dynamics of the market(s) they’re selling into, the maturity of the product and much more. In situations like this, as a product management team, one option is to accept being in a feature factory (as per ’s point in ’s newsletter recently). And, to be clear, there’s no one right way to run a company, and maybe they can be quite successful for a long time without ever “transforming” at all. Very few companies want to be “transformed” for the sake of it. It’s our job to explain why it’s beneficial in the first place.

However, if there is a chance to change things, you should certainly try. It’s important to build whatever coalition of support you can from senior stakeholders and get used to marginal gains. This is a long game and you’re never going to fix everything at once. Even relatively small companies can turn like tankers. You need to pick your battles, and not burn all of your credibility dying on unnecessary hills.

I call this “applying product management to product management” - pick the most important limiting factor and fix that, then move on to the next one. Maybe you don’t get all the way there, but you’ll still find yourself in a better place than if you didn’t try anything at all.

Addendum: Should anyone be “leading”?

To be honest, my strong opinion is that if you have to worry about who’s “leading” anything, then you’ve got bigger problems to worry about than who’s leading anything If your entire company is aligned around what’s important and how to get there, then anyone could “lead” you there. This is supposed to be a collaboration, not a dictatorship.

If one team “leads” and others don’t agree with where they’re being led, fix that! I generally find that misalignment is one of the most important problems to solve in any struggling company.

Thanks for reading

If you enjoy my content and want to keep in touch, here are some ways you can do that:

• Follow me on LinkedIn

• Join my Slack group

I’m taking a break from the virtual networking and the live meetups to work out the best format going forward, so bear with me!

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions (although I’m considering a cheap, paid tier). In any case, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!

Saeed Khan and I are running a new course for B2B product managers - “Working with Sales - Masterclass for B2B Product Managers”. It’s part of Maven’s “Maven 100” event, and you can get 25% off the ticket price until the end of Sunday 9th June. It’s late notice, I know, but go grab it while it’s hot. Otherwise, grab it anyway!

Ok, on with the newsletter…

I ran this poll recently to see what sort of developers product managers were working with. The results came out differently from how I thought they would, but they got me thinking about the best “type” of developer for a product team.

Credibility Disclaimer: I’ve worked as various flavours of developer before going all-in on product management. I started my career programming green screen dumb terminals before graduating to front-end web development and eventually full-stack web applications.

What is a stack?

Good question! Before we argue about the pros and cons of full-stack and single-stack developers, we should define what a “stack” even is. Not everyone’s a techie after all!

If we keep it simple and talk about web-based SaaS products, we can logically split the application into some core areas, each of which we can consider a “stack”:

• Front-end - all of the stuff that runs in your users’ web browsers and provides them with an interface to interact with.

  • Popular front-end frameworks and libraries include Angular, React, Vue and 150,000 other frameworks that seem to pop up daily. These all ultimately end up as JavaScript in a user’s browser. Some people still stick to raw JavaScript or jQuery (🥰) but most modern product developers will use a library or framework.

  • This code is generally served from your servers, but executed in the user’s web browser. All of the code is ultimately visible and accessible to the end user.

• Back-end - all of the stuff that runs on your servers and deals with retrieving, updating and storing data, as well as the business logic that runs on that data.

  • Popular back-end languages include NodeJS, Java, Ruby on Rails, PHP, .NET and many, many more.

  • The code is hosted and runs on your servers and the front-end will interact with it in a controlled manner, generally through some form of API that gives CRUD (Create, Read, Update, Delete) functionality.

• Database - the nuts and bolts of storing and managing the data efficiently and performantly.

  • Popular database servers include MongoDB, PostgreSQL and many others.

These are sweeping oversimplifications and there are lots of edge cases, but they are sufficient for the sake of argument.

Types of Developers from my Pie Chart

Let’s go back to the categories that I asked about in my poll:

• Full-Stack Developer - a developer who, broadly speaking, has expertise across all of the stacks and can comfortably work on all aspects of a feature.

• Soft Single-Stack Developer - a developer who strongly prefers one stack, but will happily dabble in other stacks if the need arises.

• Hard Single-Stack Developer - a developer who can literally only work on one stack and, in some cases, will actively reject working on or learning about other stacks.

Remember, based on my poll, 22% of respondents work with "Hard Single-Stack Developers”. I’m going to go out on a limb here and say that these people are going to have the hardest time making products.

The Everlasting Feature Request

Consider the following scenario. A product manager needs a new feature developed. Let’s assume that they’ve done all the relevant discovery and scoped the feature as tightly as possible. It’s all down to the development team now!

Not all development will touch all stacks (for example, that annoying broken animation on the submit button is front-end only) but most features will need to touch everything. Let’s imagine that this new feature requires some front-end UI work and needs to pull data in from the back-end to present it in an interesting way. Users can then interact with it and potentially change data on the back-end. All in all, this is a very standard use case seen by product managers across the world on a daily basis.

This product manager is working with a team of hard single-stack developers. This automatically means that this feature is broken into two or three separate chunks of work with totally different people required for each chunk, and everything will be stuck together at the end. The development team needs to collaborate on what needs to be done by whom and the order it needs to be done in. Detailed technical specifications will be written before the work can be started.

The front-end team works on the UI and the back-end team works on the API. After it’s all done, it gets wired up and… oh no! Someone missed something in the specification, or the format of a field is not as expected, or the API endpoint needs to have an additional field added to it.

Whatever the root cause, the application isn’t working as expected and it needs to be fixed. The front-end developer refuses to touch the API and the back-end developer is busy working on something else, so now we have to wait. Everything is blocked but, eventually, the back-end work is done. However, now the front-end developer is working on something else!

The cycle continues for days, weeks or months. Eventually, after several rounds of back and forth, the feature is finally completed.

By the way, I’m not making this up for fun… this scenario has happened to me several times in my career. It’s also totally avoidable.

Why Product Developers Shouldn’t Be Hard Single-Stack

I’m very much in favour of full-stack developers and strongly believe that all product developers should be competent enough across all stacks that are needed to take a feature from end to end.

This doesn’t mean that I want everyone to be a jack of all trades and master of none. Expertise is valuable! Experts can help with the hardest decisions, coach their colleagues on best practices, help with thorny issues and much more. However, if you have developers flat out refusing to touch anything that isn’t “theirs” then this can lead to:

• Product managers getting dragged into engineering management

All of a sudden, product managers need to deeply care about the capabilities of every developer in the team and, in the worst cases, start writing explicit front-end and back-end tickets or assigning work to individual developers.

• Everything slows down due to dependencies and (lack of) availability

If you need multiple people to work on everything then you’re inevitably going to hit scheduling conflicts. This means that every feature you develop will take longer than it has to. You also end up having to over-specify all features because, otherwise, you’re probably getting it back half-baked. Welcome to mini-waterfalls!

• Developers start to understand the entire product less

It’s hard to have a holistic end-to-end picture of how a product works if you’re only working on bits of it. This can lead to suboptimal solutions because one part of the team doesn’t really know how the whole product works, or what it’s used for. In the worst companies, it can lead to blame culture and tension between the teams.

• Developers start to understand the users less

It’s hard to empathise with or understand your users if you are disconnected from them. This is something that, to be fair, can affect back-end and database teams more than front-end teams, although I’ve found that all of them can suffer from this to some extent. In any case, this lack of user understanding can make it hard for engineering teams to come up with delightful solutions to their problems.

How to Fix It

Well, ultimately, product managers and even product leaders aren’t generally responsible for technical hiring decisions, but we can certainly make a case for what’s not working.

• You need good Engineering Managers

I mean, all companies should have good engineering managers, but they’re even more critical in companies with hard single-stack developers. These engineering managers can help bridge the gap between teams, resolve dependencies, and ideally help to shift attitudes. The engineering manager should be comfortable talking about and working with all stacks. Work with your engineering leadership to get the right managers in the right teams.

• Product Managers should focus on the user requirements

In hard single-stack situations, it’s very tempting for a product manager to start deeply caring about who needs to work on what. They may even start writing back-end tickets and front-end tickets. God forbid, you might even have “As a front-end developer…” bastardised user stories.

This is not a product manager’s job! Your job is to focus on the user requirements. Developers can deconstruct these requirements as they fit and write as many tickets as they need to manage their work internally. Remember, product managers aren’t responsible for managing developers.

• Factor dependencies into your planning

All estimates are fallacies, and hard single-stack estimates are even more so. There’s no getting away from it: If you have so many hand-offs in your development process then you have to assume that everything’s going to take way longer than even a pessimistic estimate. Keep your scope as tight as possible and, if pushed on dates, go longer than you expect.

• Get ALL the developers into some customer calls, or at least show them the videos

To be honest, even the hardest-hearted “headphones on” hard full-stack developer still has the same fundamental human desires as the rest of us. I’ve seen many an engineering team visibly delighted when watching real feedback from a real user who loves the product. When you’re stuck in one stack, it can be hard to empathise, so give them every chance to.

• Make a case for team change

To be clear, there’s nothing wrong with having a few hard single-stack people, but only if they’re experts in a certain thing that you need experts in. Remember, expertise is good! But, ideally with the support of engineering managers and the CTO, you need to make the case for change.

Every hard single-stack developer you have will slow you down. Do make sure to keep track of when things fall apart, not to name and shame people, but to help build a case for change. At the very least, try to start nudging those hard single-stack people into the soft column!

Podcast episodes catch-up

Here are a couple of podcast episodes to catch up on:

Firstly, I spoke to John Cutler about the Instagram-ification of product management, and how we’re all being made to feel bad by impossible standards and should make peace with product management instead.

This is a subject that’s dear to my heart and I definitely recommend listening to this one on your favourite podcast app, the podcast website or YouTube:

Secondly, I spoke to Nils Davis about product management resumes/CVs and how people aren’t showing their best side to recruiters. In this job market, putting your best foot forward is essential.

Check the episode out on your favourite podcast app, the podcast website or YouTube:

Thanks for reading

If you enjoy my content and want to keep in touch, here are some ways you can do that

Follow me on LinkedIn

Join my Slack group

Join my Virtual Networking weekly calls

Join my real-life London meet-ups

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions (although I’m considering a cheap, paid tier). In any case, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!

“Even if something is not quantifiable, and the impact is unknowable, does not mean it is not the most important thing right now. This is a crucial lesson for prioritization. There are many good PMs and product leaders out there who forget this.“

This post made me think for a couple of reasons. The first reason it made me think is that I broadly agree with the central point.

The second reason this post made me think is that this statement could be used to justify doing literally anything.

Let's dig into it. But, as you grab your shovel, do make sure to subscribe if you’re not already!

Subscribe now

When Product Managers Stop Making Progress

I’ve seen a few situations in my career where product teams seemed caught in analysis paralysis, unable to make a meaningful move, circling the airport but forgetting to land. This leads to escalating tension between product managers and business stakeholders as well as probably dissatisfied customers. The product management team is seen as “the place where good ideas go to die”.

A secondary effect is that, eventually, the CEO or some other leader ends up HIPPOing a solution onto the roadmap and everyone complains (but is secretly quite glad that they know what to work on now).

Sometimes you’ll have great information and can proceed with confidence. Sometimes you will indeed need to take a punt on something with unclear chances of success. But what stops product managers from doing this?

• Lack of Product Strategy

It’s hard to know where to place a bet if you don’t know what you’re aiming for or how you’re trying to get there. It’s not exactly a surprise that many companies don’t have a strategy at all, let alone a product strategy. Product managers know that they should be doing something to get away from randomised feature requests and top-down feature edicts, but they don’t know what. In some places, they’re actively prevented from doing so.

• No Usable Data

In an ideal world, product managers should have data at their fingertips to enable fast decision-making. It’s a lot easier to decide based on data if you don’t have to go and get the data before making a decision. This data could be quantitative usage data, market research, customer research, competitor analyses or any number of other potential inputs. If you don’t have it, you can’t move forward with confidence, and if you don’t have confidence, maybe you can’t move forward at all.

• Past Product Trauma

Part of this lack of confidence may simply boil down to the fact that the product management team tried to do something before and it went horribly wrong. They built a big feature on an educated guess, spent months building it, released it and had nothing to show for it. Often, in situations like this, the product team are the ones left carrying the can.

• Fear of Repercussions

In psychologically unsafe organisations, this can lead to blame and repercussions. We often hear of learning organisations and being able to take risks, but there are many organisations out there that seem to have zero risk tolerance. Everything has to be a slam dunk. If you didn’t get it right last time, you’re going to get judged, blamed and maybe even fired.

• Product Management Purism

Or, maybe your product managers are so addicted to all of the classic product management books that they simply don’t believe they can do anything without following the recipes inside. This is an interesting one because I’m pretty sure most of those authors would not advise being so dogmatic in all circumstances. However, particularly in low-functioning product cultures, it can be incredibly comforting to fall back on what people think are best practices.

• Undertrained Product Managers

I’ll choose my words carefully here because I don't believe in “bad” product managers per se, but there are a wide range of skills, mindsets and appetites across product management teams. This is, of course, exactly the same for any other profession too! In situations like this, product leaders have a strong responsibility to coach and mentor their teams and help with better decision-making.

Making Progress Responsibly

As mentioned earlier, the problem with “Even if something is not quantifiable, and the impact is unknowable, does not mean it is not the most important thing right now” is that it can be used to justify literally anything.

All product managers have horror stories about that one feature they spent too much time on that didn’t make a difference, the CEO’s vanity project that didn’t pay off, or the speculative integration that would unlock an entire market segment that unlocked precisely zero market segments.

The issue here isn’t that we shouldn’t think big or overanalyse. I generally recommend that product managers start Thinking in Bets. There’s no binary "good idea” versus “bad idea”, just a probability of success. This probability could start low or start high. But it’s sure easier to put all your money in the pot if you’ve got a good starting hand.

The difference between a world-changing invention and a dud vanity project is, at the beginning at least, zero. You can win a game of Texas Hold’em with any two starting cards, but most people don’t go all-in on a 2/7 offsuit.

Here are some things to try:

• Try the sniff test

There’s always room for gut feel in product management. Ultimately, does an idea make sense on its face? Based on what you know about your product, market and customers, is this thing stupid or not? Discuss it with your colleagues! You can also happily use ChatGPT, or your LLM of choice, to bounce some ideas back and forth as a kind of DAaaS (Devil’s Advocate as a Service). I wouldn’t bet a billion dollars on a sniff test, but I would be a lot more confident proceeding further with something if it just feels right. There is, of course, a danger here… some people are just massively overconfident in everything. There’s a lot of unconscious bias that could creep in here. But still do the work.

• Identify assumptions

Whilst thinking this through, you should be furiously writing stuff down. One important thing to write down is a list of assumptions that must be true for this to be a good idea. There are many good ideas that have a load-bearing assumption that, if not true, would make everything collapse. Look at these assumptions. Which are the riskiest assumptions, the things that must be true, and which are kind of irrelevant to the success of your initiative? How can you test them?

• Use what data you do have

If you have any data at all, look at it and try to find anything that proves or disproves your hypothesis. Again, this could be quantitative data, customer feedback, discovery interviews, industry reports, requests from the sales team, or anecdotes from a meetup you went to. You need to weigh the data accordingly and not treat absolutely everything as gospel, but anything is better than nothing. You’re looking for signals.

• Build the smallest thing you can (so you know whether you should build a bigger thing)

You may still find yourself with very limited information, and no real justification to build whatever you’re thinking of building. Maybe the data’s just not available. Maybe the thing you’re thinking of doing is so cutting-edge that it’s impossible to know until you see it. That’s OK, you can still make a bet but the crucial element here is the size of the bet. Putting a billion dollars and 12 months of engineering time into something is a whole lot more palatable if you know it’s going to be a guaranteed success. But nothing’s guaranteed success, so start small. Run experiments. Get prototypes in front of people. Build something, but just not everything. Test the water with a smaller bet so you can make a bigger bet with confidence.

• Avoid the sunk cost fallacy

As with Texas Hold’em, you need to know when to go all-in and when to fold the hand. You can’t win them all, and it’s lunacy to throw good money after bad. In the past, I’ve seen product and engineering teams get disappointed that “our hard work is being thrown away, what a waste of time!”, but this is only true if you didn’t learn something along the way. Building a small thing to see if you should build a big thing only works if you are prepared to not build the big thing.

And, besides, there’s always another Next Big Thing to sink your teeth into!

Overall, as with everything in product management, it depends. Good product management is as much an art as a science, and there’s no formula that guarantees success. As product managers, it’s our job to make forward progress for our customers and our companies, not just sit around looking at the floor. It’s important to be comfortable with ambiguity, react to new information and make bets from time to time. Just make sure you bet responsibly and know when to fold.

One Knight in Product - Hot Takes edition

I’ve released my first “Hot Takes” episode with returning guest Debbie Levitt. You may remember her from a few weeks ago when she was explaining how Continuous Discovery is destroying the craft of UX Research. Now she’s back to talk about her fears that, if we’re all doing each others’ jobs, we’re just making it easier for AI to replace us sooner.

You can check the episode out audio-only on your favourite podcast app or grab it here. Alternatively, you can check the episode out on YouTube via the embed below.

If you would like to have a chat about your hot take, head over and grab an interview slot. I’d love to chat about whatever’s on your mind and get you in front of my audience!

Deep Dive into Fractional Product Leadership

I wrote my own article on this topic in this very newsletter, but recently reached out and asked if I’d like to collaborate on one for his much larger newsletter. Unlike my article, we interviewed a collection of fractional leaders from around the world and synthesised it all into one mega-article. Some of it’s free, and some of it requires a subscription, but do check it out if you are interested in fractional work!

Product Growth

Fractional Product Leadership: Your Step-By-Step Guide

It might be the hottest job in the product world right now - the fractional CPO. On LinkedIn, it seems like just about everyone wants to be one. But few know how to become one. At least sustainably. It might seem obvious that you could get 1-2 clients from your network. But a consistent pipeline…

Read more

2 years ago · 32 likes · Aakash Gupta and Jason Knight

My appearance on the Go-To-Market Strategist Podcast

Speaking of fractional work, I also recently had the chance to speak to my friend and former podcast guest on her very own podcast. You may remember Maja as the author of “Go-To-Market Strategist” the book. We spoke about moving from full-time product leader to being a successful consultant, and a lot more besides. Check it out on your favourite podcast app, get it here or at the Apple podcasts link below.

Thanks for reading

I checked my “Pocket Saves” and found out I haven’t really bookmarked anything over the last week, so you’re stuck with my content alone. If you actually enjoy being stuck with my content, here are some ways you can keep in touch:

Follow me on LinkedIn

Join my Slack group

Join my Virtual Networking weekly calls

Join my real-life London meet-ups

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions but, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!

Build versus Buy

You’ve probably all been in this scenario:

1. You’re busily building some cool new stuff that’s going to help your company hyperscale (maybe, possibly).

2. Some orthogonal requirement comes up for some supporting tech or platform that you don’t have (examples I’ve seen include: SSO, analytics platforms, taxonomy management systems and entire BI suites!)

3. There are off-the-shelf solutions that do most of the job, but no one seems to be prepared to invest either time to investigate them or money to buy them.

4. A random stakeholder brings up a niche edge case that no off-the-shelf platform could ever handle (and we’ve always done it like that here).

5. Eventually, someone pipes up and says “Hey, let’s just build it ourselves! How hard could it be?”

You can probably guess what happens next. While you’re guessing, consider subscribing so you don’t miss any more issues of this newsletter:

Subscribe now

Why Building Seems Like a Great Idea

We all love building cool stuff. For many of us, that’s why we got into this game in the first place. Whatever it is we’re building for whatever problems we’re solving, building things is simply what we do. So, when it comes to deciding whether to build some new capability, we might default to rationalisations like:

1. How hard could it be?

I mean, seriously! We’ve got loads of great developers, and we’re building all this other cool stuff, and this new thing is pretty straightforward, and we can probably just squeeze it in.

2. Building stuff is fun!

We’ve had some developers working on some tech debt or re-platforming for a while and they’re kind of bored of that, plus we can finally start learning about graph databases now. And who doesn’t love a greenfield project? Hey, maybe we can finally try setting something up in Kubernetes.

3. It’ll be cheaper!

“Build” discussions often don’t come with new, fully loaded development teams as part of the package, so you’ll likely be working with existing teams. And, hey, we’re already paying those people. They can just fit it in! And that commercial SaaS is really expensive and our CFO will never sign it off anyway, so we might as well not ask.

4. We have such unique requirements!

Every company is its own special flower, and it’s impossible that any generic, mass-market solution could ever contain our multitudes! We absolutely need doohickey X and widget Y to work exactly as we want, otherwise it won’t fit into this legacy operational process that we absolutely can’t change, even though no other company in the universe works like that.

5. We maintain complete control!

Why would we offload all this stuff to some faceless nobodies at some company where we’re just 1 of 10,000 customers, even though we expect our customers to do exactly the same thing with us? And, hey, if our requirements change, we don’t need to get onto anyone’s backlog; we can fit any changes into the next Sprint.

Why Building is Probably a Bad Idea

Building isn’t definitely a bad idea. There are some reasons it might make sense, but you should bear a few things in mind:

1. Everything’s harder than it sounds

It doesn’t matter how easy you think something is… the reality is always harder. There’s always room for positivity and a “can do” attitude, but think about whatever solution you currently offer to the market. Imagine someone needed that and decided to build it themselves. Knowing what you know about your product, would you recommend they do that? Now imagine asking a vendor-side product manager the same question.

2. You should be building other stuff!

Presuming that you’re not staffing up an entirely new development team to handle this new work, which will almost certainly be more expensive than the SaaS subscription you’re trying to avoid, you’re doing this work with existing people. That’s great, but shouldn’t these people be working on something else that delivers direct value for your customers? What’s getting left behind?

3. Once you’ve built it, you have to maintain it

The problem with “easy” solutions is that you soon start to reach the limits of what they can do. If you’re rushing it through as a side-of-desk project, people are going to cut corners. If it’s using technology your team has had to learn on the spot, they’re quite likely to have missed something important. There will be servers to maintain and patches to patch and library upgrades to upgrade. No software is one-and-done.

4. Your version is probably going to suck

One of the biggest advantages of paying a company that builds this sort of thing for a living is that they build this sort of thing for a living. I’ve seen some “build” efforts take 6 months or more. The end result is, at best, a platform that’s functionally equivalent to the commercial platform you’re avoiding using… but functionally equivalent from 6 months ago. Meanwhile, they’re still building, iterating and improving based on feedback from a vast array of customers. Aside from your special, niche use case, you’re never going to catch up.

5. With control comes expectations

I’ve never seen a single “build” solution that did all the things it needed to do forever. There’s always something that either got accidentally missed, purposefully left out, or was never a requirement but now absolutely is. Maybe some new data privacy legislation came in. Maybe you merged with another company. It’s impossible to future-proof a solution, so you’re going to be committed to enhancing this thing forever.

Should I Build or Buy?

Given the above, and my own long experience of everlasting “build” projects, my general advice is generally to strongly consider “buying” unless:

1. … the thing you’re building is fundamental intellectual property

It’s possible that you are doing something so totally different or crafted to your use cases that it legitimately makes sense to build your own solution. What you want to avoid building are things that are fairly commoditised. It’s perfectly fine to build a general-purpose commodity platform, but it makes a lot more sense if that’s your entire business.

2. … It’s a differentiator for your business and gives you a competitive advantage

Even if you are doing something different, you want the differences to actually help you, rather than boxing you into a bespoke corner. Sometimes it’s worth taking a step back and trying to understand why your needs are different. Are they really, or are you just victims of status quo thinking? That said, maybe existing solutions are really quite bad. If you have really found an edge, it can make sense to press on and build.

3. … The price of external offerings is incredibly high and you have no bargaining power

If there are very few vendors in a particular, uncompetitive space, or de facto solutions that you’re expected to use, you can end up paying quite a premium. It’s also fair to say that no one really appreciates vendor lock-in. I’d argue that, in many cases, you’re still going to save money in the long run with a commercial solution, but some solutions are really expensive for the value they deliver.

4. … It’s something you could potentially sell as a customer offering in future

After all, look at Amazon Web Services! It’s absolutely fair enough to assess the landscape for this new solution and work out if it’s something that could actually unlock value not just for you, but for your customers. Your mileage may vary, depending on the type of thing you’re building or buying, but it’s important to take a big-picture view and try to understand if your “build” is the first stage in a true product offering or just an internal cost of doing business.

These days, there are a wide variety of commercial options out there to cover most use cases. If yours is so unique and you have no other option, build away! But, be careful.

A bonus tip is to consider “buying” a platform that covers the majority of your work but has an SDK, API or other integration capabilities that allow you to build your legitimately special stuff. This gives you the best of both worlds, and you can still use the standard functionality for the vast majority of use cases.

Please Fill In My Course Survey

Saeed Khan and I have gotten great feedback on our B2B product management course, but some people are asking for something a little more targeted.

Because of this, we're considering launching a shorter course focused entirely on "Mastering the Relationship between Product Management & Sales"

If this sounds like the sort of thing you might be interested in, please help us shape the course by filling in this short survey. There’s no obligation to attend, but we’ll let you know when it’s live and also offer you a tasty discount if you decide to sign up for the course proper.

Exciting, Thrilling Podcast Updates

My first exciting, thrilling podcast update is that I have a new episode that I recorded with Denise Tilles and the returning Melissa Perri. They both co-authored “Product Operations”, a relatively new book that you can probably guess the topic of. We spoke all about the book, why PROCESS is seen as such a dirty word, and how you might start getting a Product Operations team set up.

This episode is also a benchmark because it’s the first time I’ve recorded with video! Yes, now you get to see my face and the faces of my disappointed guests as they wait for me to finish my questions. Check out the YouTube channel, but never fear audio lovers! I’m also still available on your favourite podcast platform and the podcast website.

My second exciting, thrilling podcast update is that I’ve started experimenting with a new podcast format. When I started out the podcast, I intentionally cast my net far and wide to get all different sorts of people on from all over the world. That’s been great, but it sure is easy to get starstruck by all these authors who I know these days. In an attempt to rebalance, I’ve started up “One Knight in Product: Hot Takes” - super-focused, super-targeted 15-minute episodes on one topic with all comers. Don’t worry, I’ll still do the big names too, but this additional format helps me go wide again.

The first episodes will be dropping soon but, in the meantime, if you have a hot take you can grab a recording slot.

Some of my other content

Here are some things I’ve written or been involved in from the few weeks since my last newsletter (I’m trying to get into the writing habit more, I’m trying!):

My video interview with Mark Long from Numi- we talked all about fractional leadership and my own journey

Product Conversations: Differences in Product Management - a round table video chat I did with Product Growth Leaders about the differences between B2B, B2C and B2B2C.

Your first "I'm a consultant now!" post is always your most popular - the trouble with extrapolating consultant/market fit from your announcement post.

"We think strategically but we act tactically" - how people get prevented from doing strategic work, but why they should do it anyway.

What you want/What leadership wants - how to start thinking about driving change in your organisation if things aren’t they want you want them to be

Book Recommendation: Flawless Consulting - I really enjoyed this book, and recommend it both to consultants and anyone trying to affect systemic change.

Front-load your presentations - if there’s something that you know people are going to complain about lurking in the middle of your presentation, consider putting it right up front to get it out of the way.

Other People’s Stuff

Here are a few other things I’ve seen around and about in my travels that caught my eye.

How does ChatGPT work? As explained by the ChatGPT team - an excellent article from going deep on how our new robotic overlord works under the hood.

The Humane AI Pin: A Case Study in Poor Strategy and Poor Execution - crappy AI products that are more hype than substance are all the rage at the moment. Dare Obasanjo goes deep into what went wrong.

Why it's time to update our language about bad design patterns - it’s important to avoid manipulative design patterns, but let’s not call them “dark” says Amy Hupe.

Count the Digits - Numeric prioritisation frameworks can be a mess, but sometimes you need something to get started, and Rich Mironov recommends getting dirty and imprecise.

The Man Who Killed Google Search - I found this article by fascinating - a deep dive into the product decisions that can enshittify once-mighty products.

Your strategy (probably) sucks - Martin Eriksson has worked with hundreds of companies, and so many of them don’t have any strategy at all. What should they be doing differently?

Playing to Win & Agile - I’ve been reading a lot of strategy stuff these days, and I came across this interesting article by Roger Martin (Playing to Win) about whether “strategy” and “agile” are mutually exclusive.

Thanks for reading

As ever, it's been a pleasure. Here are some ways you can keep in touch with the conversation:

Follow me on LinkedIn

Join my Slack group

Join my Virtual Networking weekly calls

Join my real-life London meet-ups

If you have any comments, questions or complaints about this newsletter, please feel free to reach out! The same goes for any topics you’d like covered in future issues.

I’m still averse to charging for Substack subscriptions but, if you find my work valuable, please consider a one-off or recurring donation.

Thanks!

Stop Contributing to LinkedIn Collaborative Articles!

This is the best-performing post (in engagement terms, at least) that I’ve put on LinkedIn for a while, and it’s got nothing to do with product management. Typical!

I stand by the post though. LinkedIn collaborative articles are, for the most part, trash. That doesn’t mean that some of the responses to these articles don’t have any merit… there are some very smart people on the hamster wheel! I just wish they were writing it somewhere of their own.

People are like “Well, won’t ChatGPT scrape your content anyway?” Yes, probably (unless it honours robots.txt as it should). But, my analogy is simple: You can either go on Safari and accidentally get eaten by a lion, or you can make the decision to climb into its mouth yourself. In any case, there’s plenty of spirited debate in the thread on that post!

(Professional) Services vs Products

I was recently asked, “What is a product?”. As per product manager tradition, I immediately jumped out of the window to avoid answering the question.

After dusting myself down, I thought about this. I’ve worked with a bunch of organisations of various states of product maturity, but some of them have really been service companies in disguise. I generally believe that a good predictor of this behaviour is whether they refer to “customers” as “clients”

• Customer (n) - someone who wants to buy a thing you make

• Client (n) - someone who wants you to make something for them to buy

This doesn’t work in all languages (Latin languages use the same word for both), but I’ve not yet seen an English-speaking product company that refers to “clients” that didn’t also exhibit poor product management hygiene.

This is not to say that there’s anything wrong with being a service-mindset company. There are plenty of those out there and many of them are pretty successful. The issue isn’t that service companies are “bad”, it’s just a lot harder to scale them unless you add more and more people (or charge exorbitantly high fees). The unit economics just don’t work out, which becomes a problem when your leadership team thinks that they should.

I came up with a natty little chart to try to get this straight in my head, and the idea of:

• Products: Repeatable, standard things that everyone buys basically the same version of (maybe with customisation that they can handle themselves or, of course, different packages within the main product).

• Service-Enabled Products: Fairly repeatable, standard things that maybe have some services around them (implementation, value-add thought leadership, people stuff that is hard to fully automate).

• Product-Enabled Services: Much more manual, with an expectation of humans in the loop. The focus becomes more on how you can use technology to make your professional service engagements more scalable. You may also consider companies that have to do lots of custom development for “clients” as part of this bucket.

• (Professional) Services: There was some confusion here because the chart said “Services” and SaaS also means “Services” - but I’m not talking about the cloud-based delivery model, but the fact that every single engagement is bespoke and for an individual client.

Knowing where you are on this scale can be useful to understand where you are, and where you’re going, and start to make you think about what you might need to do to get there. Again, there’s nothing wrong with being a professional service-mindset company… but you’re in for a shock if you think you can do that whilst charging product-mindset fees for your services.

New Podcast Episode: Knowing your Customers, Seeking Evidence and Sticking up for Continuous Discovery

I’ve been off the podcast train for a few weeks since releasing my 200th episode with Marty Cagan about 10 minutes after Lenny released his episode with Marty Cagan. I’ve heard mine is pretty good though 😎

In any case, I recently interviewed Hope Gurion, a fearless product coach and one of the people that Marty calls out in Transformed as an example of the sort of person he recommends. High praise indeed!

We talked all about coaching, the importance of defining your customers, the need for evidence in decision-making, and her take on the recent controversy around continuous discovery. Is it really killing off user research as a profession? Hope works closely with Teresa Torres, so she has an opinion!

Check out Hope’s episode here.

You can also check out my older episode with Teresa Torres over here, where we talked all about Continuous Discovery Habits. I also recently interviewed Debbie Levitt, who was at the forefront of the user researcher backlash, and you can check that episode out here.

Some other posts and links of interest

My stuff:

• Faux-KRs: Not everything has to be an OKR - you don’t need to torture the framework

• Acceptance: Why Product Managers sometimes quite like being told what to do

• Marginal Gains: Why it’s important to get comfortable with small changes in a transforming organisation

• Non-negotiables: Why it’s important to understand what the big boss won’t budge on before trying to make them budge

• B2B2C: What the heck is it? And is it just as problematic for product people as B2B?

• Working Small (however you define “small”) is always better than working big

Other people’s stuff that I found interesting:

• When Will the GenAI Bubble Burst? (by )

• Top 10 Cognitive Biases in Product Design

• Things I did as Mural’s Chief Product Officer

• The Messy Reality Behind a Silicon Valley Unicorn

• 4 Ways to Productize Without A Large Tech Investment (by former podcast guest Eisha Armstrong)

That’s all folks

I’m going on holiday to Sherwood Forest for a week with the family. I’ll try to avoid the temptation to make too many Robin Hood product management analogies when I get back!

I love to give stuff away for free, and supporting the community is my passion. As part of that, I run a free Slack community… come along and join! We also do weekly virtual meetups and occasional real-life meetups.

If you’d like to support my work, please donate here.

The company has gone through product leaders at a fast pace, each one coming in with high hopes and, ultimately, failing to make a substantial difference to the company’s fortunes. The product remains uninspiring and no one’s really that happy. Each product leader eventually got jettisoned and replaced by a slightly different type of product leader (the marketing-focused one, the tech-focused one). The circle of life continues. Rinse and repeat.

My friend looked at me conspiratorally and said “You know what? I think the leadership team are starting to realise it’s not the product leadership that’s the problem”.

This isn’t the first time I’ve heard this story about one company or another, and I’ve started to refer to this phenomenon as “rake-setting”.

If you’re up-to-date on your Simpsons (and by up-to-date, I mean that you’ve watched a 20-year-old episode), you’ll remember the scene where Sideshow Bob keeps treading on rakes whilst trying to hatch his dastardly plan. He’s set up to fail, and fail repeatedly, with painful consequences.

Product leaders are set up to fail all the time. It doesn’t mean that they can’t succeed, simply that they’ve had a selection of rakes placed around them, each begging to be stood on to hilarious effect. Some of these rakes include:

• A no-questions-asked “next deal always wins” sales-led mentality.

• An overreliance on subject-matter experts who “just know” what customers want.

• Assuming that whatever your biggest customer wants is what all the others want.

• Assuming that, somehow, your sales team are coincidentally talking to prospects in the same order that you should prioritise your roadmap.

• Refusal to allow the product team anywhere near customers.

• Hiring a product leader to “optimise engineering” and keeping them at arm’s length from “the business”.

• Imposing way too much process way too soon and wondering why everything’s ground to a halt.

Now, you might assume that a skilled product leader will manage to win backing from the leadership team to start putting some of these rakes back in the shed where they belong. And, in many companies, they can! In many others, there is little to no appetite to do anything at all. Or, there’s an aggressive, intentional effort to keep these rakes on the ground. The product leader keeps getting hit in the face, eventually fails, gets replaced by another product leader with a slightly different skills mix, then that leader fails, and so on.

I’m sure there are many more rakes. I’d be interested to hear yours! In the meantime, please watch where you’re treading, and good luck out there.

Transforming your Organisation to the Product Operating Model (with Marty Cagan)

Marty Cagan has a new book out and I was delighted to get him back on the podcast to talk about it.

I had Marty on the podcast a couple of years ago to speak about Empowered. It was one of my earlier episodes, and it’s a fun story of how we got that together, but give it a listen if you want some retro joy.

The new book is called Transformed and is all about… transforming! Specifically, transforming to the “Product Operating Model' - yes, they’ve finally named “the way the best companies work”. Inspired and Empowered were very much written for product teams in product companies, whereas Transformed is an attempt to bridge the gap between legacy organisations and well-functioning product organisations.

Obviously, Marty has a lot of fans, but also a few detractors. These people complain that he’s unrealistic, setting too-high standards, or demotivating people who don’t work for companies like that. Personally, I think standards are great, but I also accept that not all companies will get there. Sometimes it’s a case of marginal gains and improving what you can. I still believe in the standards though, and those standards are based on principles that we should all aspire to.

Check out the episode here!

The PM isn’t the Boss of the Team

One thing that is always a good predictor of how well-functioning a product team you have is whether the product manager is the de facto boss of the team. It is true that the product manager should generally get to decide what problems to solve, and the order in which to solve them. But, that doesn’t mean they get to throw their weight around. This is a collaboration of peers!

As ever, I consider this a product leadership problem. A product leader who tolerates this is either saying:

• This is exactly how I want you to work

• I don’t want you to work like that but I can’t fix it

Neither of those is a great look for a product leader. Whilst accepting that there may be many rakes placed in our way, we should always look for ways to involve our cross-functional partners as equal peers rather than throwing specs over the wall at them. If you’re a product leader who believes that’s the way to work, please get someone in to help you out.

That’s all folks

I love to give stuff away for free, and supporting the community is my passion. As part of that, I run a free Slack community… come along and join! We also do weekly virtual meetups and occasional real-life meetups.

In the meantime, I hate charging for things but, if you feel like supporting my work, you can donate here.