3 Tips to scale your Empowerment and Velocity Acceleration across Product Trios
If you’ve been following the topics of Empowerment and Continuous Discovery, you realize that the product trio is probably one of the most important bodies of outcome orientation, user focus, innovation and value delivery in the organization structure.
On paper, the empowered product team is staffed and indeed empowered to take on any opportunity (user needs, pain points and desires) and create value by delivering solutions to those. The implication is ad-hoc assignment of opportunities and areas of solutions to teams that enables optimal business agility. In reality, teams do get assigned and establish areas of expertise, code area, responsibility for functions (as is typically evident when assigning responsibility for a production incident response team) etc. Thus, there is an inevitable overlap between teams and their respective areas of responsibilities.
The challenge then, is, how to optimize planning and maintanance of clear outcomes between multiple product trios and the entire empowered teams? Here are a few thoughts.
1- Define clear & distinct outcomes. In a previous article I described the initiation of outcome orientation and empowerment of the product teams. At the essence of it, each level in the “delivery” organization* considers their outcomes in parallel, independently. Then you come back to the table and consolidate the various inputs. That processes is easier to get your arms around when you’re considering a small to medium size delivery org with a handful of teams.
In a larger size organization you want to do the same, just in capsules. I.e., the teams that are co-focused around delivering user value can do this together.
The real issue is the elevated likelihood of overlap between teams. My advice is to find a way to identify distinct outcomes for both teams.
Let’s try an example. Say we want to focus next on user sign up and their initial login experience. It’s an expansion of an existing area, so far sign up was done using credentials and the user landed straight into a dashboard. We want a more engaging experience that would result in
- Increased weekly user signups
- Increased % of weekly post signup logins
- Increased time spent in the portal post login per user, weekly
These would probably be the outcomes of the product/dev/design leads.
As a best practice, you want to have teams to define distinct and measurable outcomes. Those could be verbatim one of the above, different ones or derivative of those. Let’s look at the post signup logins because that one is a little more complex with dependencies. The technology underneath login is the same that powers the signup.
Team A would take the first outcome, increasing the number of signups, and would probably consider social login as a candidate solution.
Team B could take the signup-to-login experience (communications via email, whether or not the user can land inside the portal right after signup without verifications etc.).
Team B has a dependency on team A as they need to leverage the social login solution to authenticate the user. And that’s ok, you can leverage help from other teams to achieve your outcome.
At the end of this step each team has 1–2 outcomes that are distinct, clear, measurable outcomes, that guide discovery and delivery.
2- Keeping everyone aligned- A larger delivery organization can have many layers and therefore many outcomes. It is important to keep a document that provides insight on the outcomes tree, and what team owns each outcome. Ideally, for each, what’s the outcome, the start value, current and desired value. It’s important to review these not only with each team separately (to discuss derivative activity) but also across teams so progress can be celebrated, risk can be identified and mitigated etc. I’m unaware of an objective management tool today (and curious to learn if you know of one!), so far I’ve only seen excel or Miro in use.
3- Managing tactical adjacencies and conflicts- I’m going a bit tactical here to discuss product/dev mindset when adjacencies arise. Clearly, velocity is optimized by reducing dependencies, but life doesn’t work like that. To achiev its outcome in a given timeframe, one team may needs to implement something that the other team “owns” but is unable to deliver in time. Here are a couple of best practices to go about that:
- Both product trios need to be open and honest to drive collaboration. Trying to go solo will likely antagonize the other team.
- The product manager, the dev lead and the developers need to learn and understand the business logic of that area of the code, so they don’t break things.
- The developer mindset should be “leave with less defects than before”. I.e., be responsible, respectful and collaborative. The developer should explain the nature of the code changes to the other developer from the “hosting” team.
- PRs should be reviewed and approved by the “hosting” team developers. They should also be accommodating; provide respectful and collaborative guidance and approve PRs on time.
- Eventually, responsibility for production monitoring and recovery is on the hosting team. Therefore, the developer making the changes and the one hosting should collaborate on modifications needed for the monitoring scripts and the nature of changes in alerting.
*- Delivery organization means product, dev and design in all ranks. Consider the different levels in the delivery org as the individual team trio (product manager, dev team lead, designer) all the way to the leadership (VP product, VP R&D and head of design).
In summary, driving empowerment and collaboration through clear and distinct outcomes is a process that is not restricted to small organizations, it is moreso necessary in larger ones. Teams collaborate and achive better results when both know the WHAT and WHY of the other team. They may have ideas and suggestions how to make things better and easier.
