Product teams, or product alignment, is rapidly becoming one of the biggest hot topic IT discussions. Following the trend of a host of other buzzwords, Product Alignment has become confusing, contradictory, and unfortunately dogmatic. I’d like to take a...

Photo by Quino Al on Unsplash

Product teams, or product alignment, is rapidly becoming one of the biggest hot topic IT discussions. Following the trend of a host of other buzzwords, Product Alignment has become confusing, contradictory, and unfortunately dogmatic. I’d like to take a moment to both pare back and consolidate the essence of what being aligned to a product actually means.

I’ve recently written about how I believe product alignment to be an anti-pattern, but I’m not going to change the global grammar without some pretty serious effort that I’m unwilling to spend. So, while I may talk about product alignment, what I actually mean is outcome alignment.

The aspects of good product alignment

Photo by Randy Fath on Unsplash

1. Cross-functional

Fundamentally, an outcome team must carry as much as possible with them on their journey. Dependencies are one of the biggest problems with modern IT, so the more we can eliminate the better.

There are always going to be cases made for support teams that sit outside the outcome team; support teams are there for when it doesn’t make sense to provide that function full time within the team. Think about legal, we don’t always need this represented in the team, so we accept a limited dependency. Similarly for common services, it doesn’t make sense for every team to build and maintain their own infrastructure, we’d have a platform team that provides self-service capabilities to eliminate the dependency.

Aside from these situations, we need the team to contain everything they need to fully execute on the customer value stream. If I locked the team and a customer together in a room, I expect that team to be able to resolve that customer’s challenges without going to anyone outside that room.

2. Share a common reporting structure

There will always be a hybrid model, you can’t get away from it. IT always has two directions that drive behaviours, technical excellence through functional alignment or value creation through outcome alignment. I’ve already spoken about this in detail, so I won’t go into it now, but your entire team needs to share a common reporting structure, probably through your product owner, or whatever your version of the role is called.

3. Aligned to a customer-centric outcome

We’re not aligned to functions anymore, so what is the lens around which we form the team? What’s my reason for coming to work if it isn’t doing QA or Security anymore? The answer is an outcome, an aspirational future state that we seek to bring about. The outcome should be from your customer’s perspective.

4. Customer-connected

It’s not enough to be customer-centric, you need to be customer connected. If you’re aligned to a customer’s vision of the future but have to go through 3 projects managers to speak with them then you’re missing a trick. Make sure that your team has direct contact with your end-user.

5. Support the organisation’s vision

The outcome you align to must be in support of your organisation’s overall strategy. It makes little sense to have an incredibly clear and aspirational vision that does nothing in service to the organisation’s reason for existence. Again, I’ve spoken in detail about this previously. This approach is called ‘Structure as Strategy’. We design the organisation to represent the strategic aims, thereby ensuring alignment and transparency.

6. Autonomous

Maybe the second most obvious one, after cross-functional. You currently have a team aligned to a strategic and customer-centric outcome, this counts for nothing is they are disempowered. Have trust that they will do the right thing with the tools you’ve provided. It’s alright to require certain consistency in governance, but don’t try and pull the strings.

7. Continuously improve

Having chosen to make the shift to product alignment, you’re already improving your chance of continuing success. This needs sustaining. The likely reason it was so expensive or challenging to re-align in the first place was stagnation. As soon as high performing teams start to demonstrate complacency, the effectiveness of your organisation starts to plummet. Ensuring that all teams have a healthy and robust approach to continuous improvement will help promote continued innovation and learning. Good Agile practices like proactive retrospectives or reactive post-mortems are a great start.

8. Long-lived product alignment

And finally, make sure you do everything you can to support a stable team. One of the main problems with traditional project teams is that they are transient. A team is assembled from a variety of functions, they are given a project to complete and then executes on it. On completion, the team, their knowledge, and any chance of decent support is then chopped back up and shipped to their original functions. Barring the odd minor shake up to keep things fresh, try and keep your teams together for as long as possible, they’ll continue to perform more and more effectively as they stabilise.

How is product alignment different from project alignment?

Photo by Vika Aleksandrova on Unsplash

I hope that it’s clear by now, but let’s contrast these with a traditional project team.

Cross-functional: Project teams are assembled groups of specialists, so are often somewhat cross-functional, but the little attention paid to dependencies often results in projects being chopped up by a centralised control body who ships pieces of a larger project to individual teams. That work is then assembled at some point, dependency hell.Share a common reporting structure: No chance, functional alignment all the way. Technical and localised excellence at the cost of customer value.Aligned to a customer-centric outcome: A customer might care about the project, but the team is aligned around work, not an outcome.Customer-connected: The centralised body controlling everything might be, but then again, probably not. The PMO likely connects project teams with the customer through some shadowy figure known only as ‘The Business’. Support the organisation’s vision: Without an outcome, any support of the vision is through a very short lens.Autonomous: Centralised control is the opposite of autonomous. It’s simply impossible to not use centralised-control in a project world because of the complexity of the dependencies. The organisation needs to expend massive effort in trying to control chaos because of the interconnected nature of everything.Continuously-improve: How is this going to happen if we disband the knowledge every time something is accomplished?Long-lived product alignment: Obviously not.

Conclusion

This has been my attempt at introducing a unifying standard into a world of competing standards, thereby increasing the number of competing standards by one. If nothing else, it provides clarity on some aspects in my other posts. Let me know if you too have a competing standard.

The post 8 aspects for good product alignment appeared first on Sean Robinson Consulting.

---

View Entire Post