Do you understand your value exchange model? The economic value of a software-enabled solution is the benefits a customer receives less their costs.  How a customer exchanges money for this value represents a critical design decision for product leaders with substantial, long-term implications for their underlying technical and business architectures as well as the sustainability of their solution.  Design choices made by business leaders about value exchange directly influence the profitability of the software-enabled solution’s business model.  

An Overview of Value Exchange Models

There are six patterns of how value can be exchanged between customers and producers of software-enabled solutions.  We define these patterns as value exchange models. 

  1. Time-based access: the producer grants the customer the right to use the solution for a defined period of time.  For instance, many streaming services, like DisneyPlus, rely on time-based access to govern their value exchange.  In exchange for paying their annual (or monthly) fee, DisneyPlus grants customers unlimited access to the library of classic Disney movies and new streaming content for the period of time purchased.
  2. Transaction: with this pattern, both the producer and customer agree to a clear and measurable unit of work that defines the value exchange.  When that unit of work is executed, money changes hands between the customer and the producer.  For example, every time Airbnb connects a traveler with a vacant home or apartment, Airbnb collects a transaction fee.  The transaction fee is this value exchange model in action. 
  3. Meter: for solutions that rely on this pattern, the producer constrains a well-defined, identifiable resource available to the customer or tracks the customer’s consumption of a well-defined, identifiable resource.  As the customer consumes the resource, the meter makes a record of how much was consumed and when.  While this value exchange model is less common in  B2C products and services, examples of a meter can be found in many B2P and  B2B solutions.  Amazon Web Services (AWS) is an example of a value exchange model based on a meter.
  4. Hardware: e-readers, like an Amazon Kindle Paperwhite, or wearable devices, like an Apple Watch, are examples of a value exchange model based on hardware.  In the case of this pattern, the customer purchases hardware from the producer, and the hardware comes preinstalled with (multiple?) software-enabled solutions.  In some cases, the hardware will not function without the software – in fact, it is often the software which makes the hardware useful and valuable – but the exchange of value is not based on the software and its capabilities.  The exchange of value is related to the hardware and its capabilities.
  5. Service: for this value exchange model, humans use a software-enabled solution to deliver the value customers associate with the solution.  LegacyBox is an excellent example of this pattern in action.  Customers send LegacyBox personal media items (photos, home movies, and audio recordings), and employees at the Tennessee warehouse carefully digitize these items and return them, along with digital copies, to the customers.  In order to deliver on the Legacybox value proposition, humans must use a software-enabled solution to do the work of scanning and digitizing photos, home movies, and audio recordings.  Without humans, LegacyBox does not have a product to sell to its customers. 
  6. Data: with this value exchange model, the software-enabled solution creates unique data or content that the customer wishes to access.  A B2C example is CarFax,  which provides vehicle ownership histories. An even faster growing example are digital goods in video games or NFTs.  In the B2B world fortunes have been made – and lost – over data.

Profit Implications of Value Exchange

Now that we have reviewed the common patterns of value exchange for software-enabled solutions, there are some important observations to consider.

  1. Value exchange impacts usage.  Selecting an appropriate value exchange model is a non-trivial problem for business leaders.  On one hand, value exchange is closely linked to the customer’s perception of value as it relates to the solution and how the customer wants to use the solution.  On the other hand, the choices a product manager makes with respect to value exchange will influence how the customer uses the solution.  To illustrate, the current Value Exchange Model for DisneyPlus relies on time-based access for its streaming service which has allowed it to grow its membership and develop a steady stream of recurring revenue.  However, how quickly would DisneyPlus have grown if it relied on meter or pay-per-view (transaction) value exchange models?  What impact would these value exchange models have had on the profitability of DisneyPlus?
  2. Value exchange is baked into your software architecture.  Value exchange tends to be one of the least flexible parts of a software-enabled solution’s business model and architecture. Suppose the product manager at DisneyPlus made the choice to change from a time-based access value exchange model to meter, what would need to change in the technical architecture?  To begin with, an entirely new infrastructure would have to be developed to closely track usage – start times, end times, interruptions, and what people watched.  In addition, the business would need to create a much larger customer support capability to deal with dispute resolution and refunds.  A product manager at DisneyPlus could move from time-based access to meter but it will be a costly update. 
  3. In-license agreements with suppliers impact the solution business model.  All  software-enabled solutions leverage third-party components and/or content to deliver the value associated with their solutions.  This is a common strategy to leverage the various strengths of multiple suppliers in areas that are not core competencies of the business.  When leveraging suppliers in this way, it is important to remember that the value exchange model of the suppliers needs to align with the value exchange model of the solution or the producer may end in a world of hurt.  Suppose the product manager at DisneyPlus wanted to stream content from a supplier outside of the Disney network and the in-license agreement they negotiated with this supplier required DisneyPlus to pay a royalty to the supplier each time the content was viewed, aka a transaction.  This has at least three implications for the software architecture of the DisneyPlus solution:  it must distinguish between Disney and non-Disney content, which users are viewing Disney vs non-Disney content, and when they view the content.  The architecture must also honor the definition of ‘viewing’: is it when the viewer starts watching the content or when the viewer stops watching the content? Does it matter how long the viewer watches the content?  If the underlying technical architecture does not support the supplier’s need to be paid per transaction, the product manager will have to invest time to make that upgrade. The profit implication of an in-license agreement which requires DisneyPlus to pay a supplier per transaction while the members pay for time-based access is based on how much external content is viewed.  It is possible that a DisneyPlus customer could view non-Disney content at such high volumes they become a net loss for the business.  That is to say, the transaction fees associated with the amount and type of content they consume offset the fees they pay for time-based access to the platform.

Now that we have taken the time to dig deeper into value exchange models, I hope you can see why these design choices are very important to business leaders.  If you want to learn more about this topic or how to develop more profitable business models for a software-enabled solution, please check out one of our upcoming sessions of our new course, Maximizing Your Software Profits.