john gibbon
  • Bio
  • Stanford Class
  • Product Mgt
  • Product Dev
  • Career Resources
  • Blog
  • Strategy

SaaS Partnerships

2/1/2023

1 Comment

 
Overview of SaaS Partnerships
​from when I worked at enterprise Software as a Service companies


Technology Providers: Supply capabilities used in SaaSCo's offering
Provide services required for a specific market or product
  • Database technology providers
  • Hosting / cloud providers
  • Information / data providers

Owned by Technology and Operations organizations
Non exclusive relationships


Service Providers: Implementation, support, etc. for a specific market  
  • System Integrators (SI) for a specific region or for a specific software package
  • Support services for a given market (such as a language / country where SaaSCo's in-house support not available)
  • MSP - managed service providers (overlap with technology providers as could be outsourced IT)

Owned by the department at SaaSCo that usually provides this service such as implementation or support team

Relying on expertise in market or product type so exclusivity unlikely unless referral or resell involved 


Go-to-Market Referral or Distribution Resell Channel Partners:
Assist in selling SaaSCo's offering in given market (region or segment) or channel
  • Affiliate marketing
  • Referral partner
  • (Value Added) Resellers
  • Online marketplaces

Owned by Marketing and Sales teams; and specifically Channel Sales & Marketing

Most likely involves exclusivity for SaaSCo’s market


Product Partners (ISV - Independent Software Vendor)
Enhance client offering 
  • Provides key capability or offering that is needed to help sell SaaSCo’s offering for given market or segment
  • Helps create an ecosystem which is a broader value proposition to the client​

For one SaaS company approximately 3/4 of clients said presence of a partner ecosystem and the promise that a wider base of solutions than just SaaSCo's solution was a principle reason they picked the (higher priced) SaaSCo offering.  According to CrossBeam, one company had 34% higher annual contract value (ACV) on deals done with product partners.

Owned by Product organization
Exclusivity in resell model but less likely in referral model


Although!  Often there are overlaps across these categories
  • System Integrators (especially Global System Integrator GSIs) can also refer or resell products which they integrate. 
  • Product partners can also be referral partners encouraging clients who do not already have SaaSCo’s product to use it as it makes their offering more compelling and valuable. In this case the channel sales team will own or at least dictate the terms of the referral agreement with the Product Partner, even if the product partnership team is the lead.
  • Distribution partners can be white label partners integrating SaaSCo's solution with their own offering; but partnership must be enabled in conjunction with product teams market offering strategy.


Picture
Two Distinct Product Partnership Business Models for SaaS Companies

There is a big gap between these two product partnership models because in the resell model SaaSCo owns the revenue and the risk! 

Referral
Enables solutions and sales for SaaSCo especially with regional / vertical opportunities; drives some revenue
  • Percentage (with minimums) of what partner charges for a “connector” to the SaaS company’s services or data
  • and / or a portion (maybe roughly 1/4) of the total offering that the partner charges - depending on how much SaaSCo needs the client's solution to more effectively sell their own (for example a partner's compliance offering that is required to sell SaaSCo's offering in a certain market). 
  • Also a one-time referral fee for a partner offering purchased by SaaSCo clients.

Access to basic marketing mostly focused around SaaSCo’s marketplace or “App Store” listing

Limited sales support into SaaSCo sales organization and client base

Minimum support other than integration

No/minimal influence on partner's product development roadmap

Premium Referral program could involve additional fees from partner for specific additional marketing and sales opportunities

Minimum risk vetting since not on SaaSCo paper (not a SaaS company contract); although realizing SaaSCo brand still takes some risk if there is referral


Resell
New product offering for SaaSCo; driving significant revenue
  • Negotiated percentage of partner core offering list price (very roughly in 50% range although this could vary widely depending on which party is responsible for which activities - such as support; and which party more needs the other party - who has the power!)
  • Aspects of deal may include certain exclusivity (regions, accounts), sales channel conflict avoidance strategies such as double commission, list price discounts, and SaaSCo committed volumes.

Negotiated co-marketing; and SaaSCo marketing like other SaaSCo’s products.

Sold like other SaaSCo product with customer / market restrictions and minimum volumes negotiated as part of deal.

Support negotiated but generally Level 1 and Level 2 support by SaaSCo and detailed Level 3 support by partner.

Influence on partner's product development roadmap potentially negotiated as part of deal.

Premium resell may be white labelled where SaaSCo has exclusivity across larger markets and owns more of partner roadmap.

Since on SaaSCo paper, need to do full risk review and create processes across entire operations between partner and SaaSCo

As a reminder! 

Partners want access to data and functionality and access to brand, marketing, sales teams, and clients.


​Platform & Product Partnerships Organization and Functions

Product and Partner Development
  • Product Management: Building business models and APIs and other product offerings needed to deliver on identified partner enabled use cases. Working with Technology organization and other product managers.
  • Business Development: Recruitment and contract negotiation of targeted partners and categories. Working with Corporate business development and corporate partnerships. Can also work with corporate M&A group as a partnership pipeline is being created: referral partners are good candidates to become resell partners; and resell partners are good candidates for potential acquisition.
  • Technical Enablement:​ Helping partners build the identified integrations and applications. Working with global support.

Partner Success and Partner Revenue
  • Marketing: Helping clients, prospects, and sales teams understand the value proposition of partner solutions. Working with corporate and regional marketing.
  • Alliance and Sales: Partner account management; and advocating for partner solutions to be sold to specific customers and to be integrated with specific SaaSCo prospect opportunities. Working with regional sales.
  • Services: Application implementations and partner customer support; also billing and revenue tracking. Working with global support and operations
1 Comment

Empowered

7/16/2022

0 Comments

 
Picture
  
Recently I heard Marty Cagan speak as part of the McKinsey Product Academy Series. In the past Marty has spoken at my class and I have reviewed his book Inspired, my favorite book on product management.
 
Therefore I thought it was finally time for me to read the book he wrote with Chris Jones in 2021, Empowered. It can easily be used as a reference book when considering any one of a range of topics about how companies create extraordinary software products. However there are a few central themes which I thought would be helpful to describe here.
 
Two of the main messages around creating empowered product teams are:
  • Give product teams problems to solve, rather than features to build. Empower them to solve those problems in the best way they see fit.
  • Leadership is about recognizing that there's a greatness in everyone, and your job is to create an environment where that greatness can emerge. - Bill Campbell
 
Feature vs Empowered Teams (solve customer problems, achieve outcomes):
     A central theme in the book is the distinction between feature product teams and empowered product teams. A feature team implements features and projects (output), and as such isn’t empowered or held accountable to results. In contrast, an empowered team is accountable for solving a customer problem or achieving a specific outcome, and is empowered to do so in the best way they see fit.   

Difference Between Strongest Product Companies and the Rest 

1. Role of Technology (it is the business, not an expense):
     So many companies still have the old IT mindset when it comes to technology. It's viewed as a necessary cost rather than the core business enabler it needs to be. The people who work on the technology teams are literally there “to serve the business." In these scenarios, the product and technology teams are disconnected from the real customers—in fact, they're encouraged to think of their stakeholders as their customers. For strong product companies, technology is not an expense, it is the business.
 
2. Role of Product Leaders (coaching, strategy, managing to results, deep business and product knowledge):
     Most product leaders are responsible for staffing the in-house feature factory, and keeping the trains running on time. The best product leaders are staffing and coaching product teams, creating product strategy, putting strategy into action, and managing to results
  • You need to be very specific when identifying the most important business problems a product team should solve. 
  • Your role as a leader is in helping everyone on the team achieve the competence necessary to solve those problems.
       Product Leaders need to have a deep business and product knowledge (and frequent customer interactions)
  • Data (how the product is actually used)
  • Industry and domain knowledge
  • Business and company knowledge
  • Product operational knowledge (how the product actually works)
  • (most importantly) Users & customer knowledge
     Cagan recommends a minimum of three, one‐hour customer interactions each week. During weekly one-on-ones he likes asking about these customer interactions to see what the product person has learned. He also encourages the product person to share stories of what they experienced during these visits, and then to share these stories widely around the company. One reason for this is for the product person to establish their reputation as someone who has a deep and personal knowledge of the company's users and customers.

3. The purpose of product teams (product managers, product designers, and engineers)
     Consistent with the central theme of the book, Cagan believes that in strong product companies teams are given problems to solve, rather than features to build, and most importantly they are empowered to solve those problems in the best way they see fit and are then held accountable to the results.


Picture

​Importance of Product Vision, Strategy, & Discovery
In empowered product teams:
  • Product vision describes the future we are trying that improves the lives of our customers 
  • Product strategy helps us decide what problems to solve
  • Product discovery helps us figure out the tactics that can actually solve the problems

Product vision keeps us focused on the customer and serves as a North Star 
     It provides the product organization with a common understanding of what we are hoping to accomplish together. A good product vision inspires ordinary people to create extraordinary products. A good product vision provides us with meaningful work.
     When a company has grown to the point where there are multiple product teams—supporting many customers with their constant needs. It is very easy for each product team to get caught up in their own problems and their own work, losing sight of the overarching goal. The product vision represents the common goal and constantly reminds us of the larger purpose.
 
Product Strategy: Based on insights, it is how we make the product vision a reality while meeting the needs of the company as we go
     While product strategy starts with focus, it then depends on insights.  Insights come only after you spend hours studying your data, your customers, the enabling technologies, and your industry. Insights can come from anyone or anywhere – salesperson, new technology, random comment from a customer, or an academic paper. They might pertain to the dynamics of our business, our capabilities, new enabling technologies, the competitive landscape, how the market is evolving, or our customers. The foundation for significant insights is the strategic context found in the company objectives, the company scorecard/dashboard, and the product vision. Insights are both quantitative and qualitative insights; and they need to be shared and communicated.
     Many companies have a stakeholder‐driven roadmap process, where they basically are trying to find a way to “fairly” divide up the engineering capacity across the different business stakeholders.  But by not picking your battles and focusing on the few truly critical problems, most of the product team's work  does not make an impact.
 
Product Discovery finds product market fit by considering value, usability, feasibility, viability (as discussed in Inspired) 
  • Value – will users buy and use it (Product Mgr)
  • Usability – can they figure out how to use it (UX)
  • Feasibility – can we build it (tech arch)
  • Viability – part of our overall business 
(Product Market Fit is the essential component for any successful product.)
     Discovery can’t be done by stakeholders, customers and prospects; they don’t know what is possible and they don’t know what solutions work
     Often customers try to discuss solutions but they really are discussing problems. It is natural for a prospect to try to dictate requirements for features, but a product manager's job is to work to understand their underlying issues and constraints, and then work collaboratively with your prospective customers to determine if there's a general solution that will meet their needs. This form of collaboration is at the heart of the customer discovery program technique mentioned above and discussed in Inspired.
 
​
Picture
Marty (upper right) and the Silicon Valley Product Group look like a collaborative team that knows how to evangelize 

Collaborative Product Teams
     Your company is probably accustomed to feature teams that exist very clearly to serve the business, and it can be difficult to replace them with empowered product teams that exist to serve our customers in ways that work for the business. Your product organization is moving from a subservient model to a collaborative model.
    Part of this is done by product leaders establishing a direct relationship with the CEO (or general manager in a large company) and the other key executives (sales, marketing, service, finance, legal, business development.) The basis of this relationship is for the executives to believe that the product leaders have a deep understanding of the business and are committed to ensuring that the solutions provided will work for the various aspects of the business. This should be table stakes for the product leaders. Beyond that, there are three aspects the product leaders will be judged on: business results, product strategy, product teams
 
All of this may be Tougher in Larger Companies (Evangelism will help)
     Personally, I think Marty’s suggestions seem to be better suited or maybe more straightforward to implement in small companies with more greenfield products. However, Marty does provide at least one key to being a strong (empowered) product leader in a medium-sized to large‐sized company, evangelism.  Evangelism in this context means marketing to your own organization (e.g., product marketing, marketing, and sales). Some techniques used to help communicate the value of your product or what you’re proposing to your product teams, executives, key stakeholders, and investors include
  • using prototypes
  • sharing the customer pain
  • explaining the product vision
  • sharing your learnings
  • giving great demos
  • sharing the credit
  • detailing the market opportunity
  • showing your enthusiasm for your product
 
 
Check out more information from Marty Cagan at SVPG.
0 Comments

So You Want to be a Platform Company (Updated)

7/2/2021

1 Comment

 
Picture
​​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.  (This update is based on a few things I have learned since writing the original blog post in 2019.) 

​
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 or platforms as a service (PaaS). These provide software functionality that enable other developers to build complementary technologies, products, or services.

Platforms and their specific APIs can be used to integrate and extend the capabilities of distinct SaaS offerings. Often this involves a client giving permissions to another provider to use their data in the SaaS platform. For example, these integrations or extensions can be seen in B2B application marketplaces such as Salesforce App Exchange, SAP Concur App Center, or Cisco AppHub.  

​They can also be used just to provide functionality for other applications and may be white labelled and not listed in the platform provider's marketplace. There are many API-first or developer-first companies whose primary offering is API-based or platform-based such as Stripe, Plaid, or Twilio. 

The targeted developers can be internal to your company, can be part of a partner organization, can be working for a customer already using your SaaS offering, or can be a completely new client just interested in using the API’s functionality.  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) of a platform and associated SaaS offering; or again the functionality can be used just to augment the client’s offering.
 
(As described in Wikipedia, the "platform economy" includes these “innovation” or SaaS integration platforms along with B2C transactional platforms such as Uber, Amazon, and AirBnB - not to mention the data / advertising model of companies like Facebook and Google.)

Picture
​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 the customers and partners using these externalized services, for example based on the volume of API calls. This would be the case for developer-first companies like Stripe or Twilio. For customers extending your SaaS offering that they already subscribe to, it could also just be an up-charge to the cost of your core products.  For integration partners, it could or maybe should be based on the value of the specific use cases that are enabled by using your APIs and the associated data. (Here is more information on SaaS pricing models)
​
What is often overlooked or at least undervalued is the indirect revenue impact of extending the overall value of your offering, it will 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. 

The biggest mistake I have seen across a variety of companies is not coming to agreement on the value they want to create with a platform.
​Is it:
  • Direct revenue (often emphasized too much too soon)?
  • 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)?
  • PR/marketing around becoming a platform company?

Platforms and platform partners ecosystem also enable viral growth by creating a network effect: 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.

Picture
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.  Often you have to say "no, that is not on our roadmap" to a big prospect who needs some specific capability (often for big enterprise prospects it is an integration into a legacy system). However if you have a platform 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 (more on this in an upcoming blog post). 
 
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
  • 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).
Picture
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

Every platform requires developers; here are a few tips to provide great developer support and build a vibrant developer community
  • Develop inbound SEO acquisition and brand to attract developers
  • Create scalable content (tutorials, guides, API references)
  • Build community and boost champions
  • Have a dedicated developer support and onboarding team (You need people focused on the success of the big partners that your PM and BD team recruited to expand your offering.)
  • Understand your audience (and not all of them will be developers. The decision makers and stakeholders in partner companies will include CROs, business  development executives, and CEOs!) 

​Platforms and Product Led Growth
Platforms can help you expand or build your offering and your company in a variety of ways: by organically or inorganically becoming a multi-product line company (good luck doing this without being a platform company), by enabling system integrators (SIs) and value-added resellers (VARs) to implement or extend your SaaS offering, by enabling product partners to provide integrated related functionality, and by allowing you to more easily integrate with supplier partners that provide functionality.​​
Picture
To be a successful product-led company, you need to have a view on the ecosystem in which you compete and how you use your platform to build, buy, or partners your way towards more growth and providing more value. ​ This may be the most important job of product owners and GMs. 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).
1 Comment

Don't Listen to Your Customers

6/6/2020

0 Comments

 
(or at least just listen to a select few when considering long term SaaS product strategy)

SHORT TERM SAAS PRODUCT STRATEGY
You should definitely be listening to clients, partners, internal stakeholders, prospects, and product metrics when considering what to do next with your current products - your short term product strategy.  As discussed in SaaS Product Metrics, the KPIs for these products could include win rate, customer adoption, customer NPS, short term revenue, and alignment with the your company's (short term) KPIs and metrics. 

However your short term SaaS product strategy is often focused on market penetration; it is usually a bottom's up view of how to maximize the value of your current products in your current market (your current customers and customers like them).  The Ansoff Matrix, one of the frameworks mentioned in Notes on Software Product Strategy, illustrates that there are other perspective you can consider for your SaaS product strategy.
Picture
LONG TERM SAAS PRODUCT STRATEGY
You can consider what future products you can sell into your current markets by creating a (future) product development strategy.  Also you can consider how to modify your current products to sell into future markets as part of your market development plans. (Both of these strategies are easier if you are a platform company; API-centric cloud platforms enable developers to more quickly build complementary products).  
As part of this longer term product strategy you should consider 
  • Company vision and longer term company strategy
  • Market forces (For example conside Porter's Five Forces framework which is discussed in Notes on Software Product Strategy:  competitive rivalries, power of suppliers, power of customers, threat of new entrants, threat of substitute products). 
  • Competitors in these new markets and for these new products
  • Ideas from a few of your best and most visionary customers about
    • how your core capabilities can provide value in other parts of their business (future product development)
    • how modified versions of your products can help these customers grow in other geographic / vertical markets.
In other words, you need to build your perspective on a given market and how your offerings and distinct value proposition fits into this ecosystem. 
Picture
And remember you need short term deliverables for longer term strategic goals agreed upon across your company as there will always be pressure to use that capacity to accommodate short term revenue requests.  There will always be an inherent tension between the Sales team who is paid to deliver monthly and quarterly results and the Product team who is paid to consider quarterly and yearly impact.  

And there will always be less capacity than you think. 
Picture
0 Comments

SaaS Product Metrics

5/18/2019

0 Comments

 
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/
​

Picture
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)        
Picture
​from: https://www.forentrepreneurs.com/saas-metrics-2/
  • Win Rate (and win/loss analysis)
  • Pipeline Activity (do you have enough pipeline to achieve revenue goals)
  • ACV (annual contract value or new booked revenue) & units (and therefore average selling price)
  • ARR (or annual recurring revenue) 
  • Market Penetration (% of total addressable market and/or % of total existing customers upsold) 
​
Customer Response
  • End-User Adoption and Usage Frequency
  • NPS (net promoter score) & other customer sentiment analysis
  • Customer Health or Success (often more detailed than sentiment analysis; products like Gainsight can help identify attrition risk and upsell opportunities) 
  • Customer Retention Costs
  • Attrition and Renewal Rates (gross and net)
Picture

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
0 Comments

Product Frameworks: Strategy & Execution

4/20/2019

0 Comments

 
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

Picture
Brian Lawley and the 280 Group has some great PM training and resources.
​​
Pragmatic Marketing Product Management Triad
Picture
(As previously mentioned, Pragmatic Institute is well known for its training.)

SirriusDecisions Product Marketing and Management Model
Picture
Roman Pichler's Product Management Framework 
Picture
(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 
0 Comments

Different Ways to Price Your SaaS Offering

2/17/2018

2 Comments

 
Picture

​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/

2 Comments