A Little History
On-demand software (also known as Software-as-a-Service or SaaS) is not new! It goes back to the earliest days of commercial software in the 1960’s and 1970’s. It was called time-sharing or service bureau.
Because computers were so expensive, individual customers couldn’t afford to have their own hardware. Technical resources to manage the computers were scarce. Vendors provided all of the hardware and software and services at their site to be shared by multiple customers. Customers would access the vendor’s computers either through a direct connection or dial-up. (Does anybody remember the 300 baud acoustic modems you put your phone handset into? Today’s product managers might have heard about this from their parents!). They would “share” the software and hardware with other customers at a cost lower than having everything at their own facility (now called on-premise).
One of those companies was called University Computing Company. UCC agreed to manage the technology during the day for a local university if they could use—and sell—computing time after hours. UCC developed on-premise software to help them manage the technology and later became a software vendor of those products. Computer Associates (CA) bought UCC in the late 80s and still sells those products today.
In the 1980’s, as hardware costs dropped and more people developed technical expertise, it became affordable for companies to bring systems in-house (on-premise). Fast forward to the 1990’s with the explosion of the Internet as a platform, and time-sharing became popular again. Vendors were called Application Service Providers (ASP).
Regardless of what it’s called, we can offer software as a product (on-premise at the customer’s site) or software as a service (on-demand at the vendor’s site). How is product management different for on-demand versus on-premise?
As with any variation of products you bring to market (enterprise/consumer, license/subscription, technical/non-technical, complex/simple, expensive/inexpensive, low volume/high volume, early market/late market), there will be differences in certain aspects. Think back to the basic marketing mix: the four P’s of product, price, promotion, and place. Depending on what you are building for whom, the product might be different, the price might be different, the promotions might be different, the price might be different, the promotions might be different, the place we sell the product might be different.
Regardless of the delivery method, an effective product manager needs to understand the market problem.
Fundamentally, the activities you need to do as an effective product manager are the same. Be the messenger of the market. Bring market facts, not opinions, to the organization. Clearly articulate who in the market you are serving (market segment and personas). Find and quantify problems the market is willing to pay to solve. Bring market context to development in the form of personas and their problems. Bring context to marketing in buyer language, not techno-babble. Bring context to sales in the form of a repeatable sales process.
Pragmatic Institute Framework
The Pragmatic Institute Framework is a set of activities to manage and market technology products.
What is really different? Without going through all 37 boxes of the Framework, let’s compare on-demand versus on-premise products for some of the product management activities.
Examples of common differences:
| Activity | Description | On-Demand | On-Premise | ||||
|---|---|---|---|---|---|---|---|
| Market Problems | Become the expert on the market and its problems by interviewing and observing customers and potential customers. Look for unsolved problems that are both urgent and pervasive, and that people are willing to pay to solve. | In addition to problems your product addresses, the SaaS business model addresses the hassle and expense of managing the hardware and software. | Customers solve the management of hardware and software themselves. | ||||
| Technology Assessment | Investigate different technologies (both inside and outside the company) and consider how they might be applied to solve a given market problem. | Customers don’t care (as much) about the back-end system as long as it works when they want it, fast, securely, and reliably.
Performance, scalability, and security requirements are higher to allow multiple customers to share hardware and software services. The vendor has more control over which hardware/software configurations to support. |
Technical reviewers care about the back-end because they have to support it themselves.
They are concerned with compliance, standards, supportability. They are concerned with ability to integrate with other commercial applications and in-house systems. The vendor is pressured to support more hardware/software configurations. |
||||
| Competitive Analysis | Identify competitive offerings in the market. Review their niche, approach and success in the market. Assess their strengths and weaknesses. Evaluate the presence and relative importance of key product capabilities. | If you compete against on-premise, and if the barrier to change to the competition is low, you have to constantly prove your value in order to renew subscriptions.
If you compete against on-premise, and if buyers are concerned about having their data in the cloud, you have to convince them that the security, reliability, performance, and scalability of your service will offset their loss of control. |
If you compete against on-demand, you have to show why having your on-premise solution delivers more value to overcome the financial burden of up-front license fees and the cost of implementing and maintaining the hardware and software on-premise.
You have to convince the customer having the products on-premise gives them more control. |
||||
| Business Case | Perform an objective analysis of a potential market opportunity to provide a basis for investment. Articulate what you learned in the market and quantify the risk, including a financial model. | The financial model differs for on-demand versus on-premise.
Revenue is recurring but is recognized as the service is rendered, not in a lump sum up front like on-premise. The initial cost to set up the service (hardware and services) are incurred by the vendor, not the customer. Ongoing operational costs of running the service are incurred by the vendor, not the customer. |
The financial model differs for on-premise versus on-demand
License-to-use revenue is recognized upfront, after the contract is signed and when the product is available. Recurring revenue for ongoing support and maintenance is usually in addition to the license fees. Customers incur hardware, software, and services costs (up-front and ongoing). |
||||
| Product Performance | Monitor and analyze how well the product is performing including product profitability, actual to planned revenue, customer satisfaction, and market share. | Revenue is typically subscription-based.
Revenue recognition as the service is delivered. Volumes are constrained by vendor’s operational back-end (hardware capacity, software performance, technical support). |
A large component of revenue is up-front license-to-use fees.
Revenue is recognized when product is available, not when it is implemented. Recurring revenue from maintenance and support is usually in addition to license fees. Volumes are constrained by ability to fulfill, implement, and support. |
||||
| Operational Metrics | Look at internal measurements to determine how the product impacts the company operations. Look for areas that might impact product profitability. This includes product lifecycle, quality, technical support, marketing programs, and sales support. | Service level agreements must be met.
Production requirements for system performance and capacity for multiple tenants must be addressed. Customers often have higher usability expectations, comparable to consumer web applications like Amazon.com. Quality issues might impact everyone in customer base at same time. Application of patches and service packs can be more timely, but require more rigorous quality control. |
Customer may take on first level technical support.
Vendors may incur additional costs to support multiple software versions while waiting for customers to implement. Delivery of patches and service packs can be deployed in phases rather than for all customers at once. |
||||
| Pricing | Establish a pricing model, schedules, guidelines and procedures. | Pricing is typically subscription-based.
Established value might be easier because it is “pay as you go” (appears to be less risk). Up-front implementation services might be charged to the customer. |
Pricing is typically a big up-front license-to-use fee.
Vendor needs to show more value when the license fee is large (appears riskier to the buyer). |
||||
| Sales Process | Develop a repeatable sales process for the channel that identifies the key steps of the sales cycle, the buyer personas for each step, and the collateral, tools, and marketing programs to move buyers through the process. | The repeatable sales process is usually different in an on-demand model.
Without the big up-front license fees, your selling channel might change (telesales, resellers, web). Sales cycles are typically shorter. Buyers want assurance from the vendor their data will be secure over the Internet and because other customers have access to the service. Buyers want proof of uptime and performance levels. |
The repeatable sales process is usually different for on-premise products.
Sales cycles are typically longer. Big up-front license fees require a more solution-oriented sales process. Buyers perceive more risk so more time is spent on ROI, pilot projects, proof of concept, and other evaluations. Success stories and references from successful implementations in similar environments are often required by buyers. |
So how do you manage on-demand products versus on-premise? Listen to your market, bring quantified problems worth solving back to your company, validate that the on-demand solutions solve the market’s problems in a way they are willing to pay to solve them, market your solutions to qualified buyers in the targeted market segments, help people buy your solutions…
On-demand and on-premise are different ways to deliver a solution. Different business models. Sometimes addressing different market segments and different personas. While there may be overlap in the problems they address, on-demand solutions solve additional problems, and on-premise solutions solve additional problems.
The way the products are built, marketed, and sold may or may not vary. “It depends…” A deep understanding of your market will guide you in how to navigate your way through the differences.
In other words, “Live the Grid!
