Trust in Product Development

by Jamie Flinchbaugh on 10-06-20

What does trust have to do with product development?

I have written quite a bit about product development, and also about trust (for links, see the bottom of this article). But what do they have to do with one another other than the fact that one is important and the other always good to have?

I propose that trust is an even more important enabler in product development than it is in other processes. But why?

Trust is more important when there is back-and-forth or cycles in the work

Most processes are linear. That means when you hand off some work, it goes to the next step and is really never to be seen again. This would be true of most manufacturing processes, most financial processes, and most HR processes to name a few. In these cases trust is less important as an ingredient. As a downstream customer, you may or may not get what you wanted from your supplier. You can push back, you can work with what you’ve got, you can fill the gaps yourself; you have options, but because there is no back and forth, there is an inherent equilibrium that is established, whether that equilibrium is effective or not. As a result, trust is not called upon much because there is no back and forth.

When there is a back and forth, trust is more important. This is because the ebb and flow of requests and responses, negotiated outcomes, and being suppliers to each other can either improve or deteriorate over time, based on the other party getting or not getting what they need. When the dependency flows in both directions, trust is a more important ingredient than in an environment where it only flows one way.

Planning is a good example. You start with assumptions and inputs and a model, build a plan, find gaps and get responses from other parties, and develop action plans and final plans. Because of the back and forth, if people don’t trust the inputs they are given, or question the intent behind the communicated gaps, or don’t have faith in the action plans, the process can unravel with frustration and inaction.

Product development is perhaps the most extreme example of this. The frequency, variability, and volume of dependencies are greater than in any other process. Inherently, that means that the ebb and flow, the back and forth, and necessary collaboration in this process can rise and fall in correlation with the underlying trust.

In addition to the back and forth, there is a great deal of parallel work, whereas most processes are more serial. Engineers working on different subsystems in parallel to process engineers developing processes and sourcing working on suppliers and marketing working on scope and service working on serviceability plans….and so on and on and on. This parallel work of course should be defined. Clear interface design for subsystems helps eliminate the need for trust. Well defined milestones reduce the need for trust. But there is so much parallel work, a lack of trust can lead to divergence, double-checking, chasing invalid assumptions, and more wasteful work.

Product development needs more trust because of the nature of how workflows through the organization.

2.Unknowns to knowns

The other factor that interplays with trust significantly is certainty. In a highly transactional process, there are often standards, deliverables, and metrics. Getting what you need, or not, is relatively easy to determine if there is success because it is clearly known.

When the work and the outcomes are clearly known, we are less dependent on trust to carry on. We rely on the process and metrics, along with whatever inherent accountability comes with it, to get what is needed.

Correspondingly, when there is a great deal of unknown in the work, then trust is a more important lubricant to keep the work moving forward. Before we get to product development, consider an extreme environment: a startup. Whether 2 co-founders, or 4, or leading a team of your first 10 employees, there is so much to do, and so little is certain. Without trust in the vision, the leader, each other, and the overall effort it is impossible to carry through the uncertainty.

Most product development efforts aren’t too far from that example. You don’t know the market. You don’t know the feasibility of your concept. You don’t know if customers will accept your value proposition. You don’t know if you can deliver what was promised. The uncertainty of product development requires that people wade through questions to create answers, and to do so together, requires a basis of trust in the mission, the leaders, and each other.

Each team and function has their own complex problems to solve. Their heads need to be down, focused on the problem at hand. However, their solutions likely depend on others not changing key parameters or on them solving their own problems. They have to trust that the other teams will be there when they need them to be. If the various teams engaged in product development spend even a portion of their time trying to track how other teams are on track (or not), or how they might be changing the design parameters, that is energy taken away from solving their own difficult problems. Perhaps the most common overt example of this is teams that slow down their efforts because the other teams won’t be ready anyway. You have to stay focused, and this requires trust in all the parallel paths of work going on, both in their intentions and their capabilities.

For these two primary reasons, trust is vitally important in your product development efforts and all the cross-functional work, shared leadership, and ebb and flow that the work requires. Process matters. Culture matters. Capability matters. And trust also matters.

Posts about Trust:

Posts about Product Development:

Blog