Five Ways a Product Owner Can Build Trust

For project teams to work together effectively, team members and stakeholders need trust. Each team member (product managers and owners, leaders, subject matter experts, and technical staff) have different roles and different interests.

As a product owner responsible for defining (and refining) the product backlog, you are expected to juggle a variety of issues including: choosing the most valuable work, meeting deadlines, controlling costs, incorporating bug fixes, addressing technical debt, ensuring quality, and communicating the changes to your users. If that trust breaks down, your product and process will, too. The result may be hidden agendas, rumors, gossip, no shows to standups, whining, or even subversive behavior.

Johann Rost, in his article “Political Reasons for Failed Software Projects,” [1] reported subversive behavior by team members, such as lying, withholding or delaying access to information, providing misleading or vague answers, and supplying poisonous ideas. Clearly, these projects are suffering from lack of trust.

The Types of Trust

Low trust levels can result in project churn, team turnover, low morale, and unhappy customers.

It doesn’t have to be that way.

As product owner, you have a lot of responsibility giving you the opportunity to build and sustain a healthy product development community. Reina and Reina [2] identified three types of trust needed in organizations that together influence a culture of trust.

Contractual trust: As you might expect, this kind of trust is based on having an unstated contract: “If you will look out for my best interests, I will look out for yours. If things change, we will renegotiate. Ultimately, we are jointly responsible for the team’s success.”

Communication trust: This kind of trust calls for honest and frequent communication. Team members tell the truth, admit their mistakes, maintain confidentiality, and seek and provide feedback. Their actions are consistent with their words and vice versa.

Competence trust: Finally, there must ultimately be respect for the team’s ability to get the job done. They promote mutual learning and development of everyone’s skills and knowledge.

Effective product ownership requires adherence to good practices. I have found the following five practical actions help build trust with your development team and business stakeholders:

1. Define product vision and scope.
2. Involve all product partners.
3. Identify and use value criteria.
4. Make transparent decisions.
5. Use a product glossary.

Define Product Vision and Scope

One way to build trust is to collaboratively define a clear, crisp, and compelling product vision.

The vision is the why of the product, and communicates what needs to be built, who will use it, and how it’s different from what exists today. My September 2016 newsletter provides guidelines for creating a compelling product vision. [3]

Your vision statement builds contractual trust by establishing shared goals for business and technical people. If the team can’t agree on vision, you’re not ready to build the product.

Involve all Product Partners

To build all three types of trust, you need to involve the entire team including developers, testers, UX designers, subject matter experts, business analysts, program managers, and specialists from audit, training, sales and marketing.

When you define your backlog, an early action item is to identify partner stakeholders from business, customer, and technology communities. Decide how you will engage each of these partners in your product discovery and delivery work. Share that information with them, and follow up.

Identify and Use Value Criteria

You need clarity on how you will make decisions on the relative value of myriad of possible product items in your backlog. In a recent post, I listed twelve decision factors a product owner might use to make value-based product decisions. [4] Defining them, and sharing the ones you will use to evaluate and filter backlog items builds contractual trust and eases communication.

Make Transparent Decisions

Transparent decision-making builds and sustains all three types of trust. A crucial part of this process is to develop decision rules and protocols and stick with them. I encourage product owners to use a pattern called “Decide How to Decide” [5] to help make transparent decisions. When working with agile teams, use this tool to check for agreement on iteration and release commitments.

Use a Product Glossary

The glossary defines the meaning of the business terms in your product domain. Many of your colleagues think everyone knows what they mean when they use key domain terms like customer, account, contract, device, location, and other domain terms. These terms permeate backlog conversations, product and project documentation, decisions, and ongoing planning. Yet, it never ceases to amaze me how this is not the case.

It’s can be an elegantly simple thing to resolve.

First, get clear on what you mean by domain terms by creating a glossary of terms. Product owners need to guard the key terms for the product they shepherd. Define key terms and any commonly used alternative terms. Don’t forget to include specific examples.

Next, draw on existing marketing, technical, and user documentation. (Beware: you will find inconsistencies to resolve!) You don’t need to define all of the terms, just the key ones. When everyone speaks the same language, it builds competency trust. This is a great way to bridge the gap between business partners and technology partners.

Building Trust in Your Product Community

The ideal time to build trust is at the beginning of a project, when you decide what to build. The process of building trust is difficult. This critical phase of any project is when the team liftoffs, defines product vision and scope, and begins to define (and refine) the backlog. If you are well past those early days of your project, you will benefit by pausing to do this important work.

A product owner can go a long way in establishing and sustaining the three types of trust (contractual, communication, and competence) from liftoff and throughout the product lifecycle.

References

1. Rost, Johann. “Political Reasons for Failed Software Projects.” IEEE Software, vol. 21, no. 6: November-December 2004. [Subscriber access only] ieeexplore.ieee.org/iel5/52/29730/01353234.pdf.
2. Reina, Dennis S. and Michelle L. Reina. Trust & Betrayal in the Workplace: Building Effective Relationships in Your Organization. 3rd edition. Oakland: Berrett-Koehler Publishers, 2015.
3. Gottesdiener, Ellen. “September 2016 Newsletter.” EBG Consulting (newsletter). vol. 10: no. 4: 2016. http://www.icontact-archive.com/jd3Rj9vytJC7-Vj78yXty2XNfNEm4v-e?w=4. (Subscribe to receive all newsletters.)
4. Gottesdiener, Ellen. “Factors for Making Value-Based Product Decisions. EBG Consulting (blog). December 14, 2016. https://www.ebgconsulting.com/blog/factors-for-making-value-based-product-decisions.
5. Gottesdiener, Ellen. “How to Make Product Decisions with Transparency and Trust”. EBG Consulting (blog). November 13, 2019. https://www.ebgconsulting.com/blog/how-to-make-product-decisions-with-transparency-and-trust.
6. Gottesdiener, Ellen. “Decide How to Decide: Empowering Product Ownership.” EBG Consulting (blog). December 15, 2015. https://www.ebgconsulting.com/blog/decide-how-to-decide-empowering-product-ownership.