It appears that Ray’s Rants ™ is quickly becoming a thing amongst the people who work with me day to day. They have even suggested that may actually be interesting to more people so I’m going to share.
Recently, I’ve been taking a step back to think about the most successful teams I’ve been a part of and have in common. One of the things you might have seen is me talking about trust and building trust. I want to bring attention to that trust and take it up a level, do you want to know why some of your teams aren’t working as well as they could? Let’s get into it.
1) Your product team doesn’t actually own a product.
Have you built a product team, or have you built an implementation team? (Marty Cagan calls these “delivery teams”, I don’t love the parlance but I do agree with the point — https://www.svpg.com/product-team-faq/)
If you have a predefined output and maybe even some idea of a solution. You have an implementation team. That’s okay, but take a beat and be honest about the output you’re asking them to achieve and don’t try to shoehorn nonsensical product or value metrics upon them. You’ve asked them to implement a thing, let them do that and then have a clear answer as to how that’s being supported in the future. Software rarely enters a state of “complete”, it will need maintenance and your implementation team generally won’t be equipped, nor motivated, to maintain it.
2) Your product team owns a subset of a product.
Have you given your team a product, or have you given them a part of one?
I find this usually manifests when an organisation hasn’t really done a sensible mapping of their products. For instance they may have taken a website and handed each team one page on the website, maybe they also have a team (or teams) building APIs and owning the underlying data model or there’s some unclear boundaries on data ownership and each team is out there for themselves trying to update or read the same data.
Here’s the problem, you don’t have a product team that can actually make a difference. You may have staffed them well, with a great designer, great product manager, and a cross-functional multi-skilled development team. But they won’t be able to make a true impact. Why? They’re going to spend more time negotiating with other teams, trying to get over the organisational hurdle of not actually owning a full product. They’re going to waste away chasing outcomes they can’t achieve on their own. They’re going to waste away trying to negotiate the usage or structure of data that they and another team are trying to work with.
3) Your product team owns a product, but they have no wider context.
You’ve got a product team, and they have outcomes they can control and achieve on their own. Yet somehow, what they do doesn’t match up with what you want.
Product teams should be empowered, they should be able to make a lot of their own decisions and have autonomy. But they also need context, they need to know what boundaries they’re working within, what the overarching goals are, and how their work is impacting those overarching goals.
There’s one thing I find to be true of all great product teams, they want to get their work out in the world, test it, change it and see it fundamentally work in the hands of their consumers and be celebrated for making an impact within their business. I see lots of teams that are stuck with an unclear picture of how their work actually has an impact on the organisation. OKRs are a way I’ve seen organisations try to share how teams can make an impact. They are not a silver bullet. Teams need to understand the fundamental impact that their changes have on an organisation, not just jockey to hit a metric or key result, and then be given the space to go and chase ideas that impact upon those goals.
4) Your product team should be treated like capable adults
At the end of all that, let’s cut back to the start and why I started this rant. When you want results from your teams that impact your organisation, you need to treat them like adults. Not just any old adults, but the capable adults that you brought into your organisation because they can help make a difference. Give them context, give them a real product area, and give them the space to go and be aspirational and solve problems. That’s what they want to do. Give them problems, not solutions.
If you want to rethink how your teams are aligned to products, tools like Domain Driven Design are there and can help.
If you use or want to use OKRs, make sure your organisation actually understands the concept of value.
Lastly if you ever need any help with any of this, or want to talk through some of your problems. You can always reach out to me on LinkedIn.