What To Build First — The Right Thing Or TheThing Right

Product folks, especially in early stage product teams, often have conversations that go like this.

• “Let’s create a separate bucket for the technical debt”. Or maybe, “Let’s put it on the backlog and we will get to it”
• Or “This is a non-functional requirement. Let’s handle it separately from business requirements”
• How about this, “The customer does not see it. We need to prioritize features, not technical spikes”

These are symptoms of a feature factory. These groups tend to equate more features to customer value and technical/operational excellence to cost. This mind set usually ends up being the self-defeating velocity killer that bogs down otherwise promising product teams.

The cost of NOT building the thing right (technically and operationally sound ) up-front is especially high once these teams hit scale where they might be releasing software, supporting customers, testing new features, maybe doing one-off pilots, usually all at once. Here we see a plateauing effect on release velocity.

Amazon (among many, many really smart organizations) have laid out the path, and the consensus overwhelmingly is to prioritize building the thing right over building the right thing.

So, the next time we find ourselves in a discussion to justify the business value of prioritizing building the thing right vs building more features, maybe we can use this picture to guide the conversation.