Fostering a Culture of Experimentation, and is Product-Led Growth Really For You?
I was recently thinking about Conway’s Law:
"Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure"
This is an oft-repeated warning to leaders to set their teams up efficiently (see approaches like Team Topologies) rather than defaulting to something that makes it harder for them to deliver great products.
I was also thinking of my own spin on this, let’s call it Knight’s Law for now:
“Product development teams will prioritise product initiatives that match the system's architecture over the needs of its users”
This sounds like I’m having a go at developers, but I promise I’m not! But, I do believe that it’s very, very common for product prioritisation to overemphasise development efforts. There are prioritisation frameworks that explicitly divide by it.
It’s not to say that we shouldn’t be conscious of the effort involved, especially when thinking of time horizons for releases. But, ultimately, we’re unlikely to be able to solve our users’ most painful problems if we’re scared of rewriting, refactoring, or rearchitecting around them, rather than trying to rearchitect our users around our own technical choices.
A message from our sponsor
This issue is sponsored by My Mentor Path, a free peer mentoring platform that I’ve helped to set up to ensure that product people are able to get the support they need to help further their careers, as well as pay it forward to the next generation. You can sign up now as a mentor, a mentee or both. We’ve recently launched new mentor discoverability features, as well as allowing you to have more mentors at once, all to enable you to develop your careers the way you want. Check it out now!
New Podcast Episode: Is Product-Led Growth Really For You?
If you’re in any way interested in product-led growth, you’ve undoubtedly come across Leah Tharin. Leah is the Head of Product for Jua, a weather prediction platform, as well as a growth advisor for numerous companies and an ever-present commentator across social media and her own newsletter and podcast, ProducTea. I was delighted to get some time with her to talk about all things product-led growth and AI.
Check the episode out on your favourite podcast app, or right here. Make sure you share it with your friends!
Product-led growth does not replace sales-led growth
Product-led growth just addresses a different segment in a better way than sales-led. For bigger deals, you still need a sales team, but product-led sales mean getting better quality leads by demonstrating the value upfront.
“How can we create a culture of product experimentation in an environment where there's a constant flow of business requirements with competing priorities?”
So, this was an interesting question that came up recently. Experimentation! Ah, experimentation, I hardly knew thee. But let’s dig into it (with the disclaimer that I’m coming at this from a B2B angle).
Most product managers can probably tell you why they want to be able to do more experiments. Maybe they heard about Google’s famous 50 Shades of Blue experiment where they managed to make an extra bazillion dollars by riding the colour picker. Maybe you’ve read a book like Testing Business Ideas (by my former podcast guest David Bland) or The Lean Startup and you’re all about validated learning. You want to start experimenting but “The Business” won’t let you. What to do?
Set your expectations
Before working out where you want to go, work out where you’re at. The Google button experiment is an oft-quoted example of the benefits of small experiments, but do you have as many users as Google? Do you have as many users as Google gave one button colour? If you’re working in B2B then the answer is quite likely “No”.
I’ve worked on SaaS products with 300 MAU. They paid a lot for the privilege, but I was never going to be able to do that kind of test on them. I've worked with companies that provide APIs for banks. Banks don’t want APIs changing on them all the time. If your product is a mission-critical back office application, pretty much no one wants that changing on them on a whim.
Define what experimentation means
In my interview with David Bland, we spoke a bit about the ethics of experimentation. One of the things that really resonated with me is the idea of “experimenting with” rather than “experimenting on”. That’s to say, if you’re working in a B2B product company with a relatively small number of customers, you probably just can’t roll the dice on every feature. You don’t have the numbers, and their tolerance for change will be low.
But, you can certainly run early access and Beta programmes with willing customers. You should also get into the habit of putting feature flags onto new functionality, to enable you to roll it out to certain groups at a time. It’s a lot easier to get started with this stuff if deploying literally any experiment isn’t an engineering nightmare (there are SaaS tools to do this, of course).
Find your allies (and speak their language)
One of the biggest barriers to experimentation can be the fact that people just don’t get it. We might be all about “design thinking” and “validated learning” and being “a learning organisation” but a lot of your internal stakeholders - the people you need to get on board - probably don’t care about any of these terms. They have their own problems, their own KPIs and their own success criteria. I find it helpful to talk about “de-risking”, “customer collaboration” and “early access”.
And, let’s be clear, most companies have some customers that will absolutely love to see early versions of things and will be enthusiastic partners. You need to get in front of these people and make them your external allies (just be wary of the sales team being encouraged to try to price things into renewals before you’ve decided whether to take them any further).
Start small and pick the right bet
Concrete examples are always more vivid than what, to some, can seem like academic exercises. If you’re in a company with “business requirements” flooding in (no doubt a selection of direct feature requests, “must have” features and “obvious low-hanging fruit” championed by internal subject-matter experts) then you’re not going to change the entire company in a day. And, to be fair, sometimes the best experiment is to build a real thing and see how it goes down, as long as what you’re building is small.
In any case, pick a smaller initiative, maybe something a little less certain and that people aren’t screaming for. Work out what an experiment will look like, how you’re going to do it, and what success looks like, and then just get going. Ask for forgiveness, not permission, but be prepared to pull the emergency cord if it’s just not working out.
Show your work, iterate and improve
What did you learn? Don’t hide it! At the very least, you’re going to have a great story to tell in the next “show and tell” session. You do run those, right? It’s good to get away from just telling your colleagues about what you’ve built, what’s shipped and what’s delayed. Start giving them early insight and exciting tidbits from the conversations you’re having with real customers about early versions of future product initiatives. Get away from the fear of saying that something didn’t work out, and tell people what that failure taught you, and what action that’ll drive next time. Next time, you’ll either double down, or you’ll adapt.
But you still might not get to do too much experimentation
I’m aware of many companies that have zero tolerance for any of this stuff. It’s all about cranking out the next thing, the thing after that and the thing after the thing after that. It’s a constant death match of feature requests of marginal value, and the product is never quite as good as anyone thinks it could be.
In an ideal situation, you’ll be able to make small changes, try a few things here and there, and nudge the company in the right direction. In less-than-ideal situations, you’ll get to do no experimentation, or you’ll get one chance and then be shut down forever. What happens after that is really up to you, based on the type of work you like to do and the type of company you want to work for. I do recommend to keep trying though!
Recently, for my newsletter, I’m trying something a little different. Rather than just writing about whatever random product management stuff is on my mind, I’m taking some of the questions I get from my fireside chat sessions and answering those. Hopefully, these will be interesting to lots of people. Feel free to vote or submit your own questions!
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. In any case, if you enjoyed this issue, please share it with your friends!