XPlorations

Requirements

The word "requirement" creates an illusion - that just because someone said something, it is required. I've heard people speak of "desirements," and that's closer to the truth.

A set of requirements usually has parts that are more valuable, and parts that are less valuable. It also has parts that are cheaper to implement, and those that are more expensive to implement. We need to put those two bits of data together to decide what to do.

I once worked with a system analyst for a corporate IT group who was unable to see value in having pieces. She would develop a set of requirements, but could not prioritize them: "they're all equally important." The reality was, the requirements were a mix:

• regulatory requirements (implement by Jan. 1 or face substantial fines or shuttering of the business),
• new features to enable new business
• enhancements to existing features (make this dialog require two less clicks to get through), and
• minor changes (fix spelling).

These have very different characteristics: some support existing business, some support new business. Some have important deadlines, others don't.

What's the impact of an inability to prioritize? What happens if we insist on getting all these at once? The direct impact is an increase in risk: we risk shuttering the business for a spelling change. That's hardly what the real customer wants. There are indirect impacts as well:  people get confused about what's really important; they act like they have plenty of time and resources (whether or not that's true); they often don't seek creative solutions.

The Pareto Principle often applies: 80% of the value comes from 20% of the work. If we can find a creative solution for that 20%, we can come out way ahead.

Bundling

The previous section suggested that there is value in splitting things apart. But clearly there's value in having things together too: I buy a newspaper with many sections, and I don't buy my car in a kit.

Bundling lets us take advantage of differences in customer preferences. Let's take the newspaper for an example. Suppose the following table shows how much (in cents) people value each section.

If we sell the sections separately, the most we'd sell for is 15 cents, and the least is 5 cents:

If we were selling sections one at a time (each for the same price), we'd sell them for 10 cents, and take our maximum profit of 60 cents. But we know we're leaving money on the table: one customer would be willing to spend more, another less. But customers won't tell us what their real price is.

Bundling represents a way to capture this "excess": suppose we sell each paper with all three sections for 30 cents. Each customer is willing to pay that, so now we'll get 3 * 30 = 90 cents total income for these three readers. That beats 60 cents by quite a bit!

Another value in bundling is value that customers place on our integration work. As newspaper readers, we may be glad to have somebody else who goes out and selects the right mix of pieces for us. This can be a value of the brand: we trust that we'll get a consistent level of quality from the integrator. For newspapers, it's convenient to get a bundle in the morning, right on the doorstep (or at least at the foot of the driveway).

Bundling may have other virtues, but let's go back to the unbundling side.

Unbundling

Bundling can be nice for the supplier we described above, but there are lots of suppliers. What happens when we put them together in a market?

Consider a shirt. You can buy it in a nice boutique, with helpful clerks, carpeted floors, a live pianist, and so on. This bundle is combining your shirt with other aspects that make it an experience. Or, you can  buy your shirt at a "big-box" retailer, where you have to wander around a giant store crowded with screaming kids, select your shirt out of huge pile, and then stand in a long checkout line.

Some people want a shirt plus an experience, others just want a shirt. If the boutique were all that existed, the seller could charge everybody the premium. But when the discounter comes into the picture, the people who value just the shirt are pulled away. Worse still for the boutique, the ones who want a shirt but value the experience somewhat, are also pulled away. This puts the boutique in a dilemma - they can't compete on price without reducing the experience, and if they raise the price to support an improved experience, other customers will leave.

As suppliers, it's to our advantage to bundle, but competitors have an incentive to use the unbundled parts to compete.

Conclusion

So should we bundle or not?

The trick is that the value propositions aren't symmetric:

• a bundle is valuable to a consumer because it is convenient and the average price of the parts is "good enough."
• a bundle is valuable to a producer because it captures more of a customer's money.
• unbundling is valuable to a consumer because it lets them pay the minimum price for each part.
• unbundling is valuable to a producer because it lets them pick off the customers who most value a part.

As a producer, we try to balance these challenges like this:

• retain the ability to unbundle by not unnecessarily combining things
• retain the ability to bundle by combining parts into attractive offerings

In software, we have seen creative ways to make this modularization possible:

• frameworks
• components and glue code
• plug-in architectures
• keys that activate extra features in applications
• level and part editors in games, to enable users to create their own variations

These approaches all help a producer maintain the valuable parts, and provide the flexibility to bundle or unbundle them as the market supports.

[Written December, 2004.]

Copyright 1994-2006, William C. Wake - William.Wake@acm.org