Flexibility vs. Maintainability - ProductFTW #79

A common challenge in developing new technology is choosing between ultimate flexibility for users and your product team's ability to maintain that application. On the one hand, you allow users to set up and configure your app however they want, covering as many use cases as possible. On the other, you’re asking your engineers to maintain every possible configuration through the lifetime of that product.

People > Computers

In practice, most people are more flexible than computers. (Take a second to let that sink in because I know it looks like a typo. It’s not.) Companies spend hundreds of millions of dollars customizing enterprise resource management platforms like SAP to match their company's very particular workflow. I consider these fools' errands. In reality, the better path is for a company to build a well-researched, well-developed workflow and develop a strong product opinion. (See ProductFTW #23.) When you launch the product, you say, “This is a great way to do it, and we encourage you to retrain your team accordingly.” It sounds counterintuitive to ask people to flex to the software, but the reality is that most people don't spend time thinking about optimizing their workflow. They just start working.

I learned this lesson early in my career while working as a consultant at Deloitte, even though technology wasn't really our business at the time. I worked on a project for a large utility company, helping their real estate department consolidate process flows. Utilities, not surprisingly, have a lot of real estate. They own properties, hold access easements for power lines, gas lines, water lines, and so on. We were looking across this real estate division, which had five different departments, and helping them simplify their business processes. This project was straight out of Consulting 101. As a junior analyst, I mapped these processes using a specific piece of software (whose name I have since forgotten) to determine how to consolidate and improve them. 

One process that stands out to me now is accounts payable. You would think this is pretty basic: someone sends you a bill -> someone reviews it against a purchase order or budget -> it gets initially approved -> a later approver signs off -> it gets sent for payment -> payment is released -> process complete. Seems easy. 

Yet within this company, just in this real estate division, there were five departments, each with a different way of handling accounts payable. I can't imagine what it looked like across the entire organization. I remember very vividly sitting in a conference room, projecting my screen onto the wall, using specialized process management software, watching a couple dozen people arguing about which arrows should connect to which boxes. 

In the end, it taught me that it would have been better for someone to simply say: "I've looked at all five of your processes. I've identified the problems, the opportunities, and the legal and management requirements. This is how it should be done. Now, everyone go do it.” I don't know why it became an argumentative democracy. It's just accounts payable. (Please don’t forward this to your AP person so they can yell at me.)

Human Brains > Computer Software

The same kind of thing applies to software. We all want software that works exactly like our brains, but we can train ourselves to use other tools in ways software cannot. There is some level of flexibility you can build into the software, but every time you do, you reduce your ability to maintain and understand the product.

For product managers, a funny illustration of this is task management tools. Whether it's Jira, Asana, Trello, or now Linear, there's always a new interesting task manager coming out. (See ProductFTW #43 for Ellen’s take.) Personally, I can't stand Jira. I used to joke that the problem with Jira was that it was too configurable, and you could tell because companies had Jira administrators. 

When I worked at AT&T Interactive, there were around 400 engineers and three people who basically managed the Jira instance, which is absurd. Different teams had different flows and processes, and while that has some value (for example, a mobile deployment team does need a different process than a backend services team), it was way too complicated. You couldn't jump from Team A to Team B and understand what was going on.

We use Linear at Totavi today, as many of our clients do. It's a great modern tool, and the Linear team has strong opinions. There are certain things they simply say no to, and I applaud them for it. Saying no is a critical part of product. (See ProductFTW #6, #7, #23, and #65.) 

One thing they do let you customize is ticket states: you can define how many there are and what they are. That's a simple customization because, from a software perspective, you're just defining an ordered list. If, instead, you asked for sub-sub-statuses that lead to other statuses, you'd get increasingly complex control flows. Then, when you want to build something new, such as a mobile app alongside your web application, you have to figure out how to display all this data. It just gets more and more complicated.

Flexibility = Lazy Strategy

I actually think extreme flexibility is a sign of laziness in product strategy. You're essentially saying, "I don't know how this is supposed to work, so I'll try to make it work for everyone." It's often the result of companies that build products for larger customers, say a company with 20 or 40 customers, rather than 20,000 or 40,000. When you have a noisy mass of consumers, each paying $5 a month, it's easy to stay focused. When you have 40 customers each paying $10,000 a year, it's very hard to ignore any one of them. However, as you grow and scale, the cost becomes enormous. 

A company I worked with a few years ago demonstrated this: a quarter of their product and engineering staff was dedicated solely to keeping the app running day-to-day, due to the complexity and customization they had accumulated. That's a very high number of people who aren't building new features or driving the business forward, but instead propping it up and keeping it from falling over.

All of this speaks to why product leaders need to have strong opinions, grounded in consistent user research and a clear sense of who needs to be served. The Pareto principle, aka the 80-20 rule, is a great tool here. When I was at Green Dot, we conducted in-depth research on our users and identified 86 distinct reasons people used our cards. Three of those reasons accounted for more than 80% of users' responses. Those three reasons were the messages we pounded in marketing and the areas we focused on in product. If someone wanted to use the product for reason number 82, they certainly could. We also weren't going to explicitly support it or worry about it, because with limited resources, it would have been a distraction.

Flexibility = Maintenance = Costs

Even today, in the age of AI, when we think building and customizing software will be easier, there is a long-term cost that I don't think people are paying enough attention to. Custom software still has to be maintained. If you allow your team to customize everything for individual users, and that one user leaves, what do you do with the next user? It remains critical for product managers to think through who their users are, what the best path is, and how to teach users to use the product intuitively without making everything overly flexible. Focus on maintainability and opinion rather than pure flexibility.

About ProductFTW

ProductFTW is a weekly newsletter about product management, with a focus on real-life experiences in startups. We want to help product leaders be successful by giving realistic approaches that aren’t for giant tech companies. We know you don’t have a full-time product designer on each team. We know your software probably hasn’t been used by millions of people worldwide–yet. We’re here to bridge the content gap from building your product and team to scaling it.