The Seven Deadly Mistakes of Productization & What to do when your CEO says "Just Build This"
The Seven Deadly Mistakes of Productization & What to do when your CEO says "Just Build This"
I had a little unexpected newsletter break last week, although not in the traditional sense. I actually wrote a full newsletter, only to realise that I’d basically covered the topic before. Not just similar, but all my points and suggestions were pretty much exactly the same! So I canned that newsletter and started writing another one - only to find I was doing exactly the same thing.
So here I am, back for round 3, with a bumper newsletter that hopefully won’t rehash too much!
A message from our sponsor
This episode is sponsored by Skiplevel. Do you struggle with communicating with dev teams and understanding technical terminology and concepts? On episode 98, I hosted Irene Yu, founder of Skiplevel, an on-demand training program that helps professionals and teams become more technical in just 5 weeks... All without learning to code. Learn the knowledge and skills you need to better communicate with devs and become more confident in your day-to-day role with the Skiplevel program. You can use the referral code OKIP to support my work!
New Podcast Episode #1: How to Move Fast Without Breaking Things
I recently had a chance to catch up with Dani Grant, co-founder of Jam, a tool that aims to simplify bug reporting, save product development teams time and help drive good quality software. We chatted about her origin story, her time in VC, and why she believes that quality is everyone’s responsibility.
Check the episode out on your favourite podcast app, or here.
"Move fast and break things" is so 10 years ago
First impressions count. If you're building productivity tools, you can't make people's lives harder. You need to ship something that works - moving fast and breaking things was a valid strategy only before people knew better
New Podcast Episode #2: The Seven Deadly Mistakes of Productization
A short while ago, I flew to Greece for a conference and on the flight, I read Productize, a book about digital transformation and moving away from a services mindset. The book was relatively short but full of insight and I knew I had to speak to the author. I was delighted to have a chance to speak to Eisha Armstrong about some themes from the book, and why fear is the biggest barrier to change.
Check the episode out on your favourite podcast app, or here.
The three biggest barriers to transformation are fear, fear and fear
It's natural for leaders and employees to feel fear of the unknown or of change. But fear is the enemy of growth. Yes, things could go wrong, but think of what could go right!
I got interviewed about product management by Tealfeed
I was recently asked by Tealfeed, an online knowledge-sharing platform, to contribute some answers to a wide-ranging interview about all things product management. We covered everything from how I got into product management, to prioritisation, GTM plans and much, much more. Check it out here.
What to do when your CEO says "Just Build This"
I’ve had this question a couple of times recently in some of my fireside chat sessions with startups. It’s all about the eternal Outcomes over Outputs argument, with most product managers very strongly believing in the former, and many non-product people struggling to tell the difference.
I actually most recently had the question from a CEO, rather than the product team, and it got me thinking about how to tackle the well-meaning, and very possibly totally correct, desire to build Thing X without completely undermining your product team. Here are some thoughts about how to tackle it.
By the time you’re having the argument, it’s probably too late
It’s very difficult to win an ideological battle and try to sell good product thinking or sound product principles at the point that you’re already being asked (or told) to build a thing. That doesn’t mean build literally anything you’re asked as soon as it’s mentioned but, in the grand scheme of things, you may end up holding your nose and building something. The question isn’t whether that’s a sound prioritisation strategy - it’s not - but your goal here is to stop this from happening next time.
The idea might be a good one, but not just because the CEO said so
Of course, it’s quite possible that the “Outputs over Outputs” CEO has an idea that is very good, maybe legitimately the next thing you should work on. The question isn’t whether their idea is a good one, but why it’s a good one. Why is it important to do it now? You need to ask these questions, albeit in a non-defensive way. Attacking people’s ideas is always problematic, as it makes people feel that you’re attacking their character. Some good advice I got on the podcast from David Bland once was (to paraphrase) “question the assumptions that need to be true, never the ideas themselves, because people cling to ideas”.
In any case, don’t just accept ideas at face value. Engage with the person requesting the feature, and find out as much about the Why as possible.
Try to retro-fit the Outcome from the Output
This was advice I got, again on the podcast, from John Cutler, who himself was the originator of the phrase “Feature Factory”. The idea is straightforward - maybe you do have to build a thing, but don’t just build it at face value and move on. The feature you’re building is the answer to a question - so what’s the question? Maybe the question is obvious, or maybe it’s not, but you can do some good old-fashioned investigative work, and try to work backwards to get to the original outcome that you would have ideally started from.
Again, you’re still going to end up building the feature, but working backwards means that you can start to work out what other opportunities there are in the space that the feature inhabits. It can be a precursor to further discovery, further investigation, and help to get you ahead of the curve for next time.
Get ahead of the curve before the next time
Why did you have to build this feature? Was it actually a kind of obvious use case that just got accelerated, or was it a totally out-of-the-blue randomisation of your roadmap driven by one very specific need that only your biggest customer has? In any case, how can we stop it again?
I still maintain that doubling down on direct product discovery with customers, as well as synthesising the best of the feedback you get from other teams, is the best way to get ahead of the curve. If people are pushing for features that are “table stakes”, “obvious” or “everyone wants this” then those features should come up often in discovery sessions. If they don’t, then can anyone legitimately say that “everyone wants this”? Getting away from complaining about feature factories and using those direct feature requests as precursors for forward-thinking discovery is critical.
Final thoughts
To summarise, product managers want to shoot for outcomes, but sometimes they’re forced to build stuff. It’s important they know the reasons behind the asks, work constructively with their stakeholders, and use those feature requests to explore the space around them. There’s still good product management work to be done in these situations, don’t shirk it!
If you enjoyed this newsletter, please share it with your friends! And please do let me know if there are any topics you’d like me to cover in a future issue.
Writing this newsletter is fun, and I love to give stuff away for free. But, if you want to buy me a coffee, you can always buy me a coffee.
Good approach to engage with the requestor of the feature and ask questions about the idea. Another angle of the questions is about the priority of the request. Sometimes those executive requests aren't as urgent as they appear on the surface. You can avoid needlessly churning the product team by asking good questions.