For Starters #52: Price is Mostly Packaging
"Context is that which is scarce." - Tyler Cowen
I see too many early stage founders believing there’s something wrong with charging different customers different prices for “the same product.”
It might be the same product, but almost definitely each customer requires different packaging to make the product useful in their context.
Price is every current feature and benefit (real and imagined) compressed into a single number.
Many of the most valuable features and benefits have nothing to do with the value proposition of the underlying product, itself - but everything to do with the context the product is used within…the packaging.
Just to name nine;
speed of fulfillment
volume of fulfillment
reliability of fulfillment
quality of fulfillment
level of support
level of integration with existing systems
payment terms
schedule of fulfillment
ability to collaborate with others
Each of these is important to different customers for different reasons. Each of these is already baked into your price - to some unspoken degree. Variations on them could make the product more (or less) attractive to different customers.
This is such a common practice we often don’t even notice it all around us.
The obvious, and oft frustrating, example is in airline seats. Takeoff date/time, landing date/time, class of service, how urgently the need to get there, the number of connections - none of these are about the core value proposition of the flight: arriving at the destination. All of them impact the price paid and comfort level of the passenger.
A couple examples closer to home:
I was talking with my town’s Community Services team about pricing for their rental facilities. Think; local park shelters for birthday parties, auditoriums for community theatre productions, practice fields for local kubb friendlies, etc, etc.
Even in an organization with maybe 30 rentable spaces (products) there is no single price for a given space. Every price is a combination of:
which space? (inside, outside, big, small, these amenities, those amenities)
who you are? (resident vs non, individual or group)
when are you renting? (weeknights, weekends, school days, non-school days)
how long are you renting for? (once, ongoing series)
The spaces themselves remain unaffected by any of those variables.
There’s not a sophisticated revenue maximization strategy at play, quite the opposite. Under this packaging structure is a public service mandate - to ensure space is available at an affordable rate to individual residents.
Everyone else pays a premium.
Similarly, about a year ago the major Twin Cities homebrew supply store went mail-order only. The local homebrew community didn’t fully appreciate the convenience of having multiple retail storefronts distributed around the metro for last minute supplies was. Now, we (I) were forced to rethink the value equation.
Ordering online anytime day or night is more valuable than driving across town within limited opening hours.
Driving across town costs something in time, energy, prioritization, that cost while invisible is probably equal to shipping costs.
Getting the items in an hour is substantially more valuable than getting them between 3-7 business days.
All of this is true, independent of which hops or how much malt I bought.
How does this translate to software pricing?
I was talking with a SaaS founder about their emerging product. It’s got a clear niche, a solid value proposition, and multiple pricing tiers. What it didn’t have was packaging that fit my needs. And while I do have a very strong occasional need for it - I don’t have a continuous daily or weekly need. As the data I’m looking for a) doesn’t change frequently but more importantly b) I can’t incorporate new data much quicker.
(If you remember from For Starters #33, all this means I’m probably not a customer! That’s OK.)
It turns out very little of pricing is about the core functionality of the software, and most of it is about the packaging around the core functionality.
The software, at the bare metal (think command lines and API calls) is both powerful and difficult to use. It’s brittle and error prone. It needs a trained and attentive operator. Now, introduce any kind of graphical user interface, some error checking, and basic security policies (e.g. sanitize your database inputs) and the operator no longer needs to be as attentive or as well trained. The underlying value proposition hasn’t budged. We’ve just made it more usable. All of this is 100% packaging atop the core value proposition. The software is absolutely usable without the UI, but only the most desperate customers would.
Availability. Software that only runs on the sole developer’s machine is not very valuable to the larger organization. Software available whenever it’s needed - on anyone’s machine - is substantially more valuable, but takes more effort to get there. Even then bug fixes, security fixes and other things eat into 100% availability. 90% availability translate to 3 days of downtime each month. That sounds absolutely unacceptable, but would you notice if it was 45 minutes either side of midnight? By contrast 99.99% availability means 52.6 minutes of downtime a year, and 99.99999% ("seven nines") translates to 3.16 seconds of annual downtime. Each of these is a magnitude different level of effort, that has everything to do with the infrastructure the application is on and little to do with the application itself.
Service. is there a dedicated support person, are they accessible 24/7 phone call or just text chat during normal business hours? Or is there just user forum? Or are customers completely on their own?
Is billing handled monthly, annually, based on some usage volume, or ever
I would even bet, in this era of software-as-a-service, some customers will pay to stay on a given version for an extended period of time - just to avoid the disruptions caused by continuous changes to the UI.
Integration into other systems and protocols (or not), e.g. HIPAA, SOC2, single-sign on, corporate IP & data-retention policies
Collaboration with other users (or not).
Some customers require lots of these to create the right context of their use. For others, it would be all be a complete waste.
There’s strategic value in laying all of these out on a grid and pricing out the different combinations targeting different customer segments.
I’m reminded of this pricing framework I sketched out some twenty years ago that became the foundation for the tiering in one of my startups.
What’s the most surprising bit of packaging you’ve been asked to provide a customer?