Dude, Where’s My Predictable, Growing Revenue?

XaaS Key #2:  Right Product And Service Design

Part 4:  Three Tough Decisions

So far in this series I’ve discussed product/service design and pricing, offering some rules for how to successfully create the right offers for customers.  In offering XaaS, however, you’ll confront some difficult decisions that can’t easily be solved with rules.  So here I’d like to lay out the “open issues,” tradeoffs, and challenges that are not easily solvable – but at least you can be aware of them.  

Most of these relate to achieving the ultimate success for XaaS plays:  becoming a platform.

Platforms:  Make the World Your Stage

I’ve heard, and even heard myself saying, things like this:

• “We want to be the operating system for lighting.”
• “We want to be the IoT platform for Smart Cities.”
• “We want to be the SaaS platform for human resources.”

We all know that ‘anything-as-a-service’ pales as a buzzword compared to platforms. Platforms are the holy grail of business:  occupying a place in the ecosystem that everyone else must go through to make money.  

Good platforms are value-added toll booths, giving you access to customers along with a treasure trove of support and analytics.  Bad platforms are just … well, toll booths that annoy customers and other ecosystem players alike.

Many companies contemplating XaaS offerings are aiming to become a platform, and charge others for the privilege of doing business with the rest of the ecosystem.  But very, very few get this right:  after all, there was only one Steve Jobs, and Apple expended considerable effort creating the Apple University to try to replicate his genius after his passing.  

So, central to many of the challenges of designing XaaS offers is the platform question.

There are three tough strategic decisions to make in product and service design and pricing – mostly related to seeking a platform role:

1.     Penetration/adoption pricing versus premium pricing

2.     Closed versus open systems

3.     Future-proofing versus replacement cycles

Let’s dig deeper into all three.

1.      Penetration Versus Premium:  Pay Me Now, Or Pay Me Later

In my last article in this series, “Mixing It Up – Blended Product/Services Offers,” I noted that hardware companies skew towards capturing all value in a single, one-time sale.  For hardware companies looking to capitalize on IoT, a common means to offering services, the preference will be to use tried-and-true pricing strategies. So new product lines are priced at a sizeable premium compared to existing products, and then prices decrease, often around 30% per year, as competition, commoditization, and familiarity take hold.  This strategy isn’t necessarily bad – after all, it has served companies well for ages.   

Startups also often follow the premium pricing approach since they often lack the luxury of being able to wait to capture value. I know of XaaS startups whose strategies include making implementation a profitable, paid service, in order to maximize revenue now.

However, if you are trying to establish a platform, your strategy might be different. If you want your platform to offer your own or third-party future services, or are trying to create an industry-wide standard, you might to price lower in order to drive penetration – before someone else does.  And you won’t want to charge customers to implement your product or service as it just creates another barrier to penetration.  No doubt a lower price will depress your revenues and profits now but it has the potential to capture sufficient market share to make yours the platform of choice. 

In either case – make your call on penetration versus premium pricing.  And stick with it.

Example:  Pricing for Penetration.  In my second article in this series on pricing design, I noted that Adobe priced Creative Cloud well below what many thought was a reasonable price.  Creative Cloud replaced a “perpetual” (buy it once, own it forever, but with no upgrades) product priced around $2,500 with a subscription policy.  Using the simple math I laid out in the previous article, Creative Cloud could have been priced at $100/month.  

It wasn’t.  Instead it launched at $50/month, with promotional offers as low as $30/month.  The lower $50/month pricing fulfilled several key strategic objectives:

• Proof of concept:  rapid conversion of the Adobe customer base to Creative Cloud built strong early subscriber numbers, helping to demonstrate the validity of the SaaS approach.  
• Standard:  it cemented Adobe’s role as a creative industry software standard.
• Platform:  it also created a platform for offering new applications, including third-party applications.

Example:  Pricing For…What?  A durable-goods manufacturer I worked with struggled with how to package and price XaaS offers as it introduced new IoT-enabled products.  Some camps in the company argued for low, penetration-based pricing to build a sizeable user base and data sets that could be monetized in the future.  Another camp insisted all new products should be priced at a (huge) premium, then over time lowered in price, following the usual product pricing strategy.  This camp also argued that, since future revenue flows from not-yet-developed emerging services and data monetization could not be accurately forecast, the penetration pricing strategy could not be followed, or even trusted.  Regardless of which camp was right, the point is that pricing arguments delayed the launch, costing the company critical time in establishing a platform play.

2.     Closed Versus Open:   One Big, Or Many Small

We’re all familiar with closed versus open platforms:  iOS versus Android, Amazon Kindle versus Barnes & Noble Nook…the list goes on.  Even bicycle components can be open or closed platforms.  Until recently, Shimano and SRAM components were relatively interchangeable, whereas Campagnolo components only worked with other Campagnolo components.  (Much to my relief, I can now use a Shimano Ultegra cassette on my Campagnolo Potenza groupset, saving me the cost of a new hub for my custom wheel … but I digress.)

Product companies face a multifold predicament when offering services on top of their products:  Will their services work only on their own products?  Will they allow services from other vendors to work on their products?  And will their products work together with other vendors’ products, in a total solution, or only their own products?  (Figure 1)

It’s a tough decision, with multiple tradeoffs.  Many textbooks have been written on this subject, so I’ll focus purely on the issues for companies new to XaaS, particularly hardware companies.  

If you use a walled-garden approach in your transition to services, you could realize significant benefits:

• All mine:  You will capture 100% market share of products and services in your solution – since you lock out your competition from your product and service solution.  
• I’ll take more:  You potentially also capture higher market share than usual, since every product and service in a given solution must come from you.  
• Better together:  Also, you may speed up adoption, since you design and develop all of your products to work seamlessly together, and don’t have to conduct costly and laborious interoperability testing with others.

But this comes with significant risks:

• You’re not alone:  You may not gain very much market share in the overall market – unless you are clearly first, and clearly better.  It’s unlikely your traditional competitors aren’t already developing their own services-enabled products and suites of services.
• I’ll get back to you:  You may stunt the growth of the overall market, since customers need to make permanent decisions on which vendor’s solution to select.  They may not have enough information for this.
• Variety is the spice of life:  Market growth could be slow since customers may be accustomed to mixing products from several vendors, and don’t want to be told to purchase a full solution from one vendor.  For example, in the lighting industry, very few full large-scale lighting projects such as large office buildings or outdoor city lighting come from a single vendor.
• I thought this would be easy:  Finally, if you have limited experience with developing new apps – a reality that most incumbent product companies considering IoT have had to face – you face the prospect of slow growth of your services revenue.  Since you won’t be enabling other companies with more applications experience to access your platform, customers can only use the applications you develop, as you learn to develop them. They will not have access to a selection of competing applications from experienced application developers, and may not see the value in your product + services offering at all. 

The core consideration for product companies is this:  fragmentation.  Commodity, mature markets can be very fragmented.  And often B2B sales are based on projects, with customer preference to have multiple vendors involved in each project.  In this environment, being closed may work at first, but ultimately will be challenging to maintain.  

Example:  Half-Open, Half-Closed, Fully-Confused.  A durable goods company I worked with struggled for years to determine whether to offer a completely closed solution of IoT-enabled products and proprietary applications, or to open up their IoT platform to third party applications.  “Opening up” was a completely novel and terrifying concept for a company, accustomed to fighting over individual unit sales and market share, and now dealing with a fragmented market characterized by sourcing products for individual projects from multiple vendors.  But this company had very limited information technology skills. 

Different groups within the company argued over closed and open approaches – and even launched the two approaches alongside each other.  The result was stalled development efforts, confused go-to-market, repeated market launch delays, very slow market adoption after launch, and missed opportunities.  

3.     Future Proof Versus Refresh:  (Don’t?) Play It Again, Sam  

We’ve all faced that time-honored question as consumers:  do I fix it, or do I replace it? But increasingly, we’re faced with a different dilemma:  do I need to upgrade it, or not?

Future-proof products can add functionality without the customer having to buy a new generation – at least anytime soon.  Refresh cycle products require the customer to buy a new product to get the new functionality.  Sometimes they’re called “forklift” products when the customer actually needs to remove and completely replace the older-generation product.

If your goal is to be a platform play, it’s not obvious whether you should make your products future-proof or refresh-oriented.  Each approach has both advantages and drawbacks for vendors: (Figure 2)

Let’s focus on one of these factors, as an example:  uncertainty.  A former client of mine, a new-entrant telecommunications company, asked us to create a product and services strategy.  My manager on the strategy project suggested a platform strategy, including the required network and services components to enable “not-yet-invented emerging services.”  A client team member then asked, “Can you give me an example of a ‘not-yet-invented emerging service.’”  My manager innocently replied, “Well, no, because they haven’t been invented yet.”  All humor aside, the point is important:  it’s hard to predict where customer needs will be in 5 months, let alone 5 years, but future-proofing does require making tough decisions on functionality and product specs.  This is especially true of white goods with a long lifespan.

Of course, the most important perspective on these two approaches is the customer’s:  (Figure 3)

Again, let’s focus on one of these, for example, “forklifting.”  For cyclists, “What do you ride?” doesn’t refer to frame brand or material.  It refers to components, or groupsets.  Shimano and SRAM groupsets aren’t rebuildable: if a part breaks in your Shimano gear shifter, you’re buying a new one.  They behave more like refresh products.  Campagnolo components, on the other hand, are rebuildable, and highly backwards-compatible as long as the number of gears does not change, making them somewhat future-proof.  They behave more like future-proof products.  

However, all groupset manufacturers break the future-proof mold when they add more gears to the cassette (rear gears).  The vast majority of cyclists don’t care whether there are 10 or 11 gears in the rear cassette – except when you break a part in a gear shifter, find out the part is specific to the 10-gear version and has been discontinued, and you have to buy an entirely new groupset.  Because of one broken part, and a generation-change in product by the vendor, all of your other components are now obsolete and must be removed just to replace one faulty part.  (Yes, this happened to me. And yes, it annoyed me to the point that I exercised my right to change vendors.)  In this case, vendors are forcing you into a refresh situation, when you thought you were owning a future-proof product.  

We All Get Trophies!

I’m not saying there is a right or wrong approach on any of these three critical decisions:

1.     Penetration/adoption pricing, versus premium pricing

2.     Closed versus open systems

3.     Future-proofing versus replacement cycles

I am saying, however, that you can thoughtfully analyze your situation – your market, your customers, your competition, your capabilities – to come to the right decision.

What’s Your Take?

I’m interested in your take – especially if you work in a product business that has considered XaaS offerings, and/or considered platform plays.  What challenges have you faced?  What are the tough decisions you have confronted? Comment here, or feel free to contact me. I’d love to hear from you!