​More and more companies are trying to become platform companies. Even if you are sure what that means and why it is important; how you get there still isn’t easy.

​
WHAT
While the term "platform" can have a broad range of meanings in just the technology market, the  focus of this article is API-centric cloud platforms. These provide software functionality that enable other developers to build complementary technologies, products, or services.

These developers can be internal to your company, can be working for your customers, or can be part of a partner organization. They can build capabilities that interface to and impact the UX (user experience), business processes or workflows, underlying data, or infrastructure (such as IaaS providers like AWS). 

​WHY
Platforms enable companies to create more value and even new business models by digitizing their services and connecting with other similarly enabled entities. For example you can connect with other platforms and/or different channels where your customers are consuming digital services: AWS, Salesforce, Uber,  Square, Microsoft (O365), SAP, WeChat, Slack, etc. 

​These business models can include direct revenue from customers and partners of these externalized services. They can be based on an up-charge to the cost of your core products (for customers) or the volume of API calls. However ideally, especially for partners, it should be based on the value of the specific use cases that are enabled by using your APIs. 
 
Yet what is often overlooked or at least undervalued is the indirect revenue impact of extending the overall value of your offering, as can it now be made up of both your products and services and the complementary products and services of your partners. This can lead to benefits such as a higher competitive barrier and a higher base cost of your core products. 

A platform can also enable a variety of partners that can help you build your company: integration partners, supplier partners, product partners, strategic / consultant partners, etc.  This platform partners ecosystem enables viral growth: the more APIs being exposed and the more data that is accessible leads to more paying partners creating more applications, integrations, and value; which leads to more customers using (and paying for) your platform and generating more data (and you externalizing more APIs); which leads to more paying partners creating more applications, integrations, and value …

Platform and APIs can also lead to happier or at least more easily retained customers (leaving you may also mean leaving or at least changing how they interact with vendors from your partner ecosystem) and a lower cost and higher win rate for big prospects.   The customization afforded in an on-premise world can be more easily replicated for SaaS when there is a platform.  Instead of saying "no, that is not on our roadmap" to a big prospect who needs some specific capability; your answer can more likely be "yes, you can do that via our APIs, let's show you how or introduce you to a third party integrator."  (This is certainly one of the few times you'd say "wow, the cloud is finally catching up to on-prem.")

​Later technologies such as blockchain could usher in new era of api-driven business models as Joe Liebkind contends. However much like the same way that 25 years ago we couldn’t imagine the value and capabilities the web delivers today; we have little ability to understand how the proliferation of blockchain’s distributed, trusted, transactional capabilities will impact our economy.
 
​
HOW
Whether building from scratch or undertaking the long, difficult journey to transform current (often on-premise often monolith) software to being services and API based; it's going to be tough.
 
In short, you need to consider your platform business offering like any other business offering: what are the objectives or strategy, how are you going to design, build, test and deliver it, how will your customer use it, and how will you manage and maintain it throughout its lifecycle.   (Themes emphasized by Carol Russell and Forrester’s Randy Heffner)
 
Another way to consider the business plan for an API or platform is the API Model Canvas (created by Manfred Bortenschlager based on the Lean Canvas).

The biggest mistake I have seen across a variety of companies is not to come to an agreement internally on what value the company wants to create from the platform. Is it direct revenue (often emphasized too much too soon), is it indirect revenue (expanding the offerings a customer can build or get from a platform-based ecosystem increases the possibility a customer will buy and not attrite) or is it the PR/marketing around becoming a platform company?
 
STRATEGY
Overall us product owners and GMs need to have an opinion on what the market wants; and consider how to build, buy, or partner our way towards that vision.  However unfortunately many of us just think about what we can build next and even worse what is the next incremental improvement to what we have already built (10% faster, 10% less bugs).

Platform strategy can also be considered through the lens of developer experience.  In an often quoted 2012 speech by John Musser at the O’Reilly Open Source Convention, he said that the
​5 Keys to a Great API are
·       Provide a valuable service
·       Have a plan and a business model
·       Make it simple and flexible
·       It should be managed and measured
·       Provide great developer support

Core SaaS Company Metrics include:

• Customer Acquisition Cost
• Annual Recurring Revenue
• Annual Contract Value (or Net New ARR)
• Churn (attrition)
• Cash Flow

https://blog.hubspot.com/service/saas-metrics
https://a16z.com/2015/08/21/16-metrics/
​

from: https://www.forentrepreneurs.com/saas-metrics-2/

Tien Tzuo CEO of Zuora says that there are only three metrics that really matter for SaaS companies:

• Retention Rate (how much ARR you keep every year)
• Recurring Profit Margin (ARR - Churn - non-growth spend)
• Growth Efficiency (how much does it cost you to acquire $1 of ACV)

http://www.slideshare.net/Zuora/zuora-always-on20123-saas-metrics-that-matter-12301579
https://www.socialmediatoday.com/content/3-key-metrics-matter-new-subscription-economy
​

Product Metrics:
As a product manager or product business owner you should choose from these core SaaS company metrics and a variety of other metrics to understand the performance of your product.  Track both the metrics themselves and the trends in your metrics such as:

​Marketing & Sales Performance (for different markets / segments)

• Customer Acquisition Costs (including marketing lead analysis and sales funnel analysis)        

​from: https://www.forentrepreneurs.com/saas-metrics-2/

General Product Health

• Main Value Proposition Metric:                                                                             Is your product achieving its described central benefit for your principal (or various) persona?  “Administrators can now save 50% more with our offering… End users can do this task 75% faster...”
• Other Product Usage Analytics:                                                                             In-product analytics help you see if your product is behaving and creating value as expected. Product engagement tools such as Pendo, Google Analytics, or Adobe Analytics can facilitate this analysis. Often enterprise SaaS or transactional applications are trying to lower the amount of time a user spends to complete a task unlike consumer or engagement apps which are trying to increase the total time a user spends in an application. 
• Overall Financial Analysis:                                                                                   This includes many of the metrics already mentioned and others such as Gross Margin, Customer Lifetime Value, and metrics which represent whatever other assumptions were made as part of the business case and pricing strategy.
• Internal Team Metrics:                                                                                           Obviously a broad variety of metrics could be considered including team sentiment and key stakeholder metrics such as feature release quality for Dev Ops or story points for Agile teams.
• Software Quality and Support:                                                                                Examples include open tickets (per customer), time to close (different priority support tickets) and open bugs. 

Further References:

• https://www.pragmaticmarketing.com/resources/articles/15-product-management-metrics-you-should-know
• https://280group.com/product-management-blog/25-metrics-matter-mobile-product-managers-2018/
• https://www.gainsight.com/blog/calculate-6-key-customer-success-metrics/
• https://productcoalition.com/critical-metrics-every-product-manager-must-track-c5f1e46e3423
• https://medium.com/product-breakdown/product-management-analytics-what-metrics-should-you-be-measuring-241609b1950d
• https://svpg.com/the-role-of-analytics

Recently in my blog on Product Frameworks, I mentioned some of the common components of a product strategy.  Previously I published some product strategy notes from the class I taught at Stanford in their Continuing Studies department.  (Also here is a video of me discussing Platform / ISV strategy while at Salesforce.com).

Basic Strategy Model
When I taught my class, the basic strategy model was:

• Where should we go?  Using market analysis & competitive analysis, financial plans, and success metrics.  
• Why will we be successful there? Using core competencies, mission, and competitive differentiation.

​Market & competitive analysis sources include:  clients, analysts, competitor websites, and other internet / published sources; and they can be utilized in one or more of a different frameworks such as (mostly from Gorchels The Product Managers Handbook)

• Market Segment Analysis (percentage of company sales, percentage of industry sales, market attractiveness, size, growth rate, etc.) 
• Basic Competitive Analysis (including competitive analysis via advertised positioning)
• Competitive Analysis Alternatives (direct competitors, substitutes, etc.)

This analysis can help you make decisions both about a specific product and about investments across a product line or portfolio. 

Product Portfolio Decisions
Other frameworks that help you make your portfolio investment strategy decisions include Porter's Five Forces for Market Competitiveness

Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant by Kim and Mauborgne 

 
​Boston Consulting Group's Product Portfolio Growth-Share Matrix

​Ansoff Matrix

However the trade-offs are rarely that simple as we need to consider a variety of factors:

• New Product vs. Mature Product
• New Market vs. Existing Market
• Short Term vs. Long Term Revenue
• Usage vs. Revenue
• Client A vs. Client B
• Research vs. Development
• High Risk vs. Low Risk

Agile Product Strategists
As stated in the Product Frameworks blog post, with the advent of Agile methodologies another viewpoint is that product strategy activities are owned by Product Strategists (External Facing Agile Product Managers):

• Understand market needs and competitors offerings
• Talk with customers; work closely with Sales, Marketing, Services and Product Marketing
• Position product and create roadmap
• Own launches, pricing, beta programs, and product revenue
• Consider next major release and next MRD

Lean Startup
An even more recent take on product strategy is what is prescribed for start-ups by Eric Ries in Lean Startup (Amazon, Medium, Wikipedia)

In short, startups have a vision and employ a strategy to achieve their vision (business model, roadmap, product roadmap, point-of-view about partners, competitors, customers), the product is the end result of this strategy.  Products are always evolving, sometimes strategies change, visions almost never change.

(from LightCastle Partners)
​​ 
An MVP for a proposed solution or product should be quickly defined and then  actionable (not vanity) metrics should be used to quickly iterate and incrementally improve a product for a better product market fit (Build-Measure-Learn feedback loop).  The two most important assumptions are the value hypothesis and the growth hypothesis.   Your MVP will have to be geared towards early adopters who understand the kinks haven’t been completely worked out for your innovative product.

Previously I listed a few product management resources including 

• Marty Cagan's book "Inspired" which I review here
• A list of product mgt associations, consultants, blogs, and courses 
• A few product management and business strategy books 

In those resources there are product frameworks that can help you consider what are the right activities at the right time during a product lifecycle. These include:

280Group's Optimal Product Process

Brian Lawley and the 280 Group has some great PM training and resources.
​​
Pragmatic Marketing Product Management Triad

(As previously mentioned, Pragmatic Institute is well known for its training.)

SirriusDecisions Product Marketing and Management Model

(Recently I discussed some of these frameworks with a few colleagues including Kathleen Marzahl and Rick Xu). 

One theme often found in these frameworks and in other descriptions of product management is a delineation between technical (execution, internal facing) and strategic (external facing) activities.

Often in Agile methodologies there are:

Technical PMs (Internal Facing “Agile Product Owner”)

• Lead daily stand-ups, get issues resolved that are in the way of developers making progress
• Own product specifics (PRD, specific requirements) and backlogs
• Work on dev/test/release process (or ultimately a DevOps culture with frequent releases) and bug log w/ Tech Lead
• Consider the next minor release

 
Strategists (External Facing Agile Product Managers):

• Understand market needs and competitors offerings
• Talk with customers; work closely with Sales, Marketing, Services and Product Marketing
• Position product and create roadmap
• Own launches, pricing, beta programs, and product revenue
• Consider next major release and next MRD

Here are a few additional resources that detail this distinction
ProductPlan Product Manager vs. Product Owner
Aha Product Manager vs. Product Owner
Agile Product Manager vs Product Owner at SmartSheet

Similarly Marty Cagan says establishing a strong product culture requires 

• Innovation culture: compelling product visions, strong product managers, empowered business and customer savvy teams product teams often in discovery
• Execution culture: urgency, high-integrity commitments, accountability, collaboration, results orientation, recognition, strong delivery management, frequent release cycles 

​The second edition of Inspired is even better than the first (which I reviewed here and used to be my favorite product management book).

It is the best articulation of how to be successful in product management and how to create successful products that I have ever read. It is impossible not to run into into insights about challenges you are having or have had as a product manager when reading it. (This can be a little creepy, how does he know about all these mistakes I have made, is he a psychic?)  

Do you want to get a job as a product manager? Read and re-read Marty’s book and steal at least a few of his insights for the interview - you’ll sound like a genius.

Some of the topics that resonated for me (I’m sure there will be different ones for you):

-Product management is distinct from other essential roles: design, engineering, product marketing, and project management (Chapter 1).

-Two inconvenient truths that often cause failed product efforts are: at least half our ideas are just not going to work (customers ultimately won’t use it - which is why you need customer validation early in the process) and it takes several iterations to implement an idea so that it delivers the necessary business value (Chapter 6).

-The three overarching product development principles from Lean and Agile which help you create successful products are (Chapter 7)
     -Risks should be tackled up front, rather than at the end.
  -Products should be defined and designed collaboratively, rather than sequentially.
     -Its is all about solving problems, not implementing features.

-You need a team of missionaries, not mercenaries to create the smallest possible product that meets the needs of a specific market of customers (Chapter 8,9).

-A product manager must bring four critical contributions to their team (Chapter 10): 
    Deep knowledge 
        1) of your customer 
        2) of the data 
        3) of your business and its stakeholders 
        4) of your market and industry 

-Product managers (PMs) need product designers - not just to help make your product beautiful - but to discover the right product (Chapter 11).

-Typical product roadmaps are the root cause of most waste and failed efforts in product organizations (Chapter 22).  It is all too easy to institute processes that govern how you produce products that can bring innovation to a grinding halt.  You need to try to wean your organization off of typical product roadmaps by focusing on business outcomes, providing stakeholders visibility so that they know you are working on important items, and by eventually making high-integrity commitments when critical delivery dates are needed (Chapter 60). Part of this is managing stakeholders which includes engaging them early in the product discovery process ideally with high-fidelity prototypes (Chapter 61).

-Products should start with a product vision in which the product team falls in love with the problem, not the solution (Chapter 25).

-Strong product teams work to meet the dual and simultaneous objectives of rapid learning and discovery while building stable and solid releases in delivery.  Product discovery is used to address critical risks: (Chapter 33)
    -Will the customer buy this, or choose to use it? (value risk)
    -Can the user figure out how to use it? (usability risk)
    -Can we build it? (feasibility risk)
    -Does the solution work for our business? (business viability risk)

-PMs can’t rely on customers (or executives or stakeholders) to tell us what to build: customer doesn’t know what’s possible, and with technology products, none of us know what we really want until we actually see it (Chapter 33).

-While Amazon has a culture of “write the press release first”, Marty suggests PM should write a “happy customer letter first."  Imagine a letter sent to the CEO from a very happy and impressed customer which explains why he or she is so happy and grateful for the new product or redesign.  The customer describes how it was changed or improved his or her life.  The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business  (Chapter 36).

-Product managers need to consider the role of analytics and qualitative and quantitative value testing techniques (Chapter 54).

-What it really means for a PM to be the CEO of Product is testing business viability: listening to Marketing, Sales, Customer Success, Finance, Legal, BD, Security, etc. before building the product (Chapter 56).

-Establishing a strong product culture requires (Chapters 66-67)
    -Innovation culture: compelling product visions, strong product managers, empowered business and customer savvy teams product teams often in discovery
    -Execution culture: urgency, high-integrity commitments, accountability, collaboration, results orientation, recognition, strong delivery management, frequent release cycles 
    (and it is hard to do both)
    
    

​There are several distinct pricing models for the on-going use of a Software-as-a-Service (SaaS) offering.  

​​​(Often there will be distinct tiers in these different models in which the cost increases as the capacity or capabilities of the offering increases.  Also there are often increasing discounts for an increasing amount of pre-committed volume; with an additional “overage” fee for when a customer surpasses that volume.)  


Per User or "Per Seat"
     Pros: Easy to calculate and allocate, encourages adoption and increased usage by users who have a license or seat.
     Cons: Discourages adoption across a company by creating a barrier (seat license) for potential infrequent users - who might later become frequent users. Slack’s per-active-user model partially addresses this by only charging for users have been active in the last two weeks (https://www.quora.com/Who-pays-for-Slack)
     Examples:  Salesforce (CRM).  Has a standard per user licensing model which increases as the number of users and the capability increase (currently from $25/month to $300/month). https://www.salesforce.com/editions-pricing/sales-cloud/
     This pricing model can sometimes vary across roles. 

Per Transaction
     Pros:  Enables adoption from the occasional to the power user which helps make the offering ubiquitous across the client's organization significantly increasing its value and impact. (This is SAP Concur's pricing model and its adoption is often aided by it being the only way an employee can be reimbursed for their expenses. Opinions are my own, but I work for SAP Concur).
     Cons: For some high price per transaction offerings, the lack of an all-you-can-eat model can limit usage for a given user or on a given project. 
     Examples: Concur https://www.concur.com/en-us/small-business/expense.
     Note: A variation of this per-number-of-transactions model is a per-$-of-transaction model.  For example it seems that Zuora, a subscription billing company (so helps actualize pricing models), bases their model on the amount of subscription revenue the customer has on Zuroa's platform. https://www.quora.com/Does-anyone-know-the-cost-to-use-a-solution-like-Zuora
https://www.mckfastgrowthtech.com/time-rethink-per-user-pricing-enterprise-saas/

Per User or Per Transaction Freemium (free is often ad-supported) 
    Pros: Enables easy adoption
    Cons: Must have compelling enough capabilities so that users will adopt the free version; but still significant enough differentiation that users will upgrade to the paid version. 
    Examples: Slack:  https://slack.com/pricing.  While Slack has a standard per user model, they also have a free version "for small teams wanting to try out Slack for an unlimited period of time.” So Slack doesn't limit time, but it does limit storage (and other premium capabilities) in the free version. 

Per Project
     Based on the value of the project (construction management) or portfolio (financial assets under management) that is benefiting from the offering.
      Pros: Encourages viral adoption for all users and third party partners across a project (leading to familiarity and possible adoption on future projects). The benefits of this type of model is that it encourages interactivity and adoption with all the participants involved; both within the subscribing company and by other third parties (often subcontractors).  
     Cons: This all-or-nothing approach makes it unsuitable for use on a small portion of a given project; and makes it difficult for the gradual increased adoption across an entire project. 
    Examples: Some financial services SaaS products and some construction management products such as Aconex, a construction project management tool. Aconex drives adoption of their  “project wide solutions" by including "unlimited access to training and support resources for every organization you work with.”  (From certain sources it seems that Aconex contends with the cons of this model by offering an enterprise model for companies that adopt their tool across many projects and a per user pricing model when the tool is just used for a small portion of a project). 
https://project-management.com/aconex-software-review/
https://www.aconex.com/pricing
https://www.eurekareport.com.au/articles/138999/aconex-xero-construction-sector

Per Resource Used (or Pay-as-You-Go): 
    This is more common in the rent-a-resource world of PaaS/IaaS where providers will charge based on resource usage; example per CPU or per GB storage.
   Example: AWS (https://aws.amazon.com/ec2/pricing/) which has per hour (and per second) pricing that can vary depending on required availability of service, "on-demand" is more expensive than "spare capacity" pricing.  

Per Outcome or % of Savings:
     While many offerings claim a hard dollar ROI, a pricing model which is based on a percentage of that return on investment (such as savings) can be compelling.
     Pros: Obviously this model aids adoption since the buyer only pays if they receive the guaranteed benefit.
     Cons: Only certain offerings have specific well-defined financial benefits such as savings. Also there are specific companies who have moved away from this models since it leads to disagreements with their customers over the specific savings achieved.
     Examples: Vat Reclaim: TaxBack https://www.taxback.com/en/corporate/vat-recovery/ and VATiT: https://www.vatit.com/en/page/vat-recovery

Per Company (Flat-rate or tiered) 
    For simple services provided by SaaS providers                  
    https://www.cobloom.com/blog/saas-pricing-models

Open Source Model
    Open sourced companies often charge for support or additional features (in which case it could be consider a type of freemium model). https://techcrunch.com/2016/02/09/the-money-in-open-source-software/
     Examples: RedHat (Linux) or Docker (containerization) 

Loss-Leader
    Some offerings are either free or sold at a considerable discount as a loss leader for other products or services that are provided by the company (such as computer hardware).


Other Notes:
   Hybrid Model: As noted by McKinsey, companies can use hybrid models that include both user and non-user metrics. https://www.mckfastgrowthtech.com/time-rethink-per-user-pricing-enterprise-saas/
   Price as a Client Buys:  Almost as bad as trying to convince a prospect that they have a problem that they should pay you to solve, trying to convince a customer to purchase your solution in a manner that doesn't align with their business and how they typically buy services is problematic. Therefore you should understand how a typical customer buys a solution like yours before you define your pricing model. 
   Pricing Strategy:  This blog posts suggests a few different models used to price a SaaS offering, but it doesn’t address the more complex question of what should your price be considering a given model.  (One simple framework is the three C’s: cost-based pricing, customer value-based pricing, and competitor-based pricing.) 
  On-Premise: SaaS pricing models are typically distinct from on-premise pricing models which are generally based on a one-time perpetual license plus an on-going service and support fee.
   Non-Profit Pricing: Many of these companies provide a free or significantly reduced pricing for non-profits which is a good cultural signal about the company.
    Setup and Training Costs:  Ideally your SaaS product is easy to “discover, try, and buy” with a quick time to value with minimal setup that can be performed by the customer. Sometimes either the complexity of the software or the topic prohibits this, so that there needs to be implementation (and possibly data migration) and/or training provided either by the SaaS company or a third party.  Often this is baked into the on-going fee, sometimes it is a distinct upfront cost. 
    Sources:  Information for this article came from sources including: 
          https://www.inturact.com/blog/the-top-10-saas-pricing-strategies
          https://www.cobloom.com/blog/saas-pricing-models
          https://www.cloudesire.com/7-best-pricing-models-for-saas-businesses/
          https://blog.kissmetrics.com/saasy-pricing-strategies/

Presenting at Dreamforce '13 as part of Founders Forum 

A hands-on session around company and product strategy which will help you make decisions on how to grow your SaaS product business, including how to:

-Measure growth and define success
-Identify common roadblocks to company growth
-Determine where to focus your efforts 
-Refine company & product portfolio strategy and trade-offs
-Assess different potential opportunities    


Thursday, 11/21/2013 10:00 AM
p.force.com/foundersforum
Click here to learn more about my session in the Dreamforce app