Many paths (or: musings on making product decisions)

In the maintenance stage of a software product, product design can become a diffing problem. The designs were made at some point in time, but the product has evolved. Things were added, things were removed, and things were just implemented in different ways.

It’s impossible to keep design and development 100% in sync. In the later stage of a product, when you are maintaining it but also adding smaller features, you’re going to have a source of truth problem: both designers and developers want to know what the source of truth is. But building up the source of truth 100% in design (i.e. every screen has an equivalent in whatever design app you are using) is hugely inefficient.

Some teams tackle this problem by designing in the browser. We have done this before by creating HTML prototypes. This can be hugely beneficial for a part of the process. But if you are not careful, you are dragging along three sources of truth in your project: a design file, a prototype and the actual implementation.

It’s also quite difficult to find the people who can combine front-end skills with UI/product design skills (we are still hiring, by the way!).

Let’s assume that you are simply developing from design files. You observe that the implementation is 20% different from what the designs look like. Then, as a product manager, you also see that the designs are 20% different from the vision of what they should look like.

You can substitute your own numbers, but herein lies an interesting question: are you now going to brief the change via design or development? Are you going to try and affect the change by first having the perfect mock-up designed, or are you going to describe in words what you want in a development ticket, and let the devs figure it out?

Whatever you decide, now you have a communication problem. Communication within a software team is not easy to begin with. People with different roles have different concerns. There is software stability versus newness; there’s shipping software versus working software; there’s the actual use versus the theoretical beauty from a craftsmanship standpoint.

A complex software product is a complex problem with many layers. Sometimes people get confused about the way forward. It takes some seniority to see what is productive and what isn’t. I’ve seen companies waste weeks on wrong decisions. But not moving is a problem in itself. You can easily get stuck in unproductive discussions.

So, in conclusion, which path to take? There’s a thousand details that go into these kinds of decisions. But making that decision is what makes you a product manager.