The Value of Transparency in Product Development
We’ve already covered the value of both granularity and cadence. Along with that must come transparency, as, without it, all the information flow, connections, and ability to problem-solve has less value.
First, transparency is a precursor to trust (or is trust required to have transparency? Well, it works both ways). How do I trust that all the teams are on track, or not? How do I trust that I’m working really hard on something that matters? How do I trust that when I need other teams to be synching up, they will be ready? This isn’t trust in a person, but trust in the progress of product development. Trust is more important in product development because it is less linear and has more detours than many other processes, along with the fact that there is often more coordination across different sub-teams or functions. For example, if I tell someone I’m leaving the office and coming straight home, then that likely has a fairly predictable timeline. Sure, abnormalities happen (such as accidents), but then the impact of the abnormality is easy to detect and understand the consequences. But if I have to get from unknown point A to unknown point B, and don’t even know if I have a car, am using public transportation, or walking, then it is very hard to determine normal from abnormal, or understand the consequences of an abnormal condition. This is much closer to what product development feels like.
Why does this matter? There’s a schedule, just follow the schedule! Well, that’s fine when everything is predictable. But to get there in product development, you sometimes have to push extra hard, take an extra risk, or put something else aside because it is a creative process. If there are 5 teams that all have to come together for the whole thing to work, if I don’t know (or can’t trust) that everyone else will be there, then how many barriers will I bust through to make sure I’m ready. And that’s just the schedule.
The same issue occurs not just in the schedule but in the scope of work. If we are asked to take 20% of the weight out of the product, and I own a subsystem, there are only so many sacrifices or new ideas I’ll try if no one else is making progress or testing boundaries. If I don’t trust that we’re all trying to deliver the winning product together, there is only so hard I can work, and so creatively I can think, to achieve the win on my own.
Essentially, you are trusting in progress to the vision, including performance, cost, and timing. Your trust that we can achieve the vision is increased through transparency of progress towards it. And therefore, product development benefits greatly from transparency not just of schedule attainment, but also in terms of system or subsystem performance outcomes.
Finally, transparency helps us solve problems. We can’t solve the problems that we cannot see. Granularity helps us detect problems while they are small, and high cadence helps us solve them sooner, but we can only solve them if they are also transparent. See a problem, fix a problem. This should be going on throughout the product development process.
We cannot hope that problems will work themselves out in the end. A common behavior in product development is to encounter a problem, and then have faith that it will be solved. After all, why create a lot of noise and angst over something that isn’t a problem; let’s wait to see if it’s really a problem. However, this lack of transparency is more successful at delaying resolution than creating resolution. Product development teams that practice surfacing problems early in a transparent way do not result in more engineering design changes than those that do not. However, their engineering design changes occur earlier, which ultimately is cheaper and creates less risk than delay will. If sunshine is the best disinfectant, then transparency is the best solution for problems.