In a previous post, I discussed the analogy of product management as editing. That the key to building and adding to the customer experience is too diligently reduce. To reduce options, reduce clutter, reduce obstacles. By editing correctly, we enable the product to go beyond just solving the customer problem by creating an experience of lightness and effortlessness that will live long in the user’s memory. The narrow path of success rests somewhere between reducing mental and practical complexity, even while increasing the power of the product. And it is precisely there that we see the major paradox at the heart of this analogy.
Product management is predominantly a game of addition. We build products, features, widgets, and gizmos. So it is all very well to say that reduction is central to the role, but at the same time, most of us are working every day on the very next thing to be added or appended to our products and platforms. This can be an exasperating mismatch between the ideal and the practical. What’s needed is a way to think about how to achieve reduction while simultaneously building. We need to think about simplicity.
In this, the first of two posts on simplicity and complexity, I will discuss how we can edit our products by using simplicity as our guiding light. To do this will require us to understand what simplicity means, and it’s different forms. I’ll follow up with an examination of complexity and the relationship to simplicity. Throughout, I will be leaning heavily on the work by John Maeda and his excellent (and short) book The Laws of Simplicity. I strongly recommend checking out John’s work. He’s an independent and nuanced thinker operating at the intersection of design, business, and product.
The core dilemma at the center of a Product Manager’s (PM’s) work is that often our value is determined by shipping, and shipping used as a synonym for adding more. More features. More functionality. More products. We do this in the name of solving customer problems and driving business value through customer value. Ultimately this translates into the simple equation that more product = more sales. Nothing will impact your bottom line more directly than new products and features. I’ve seen this directly at the SaaS company I worked for, and Joel Spolsky talked about this back in 2006:
With six years of experience running my own software company I can tell you that nothing we have ever done at Fog Creek has increased our revenue more than releasing a new version with more features. Nothing. The flow to our bottom line from new versions with new features is absolutely undeniable. It’s like gravity.
Joel Spolsky, Joel on Sofware
In John Maeda’s The Laws of Simplicity, he lays out ten laws and three keys that offer avenues of approach to achieving simplicity. As you read it, you can almost feel him wrestling with the paradox of writing a 100-page book with lists, laws, keys, and acronyms designed to explain a framework for simplicity. But within that paradox is the crux of the challenge. Just because simplicity is the goal does not mean how you get there is not a complicated and thoughtful process, or that the end product itself should be functionally simplistic. Therefore, the book is a wonderful analogy for how we must think when we build simple products. Achieving simplicity will require strong decision-making and ruthless pursuit of the goal of solving the customer problem while not getting in their way as you do so.
I will not list the ten laws of simplicity but will instead focus on two of them here, Reduce, and Trust. There is also a law on Differences which describes the symbiotic relationship between simplicity and complexity. I will explore that law in the next post. However, they are all worth reading and learning, so I highly recommend the book, or visiting his site http://lawsofsimplicity.com/.
Reduce
The Reduce law is the law of the editor. You must understand that with every option, every feature, and every widget, you are layering complexity into your product, even if what you are adding is designed to make the customer’s lives easier. Without careful thought, you are plodding, step-by-step, release-by-release, towards bloat and incoherence. To help tackle this, Maeda proposes looking for ways to Shrink, Hide, Embody (SHE). The fundamentals of reduction, however, comes down to this. Focus on the vital few.
The simplest way to achieve simplicity is through thoughtful reduction.
The Laws of Simplicity by John Maeda
To focus on the vital few is not unlike the principle of the minimum viable product (MVP) found in Lean methodology. What’s distinct here is that reducing to a minimally viable product is centered not only on functionality but also on what it will feel like to use the product. The customer should not only get the solution they need, but it should be delivered with a lightness of touch and optionality of design that will ultimately create a feeling of simplicity. That feeling, the emotion derived from simplicity, is what we want to achieve.
The Pareto Principle is commonly used by PMs as a way of setting out their MVP plans. I frequently use it myself. You say that by building x version of the MVP, you will solve 80% of the use cases. First, let’s acknowledge the inherent flaw here. Assuming your customer base is in any way diverse, the 80% use case is not a reality, because what is the 80% solution for one group will not be the same for another. Regardless, Pareto provides a useful approach tactic for reduction. Therefore, a nice twist on Pareto is to not only think of functionality and use cases but also the experience. Instead of, what is the minimum feature-set needed for the 80% use case ask, what is the lightest version that would delight 80%? What is the simplest MVP we could deliver? What are the patterns you are establishing now that will allow simplistic-driven development later?
It is a nuanced change but an important one. By nature, PM’s have a utilitarian drive. We want the most powerful solution for the greatest number of customers. But consider that our need to reduce, to edit, that solution is demanded of us anyway not by a passion for simplicity, but instead by facing-down the reality check that is the engineering estimate for your first MVP. Of course, that constraint is also positive and a required step. But we should also step out of the functional and consider the cognitive burden, and emotional response, the customer will have with a solution. Simplicity and emotion can also be the lens you use to inspect your product meticulously, frame-by-frame, that will allow you to start cutting so you can tell your story better.
Trust
The second most important law of simplicity is Trust. I’ve chosen Trust because of the times we live in (2020) when our gaze for how to reduce complexity and enhance productivity and functionality, is to look to ever more frequently to the machines. Not only do we use machines for raw computing power but also, increasingly, for decision-making. We seek to add more to our products by taking away more control, and ultimately determination, from our customers. This impulse is firmly in line with the spirit of simplicity. The fewer decisions the user has to make should be directly proportional to the simplicity and ease the customer should feel. But, this ease of use is tempered by another feeling—that of trust.
In simplicity we trust.
The Laws of Simplicity by John Maeda
A test of trust allows the customer to hand-over responsibility or decision-making to the machine the first time. Based on the outcome of that test, it is trust that allows us to do that again and again and ultimately rely upon the machine. It’s how a trial converts to a paid account. Trust is also crucial because it’s linked to another word that is top of mind right now: privacy.
Consumers from all points on the technical proficiency spectrum now understand how they trade their time, attention, and data with businesses via the products they use. To continue to use those products is to have a daily debate with them on whether they have earned their trust enough to continue to make that trade. Once that trust starts to be eroded, it can be hard to stop the questions and concerns from growing. Therefore, the stage is set for how we must think about all products, whether they capitalize on time and attention like a social network or media business, or are a straight-up monthly subscription SaaS platform. We must first understand where a trust trade is happening within our products and then search for ways to repay and reaffirm that decision continually.
It is easier to wrestle with this problem when it is writ large during the build of an entirely new product or feature. During such a time, you will be making large-scale decisions on what the customer must-do versus the machine’s responsibilities. But the problem is fractal. It looks the same all the way down. Consider the many micro-decisions that need to occur during any interaction, and you see how the customer-to-machine trade and trust repayment dialogue happens at all levels. However small, all interactions are moments to evaluate whether we can remove this decision or action from the customer’s purview. If the answer is yes, and we decide to hand that decision to the machine, can we consistently and predictably repay that trust? Will the customer understand what happened and feel the impact?
Think of this as a micro-financing model. With a charity like Kiva, they ask their donors to loan small amounts of money directly to individuals and groups in need. Should that loan be repaid, it can then be re-loaned to someone else. Not only did the individual benefit who received the loan, but the whole system did because the money circulates multiple times, compounding the good that it can do and encouraging repeat donations. Similarly, with our products, the customer is being asked to make micro-loans of their trust. Each of those loans requires repayment. They must understand, notice, and feel the benefit. Did they achieve their goal more quickly, or with fewer steps or distractions? Each time that loan of trust is repaid, you are establishing a system in which the customers have belief. With that belief, they will feel encouraged to invest more time and resources because the return on that investment is predictable and beneficial.
To edit our product, therefore, is to consider simplicity at the core of our decision-making. What we cut, and how we do it, should be in pursuit of simplification above all else. Other influences will, of course, impact our decisions. The iron triangle of scope, time, and cost never goes away. But if your north-star is a simple to use but powerful tool that solves the customer problem, then you are navigating a sustainable path for your product.
Up next is a discussion of complexity, and how that fits within the nexus of editing and simplicity.
Inspired by: The Laws of Simplicity by John Maeda