The Terms and Conditions Effect

Why we end up with Frankenstein Products.

The Terms and Conditions Effect is what I’m calling the result of extreme prioritization of individualistic over holistic thinking. Where every individual subtask, is analyzed for relevancy in its own right, without any consideration from a holistic perspective. This effect is epitomized by a typical Terms and Conditions agreement: Each individual T&C is (theoretically) justified in its own right, and thus included in the overall T&Cs. However the end result is a giant document, that is never read by any consumer, and often never even shown unless explicitly requested, and thus the whole exercise provides zero value.

This is what I believe is the major cause of the Frankenstein Product: A product filled with features, where each individual feature’s inclusion was judged based on its own terms rather than as part of a whole product.

What brought this to my attention lately was an exchange with a colleague, which I am entirely oversimplifying here for the sake of brevity, where the request was for our internal dashboard to “increase the information to display area”, because there was too much unnecessary white space.

For this colleague, there was space that could be filled, so why not. While I, for the sake of playing devil's advocate, was focused on leaving the white space and limiting the information to what I thought was highly relevant.

To illustrate my point, imagine two products.

Product A: A product that does only one thing, really really really well.

Product B: A Product that does a million things, and really poorly. Like those swiss army knives with 100 tools, where even using the knife would be near impossible.

While the above is an extreme false dichotomy, we all know which would be a more successful product.

Other examples of the extent of the T&C’s effect include:

• Some Documentation — Where every piece of information that may possibly be ever required, for every obscure edge case or user scenario is included, resulting in a “complete” and extensive document which is impossible to navigate, and due to its complexity isn’t maintained and quickly becomes irrelevant.
• Company Tooling — Where each individual part of a company implements a different tool that suits their own process and then expects that every employee outside of their section can remember exactly how to use their tool, amongst the myriad of different tools employees should remember how to use inside the company.
• Emails — Both the ones we subscribe to and the ones we send. I don't know many people with zero-inboxes. How much info gets lost?
• Security — hands up if you’ve heard “You can never be too safe” or “There is no such thing as too much security”.
• Bureaucracy — “Its just one more form, no harm”
• Notifications — need I say more.
• Clothing — ever have trouble finding that one pullover you wanted to wear.
• Stuff — Here I’m talking simply about all the stuff we have, but never use or don't need, but piles up.

But back to the Frankenstein Product. Why does it come to this? I see three possible reasons.

1. Lack of clear direction. Without a clear set of priorities or clear product vision, everything is on the table. With no clear direction, answering the question “Why not include this feature” becomes an exercise in arbitrary rejections, or acceptance… over and over again…
2. Wanting to help. A sub-reason that assumes the first; As product managers, we want to help, solving problems is the most fun part, and while you may feel more pain regarding certain problems, in the end you want to solve them all.
3. Lazy, weak leadership. Maybe a little harsh…. I think that we’re all guilty of taking an easy short term position of just saying yes to a feature request, rather than taking a difficult short term position and engaging in a respectful dialogue explaining why a feature isn’t the best use of limited developer resources.

The previously mentioned discussion with my colleague ended in a concession: At the end of the day, everything is a trade-off: Quality v quantity, standardization v customization, focus v flexibility. While I’ve painted a picture above that sounds like we should never consider things in their own right, this shouldn’t be read as a dogmatic defense of only including features within some mythical core of a product. Rather I’m stressing the importance of considering the effect of adding a feature not only its own reductive right, but also in the holistic sense with the entire product in mind.