The Product You Want to Build vs The Product You Can Build

As a leader I have sat through countless product reviews. One of the most common patterns I've come across are team's convincing themselves that the product they are building is actually good when they know it isn't.

Denial isn't just a river in Egypt, it is a powerful cognitive force. But when teams think they have to ship, they will justify all actions. It is pretty easy to spot these teams. The product is sprawling. It is trying to do too much, not very well. Team members appear unenthused. They are back channelling concerns about their belief in the product they are building, the motivations of their team mates and questioning the strategy. The docs have holes or worse, depend on a "Field of Dreams" strategy (build it and they will come).

When I see these signs, I will ask, "Is this the product you want to build or is this the product you can build?"

The product you want to build is a product you have conviction in. That conviction can stand up to scrutiny. While people can disagree, they can’t fault your logic or insight. The product you want to build, the whole team is excited about and this excitement is shared by others.

The product you want to build is a product that everyone believes will help you learn. In many cases, learning will be far more important to the product than if the product is “successful”.

The product you want to build does not mean it has every feature you wish you could deliver. Nor is it some idealized north star/speculative future design.

The goal is to have strong conviction about the product you want to build, with clear understanding of the trade offs and improvement path.

The product you can build is a product defined by the constraints of the technology, the resources available and the market as it exists today. The product you can build answers “what can we get done in the time and resources allotted?” as its primary criteria for success.

These products start with good intentions. They recognize the sober realities they face and try to make progress inside the world as it is vs the world they wish existed.

The team will justify the product they can build as an “MVP” or a “Version 1” without any acknowledgement that the resulting product is just not that good. Perhaps worse, it will not help them learn enough to make future decisions. Through the process the team convinces itself that the product is good because it is what can be built. The team’s mantra is “something is better than nothing”.

In the end you need both elements to ship products. You need some combination of the product you want to build matched with the product you can build.

Teams need to be intellectually honest about which product they are building. They can not be held hostage by the constraints and then convince themselves that this is actually what they want to build.

When presenting work, be clear if the proposed product is what you can build or is it what you want to build. If it is more of the former, discuss what needs to happen to get to the latter. Show people the path to the product you want to build.

The worst thing a team can do is show up with an underwhelming product that is buildable masquerading as the product the team is excited to build. In the words of the immortal DJ Khaled… “congratulations you played yourself”.