My favourite mistakes

Having been in product development for just shy of two decades I've made my fair share of mistakes, and then probably made a few more. Some have been small and barely noticed, others larger and more costly. But each mistake has been a valuable learning experience, and I wouldn't be where I am today without them.

In this article, I want to share my favourite mistakes - the ones that have taught me the most and have had the greatest impact on my development as a product practitioner and leader.?

Whilst the main contributing factor in drawing up this list was the breadth of my experience - being able to compare and contrast different ways of working, team dynamics, cultures, and organisational approaches - I’ve also sprinked in a few articles that either influenced my thinking, or articulate the challenge way better than I could.

Here we go:

Building the thing without asking why

One of the most common mistakes product teams make, and indeed organisations as a whole, is to jump straight into building the thing without first understanding why it's needed, if at all. It's easy to get caught up in the excitement of creating something new, but without understanding the problem you're trying to solve it's unlikely that the thing you build will get you closer to your desired outcomes.?

I look back on the early stages of my career and all the things that the teams I worked in built, and it pains me to think how little discovery, scrutiny, and challenge was afforded to an exec’s random idea, or a single client’s suggestion raised by the most vocal account manager, or the next sales prospect’s must-have, or the thing that we’ve already sunk three months into.

This is less about continuous discovery and more about being constructively relentless in challenging whether you are doing the highest value thing, or whether a thing even needs doing at all.

Practically all of the A-list people I’ve worked with - regardless of employer, specialism, or seniority - have all reached the same conclusion, although the penny can drop at any time during a career: It isn’t about what you choose to do - it is what you choose not to do.

• An Introduction to Modern Product Discovery Practices, Teresa Torres (2016)?
• Why you should stop using product roadmaps and try the GIST Framework, Itamar Gilad (2018)?
• The Lure of New Features and Products, John Cutler (2020)?
• Where Product Ideas Come From, Laura Klein (2020)?
• Enough With Must-Have Features, Itamar Gilad (2021)
• Pledge to Customers, Marty Cagan (2022)
• Making Room For New Things, John Cutler (2022)

Fighting over role definitions

One experience that sticks with me: an hour-long, horribly awkward meeting with my “opposite number” of another specialism. A “mediator” was present and we worked through a list of “responsibilities”, negotiating and trading who owned what as if we were a poor man’s Reagan and Gorbachev fighting our own crappy Cold War. It blows my mind.

Once you accept that the only way to do things well is to embrace shared responsibility, you feel liberated. It all pales off into insignificance. It doesn’t matter who creates the goddamn Jira ticket.

This influenced me to write my team characteristics article and to temper my core roles article. The whole is greater than the sum of its parts, and any conflict relating to roles and responsibilities will just slow you down. There is no need to be precious. Empire-building will never, ever help your organisation win.

• Design the Team You Need to Succeed, Christina Wodtke (2017)
• The T-Shaped Product Manager, Roman Pichler (2017)
• How to facilitate a team roles and responsibilities workshop, Monica Viggars (2019)
• Mandate Levels, John Cutler (2021)
• Product development guiding principle: The basic unit of product development is the team, not the individual, Jason Yip (2022)

Assuming that what users asked for was what they actually needed

Permit me a cliché moment (sorry, not sorry):

“If I would have asked people what they wanted, they would have said faster horses.” Henry Ford 1909

Although he mightn’t have actually said this, it rings true a lot of the time. Probably most of the time in my experiences. People do not necessarily know what they want even when they think that they do. They certainly don’t know what will move you towards your outcomes, and even if they did, they may struggle to articulate the problem that they need to overcome. And asking them what they want can worsen matters, cajoling them into a sweetshop mindset that only serves to generate noise.

I know that the Google Docs iOS app falls over if you change orientation whilst viewing a really lengthy document (70k+ words). I could ask them to fix this. Ten years ago I would have been compelled to do so. Now I am almost certain that this would fall on deaf ears or, worse still, would distract the team(s) who work on Google Docs from focusing on the things that will really move the product forwards.

Study your users in the wild. Analyse your performance data. If users, or anyone else for that matter, asks for something, ask them (or failing that, yourself) “why?” several times - five is a good number. Please do not build things just because people ask for them. We owe it to ourselves not to misdirect the passion and expertise of our peers on such low-return investments. We owe it to our users not to make their experience worse by focusing on the wrong thing and distracting them with things that they don’t need.

In my early twenties in B2B-land I once wrote a 20+ page specification on a new system parameter that, when toggled on, clawed back commission on a transaction and moved it from one ledger to another on our proprietary (read: inferior) accounting system. There was only one customer that wanted it (reportedly) out of several dozen that used the system. I don’t know if they ever used it. I don’t even know why they wanted it. I certainly don’t know whether they needed it. It still haunts me to this day.

• First Rule of Usability? Don't Listen to Users, Jakob Nielsen (2001)
• Great User Research (for Non-Researchers) — Part 2, Steve Portigal (2020)?
• The art of user interviews, Anthony Murphy (2022)

Requirements Gathering?

Many product development teams make the mistake of thinking that gathering requirements is the same as understanding the problem. I can confirm categorically, it is not.

Requirements Gathering? was forced down everybody’s throat during the early stages of my career - it was a module on both my undergraduate and postgraduate degree courses, and a compulsory part of the ISEB International Diploma in Business Analysis syllabus. I think it’s human nature as well, which doesn’t help. We’re wired and indoctrinated to collate crap in lists. We’re hipster magpies. We have to unlearn this - to free ourselves from this madness. I sat in so many meetings in the noughties and ‘10s about requirements. It’d go:

“Ooh, someone said we have to make that button’s colour configurable. Capture it. Stick it in the Prioritised Requirements List. Requirement 14,272.”

Then six months later:

“We’ve nearly finished the week-long regression pack, but it failed on requirement 14,272. Who asked for it? Is it a must-have? Should we delay the release?”

I reckon half of the requirements I captured were bullshit and delivered no value to anybody. Maybe more than half. They were bloat. They made the product worse. They sapped morale and enthusiasm and stifled innovation. And they ate up time and headspace. Requirements Gathering? does more harm than good.

• Requirements Considered Harmful, Jeff Patton (2007)?
• Product Fail, Marty Cagan (2015)
• Your To-Do List Is, in Fact, Too Long, Peter Bregman (2020)?

Not trusting my instinct

I can’t quite articulate how my instinct has developed as my career has progressed, or how my decision-making has improved. I can only relate it to how footballers - particularly attackers - appear to have a moment in their career when they begin to affect games consistently. They take it up a notch. For what it’s worth, I’m hoping Marcus Rashford has turned this particular corner ????

I felt like the watershed moment for me was my first contract engagement with Transport for Greater Manchester (TfGM) - the first role where I truly began to feel like a leader. Almost as if the responsibility made me acutely aware of the importance of instinct and decision-making. Made me realise that these were tools to be harnessed, studied, and sharpened.

As a leader, it's important to trust your instincts and to be bold. Sometimes, even if the data seems to be pointing in a different direction or consensus is steering you down one road, your gut feeling can still be the best way forward.

Failing to truly collaborate

Product, design, and engineering practitioners need to work together closely to build a successful product. But it's not enough to just talk to each other. It’s not enough to have a handful of shared ceremonies. There are two mistakes in one here:

First, a failure to actually work together - not just to write user stories and throw them over the fence. To foster a sense of shared responsibility for the product. For its users. For each other. And to work together earlier, which compelled me to write about an article about technical discovery.

Second, a backlog or roadmap disconnect. Here is a stack of product things to do, and here is a stack of engineering things to do. Or worse still, a battle of wills leading to the balance being off, covert work being undertaken, and noses out of joint.

You cannot achieve this by accident - it takes a concerted effort to marry the two, particularly at C-suite level. This really landed for me during my time at cinch, where the product and engineering directors were in utter lockstep. They knew each other’s domain (and probably each other’s brain) inside-out. Both knew that they were two sides of the same coin and that the product couldn’t succeed without equilibrium. They were a united front. It was no surprise to see another unicorn born under their stewardship.

• Core Concept: The Product Trio, Teresa Torres (2021)?
• Coaching – Collaboration, Marty Cagan (2019)?
• Developer & Designer Collaboration (in the Real World), John Cutler (2020)
• ‘Product vs Design vs Tech’: A Partnership, not a Battlefield, Anthony Murphy (2020)?
• Your Calendar = Your Priorities, John Cutler (2021)

Feigning certainty

I would love to calculate how much of my career was (still is, to some degree) spent t-shirting and planning and reporting and estimating and answering “why isn’t it done yet?” and “when will it drop?”.?

And how much each of the organisations I worked with spent on this most unnecessary of dances.

And how many times I (and many, many others) offered up the chocolate fireguard nonsense of a “high-integrity commitment” that wasn’t met.

Think of all of the noise that could have been avoided by saying “I don’t know when this will be delivered”, or better still “I don’t know if this will even be delivered as we are not yet confident enough that it will deliver value.”?

Think of all of the horrible conversations that would be avoided. Nipped in the bud. Would you lose some of your customers in B2B-land? Maybe. Would your employees be happier? Most definitely. Would you get more done? Almost certainly.

My default stance is to refuse to commit to timelines now. I get the odd challenge, yet somehow the world keeps turning. Nobody gets sacked. Team morale increases. The mindset propagates.

• Why Do We Estimate? John Cutler (2017)?
• How to Sell Your Boss on Roadmaps Without Timelines, Janna Bastow (2017)
• Stop Obsessing Over Development Velocity, Focus on This Instead, Itamar Gilad (2021)

Ignoring impact (or lack of)

It's easy to get caught up in the excitement of building a new feature, but it's important to take the time to evaluate the impact it will have on the rest of the product and its users.

I remember being interviewed for the aforementioned TfGM gig, where I was asked to draw out my preferred way to visualise work in progress and talk through it - a great interview question in my opinion. I remember seeing the excitement on the interviewer's face when I marked out a “measure” column to the left of “done”, and commenting on how this was something that the current team were striving for.

I remember battling for years in one of my roles to get some product usage data. Any product usage data. Even at the BBC it was difficult to get at usage data at times as it was “owned” by a dedicated audiences team. You almost had to break into Alcatraz to get your hands on some.

And so many only do user research before they build and ship something. I reckon only 10% of the teams I’ve worked with undertake another round of user research once something is in the wild.

Measuring impact is integral. It should be front and centre. Something is not done until you know how it has landed.

• Flying Blind, Marty Cagan (2011)
• Fixed time, fixed scope projects always end in 1 of 3 ways. None of them good, Jeff Gothelf (2019)?
• The Mindset That Kills Product Thinking, Jeff Patton (2020)?
• The Data-Informed Product Cycle, John Cutler (2022)?

Permitting subjectivity

It's important to make decisions based on data and objective criteria rather than personal preferences. Being bold and disciplined enough to defer decisions in the absence of insight can also prove incredibly valuable.?

Again, I hark back to my TfGM days to a moment when realisation dawned. Four of us huddled around the widescreen monitor of our lead designer in Manchester’s Northern Quarter: a product manager, a business analyst, a delivery manager, and a tech lead. They talked around the colour of a button and its label for a good 20 minutes. Going around in circles. I even contributed to this madness. Finally, my frustration got the better of me and I put a stop to it. I now find myself saying this, or a variation of it several times a day:

“Let’s just go with a and measure it. This is the only thing holding up delivering the value of b to our users, and we’ve been discussing it for c minutes. We can always tweak it and ship it in d hours/days if we find something is massively wrong. Any objections?”

I can probably count on hands and feet how many times somebody has objected, or something has gone massively wrong.

Opinions are the lowest of the low. I now suppress mine at all costs. I implore you to do the same.

• Idea Prioritization With ICE and The Confidence Meter, Itamar Gilad (2018)?
• Good Idea? John Cutler (2020)
• Strong Opinions, Loosely Held, Jeff Gothelf (2023)

Undervaluing myself

This is kinda related to “not trusting my instinct”, but it’s more than that. Maybe you could call it “imposter syndrome”. For a good decade, I did what I was told on the whole. I trusted the direction of others almost absolutely. I consciously shirked responsibility as others seemed to have it all under control. As I progressed to lead business analyst at CDL I trained myself not to do this. To constructively challenge leaders. To surface and test assumptions. This characteristic may be more important than all the others, and I realised that this was one of my core strengths, particularly when coupled with my bigger-picture-but-also-the-details systems-thinking mind that I can rarely switch off.

To this day, whenever I start a new engagement (or company in the case of Hyperact), I go through the same cycle on a much smaller scale, and it seems to reduce each time. At the beeb it was months before I felt confident to challenge. As a contractor it was weeks. Now it’s days - maybe even hours.

I’m still regularly the quietest person on the call, but believe me when I say that listening and thinking beats talking all day long. Don’t make the mistake of assuming this shows weakness or passiveness in your colleagues. If my gut tells me that intervention or direction is required, and at some point it invariably is, I won’t stand on ceremony. I know many others in the same mould: “The cement between the stones” as Erik ten Hag might call them.

Letting things drag on

This is almost a composite of “not trusting my instinct”, “permitting subjectivity”, and “undervaluing myself”.

Sometimes - most of the time in fact - it's better to make a decision and move on, even if you know it’s not perfect than to get bogged down in the weeds. Or to defer the decision, as alluded to earlier. There are three attributes that really help in this regard: Urgency, decisiveness, and clarity. Each is a cornerstone of building successful, differentiated products. If my team collectively lacks some or all of these, I will personally fill the gaps and will coach them to try and do the same. Most teams I join do not have all three of these and require levelling up. When a team has them all autonomously, it has a multiplying effect on my own productivity and the same can be said for the team as a whole. When an entire organisation has this, it is an incredibly powerful thing.

Over the last five years, I reckon that I have accelerated the delivery of something most days simply by closing something down. By injecting some urgency. By providing clarity. By swarming to unblock. By intervening. By inspiring others to do the same. I strive to do this every single day. To have impact. It is such an obvious differentiator that it baffles me why this is so often lacking, even in some really mature teams. And anyone can do this, regardless of specialism or seniority. Give it a try.

Owning it too much

Last but absolutely not least, I still struggle with this one. As hinted at in the previous mistake, if I see a gap I fill it. On my current engagement, as I write this, I am a full-time product manager. But I also take the lead on delivery in the absence of a delivery lead. And I have QAd a lot of the items we’ve delivered in the last three months (we don’t have automated tests, but that’s another story). And I’m striving to build out our product analytics, shape the product vision and strategy, and align the product function with the sales and marketing function. If any one specialist is missing, I automatically fill in.

I know full well that some of this is unhealthy and not sustainable. I know on some level it’s a mistake, but I also know that it needs to be done if I am to have the impact that I want to have: for the organisation to succeed. I know that my team sometimes suffers because of the demands that this puts on my availability and my headspace. I know that there is a risk of me being relied on too heavily. I have mechanisms to mitigate these concerns, but I’m still not satisfied. Suggestions on a postcard, please!

In summary

Without question, making and recognising mistakes has shaped and developed me better than any other aspect of my career and education. Better than any course I’ve undertaken, qualification I’ve achieved, or textbook I’ve read. Try things. Fail. Learn. Repeat. Sounds a lot like applying a product mindset to yourself now I think about it… ??

Ask your peers about their favourite mistakes. Read up on other people’s. Write about your own. Steel yourself with them. And don’t stop: I look forward to revisiting this article in a few years and assessing how my stance on some of these has evolved, whilst undoubtedly adding new (and probably bigger) mistakes to the list.