Improving Agility when you’re anything but Agile, and why we're living in a Generalist World
You see it again and again. Product managers read all the books and start talking the talk, but the rest of the business just sees them as backlog administrators and message carriers. But product management should be a crucial, strategic partner to the business. Product managers should never be afraid to stand up for themselves!
A word from the sponsor - me!
Yes, yes, that's me. But listen up. I started One Knight Consulting because I have seen variations of the same problems plaguing growing startups, scale-ups and larger, digitally transforming companies again & again. These problems can cause friction between teams, slow product development, lacklustre sales, and ultimately lead to constrained growth. If you're scaling your product organisation, struggling with cross-team alignment or having trouble executing your product strategy to support your business goals, book a call with me and we can discuss your needs and how I can help.
New Podcast Episode: Using The Power of Community to Help you Thrive in a Generalist World
I recently had the pleasure of catching up with Milly Tamati. Milly lives on a tiny island off the coast of Scotland and is trying to shake up the world of work as the founder of Generalist World. Milly says that generalism should be celebrated, and generalists don’t need to be put into boxes.
Check out the podcast episode on your favourite podcast app, or check the episode link.
Not everyone needs to be a specialist, you could be a generalist!
Do you not fit neatly in a box? Do you consider yourself a jack of all trades/someone who wears many hats? You might be a generalist & there are lots of generalists out there. Embrace it and find your people!
Improving Agility when you’re anything but Agile
Agile, hey? It all seems so simple. Read the Agile Manifesto, check out the Agile Principles and start building. There are so many thought pieces out there extolling the virtues of continuous delivery, breaking stuff down small, getting constant feedback from customers, changing based on that feedback, collaboration, communication, the whole nine yards.
And, you know what? I’m 100% behind all of that. I genuinely believe that getting as close as possible to these principles helps deliver valuable products with minimal risk, and maximum flexibility. It can give companies a competitive advantage and ultimately delight customers. And you’d like to think that developers would love this stuff too.
So why do we hear so many stories about product development teams slaving away, unable to get features out and ultimately getting caught up in knots? You might hear stuff like:
“We can’t release this feature because it has to go with X other changes”
“We need to bundle this into release Y and that needs a month of testing”.
“This has a hard dependency on product Z and that team doesn’t have any capacity”
I’ve worked in companies where even mentioning the prospect of releasing a feature felt like throwing a stink bomb into the middle of a crowd. Developers panicking and flying off in all directions, desperate to avoid being the one lumbered with pushing this release out.
Working software is the primary measure of progress indeed!
This addiction to big-bang, overweight releases causes a number of problems and leaves you with the equivalent of inventory in a warehouse. No one wants excess inventory sitting there getting in the way of the forklifts. The best place for that inventory is on the shelves of a shop, in front of customers, waiting to be bought.
Consider also that in particularly siloed organisations, of which there are many, development may be a black box. Customers, and potentially even internal stakeholders may not touch (or even see) upcoming features before they’re ready. This increases the risk that the solution you’re building doesn’t even solve the customer’s problem, and means you end up doing emergency rewrites.
What’s a team to do?
1. Don’t hate the player, hate the game
This is, of course, excellent advice for most things. Avoid fundamental attribution errors and don’t judge motivations or abilities. Things are this way for a reason, let’s talk about the reasons and not start throwing shade at the development team. It’s quite likely that this is just as frustrating for them!
If it’s not, it could simply be that the developers in your team have never really worked this way before. I remain convinced that, despite all the talk of manifestos and principles, there is a large cohort of developers out there that have never worked the “proper” way. Or they may have tried in the past, had a bad experience, been chewed out by IT-mindset leadership and developed a fear of even trying or a “this won’t work here” mentality.
We need to work with these people, not blame or criticise them.
2. Frame the problem in business terms
No business leader, and not all engineering leaders, will care about doing stuff just for the sake of it or for some quasi-mythical principles. It’s important to make people realise that the changes you want to bring in are for the greater good. Arm yourself with data about all of the times customers have been left disappointed, any high-integrity deadlines have been missed, and how many times huge releases have gone wrong and caused complaints.
Big releases are risky. You need to frame that risk to start getting support for investment in tools, training, and maybe even new people.
3. Don’t try to boil the ocean
This is a cliché, but you can’t change everything at once. If there’s substantial technical debt holding the team back, or loads of stuff needs to be rewritten, or you’re missing unit tests so can’t safely deploy anything without loads of manual testing, you’re going to need to be good product managers and prioritise. Work with the engineering team to work out how to break down technical tasks to deliver the changes you need incrementally. No one wants to spend 6 months re-platforming, not the engineers, certainly not the rest of the business. Tackle the worst problem, then the next, then the… you get the idea.
4. If you can’t show working software, at least show non-working software
Yeah, I get it. We’re supposed to continuously deploy working software to our customers. This is a great approach and something to be aimed for, although there are definitely times you might want to cool your jets. This is especially relevant in B2B products with risk-averse customers who don’t just want random stuff popping up all the time. This can be somewhat obviated with feature flags, early access plans and so forth, but it’s still something to be considered. You should always be able to release it if you want to though.
But, one thing that is really, really important is avoiding black box development and last-minute user acceptance. Every day that people aren’t seeing the proposed changes is a day that might need to be unwound when people inevitably find a flaw. In cases like this, I believe it’s important to show non-working software regularly. I would prefer to see working software, but if I can’t do that then at least I can show the work so far, even if it’s on the developer’s local machine. Constantly showing your work is the best way to get feedback quickly and adapt, even if you can’t smash out 24 features a day. You can even do this with customers (I’ve done it!) as long as they understand the terms.
As usual, this stuff ain’t easy. Anyone expecting to click their fingers, say “Agile” into the mirror thrice and watch everything drop into place is going to be disappointed. But, I do believe it’s important to start the battle for hearts and minds, break it down into manageable chunks (very agile!) and start improving observability while you do it. And, even if you’re not living the full Agile dream, always remember: Better is better than not better.
Thanks for reading, do please send feedback and let me know if there are any topics you’d like me to cover. And remember to share the newsletter with your friends!
If you want to buy me a coffee, you can buy me a coffee!
Thanks for reading One Knight in Product newsletter! Subscribe for free to receive new posts and support my work.
Alongside my own stuff, I want to start shouting out other content I see around the internet. Here’s a handful of stuff you should check out:
Hot Take: Google has a company strategy, not a product strategy — an interesting article by the excellent Jackie Bavaro, who talks about the differences in product development approaches based on her time at Microsoft and Google.