The Difficulty of Building Simple Products
Building something effortless takes a lot of effort. Why not to ship suboptimal products, the hidden cost of complexity, and a way to see whether our product is like a hammer or an airplane.
👋 Hey, it’s András here! I write about all things product management: concepts, frameworks, career guidance, and hot takes to help you build better products. Subscribe for each article to be delivered when it’s out!
What’s the simplest product that first comes to your mind? For me, it’s a weather app. The application that already serves you relevant content without setting anything up. No fiddling with a registration, choosing content preferences, or customizing the app theme.
And a lot of people base many decisions on what’s displayed there: how warm they dress up for the evening, whether they organize that outdoor activity for the next day, or if they should take an umbrella when they leave home.
But to get this effortless experience, there is a ton of complexity behind the scenes: the app needs to correctly determine the location, pull up the data from one of the available sources, and visualize the forecast within a second. And doing these things reliably.
Building simple products is difficult.
In this article, I look at the hallmark of simple but capable products, the indirect cost of complex experiences, and at the end, I present a framework for triaging products based on the effort invested and the user experience they offer.
Tip of an iceberg
Think about a lamp: it’s easy to buy one, plug it into the electrical outlet, and turn it on. Does not seem like a highly complex product in any sense. But what would the same lamp be worth without the intricate power grid system behind it?
Not much.
Many everyday products hide their complexities well. On the surface, we see the user experience and know what the solution is capable of, but we cannot fully understand the work that went into creating the product or what’s powering it.
Just like the tip of an iceberg: what’s visible is less than half of the whole thing.
For digital products, the under-water part is usually the research, the one problem worth building a solution for, securing a budget, recruiting experts, considering many possible alternatives, settling on the final solution, and creating a frictionless experience while making the application reliable and performant on a scale. And if it’s done right, enough customers will be interested in the product to make it a business.
But on the way to building simple products, it’s easy to start cutting too many corners. And we can only play around with the scope, time, or available resources.
What’s an acceptable compromise in terms of user experience, technical excellence, and scalability? Finding the right balance is challenging, and too often we’re encouraged to ship something suboptimal just to get it out the door.
If this happens, let’s remember that every new feature adds to the complexity of the overall product. And if shipping suboptimal solutions become a pattern, we’ll be forced to invest heavily to counterweight that complexity.
So what’s that investment exactly?
The hidden cost of complexity
Imagine writing a five-page essay after every button, checkbox, input field, and other interactive element your product/feature has. How many pages would you end up with?
This exercise roughly illustrates how much communication a product manager and the rest of the organization need to do when documenting, announcing, selling, and supporting a solution.
But that’s not all of it.
The hidden cost also materializes in…
Hiring for support roles: the number of customer support and training staff, and how deeply technical expertise they need.
Training investment: training customers and internal colleagues, or educating employees when they join the company.
Building on top of the solution: the complexity of the user flow, the crowdedness of the interface, architectural complexity, or the always present internal knowledge gap.
Customer satisfaction: users getting lost in the solution, the feeling that getting things done takes a significant time, and not falling in love with the product—thus considering competitors easier in case there is an attractive offer.
If you use Slack, you might be familiar with how its messaging notifications work. If you mute a channel, you won’t get notifications from that discussion channel. If you activate “do not disturb” or manually pause notifications, all notifications will be muted then.
What sounds like simple logic for the user, ends up being a complex diagram of decision points for the company. Again, we see the tip of the iceberg (customer experience), and everything that’s underneath it (complex but coordinated flow):
In addition, behind-the-scenes complexity can also work against us if we invest in the wrong area.
Imagine search engine “A” that provides 85% relevant results, but it takes two minutes to load those links. Then compare it with search engine “B” which would give 70% relevancy in only two seconds.
As a customer, which search engine would you prefer to use?
The one that invested in the right kind of complexity.
Product complexity matrix
The examples above illustrate that building a simple product is often difficult. Even if the source code is not complex, it takes an effort to figure out the details of an idea and then pressure-test it against everything that can go wrong.
When discussing complexity, we can talk about two types related to product development: the complexity for the company to build the product and the complexity for the user to use the product.
And if we put these factors into a quadrant, we can identify where our products reside:
On the lower left, there are products that are easy to build and easy to use, like a hammer. Products that serve a simple purpose and support 1-2 customer use cases that are used often enough to make it worth building.
On the lower right, we find everyday solutions that are complex to build but easy to use. The more people use it; the more effortless the product should be. Companies want to avoid answering thousands of questions daily if they fail to deliver on their standards.
On the upper right, we can usually observe specialized products geared towards a specific segment of users, intending to serve a wide range of use cases. Airplane cockpits or B2B products are typical examples where there is a high need for training, but also a high need for customization.
And last, on the upper left, we see failed solutions, or at best, temporary ones. If it takes a low effort to build something but a high effort to use it, the product will eventually fail.
Conclusion
Building simple products is difficult.
We must be constantly reminded of the complexity we expose to our users. Plus, building something effortless takes a lot of effort.
If we fail to do this, we might have to pay a higher price in the end.
But not everybody needs to build simple products. Sometimes, our users and the problems we’re solving require complexity, and that’s fine, as long as that complexity is well-managed. Nevertheless, don’t let this be the excuse to give up on simplicity, especially if it’s worth it.