Do you want to win arguments or solve problems?

Hey I’m Ant and welcome to my newsletter where you will find actionable posts on topics related to product, business and leadership.

You might have missed these recent posts::
- Building Effecive Product Roadmaps
- Long Backlogs and Unmeasurable Work
- Break Outcomes Down, Not Initiatives

My day job is helping companies shift to a Product Operating Model.
My evening job is helping product people master their craft with Product Pathways.

If video is more your thing, check my Youtube channel out!

---

“Do you want to win arguments or solve problems?” - Rory Sutherland

You’ve gotta love this quote from Rory Sutherland.

With so much noise in the product industry today, it couldn’t be more relevant.

You don’t need to go far to see comments like "that's not real product management", "that's not agile" or [insert practice X].

While I do believe there’s a place for inspiration and increasing our exposure to what’s possible.

It’s not going to solve any problems.

For example, while we can all agree that big, upfront, 12-week discovery cycles are not very agile, they’re better than no discovery at all!

And that might be the current state - no discovery.

So, while it’s great to inspire the organization to do continuous discovery, telling them they’re doing it wrong doesn’t help.

What is ‘right‘?

It can be easy to criticize certain practices.

We saw this a few months ago when Brian Chesky made significant changes at AirBnb (I won’t go into it for those who haven’t heard yet. You can watch his interview with Lenny below if you’re interested).

But while it may be jarring to hear something that you couldn’t imagine working, it doesn’t mean that it’s somehow ‘wrong.’

The more different companies I see, the more I see their nuances and challenges of trying to solve ABC challenges whilst working within XYZ constraints.

It’s led me to the conclusion there is no right or wrong - there are just choices.

Choices to optimize for something over something else, to prioritize something, or to choose not to do something.

You’d be surprised how many CPOs I’ve spoken to who would love to have product designers on every team but just don’t have the budget or are dealing with other constraints that have forced them to make a tradeoff.

I applaud those like Brian Chesky because he’s making a deliberate choice.

If you really think about it, it's simply a ‘Big Bet’ for the company on how it should function.

And I’ll take deliberate intention (regardless of the choice) any day over no decision.

In fact, Roger L Martin, author of Playing to Win, would argue that defining how we want to work is a core part of your strategy - and I would agree with him.

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

So, in a sense, he's simply doing what a CEO should - defining the strategy for the company.

Solving problems

Change is seldom revolutionary.

Rather, it’s incremental, small steps over time.

We can’t expect a company to go from no discovery to continuous discovery practices overnight.

That would be like having a theory lesson on swimming and then jumping into the deep end.

We also know that there are no silver bullets in the product.

Product is inherently complex and uncertain, which makes every company, team, and industry different.

This is why I’ve recently started using terms like “common practice” rather than “best practice” and framing things as pros and cons - because nothing is perfect.

Of course, I still have my own preferences, biases, and strong opinions (loosely held).

But I learned the hard way the mistake of trying to win arguments.

I used to hate stakeholder management, and this meme pretty much sums up how I felt about it.

My distaste for Stakeholder Management early in my career made me view stakeholders as adversaries that I had to challenge and say ‘no’ to rather than partners to collaborate with.

The best advice I got was to treat stakeholders like your users.

To build empathy with them.

This completely changed my approach.

Could you imagine arguing with your users about what problems they’re facing or how they should be using your product!?

You wouldn’t (I hope!).

It should be the same with your stakeholders. The goal isn’t to win arguments, it’s to work together to solve customer and business problems.

Your job isn’t to be an order taker, but nor is it to flat-out say ‘no’ to everyone.

So, as annoying as it is to have a stakeholder come to you with feedback or a suggestion - the best response is to be curious.

Approach it as an opportunity to learn something. Unpack the underlying assumptions, experiences, information, and beliefs that have led them to their conclusion.

In doing so, you will be in a far better position to influence - and who knows, you might learn something important!

Actionable Insights

Are you trying to win arguments or solve problems?

I often ask myself this.

Consider the next time you’re in a disagreement with a stakeholder or peer.

Let’s say that the stakeholder is pushing something that you don't agree with.

We could try to win that argument and dig our heels in.

Or we can shift gears and start problem-solving.

We could start to unpack:

• What does the stakeholder know that you don’t?

• What beliefs, assumptions, etc, have led them to that conclusion?

• What do I know that they might not that has led me to a different conclusion?

• How might break the tie and find a way forward (even if I don’t fully agree with it)?

Finally, are you also considering HOW you work as part of your strategy?

I really liked how John Cutler framed it in a recent post of his;

“leaders ignore ways of working as a potential differentiator. They are too quick to assume that ways of working spring from hiring (or not hiring) "the best", instead of a set of capabilities you can support, grow, and strengthen.” - TBM 281: Stop Chasing Unicorns, John Cutler

Or as I like to say: “People can copy your product but they can’t copy the way you do product”

That’s it for this week—it's a bit of a different one. It's a bit about product, a little bit about business, but largely a leadership post.

I try to embrace this mentality every day as a Product Coach.

My goal is to partner with my clients to solve THEIR problems.

This means setting aside my biases and building empathy for your unique context.

So, if you're looking for a playbook, I'm not your person.

But if you're looking for someone to help you navigate your unique context, then hit me up!

---

Top Posts