{"id":7078,"date":"2017-10-11T15:49:35","date_gmt":"2017-10-11T15:49:35","guid":{"rendered":"https:\/\/www.gosquared.com\/blog\/?p=7078"},"modified":"2019-11-28T11:13:32","modified_gmt":"2019-11-28T11:13:32","slug":"simplicity","status":"publish","type":"post","link":"https:\/\/www.gosquared.com\/blog\/simplicity","title":{"rendered":"Simplicity is a war"},"content":{"rendered":"

\"Simple\"\/<\/p>\n

\u201cFools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it.\u201d
\u2013 Alan Perlis (American computer scientist)<\/p><\/blockquote>\n

The default trajectory of all products and companies is to increase in complexity.<\/p>\n

Simplicity is a continuous challenge \u2013 it\u2019s something that is achieved over days, weeks, and months of dedication and obsession.<\/p>\n

Simplicity is so easy to lose, and it\u2019s always being eroded \u2013 by team members, customers, investors, new features, new pricing, new questions, and new answers.<\/p>\n

We\u2019ve written about the importance of simplicity before \u2013 primarily from a product perspective inspired by Dieter Rams: Good design is as little design as possible<\/a>.<\/p>\n

This post was originally titled \u201csimplicity is a battle\u201d, but it dawned on us that that\u2019s not strictly true \u2013 battles can be lost, while a war can still be won. Similarly, you can win battles while still losing a war. Simplicity is a war because it\u2019s eroded in small battles that occur daily, often faster than the blink of an eye. You can win many battles for simplicity, but still end up with a complex product or company.<\/p>\n

Simplicity is a war. And it\u2019s being lost with thousands of tiny battles.<\/p>\n

What is simplicity?<\/h2>\n

\"What<\/p>\n

Simplicity is the courage* to say no. It\u2019s daring to have an opinion. It\u2019s being bold enough to make a compromise for a subset of customers in order to make life better for a much larger group.<\/p>\n

Simplicity isn\u2019t about hiding buttons and options behind a curtain \u2013 it\u2019s about reducing the complexity of a system or interface into a structure that is easy to understand.<\/p>\n

Many people equate \u201csimplicity\u201d with terms like \u201cbeginner\u201d, \u201cbasic\u201d, or even use phrases like \u201cit\u2019s a toy\u201d. But \u201csimplicity\u201d can benefit everyone \u2013 even the most advanced and accomplished users of a product or system appreciate and value simplicity.<\/p>\n

The more advanced a system becomes, the more important it is for the system to have originated from something simple and elegant.<\/p>\n

Why fight for simplicity?<\/h2>\n

\"Why<\/p>\n

\u201cA complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.\u201d
\u2013 John Gall (American author and retired paediatrician)<\/p><\/blockquote>\n

Simplicity is a constant fight. But it\u2019s worth fighting because the rewards allow you to move faster, more confidently, and more aggressively.<\/p>\n

As complexity builds, everything becomes more challenging \u2013 customers find it harder to understand your product, your team struggles to understand where the quick wins are, small changes take considerable time, and big changes become even more terrifying because so many different concepts need to be considered.<\/p>\n

Fighting for simplicity often feels counterintuitive \u2013 you often find yourself saying \u201cno\u201d for very few reasons other than for the desire of simplicity itself.<\/p>\n

But a critical reason for erring on the side of \u201cno\u201d and for preferring simplicity is that complexity often takes you down a route that is harder to navigate away from in the future. Keeping things simple helps you stay nimble and flexible to change in the future. Adding complexity implies adding weight that can slow you down in later decisions \u2013 it can make it slower for you to reverse, and it can make it slower for you to change course.<\/p>\n

A high-level guiding principal we have: the less certainty we have around a decision, the more we should err on the side of simplicity<\/em>.<\/p>\n

How to lose simplicity<\/h2>\n

\"Tip<\/p>\n

Building a simple and easy-to-use product is extremely hard in the first place. But even if you manage it from day one, it\u2019s all too easy to lose that beautiful simplicity as time progresses.<\/p>\n

Adding more features naturally reduces simplicity<\/h3>\n

There\u2019s always a desire to add more to a product. Customers always want more advanced functionality. They want features they were used to with a tool they used before. They want features they think would be handy. They want features that are genuinely a great idea.<\/p>\n

A surefire way to build a more complex product, and add complexity to your sales process, your onboarding flows<\/a>, your customer success organisation, and your customer support docs, is to default to saying yes to feature requests.<\/p>\n

A better mindset when dealing with feature requests is generally to default to saying \u201cno\u201d when they come in. This is painful in the moment \u2013 \u201cno\u201d is always a tough thing to say, and it often results in frustration on the receiving end.<\/p>\n

But saying \u201cyes\u201d to features is dramatically more painful in the medium and long term.<\/p>\n

A yes can often feel simple \u2013 it can feel like a small feature you’re agreeing to. It can be just a button here, or a setting there, or an extra field in that one screen. But as humans we tend to be far too optimistic when thinking about the complexity and weight of any given feature. We blinker ourselves into believing the feature is just that piece of the product, but we forget the consequences.<\/p>\n

The consequences of saying yes to even small features are often numerous and heavy:<\/p>\n