Simplicity vs. Complexity in Product Development
250 menu options or four? The experiences (and meals) could not be more different. For folks in the U.S. you most likely have eaten at one or the other — The Cheesecake Factory and In-N-Out Burger. These restaurants take polar opposite approaches to their menus. There is the thick binder of dishes that caters to every imaginable palate and a red-and-white board with three basic styles of burger and fries. Diners love both for different reasons. There is a lesson here for hungry product managers.
Product development is a continual process of evaluating insights and working to deliver solutions that reach the best possible outcome for everyone involved. Ultimately it comes down to knowing exactly what your customers need.
Recently I have been writing about a forward-thinking product development model that includes a holistic multi-stage process, a dedicated product team, and an organizational commitment to delivering real value. The premise behind that last one — value-based product development — is that the product team should prioritize what will bring the most value with the least effort and are responsible for measuring the actual worth of what was delivered.
Go searching online for ways to make these types of prioritization decisions and you will likely find a modified version of the Eisenhower matrix. Originally a decision-making tool for evaluating competing tasks against urgency and importance, the quadrants can be updated to reflect whatever two factors you are weighing — such as value versus complexity. This somewhat reductive method can be helpful when you are actively choosing what to prioritize within a release and balancing what you think will be most beneficial against the resources available. But this is just one way of looking at it.
When you are enhancing a software product you want to avoid adding unnecessary complexity at every stage — from the effort required to build to how it will interact with other functionality to the level of support customers will need to use it.
In our quest to create exceptional customer experiences, we can end up over-engineering our way out of value. This is a documented phenomenon called “complexity bias.” Most of us instinctively see complex solutions as better than simpler ones. But the truth of what is best for your customer depends on a variety of factors. For example, if your industry and use case are quite sophisticated, your product will be more complicated than a basic app intended for a general audience.
Complexity is not inherently bad. But it does require finesse to identify when it is needed. We know this well at Aha! because we are constantly working to deliver what the world's most sophisticated product teams need to build their own products. We do our best to also ensure that new customers can get going with our software without being overwhelmed. It is a hard challenge that is always a work in progress. Our experiences have shown a few tactics that can help you get the balance right:
Pick a lane
Would you rather use a product that does many things sort of well or one thing exceptionally well? It is perfectly acceptable to solve narrowly. And it is preferable when you just start building. But even as your product matures, it is easier to identify what supports your goals when you have a clear product vision that focuses on a specific problem. Commit to only what is most essential for that problem — not every potential scenario. Over time customer requests will reveal how you can help in other ways.
Feel more
Your customer is much more than a one-dimensional persona. These are real people with real problems who need your help. Tap into empathy so that you can better relate to their wants, needs, and wishes. A deep understanding of who is using your product enables you to make stronger decisions about what will bring the most value. Then you can better gauge whether the effort required to do so and how that additional functionality will impact the rest of your product will be worth it.
Connect the dots
Team structure has an impact too. Your organization might segment product development teams by technology, product functionality, or a defined user journey. This means that different people are working on different aspects of the product. And you can end up with friction points as a result. Ensure that teams communicate frequently and that the overarching product roadmap has customers at the center — not just how you build it.
Do less often
Saying “no” is underrated. So is doing the minimal amount required to make customers love your product. Product leaders can encourage the team to avoid over-engineering by questioning how they can do less and get the same result — conserving resources, avoiding waste, and creating space for customers to ask for more in the process.
Take bites
Wait for an entirely refreshed product or benefit from an enhancement now? There is often a propensity to slow down and put energy towards fewer (but larger) updates as a product matures. But you might get it wrong and customers have to wait. Rather than go all in at once, tackle solving a big problem incrementally. The speed of software development means that most SaaS teams can continually enhance products at a rapid pace. This gives you the chance to improve based on actual usage and feedback.
Keep cutting
Pruning a plant often results in a more beautiful bloom later on. The same is true for products. If you continually add new functionality without removing anything, you will end up with a leggy and unwieldy offering. Cut out potential work that is not aligned with the vision of the product. Continually refine existing functionality as well based on what is most needed and what customers actually use.
Everything you choose to add (or not add) to your product will impact your company, team, and customer — whether positive or negative.
What you build today represents the future of the business. Customers and colleagues across the company are relying on you to make the right choices — investing in the most value for the least effort. Some want a basic burger and some want to choose from 34 types of cheesecake. (And sometimes you want both.) There is no right answer. But product development teams have a responsibility to consciously choose what you are building and be able to answer why.
