Years ago, I read a book about Airbus and the thinking that went into the scalable product design of its aircraft. I no longer remember the book’s name, but one idea stuck with me. In fact, I think it influenced how I thought about product design when we were building ROI Solutions.
The idea was remarkably simple: if you’re going to build a family of products, don’t make people relearn the product every time you build another one or introduce new features. That sounds obvious. It isn’t.
For decades, Boeing and McDonnell Douglas dominated commercial aviation. As air travel grew, so did their product lines. Airlines needed different aircraft for different jobs. A route carrying 100 passengers obviously had different economics than one carrying 300. A short flight between regional airports had different requirements than a transatlantic flight. So, manufacturers built different airplanes. Boeing gave us the 727, 737, 747, 757, and 767. McDonnell Douglas had aircraft ranging from the DC-9 through the DC-10 and eventually the MD-11. It made perfect sense. Different-sized problems required different-sized products. But another problem hid inside that solution.
A Family of Products Isn’t Necessarily a Product Family
Think about cars. If you know how to drive one Volvo, you can pretty much drive another Volvo. The vehicle might be bigger. It might have more features. Parallel parking might require a little adjustment. But Volvo doesn’t decide that because you bought a larger model, the turn signal should suddenly be somewhere else. You don’t get into another model and discover that Volvo has moved the brake pedal; the basic experience remains familiar. [Note: this feature portability doesn’t exist in all car manufacturers].
Aircraft, historically, wasn’t always designed that way. A pilot trained on one Boeing aircraft couldn’t necessarily move to another Boeing aircraft simply because both had “Boeing” painted on the side. Different aircraft could have significantly different cockpit layouts, systems, and operating characteristics. Moving between aircraft types meant additional training and certification. That costs airlines real money, and it also makes their workforce less flexible. If an airline has plenty of pilots available, but the pilots qualified on a particular aircraft are somewhere else, having “enough pilots” doesn’t necessarily solve the problem. Airbus looked at this differently.
Airbus Didn’t Just Design an Airplane
With the A320 family, Airbus made commonality central to the design. The A319, A320 and A321 weren’t simply different airplanes made by the same company. They were designed as members of the same family. The cockpits looked and behaved alike. Controls were in familiar places. The underlying flight-control philosophy was consistent. Airbus used fly-by-wire technology and standardized cockpit conventions across the family. That meant something enormously valuable to airlines: knowledge became portable. A pilot’s investment in learning one aircraft had value when moving to another aircraft in the family. The same idea extended beyond pilots. Common components and design approaches could simplify maintenance, parts, manufacturing, training, scheduling, and airline operations.
Airbus wasn’t eliminating complexity. An A321 is still different from an A319. But it seemed they were deciding where complexity belonged and, whenever possible, it didn’t belong with the person using the product. That distinction has stayed with me.
When we develop products at ROI Solutions, we deal with surprisingly similar product questions. Our customers are nonprofit organizations, and nonprofit organizations can be incredibly complicated. They have different fundraising programs, organizational structures, constituencies, business rules, terminology, and ways of working.
The temptation in our industry has always been to accommodate that complexity by building increasingly customized products…
Customer A needs something, so you build it for Customer A.
Customer B works differently, so you modify the product for Customer B.
Customer C has another requirement, so you create another variation.
…Keep doing that successfully for enough years, and you can end up with dozens of individually satisfied customers sitting on top of an increasingly unsustainable product. You have essentially built the software equivalent of an airline where every airplane has a different cockpit.
We take a different approach by making our products configurable enough to accommodate genuinely different organizations without becoming a different product for every organization. If we solve something useful for one customer, we consider whether it could become useful to many customers. When we create a new capability, we want it to behave like the rest of the product. If someone learns how one part of the product works, that knowledge should help them understand another part. In that sense, we’re building the A320 family, not another collection of unrelated airplanes. That distinction “configurable versus customized” is enormously important and vastly scalable.
Scalability Is About More Than Technology
When people in technology talk about scalability, they usually talk about infrastructure, and those questions generally are:
- How many transactions can the system process?
- How many users can it support?
- Can we add servers?
- Can the database handle another hundred million records?
Those things matter. But I think that’s only one kind of scalability. A product also must scale cognitively: Can someone who understands one part of it reasonably understand another? It must scale operationally: Does every new customer require another group of people who possess specialized knowledge that nobody else has? It must scale economically. Does adding the 100th customer cost roughly what adding the 10th customer did, or has complexity made each new customer progressively more expensive? And it must scale organizationally. Can your support, implementation, product, and engineering teams develop expertise that transfers across customers and products? This is where commonality becomes incredibly powerful.
The more things you can make familiar without making everything identical, the more valuable everyone’s accumulated knowledge becomes. A customer-service person gets better because what they learned yesterday applies tomorrow. An engineer understands the patterns behind the product instead of learning a different architecture for every customer. A customer moving into another part of the application isn’t starting over. Just like the pilot moving from one Airbus cockpit to another.
Standardization Isn’t the Enemy of Flexibility
There is a danger here. Standardization can become rigidity. The answer isn’t to tell customers, “This is how our software works, so this is how your organization must work.” That isn’t good product design either. The trick is figuring out what should be standardized and what should be configurable. Airbus didn’t decide every airplane should carry the same number of passengers. That would defeat the purpose of having different aircraft. They standardized what created leverage. That’s a very different idea.
A scalable product should allow variation where variation creates value while maintaining consistency everywhere else. I’ve come to think that this may be one of the hardest disciplines in product management. Customers will always have good reasons why their situation is different. And quite often, they’re right.
The product team’s job is to determine whether that difference requires a different product or whether the product can be designed so that one underlying capability elegantly supports many variations. Those decisions accumulate over years. Eventually they determine whether you have built a solid platform or a collection of exceptions.
The Turn Signal Should Still Be in the Same Place
I keep coming back to the automobile analogy because it makes the point so easily. You can make a small car and a large car. You can make an inexpensive one and a luxury one. You can make an electric version. You can add capabilities that didn’t exist when the original model was designed. But there is tremendous value in getting into the next vehicle and instinctively knowing where the turn signal is, and to me that’s what good scalable product design feels like. The product can become substantially more capable without becoming substantially more difficult to understand. Perhaps that’s the lesson I carried away from reading about Airbus all those years ago. They weren’t simply asking: How do we build the next airplane? They were perhaps asking a much more interesting question: How do we build so that everything we’ve already learned becomes more valuable?
That’s a question we keep asking every time we build the next feature, the next product, or the next generation of our company.
Key Takeaways
- Designing a family of products should minimize the need for users to relearn, enhancing familiarity and efficiency.
- Airbus exemplifies this approach by creating common avionics and control layouts across its aircraft family, enabling portability of pilot knowledge.
- ROI Solutions applies similar principles by developing configurable products instead of customizing for each individual client, promoting scalability.
- Scalability entails cognitive, operational, economic, and organizational aspects; familiarity across components amplifies team expertise and customer satisfaction.
- Good product design balances standardization and flexibility, ensuring that variation adds value while maintaining a consistent user experience.
