Trust and empowerment for internal product teams

If you’ve read the preceding two articles in this series, you’ll likely be aware that the inspiration for writing them is in part due to a post that Casper Rasmussen posted earlier in the summer. In this he spoke about the transition of digital teams from “Component Teams” to “Feature Teams” and onwards to “Product Teams” and why this cannot be done as an overnight shift, something I certainly agreed with.

The initial articles I wrote in response gave a foundational view of my perspectives when working on products internally within an organisation. I discussed the differences and unique considerations applicable to internal products, and focused on how the concept of customer applies within internal applications.

With those foundations in place, we’re ready to look at what I think is one of the biggest considerations in being able to move from a Component to Product approach within an internal technology function. The concept of trust and through this, empowerment.

Setting the scene

Picture a scenario - you’re the new product manager for an internal tool and you have an idea for how it could be evolved to transform how a task is performed by the business team who use it. But currently the senior manager in the team steers the direction of the tool and how their team works, they don’t really know you or how well you know the business, and your suggestion is a challenge to the ingrained ways of working. How is this conversation likely to be received? The answer in most cases, is not very well.

Contrast this with the same scenario, but where you’re seen as a partner who knows the aims of the business, the way the teams work, why things have evolved how they have and its clear you’re aligned with what those teams and the business are striving for. Then it can be a completely different reaction. The difference between the two is trust.

Defining trust

Trust (noun): firm belief in the reliability, truth, or ability of someone or something

Using the dictionary definition, but applying it to this product context, what do I mean by trust? Much of this can be answered by determining on what basis your business stakeholders would evaluate their views of reliability, truth and ability. From my experience, I think this has five main components:

• Knowledge of the business
• Understanding of the process
• Alignment in purpose
• Integrity in approach
• Confidence in methods

But look closer at the definition, and there is another critical factor. Trust is about belief, and therefore is as much about perception as it is reality. If you do actually know the business and the process, but aren’t seen as such, then trust won’t be forthcoming. Likewise, you can’t simply create a fa?ade of comprehension and alignment, lest you will fall foul of the fourth point, integrity.

Because of this, we can take the five components and overlay a sense of how this may be questioned and evaluated by your stakeholders:

• Do you know what the aims and objectives of the business are?
• Do you know what my team and I do, how we work and why it is like that?
• Are we in this together?
• Are you being consistent and honest in your approach and objectives?
• Do your methods and ways of working make sense to me?

For each of these, you should be able to answer honestly from a place of reality if it is the case, and your counterpart needs to be comfortable in their opinion that the same is true. Wherever a gap exists, real or perceived, it needs to be closed.

Moving towards empowerment

But why is trust so critical to building internal products and moving towards an empowered product team approach? Can a technology function not simply determine that is how it is going to work, and the business stakeholders simply need to move with it? Most of the time, no.

As I wrote in my initial article, unlike in a pure technology business, where the product is the end-result that is being sold to external customers, internal products are developed to enable internal functions to operate. Quite often the business stakeholders and customers of these internal products are senior leaders within a business. They’re likely to have significant influence in how things are done, particularly within their areas of responsibility. And if they’ve been used to a project or Component Team way of working until now, where they dictate to the technology team what they need to do, then it is a seismic shift for them to be relinquishing this control.

The original table that Casper shared showed a progression in the mission of a team ranging from “tell us what to do”, through “deliver the features required” to eventually “what are the problems / opportunities to solve?” as the focus of the team develops and empowerment increases.

But if a technology function wants to become empowered, to take ownership of the solution to business and customer problems or opportunities, it needs the support and trust of the business to do so. There needs to be a reason for this change to happen, and a benefit in doing so. The incumbent owners of the responsibility for providing the direction of the product need to be confident that handing this over to someone else is in the best interests of themselves, their team and the business.

In short, this isn’t going to happen without trust. Building this will take some time and effort. It may be that some time needs to be spent in the middle ground of features, supportively aiming to remove frustrations with the current ways of working, gaining experience in the ins and outs of how the existing products and processes work. Or it might involve adapting and explaining your methods and approach to one that your stakeholders become more comfortable with. But over time, the team’s credibility to deliver and assist will grow, and constructive challenge and suggestions for more novel ideas can arise.

Will you know for certain when your status as a Product Team has been reached? Maybe, or maybe not. There won't be an email or notification to tell you as such, but as trust increases and empowerment follows, there will become a time when the questions from the business shift. And as they move from “Can you build this?” to “Can you build something to solve this?” then you’ll know that trust is there, and you’re well on the way towards empowerment.