The trust stack: confidence and unknowns in product development
In uncertain environments, typical markers of trustworthiness like honesty, reliability and competence aren't always enough. Stakeholders also need a confident relationship with the unknown.
How many times as a product manager or member of a product team have you felt that, deep down, stakeholders or other parts of the business don’t trust your ability to deliver, or worse, exhibit signs of open distrust?
Trust is usually seen as relational and based on values and behaviour. Trust exists between individuals or within social groups, or is conferred on organisations and institutions. Trustworthiness rests on characteristics such as honesty and integrity, reliability and predictability, commitment and competence.
Based on these qualities, we form expectations about another party’s actions or behaviour, we make judgments about that party’s credibility and dependability, and we leave ourselves reliant on (or even vulnerable to) other people’s actions.
In this context, where trustworthiness is characterised by honesty, competence and reliability, when someone questions a team’s track record or approach it can feel like they’re questioning your honesty and personal competence as well.
Author and academic Rachel Botsman, on the other hand, describes trust as “a confident relationship with the unknown” and likens it to a bridge between the known and unknown.
It’s a simple definition that’s worth anyone working in product development or software engineering keeping in mind when it comes to relationships with stakeholders and the wider organisation.
It can help avoid unnecessary aggravation and better condition our response to doubt and scepticism, especially when working in areas characterised by ambiguity and uncertainty, where establishing the typical markers of trustworthiness can be challenging.
Using Botsman’s definition, which might be called situational, trust doesn’t depend solely on the objective qualities of another party, or a subjective assessment of character. Conversely, distrust isn’t necessarily directed at an individual or team.
Lack of trust could result from the general uneasiness or discomfort that often accompanies uncertainty. Building trust becomes primarily a confidence-building exercise that creates that bridge between the known and the unknown.
This is important, because if a perceived lack of trust is wrongly (or overly) attributed to missed commitment dates or changes in approach, for example, then common responses will do little to increase confidence and can have damaging side-effects.
Product managers might start sticking too rigidly to a roadmap or specific implementation, ignoring evidence of changing user needs or market conditions for fear of “reneging” on an earlier commitment.
Teams might also start to scale back exploratory user research, experimentation and prototyping in favour of relatively safe, predictable increments, even coming to see change as evidence of failure.
Similarly, a product team might attempt (or be asked) to estimate tasks in ever-more granular and excruciating detail, in the hope of becoming more reliable or predictable.
They might succeed, but the outward appearance of reliability and personal competence has started to take precedence over adaptability and responding to change, which is unhealthy in the long-run.
Also, I’d argue that what that team is really doing is reducing the need for trust by “managing out” (or just hiding) the unknowns and uncertainty, rather than building trust by demonstrating an ability to deal confidently with ambiguity and risk.
There’s absolutely nothing wrong with trying to establish trustworthiness based on reliability, predictability and personal qualities. But trust derived from a confident relationship with the unknown strikes me as more adaptive and sustainable, precisely because it doesn’t rely so much on personal relationships and doesn’t reset from one initiative to another.
Another of Rachel Botsman’s ideas is the “trust stack” which, as illustrated below, embodies the bridge between the known and the unknown. (In this example, she was discussing the trust stack for a ride-sharing app.)
Here’s an org-wide trust stack of my own for product development. It’s important that the people we work with across departments are trustworthy, which is to say honest, competent and dependable. But that’s just layer one.
When developing products or new features designed for maximum business impact, the organisation also needs to trust the strategy in its different incarnations (layer two); trust product teams’ approach to discovery, prioritisation, research, design and development (layer three); and trust execution across a range of business functions, not just product development (layer four).
This is where the trust stack starts to resemble a Jenga tower. And yes, if you remove too many pieces or decide too hastily that a piece is dispensable, the whole thing can come crashing down.
Recommended stuff
Trust-Thinkers: What does it really mean to trust? by Rachel Botsman
Being More Trustworthy: The Basics by Rachel Botsman
Future of the Corporation: Trust, Trustworthiness and Transparency.
A 2017 breakfast briefing by Onora O’Neill and James Bardrick (PDF)Rachel Botsman’s Rethink newsletter
The Trust Shift (BBC Sounds)
Next time…
The hardest thing about switching from outputs to outcomes