Saas Entrepreneur Progressbookclub

YOUR COMPLIMENTARY CHAPTER
CHAPTER 1:
SaaS and the Power of
Communities
SaaS Entrepreneur: The Definitive Guide to Succeeding in Your Cloud

Application Business by Merrill R. Chapman
www.progress.com
Foreword: An interview
with Zach Nelson, CEO of NetSuite
Zach Nelson is an accomplished software in-

dustry executive and visionary with more than
20 years of leadership experience. He has held
a variety of executive positions spanning mar-
keting, sales, product development and business
strategy with leading companies such as Oracle,
Sun Microsystems, and McAfee/Network As-
sociates. In 2002 he took the helm of NetSuite
and grew the firm exponentially to its current
position as one of the industry’s leading SaaS
companies, with 2011 revenues of $236.3M, a 22% increase over
2010. NetSuite is a publicly held company, with 1.3K employees and
a market cap currently hovering in the range of $3B. The company’s
principle stockholder is Larry Ellison of Oracle. Both NetSuite and
Salesforce.com were founded on investments by Ellison, which is why
we find it very funny when various industry pundits proclaim that
Oracle does not ‘get’ SaaS. Really.
As the primary driver of NetSuite’s vision and market direction,
Zach led the company’s successful IPO in December 2007. In early
2008 he provided the keynote presentation at our first SaaS University
conference in Atlanta, and once again in 2012 at the session in Austin,
TX. Zach holds a patent in the field of application integration, and has
several other applications pending approval. He holds B.S. and M.A.
degrees from Stanford University.
This interview was conducted immediately after NetSuite’s annual
user conference, SuiteWorld 2012, which we attended on a media pass.
1
The five-day show, which drew over 3K attendees, is dedicated to the
NetSuite platform and the development and business ecosystem that
has grown up around it. The 2012 show featured numerous breakout
sessions, keynotes by Zach Nelson and other NetSuite executives and
partners, and a substantial exhibit floor featuring different companies
that have built applications that integrate with NetSuite or are built
around the NetSuite PaaS. The tone and energy of the event reminded
us of the software industry’s early COMDEX conventions in the 1980s,
where attendees walking the vast, cavernous aisles of the Las Vegas con-
vention center knew they were participating in a business movement
that would change every aspect of society. They were right, but not even
those foot-weary pilgrims foresaw how much would change over the
next 30 years. We suspect much the same dynamic is taking place right
now in SaaS and mobile applications.
NetSuite (originally NetLedger, then later Oracle Small Business
Suite, then finally NetSuite) was built around the concept of layer-
ing functionality onto a back office, ERP-style architecture. This is
in contrast to Salesforce.com, whose roots stretch back to the 1980s
and the sales and contact management software of that era, including
products such as Telemagic, Act! and Goldmine. Salesforce.com has
grown by expanding beyond its CRM roots into new markets, while
NetSuite has moved out of its position in the back office into CRM
and other markets. As exemplified by its name, core to the company’s
business model is the ‘suite,’ a tight coupling of applications with an
underlying single data model.
Zach, we listened to your keynote at SuiteWorld and have read
and listened to your other writings on SaaS suites. You are a
strong advocate of the future of the suite concept in SaaS and
believe it will ultimately triumph. The industry has been here
before with the desktop software battles of the ‘90s, where the
best of breed philosophy championed by companies such as
Borland and WordPerfect took on Microsoft Office.
“Yes, and we all know who won. And don’t forget that in the client
server markets there was a similar battle. I think one of the best ex-
amples was Siebel vs. SAP. Siebel certainly made the claim that their
CRM was best of breed, but SAP won that skirmish as well.
I think it’s important to remember that the early desktop wars
2 SaaS Entrepreneur
were driven by pricing and the desire for vendor reduction. The
first several iterations of Microsoft Office were not very ‘integrated’
at all, but they were a good deal. I don’t think Microsoft Office
Model could be regarded as integrated until the release of the 1997
version, and Microsoft has been working on increasing integration
between the applications since then.”
That is true. The desktop suite wars are described in “In Search
of Stupidity: Over 20 Years of High-Tech Marketing Disasters.”
The Microsoft Office suite was released in 1991, and it was cre-
ated as a response to and retaliation for Borland and Philippe
Kahn’s ‘barbarian’ price promotions and competitive upgrades.
“Well, as we see, history made its judgment. But in terms of SaaS,
our philosophy is driven by our belief that the suite always wins
where a tightly coupled, transactional business model is a core re-
quirement. Let us take an order as an example. An order is com-
prised of many different details but which details and what type of
reporting needs to be built around them differs very widely based
on your place in an organization. Someone in manufacturing needs
to see orders aggregated and characterized to help manage inven-
tory and supply chains. A sales person needs to see orders broken
down to the account level to track closes and sales pipelines. Upper
management wants very high level reporting so that they can un-
derstand how their organization is doing across multiple business
lines, subsidiaries and countries. In NetSuite, all these views are de-
rived from a single data model; this ties back to the product’s ERP
and back office beginnings.
“I do want to qualify this a bit. We believe the suite wins with
closely coupled data, but not necessarily for situations where the
data is loosely coupled. A good example of what I mean is that when
you are using Quicken Online Mobile and it pops up a Google map,
perhaps to show you where a potential service or business is lo-
cated, the data being manipulated is not integral to any transaction.
There are also the various social ‘aggregator’ dashboards and view-
ers; these are also examples of loosely coupled systems where the
tightly coupled suite does not offer a significant advantage.”
In SaaS Entrepreneur, when we discuss the reason for the SaaS
Foreword 3
resurgence that began in the 2004/2005 period, we make the
point that the primary reason for the rebirth was the inherent
ability of the SaaS business model to open up new markets and
new market segments.
“Yes, NetSuite believes strongly in verticalization. SaaS allows what
seem to be small markets to be aggregated into much bigger ones.
For example, one of our partners is building a product that services
the 8K to 10K marinas in the U.S. and the over 100K in Europe
alone. Attempting to build a desktop or client/server application
for such a widely distributed industry is not practical with anything
but a SaaS application. Another example of this is a partner who
is building a vertical for the wine distribution business; again, the
aggregation effect transforms this into a new market opportunity.
“At NetSuite, we have built a vertical product designed to run a
software business. We are a software company, so we’ve a great deal
of domain expertise on the subject. We run our software business
on this product and so do 750 other software firms. We understand
issues such as revenue recognition, always a tricky issue in software,
and hundreds of related issues specific to this industry.”
Since we are talking about verticals and markets, which in-
dustries currently dominated by client/server products do you
think will come under increasing pressure from SaaS competi-
tors over the next three to five years?
“I think you need to look at this from a couple of different perspec-
tives. In terms of new markets such as the ones I have described
above, I think the more relevant question is whether or not we’ll
ever see desktop or client/server competition appear in these mar-
kets. The answer is probably no.
“Of course, as everyone knows, SaaS-based CRM has driven cli-
ent/server out of the market. And there were always markets that
were a natural fit to SaaS, such as HR, project management, talent
management and so on. These markets are increasingly dominated
by SaaS, and the clock will never turn back.
“Given our roots, ERP markets are of great interest to us, but
ERP is very different. Moving your HR system from client/server
to SaaS can be thought of as knee surgery: it can be somewhat com-
4 SaaS Entrepreneur
plex, somewhat painful, but you will be out of bed pretty soon after
the operation.
“Moving off your ERP system can be thought of as heart sur-
gery: it is very complex, very painful, and if the operation fails, the
patient dies. Where we are seeing the greatest opportunities in ERP
are in areas of the world and industries where there is a great deal
of change pressure. In Chinese and Asian markets, where manufac-
turing must automate quickly, 36-month implementation periods
for an ERP client/server product is simply not acceptable when you
look at three months for an equivalent NetSuite installation. On a
global basis, GroupOn chose NetSuite to manage their global oper-
ations based on speed of implementation. This ties back to our fun-
damental product architecture, which is based on creating views of
an integrated data model.
“Even in cases where a company may have an existing
client/server product in place and does not wish to disturb it, we are
winning new business. For example, Land of Lakes chose NetSuite
for its Mexican and Chinese subsidiaries. They chose a SaaS-based
ERP system based on the fact that these are fast-growing markets
for the company and they wanted to get their IT up and running
quickly. A similar situation was in place when P&G picked NetSuite
for its Manila-based distribution management in The Philippines.
“I will say we are seeing a greater migration rate from legacy ERP
systems. Many of these systems are not ‘Cloud aware’ and retrofitting
these abilities into a legacy system is not a trivial exercise. In many
cases, the hearts are getting old and starting to miss a few beats. But
new markets facing rapid change are our current ‘suite’ spot.”
Speaking of the Cloud, how do you define it?
“The Cloud is just the Internet. Well, let me modify that. The Cloud
is the intersection of computing and telephony. The original cloud
concept came from AT&T in the ‘50s and revolved around a vision
of ubiquitous communications. This idea has become possible with
the convergence of computing and communications as exemplified
by the smartphone. Do you know anyone who does not have one? I
don’t, and in a few years the only phones being sold will be ‘smart.’”
Foreword 5
Mobile applications are also Not applicable
an arena of great interest to 4%
SaaS firms. Below are some We are
developing
interesting statistics from one
our just-released 2012 SaaS 32%
Report. Yes
27%
Have you developed a
‘smartphone’ mobile ap- No
plication interface for your 37%
SaaS system?
Figure F-1: Percentages of SaaS
companies developing mobile ap-
plication interfaces for their systems. Source: The 2012 Softletter SaaS Report
In light of these numbers, do you think mobile/tablet applica-

tions represent a revenue opportunity for SaaS firms?
“For B2B SaaS? No. In my opinion, mobile is an interface to a sys-
tem and no one is charging for interfaces. The last time the market
was paying for an interface was back when people bought Win-
dows 3.X. Our PaaS offers mobile application development tools as
a core capability of the system, and I believe that over time, with a
few exceptions, every business app will have native mobile support.
Mobile will enable you to deliver new functionality and new con-
venience to your customers, but not new revenue. Mobile, analytics
and social networking will be table stakes. You will have to have
them to compete.”
In this book we spend a great deal of time discussing the value
of analytics to SaaS firms. What is your take on the issue?
“We think analytics is very important and it is baked into our prod-
uct line. SaaS systems create vast data sets, ‘big data’ in today’s par-
lance. And a well-engineered SaaS system should be able to report
on the full range of data, from aggregating entire customer bases
to assigning values to a single detail assigned to a single customer.
“In terms of social networking, there are two aspects to this. The
first is what I call ‘socializing’ the data. When an account places an
order, the sales person who closed that account wants to know what
6 SaaS Entrepreneur
their customer is doing. finance wants to know about cash flow.
Management is worried about revenue and profitability. Within the
SaaS system, this data flow should be directed to the right people at
the right time with the relevant information they need.
“The other aspect of this is interaction of the company with cus-
tomers and with each other. Years ago we found out that the best
source of leads was references from current customers to prospects,
and interaction with our customer support team. We now allow
customers to engage with each other within our applications, and
we are going to be building on this concept.”
Let us close with a discussion of the future of PaaS. NetSuite,
along with Salesforce.com, is one of the major PaaS providers
in the industry. Our research indicates high levels of skepticism
towards PaaS adoption because of concerns about lock-in and
PaaS provider competition. What is your take?
“If you are worried about provider competition, at least from Net-
Suite, my advice is to build verticals. NetSuite is never going to
enter the marina management or wine distribution businesses. We
do not have the domain knowledge and expertise in these areas and
never will. As you have pointed out, SaaS opens new markets and
opportunities.
“As for lock-in, you can’t avoid it. Once data is entered into a
system, lock-in begins. The only question is at what level. A SaaS
company making a decision on what platform it is going to develop
on has to accept that if it wants to move from that platform, it will
take time and money. You can spend money on building out your
own infrastructure, buying licenses, learning new languages or
contracting for outsources. You can decide on various intermediate
strategies, such as integrating with applications from NetSuite. We
think that if you evaluate all your options carefully, from a business
standpoint developing on the NetSuite platform can make a great
deal of sense. It will be your call.”
Foreword 7
Introduction
Thank you for purchasing SaaS Entrepreneur: The Definitive Guide

to Succeeding in Your Cloud Application Business. This book is the
most comprehensive guide you will find to understanding and suc-
ceeding in building Software as a Service — SaaS — a powerful
model for providing software applications and services online. Its
case studies, operations analyses and timely data will help you build
and grow a successful new SaaS business. Its focus is on those areas of
community and product management, sales, marketing, compensa-
tion, customer service, and operations and infrastructure where SaaS
B2B companies sharply diverge from their on-premise counterparts.
What is in SaaS Entrepreneur?

SaaS Entrepreneur is divided into the following chapters:
Foreword
Introduction
SaaS and the Power of Communities (and the Death of Tradi-
tional Software Product Management)
Marketing, Selling and Pricing Your SaaS System
Sales Organization and Compensation in SaaS
SaaS Business Metrics
Operations and Infrastructure in SaaS
Development and SaaS
Customer Service and SaaS
Professional Services in SaaS
Legal Issues, SLAs, Taxes and VAT in SaaS
9
International Markets and SaaS
Appendix A: The SaaS Entrepreneur Checklists
Appendix B: Glossary of Terms
Appendix C: The SaaS Resources Directory
Appendix D: Further Important Reading for SaaS Companies
Each chapter contains detailed descriptions of the specific op-
erational issues and challenges you may face, as well as appropriate
and helpful case studies, all of which are based on actual events and
challenges faced by SaaS companies. We would like to take a mo-
ment to personally thank the company executives and staff person-
nel who participated in our research and provided us their valuable
industry insights.
The SaaS Entrepreneur Virtual DVD

In the past, we have included a CD or DVD with many of our books
to further assist you in carrying out the activities and suggestions
contained in their pages.
For SaaS Entrepreneur: The Definitive Guide to Succeeding in
Your Cloud Application Business, we have decided to make this
DVD available ‘virtually’ as a downloadable zip file or as an image
file you can choose to burn to DVD.
The SaaS Entrepreneur Virtual DVD contains:
• Extensive goal and execution checklists that back up the
topics discussed in the book. These checklists are in Excel
formatted and are indented and color coded. They can be ex-
tended and/or modified to fit your business environment and
challenges. There are approximately 600 separate checklisted
items and many of them are commented to assist you further.
• Several hours of video presentations from past SaaS Univer-
sity conferences with accompanying presentations in PPT or
PDF format.
• Several spreadsheets dealing with sales compensation, calcu-
lating key SaaS business metrics, setting up sample budgets
for your company and more.
• Various document and templates that provide you assistance
10 SaaS Entrepreneur
in creating business plans, positioning your product, creating
customer ‘success’ surveys and more.
All contents are stored in folders that mirror the structure of
SaaS Entrepreneur.
The complete contents of the SaaS Entrepreneur Virtual DVD
can be downloaded from the Softletter website at the following link:
http://www.softletter.com/Resources/SaaSEntrepreneurVirtualDVD.aspx
We strongly suggest you register with the Softletter website if
you have not purchased SaaS Entrepreneur from us directly as the
virtual DVD is updated from time to time and you will be notified
when it is if you are on our E-mail list.
The Appendices
The appendices provide additional information relevant to a SaaS
entrepreneur’s business strategy.
Appendix A provides a listing of suggested resources to assist you
in building and running your SaaS business.
Appendix B is a glossary of terms commonly used in SaaS and re-
lated markets.
Appendix C provides a sample of the goals and success checklists
found on the SaaS Entrepreneur Virtual DVD.
Appendix D provides further reports and books of interest to SaaS
companies.
Who Should Use SaaS Entrepreneur?

SaaS Entrepreneur can be used by SaaS B2B companies of any size.
Larger software publishers with existing desktop products as well
as firms selling on-premise, client/server applications can use it as
a transition guide to building new SaaS products and lines of busi-
ness. Smaller firms should use this book as a field manual to success
and apply its case studies, data and checklists to speed their time
to market and avoid making mistakes and wasting money as they
ramp up operations, marketing and sales activities.
Introduction 11
About SaaS Entrepreneur’s Charts and Tables
This book also contains extensive, up-to-date data on current SaaS
business operations, costs and best practices. Unless otherwise
noted, the charts, tables and numbers in the book have been ac-
cessed from Softletter’s extensive series of SaaS surveys and reports.
Since 2006, Softletter has led the industry in digging into all aspects
of the SaaS business model and the growth of Cloud-based infra-
structure technologies that support on-line applications. Reports
and surveys of interest to SaaS companies include The Softletter
SaaS Report (now in its fifth year of publication), The Softletter
Lead Generation, Management and Conversion to Sales Report,
The Softletter SaaS Escrow and Fallover Report, and the Softlet-
ter SaaS Marketing Report.
What is SaaS?
Despite the existence of ASPs, SaaS firms and ‘cloud applications’ for
well over a decade, some confusion remains in the market about the
precise definition of SaaS. Along the way, needless complexity has
been added to the topic. Many answers refer to virtualization, multi
tenancy (MT), architecture, standards, Open Source and more.
Some pundits defer to so-called authoritative organizations such as
NIST (the National Institute of Standards and Technology), a gov-
ernment entity which is currently wasting taxpayer money in an at-
tempt to impose standards on a rapidly evolving business model.
In actual fact, SaaS is easily defined, particularly in the view of
those buying subscriptions — in other words, customers. Three
key factors define an application as SaaS:
• The subscriber does not license (’buy’) the software.
• The subscriber does not install the product on their hard-
ware, either on their desktop(s) or on corporate servers.
There are a few exceptions to this. In some cases, a ‘thin cli-
ent’ or program ‘stub’ may be downloaded to a device to pro-
vide for greater security and/or performance.
• The use of the product is paid for on a recurring basis; this as-
sumes a paid model. As we will read later on, some SaaS com-
panies such as AnyMeeting operate using an ad-based model.
Many major social marketing systems such as LinkedIn and
Facebook, both of which operate in a SaaS environment, rely
partially on ads to generate revenue as well as a variety of dif-
ferent ‘premium’ services. In the case of LinkedIn, payment
for its premium membership is recurring.
That is it. If your products meet the above three criteria, the sub-
scriber will identify it as SaaS. In most markets and in most sales
situations, subscribers will not be interested in the underlying tech-
nical foundations of your product. Long and passionate expositions
on the glories of multi-tenancy will eat into the limited time you
have to convince prospects to open up their checkbook and sub-
scribe to your system. If your SaaS system stores data securely and
retrieves it quickly, you can be using MDRG (magic data retriev-
ing gerbils) technology and they will be content. When developing
your marketing collaterals for your SaaS sales teams, be prepared
to accept that most technical glories will be reduced to quick ‘tick
list’ bullet points of limited interest to most of those involved in the
subscription decision.
Why SaaS?
Software as a Service is the second-fastest growing segment in the
software industry today (mobile applications are the first, but SaaS
companies are making much more money). In 2009, various indus-
try analysis firms, such as Gartner and IDC, estimated worldwide
revenue to range from $12B to $14B by 2012, with 2014 numbers
estimated to reach $35B to $40B, or more. That is an annual growth
rate in excess of 20% to 25%, numbers the software industry enjoyed
during the golden eras of the 1980s and 90s. In terms of the over-
all software market, the current consensus is that SaaS subscription
revenue will represent approximately 35% of all worldwide business
purchases by 2014. (Softletter believes this number is low and will be
closer to 45%.) Most growth is currently in the B2B markets, though
important consumer markets such as the various online gaming
worlds and social systems represent an important (and overlooked)
area of revenue growth and profits. Softletter provides its subscribers
periodic analyses of VC investments into the software industry, and
Introduction 13
by 2010 the amount of venture money allocated to companies not
built on a recurring revenue model had dropped to under 20% of the
total. By 2012, it was difficult to identify any new money flowing into
companies developing new on-premise software.
For companies looking for new growth and opportunities,
SaaS (along with the mobile markets) is the path to the future. To
drive the point home, let us look at the 2012 Revenue Growth and
Profitability numbers from the Softletter 2012 SaaS Report.
Did your company’s SaaS
revenues grow from this
period in 2009/2010 to this No
period in 2010/2011? (Please 15%
include revenue ONLY from
increases of sales of SaaS Yes
85%
products and services.)
By what percentage did your
revenues grow? Source: The
2012 Softletter SaaS Report
1% to 5% 4% 41% to 50% 6%
6% to 10% 11% 50%+ 2%
11% to 20% 25% 75%+ 2%
21% to 30% 15% 100%+ 29%
31% to 40% 6%
Figure F-2: Revenue growth of SaaS companies. Source: The 2012 Softletter SaaS
Report
It is worth noting the num-

ber of SaaS companies reporting
100%+ growth. No
38%
Is your SaaS company or busi-
ness unit profitable?
Yes
62%
Figure F-3: Profitability of SaaS com-
panies. Source: The 2012 Softletter
SaaS Report
A Brief History of SaaS
Before continuing, a brief history of SaaS is in order, along with
a concise discussion of its predecessor — the application service
providers (ASPs). For a more complete history, we urge you to pur-
chase a copy of In Search of Stupidity: Over 20 Years of High-Tech
Marketing Disasters. Think of this book as the Evil Twin of SaaS
Entrepreneur, a ‘how not to succeed’ guide for entrepreneurs and
executives. This will be a valuable exercise because over the last sev-
eral years, ‘newbies’ to the SaaS industry have begun to promulgate
various myths and misstatements about why the ASP movement of
1999 to 2001 failed. If you accept these myths as fact, you run the
risk of not learning from history and repeating the mistakes of the
past (which is what In Search of Stupidity is designed to prevent)
In 1999 a new acronym was introduced to the computing world:
ASPs (Application Service Providers). This new class of software
provider spearheaded the reintroduction of shared computing re-
sources and applications remotely administered and then provided
to people and companies via subscriptions. To many computing
veterans of the time, ASPs were highly reminiscent of time-shared
computing, a model of renting computers and applications that de-
veloped in the 1970s when people such as the author’s father rented
spreadsheet-type products that were accessed on green screen ter-
minal systems while the software resided on main-frame and mini-
computers. Time sharing for the masses disappeared in the 80s
with the rise of personal computing; PCs were much cheaper and
provided far more functionality than their time-shared competi-
tors. Time sharing retreated back into such enterprise niches as air-
plane reservation systems, best represented by the SABRE system,
the brainchild of American Airlines.
The ASP movement reached its heights conterminously with
the dot.com bubble and when that bubble burst, the ASPs (many
of them, at any rate) also vanished, taking approximately $10B
with them in investments while returning $600 million in revenue
(not profits). Venture firms and resources fled shrieking from the
whole mess and the ASPs movement seemed to evaporate almost
overnight. But, here and there, survivors of the collapse survived
(most famously, Salesforce.com) and scraped by for a few years.
Introduction 15
By 2004/2005 interest in ASPs (now renamed SaaS) was growing
steadily, as was the market for online applications. By 2007/2008
SaaS was back with a vengeance as industry growth started to hit
20%+ per annum levels.
As the SaaS industry regained its footing and gathered strength,
the SaaS Myth Makers also appeared and began to expound on
the sad history of the ASPs. Statements explaining the demise of
the ASPs such as those below began to circulate widely and naïfs
new to the industry took them seriously. (Both examples are quotes
from a LinkedIn group devoted to SaaS business issues and were
answers to the question “What is the difference between ASP and
SaaS companies?”)
“The difference is that while the ASP model has been around
a long time it was highly conceptual and specifically did NOT
imply or require agreement concerning STANDARDIZED
architecture, whereas SaaS (properly defined, architected,
and implemented) does require adherence to open standards.
For example, ASP vendors were free to offer completely
PROPRIETARY solution architecture and their clients were
required to implement that proprietary architecture in order
to interoperate.”
“The main difference is that an ASP provider may or may not
be providing a SaaS architecture solution. They could pos-
sibly be providing a web based solution that is operating via
a remote on-premises server that is unique to each customer
including individual customizations.”
In the case of the second example (the first is simply not true), by
‘SaaS architecture solution’ the writer was referring to multi-ten-
ancy, a popular database technology that enables a SaaS provider
to administer all its customers’ information in a central data struc-
ture, as opposed to creating and managing multiple individual
databases. (Think of a condo vs. a row of tract houses.) Over the
last two years, a lot of ink has been spilled by those proclaiming
that multi-tenancy is the SaaS technology ‘Mark of Grace’ and that
without it, no application can possibly be called Software as a Ser-
vice. Furthermore, many SaaS myth makers are convinced that
this lack of technical purity, which they consider the original sin, is
what doomed the ASPs.
All of the above is incorrect and allows us to immediately spot
what we call a SaaS Newbie, someone you can safely estimate has
experience in SaaS that probably goes back no earlier than 2007 and
2008. Why this time frame? Because it coincides with the SaaS indus-
try moving from its comeback stage to its current explosive growth.
Beginning in 2007, SaaS companies began to get serious about in-
corporating technologies such as MT into their product’s architec-
tures, as the amount of business they were generating started to make
scalability an important issue. By 2008, scalability and MT were
becoming critical issues for many (though not all) SaaS firms. The
SaaS Newbie is simply telling you what he or she has recently learned.
They are also confirming that they are believers in using technology
to drive their marketing, and are seizing on the latest, hottest, shiniest
bit of coding-bling to sell their companies and themselves.
Oh, we apologize. The correct answer to the question is that
SaaS companies make money and the ASPs did not.
No, we are not being funny (though the reality is grimly humor-
ous). As the ASP market collapsed in 2001, the SaaS Newbie will
not be aware of the following facts:
• There were ASP firms implementing multi-tenancy that
failed.
• There were ASP firms not implementing multi-tenancy that
survived.
• While high-speed bandwidth connections were far more
problematic over a decade ago, they were available, most com-
panies did have access to high speed bandwidth, and the ASP
movement did not collapse because of dial-up connections.
Multi-tenancy was not a new idea in the late 90s; variants of the
technology had been used in the software industry since the late 80s.
Anyone who played with Microrim’s R:Base system in the 80s un-
derstood the underlying concept of creating a ‘Big Cube’ of data and
‘virtually’ stacking more cubes on top of one another. Online gam-
ing companies particularly understood the value of multi-tenancy,
as they used the technology to support the myriad of customers who
Introduction 17
signed up to slay orcs, fight dragons and virtually marry cute mythi-
cal creatures such as elves and fairies. (Not that there’s anything
wrong with that!)
Backing up these facts is another one. In 2006, in the midst of
the ASP (now renamed SaaS) recovery, Softletter released the first
edition of its comprehensive SaaS Report. That first edition, as have
all subsequent editions, asked SaaS providers if they implemented
multi-tenancy in their systems. In 2006, about 60% of providers did
not, yet SaaS was roaring back to life and continued to do so despite
the fact that by 2007, 50% of SaaS firms had not yet implemented
the technology into their system architecture.
Now, the SaaS Newbie is also not going to know when SaaS re-
placed ASP as the official designation for on-demand software, and
why. If you ask, you will hear more babble about ‘scalability,’ ‘multi-
tenancy,’ ‘hosting,’ and so on. The answer to this can be found in
the pages of In Search of Stupidity: Over 20 Years of High Tech
Marketing Disasters. The first edition was written in 2000-2001 as
the ASP movement was melting down; the second as the technol-
ogy was picking itself up off the canvas. Here is an excerpt from the
second edition that describes the gruesome demise of the poor old
ASP acronym. This was written in 2005 as SaaS was winning the
acronym war of the time. It is from Chapter 11, Purple Haze All
Through My Brain: The Internet and ASP Busts:
“In a desperate attempt to distance itself from the unrelenting
stream of failures, the industry frog marched the ASP label up
against a wall and summarily executed the unfortunate acro-
nym. Taking its place were a plethora of new alphabetical appel-
lations — MRPs, HSPs, HRPs, XSPs, etc. — intended to take
everyone’s mind off the current depressing state of affairs. Most
were immediately hunted down and dispatched. The ASP des-
ignation crawled back from the grave and resumed its official
role as the standard designation for hosted applications, but it
was now in official disgrace and no one talked to it. It finally
expired from all the sheer contempt directed at in 2005, to be
replaced by the fairly unpronounceable “SaaS (Software as a
Service).” (The boldfaced text was added by the author in 2005;
the rest of the paragraph is from the 2001 first edition.)
Of course, the logical next question is if it was not the lack of
multi-tenancy, infrastructure, scalability, ‘open standards,’ and all
the rest of it that killed the ASP movement, what did?
The simple answer is: the lack of customers. As the author was
writing the first edition of Stupidity in 2000-2001, he interviewed
perhaps three dozen people from different ASP firms and asked
why their companies were dead or dying. Invariably, the answer
was lack of revenue from far too few people signing up for the
ASP offering. The SaaS Newbie will frequently start to stammer on
about ‘scalability,’ but for those of us who were there and paying
attention, there was a conspicuous lack of business and trade press
reporting on ASP firms dying because they were being crushed
under the weight of all those customers rushing to subscribe. No
one interviewed in that time period reported that their firm had ex-
pired because of too many customers or that their operations were
groaning under the stress of too much business; it was a problem
they would have been glad to have. (By the way, if you are going
to claim that your company died for just that reason, your word is
not going to be good enough to convince us. We would like to see a
copy of the press release issued the day your company died stating
you were going down for the count from too many customers, and
a press clipping or two reinforcing that assertion. And yes, if you
can not provide them, we do not believe you.)
Why was there a lack of customers for ASP products in the 1999-
2001 time frame? For the complete answer, you need to pick up a
copy of the second edition of Stupidity. Read Chapter 11, then turn
to Chapter 14, Stupid Analyses, on page 324. Read the section on the
Disruption Model carefully. This will help bring the era into focus.
But we do not wish to tease you too much! The short answers
are:
• Too many SaaS companies launched into horizontal markets
occupied by big bruiser companies ready, willing, and able to
defend their turf. SaaS succeeded by moving into new mar-
kets and opportunities inherent in the on-demand model.
Yes, Salesforce.com is an exception, but it’s one that proves
the rule. (SaaS veterans will remember how beloved Siebel
was by companies in the 1999-2001 time frame.) We will
Introduction 19
soon be discussing in this chapter more about why SaaS is
sweeping the software industry.
• The ASP model suffered from collateral damage caused by
the dot.com implosion. Even deserving companies, in some
cases, were taken down.
• Too many ASP firms received funding they should not have.
In the period leading up to the 2001 meltdown, the VC com-
munity lost its collective mind and threw money into firms
with stupid business models that had no prayer of succeed-
ing. There were plenty of SaaS (ASP) companies in that mix.
There were other reasons for the bust but you’ll need to read In
Search of Stupidity to learn more.
Why is SaaS Succeeding?

As SaaS began to grow and flourish, the inevitable press stories about
whether SaaS was right for the ‘enterprise,’ i.e. large companies, ap-
peared in the pages of all the major IT magazines and periodicals.
Based on these articles and prognostications, a neutral observer
would have concluded that the fate of SaaS lay in the hands of the
Fortune 500 (or at least the 1000) CIO community. In all their wis-
dom, knowledge, and with their grasp on the keys to corporate com-
puting resources and establishments, would they bless SaaS? Or curse
it and consign the market (again) to the Stygian Darkness occupied
by OS/2, hierarchical databases, token ring networks and related
products and technologies? The covers of InfoWorld, Computer-
world, CRN and others were covered with staged photos of IT execs
pondering deep strategic thoughts and smiling reassuringly into the
camera lenses while they pondered their momentous decision.
But the question was off the point. (So were the photos.) The truth
is that the SaaS industry did not care what corporate America CIOs
thought; the industry was growing quite nicely without their official
sanction and approval. And it continues to grow today, though CIOs
throughout the world are starting to get with the (SaaS) programs.
If you lived through the PC revolution of the 80s, you’ve seen
this before. When the combination of the Apple II and VisiCalc first
began showing up in corporate CFO and accounting operations in
the late 70s, it was regarded by the IT establishment (then called MIS)
with the same favor as the roach crawling across the cake at the wed-
ding. Stories of Apples being purchased via expense accounts and
snuck into executive suites while being concealed under rain coats
are legendary (and only a little bit apocryphal). And despite the best
efforts of the Geek Squads of the time, nothing IT did was going to
chase those little green critters out of the CFO’s or controller’s office
once he had sat down and played a bit with VisiCalc. A few years later,
in 1981, the rollout of the IBM PC made IT feel a bit better about the
whole mess, but all that Big Blue’s legendary micro computer did was
accelerate the inevitable. PCs, with their decentralization of comput-
ing resources and empowering of the workforce en masse, were an
unstoppable force. Very much the same dynamic was in play when
Novell pioneered PC networking in the 80s and early 90s.
This now leads us to the logical question: why did SaaS crawl
back from the grave and vigorously reanimate? Insight can be
gleaned from these responses to the following question that has ap-
peared in every edition of The Softletter SaaS Report:
What do you believe is the primary reason your customers
choose to subscribe to a SaaS system?
Customers can quickly gain access to new capabilities
and functions that they cannot obtain by purchasing ex- 40%
isting software products and services
Customers wish to replace existing licensed and/or client/
server applications with SaaS applications to reduce overall 19%
IT operations and complexity at their company or business
unit
Customers wish to replace existing licensed and/or client/
server applications with SaaS applications to reduce the 13%
overall cost of software at their company or business unit
SaaS applications are counted as an operating expense
(OpEx), not as a capital investment (CapEx) 16%
Other (These were usualy combinations of answer one and
another choice) 11%
Figure F-4: Reasons to purchase SaaS as seen by SaaS providers. Source: The
Introduction 21
As you can see, Quickly gain access to new capabilities is the re-
sponse leader by a strong plurality. In fact, in the previous four re-
ports this answer was always the majority response. (Last year
Quickly gain came in at just over 50%.) What accounts for this year’s
numbers shift?
Before we answer this question, let us look at these responses in
greater depth. In the Softletter SaaS Report, we drill down into our
survey questions by various criteria, including years in business,
revenue size of the company and development state. Below are the
crosstabs for development state of the company.
What do you believe is the primary reason your customers
choose to subscribe to a SaaS system?
Development Stage
Privately
Privately Owned/
Owned/ Venture
Start-Up Funded Funded Public
Quickly gain access …
A (See below) 43% 40% 40% 33%
Reduce complexity …
B (See below) 14% 19% 20% 22%
Reduce overall cost …
C (See below) 14% 13% 20% 11%
OpEx vs. CaEx …
D (See below) 29% 14% 13% 33%
Other 14% 7%
A. Customers can quickly gain access to new capabilities and func-
tions that they cannot obtain by purchasing existing software
products and services
B. Customers wish to replace existing licensed and/or client/server
applications with SaaS applications to reduce overall IT opera-
tions and complexity at their company or business unit
C. Customers wish to replace existing licensed and/or client/server
applications with SaaS applications to reduce the overall cost of
software at their company or business unit
D. SaaS applications are counted as an operating expense, not as a
capital investment
Note that across the four categories in this breakdown, Quickly
gain access maintains its lead in three of them and ties in Public
with Reduce IT complexity fairly stable across all cohorts. It is not
surprising that CapEx vs OpEx is strong in Public, as most of the
companies in this category are dealing with larger companes in es-
tablished and successful SaaS application categories (CRM, project
management, HR, etc.). In these markets, CapEx vs OpEx is be-
coming more compelling.
One answer to the shift in numbers is that the uptake of SaaS in
the enterprise is indeed increasing, driven by the poor economic
climate that arrived in 2008 and that persists today. Faced with a
ongoing slowdown, companies have been continuing to modern-
ize their business operations and increase flexibility while also con-
serving cash. But note that the CapEx vs. OpEx answer comes in
at 16%; in 2011, this response came at 19%. Over the five years of
the survey and report, the response to this question has ranged be-
tween 15% and 19%, with a mean of 16%.
Another factor driving the change is that for the 2012 Report we
added a new question to the survey on which the SaaS Report is
primarily based, Reduce overall IT operations and complexity. The
introduction of client/server technology in the 90s gave businesses
the ability to build and maintain internal datacenters of amazing
complexity and flexibility. But as more and more applications have
been poured onto corporate servers, these environments have be-
come increasingly fragile and difficult to maintain, leading to a coun-
ter movement in IT to simplify their computing environments.
Today, increasing numbers of companies believe that existing
client/server applications that work, are paid for, and address key
elements of a company’s business operations should stay in place
for many years into the future, much the same way COBOL ap-
plications devised for the financial and insurance industries in
the 50s are still chugging away in back offices all over the world.
A working application in place bothering no one tends not to be
bothered, and no one wants to bother it in return, as Microsoft,
Oracle and other companies built around on-premise software are
Introduction 23
discovering. Within software categories that have existed for over
thirty years, customer resistance to change is steadily increasing as
the perception grows that everything these applications can do they
are doing, and it is cheaper and best to leave them alone to keep on
doing what they do best. And it is also probably best to leave the
servers on which these programs reside alone, as well, something
that becomes increasingly difficult to do as more programs take up
residence next to these placid, domesticated chunks of code.
This point is driven home by the next question we asked in our
survey:
What do you believe is the main secondary reason your custom-
ers choose a SaaS system?
Customers can quickly gain access to new capabilities
and functions that they cannot obtain by purchasing 31%
existing software products and services
Customers wish to replace existing licensed and/or
client/server applications with SaaS applications to 24%
reduce IT complexity and overhead at their company or
business unit
Customers wish to replace existing licensed and/or
client/server applications with SaaS applications to 11%
reduce the overall cost of software at their company or
business unit
SaaS applications are counted as an operating expense, 18%
not as a capital investment
There is no secondary reason 11%
Other 6%
Quickly gain access maintains its number one standing but

loses ground to reduce IT complexity. CapEx stays stable; clearly,
it is important to a significant segment of customers but it is never
a main driving factor.
But the world is not standing still and the need for new applica-
tions to address new needs is not going away. And herein lies the
primary reason for the growth of SaaS over the last several years
as the market began to recover from the ASP meltdown of 1999-
2001. The on demand model inherently opens up new markets and
opportunities that can not be adequately serviced by existing on-
premise products. We will be exploring this point in greater detail
in the Marketing and Pricing chapter of SaaS Entrepreneur.
Other Contributing Factors to the Growth of SaaS

The Great Recession (Otherwise Known
as the Very Slow Recovery)
Yes, this seems paradoxical. Recessions hurt companies, including
software firms, and the longer the economic malaise lasts, the more
it will hurt. Since the recession (or VSR) began, and while this book
has been under development, we’ve spoken to over three dozen
SaaS firms that also offer on-premise versions of their products,
and asked them all the same question: “How have sales of your on
premise product compared with those of your SaaS equivalents?”
Most of the companies reported strong and continued revenue
growth in their SaaS product lines, while their on-premise sales
have slowed or stagnated. In many cases, the ability of SaaS firms to
discuss purchases in the context of operating budgets was a factor
in opening customer wallets.
The Struggles of Microsoft
Love it or hate it, Microsoft, since the advent of Windows 3.X and
NT, has established the standards by which both the network and
the desktop operate. But as the recent Vista debacle and Redmond’s
struggles on mobile and tablet platforms demonstrate, Microsoft is
heading down the path of IBM as it struggles to manage a dizzying
array of increasingly unconnected agendas and initiatives.
One result of the aging process is an increasing reliance on the
tried and true. Windows 7, a cleaned-up and tidied-up Vista, rep-
resents the apotheosis of a strategy desktop and server companies
developed to drive revenues decades ago — the upgrade cycle. It
is difficult to argue that either Windows 7 or Vista were necessary
products in terms of increased functionality or productivity (at least
Microsoft has been unable to make a convincing case for this), but
they do drive revenues into Microsoft’s coffers (as the company
hopes the case will be with Windows 8). Microsoft, as demonstrated
Introduction 25
by its focus on copy protection via WGA and related technologies,
is intent on squeezing ever more money from its installed base via
upgrades. This clashes with the desire of many companies that have
stable, working server platforms and applications to not bother
them. Ever, if at all possible. Microsoft has different motives. Absent
significant new sources of cash from innovation, the company must
drive revenues via upgrades. As this desire breaks more and more
systems, forcing expensive outlays for IT operations for little per-
ceived benefit, the allure of SaaS becomes greater. (But let us be fair to
Redmond. It must be frustrating to be asked to support a decade-old
operating system (XP) that can only be updated via a very tedious
and problematic remote update process. If only there was an alterna-
tive to all of that. Hmmm.)
This is not to count Microsoft out as a potential force in SaaS.
The company is striving mightily to establish itself as a platform
provider via its Azure framework and, with the release of Office
365, the company is attempting to counter the threat from Google
Docs to its Office monopoly. The release of Windows 8 later in 2012
will herald a very ambitious effort by the company to both maintain
its desktop grip while simultaneously rebooting the company’s ef-
forts in the fast-growing tablet market. But the Microsoft is ham-
pered by the fact that to fully adopt the SaaS model it must accept
the cannibalization of its two ultra profitable monopolies, Win-
dows and Office. While it is all very well for academics and unac-
countable business book writers to preach the virtues of innovation
by destruction, they are not faced with the prospect of chewing off
two major revenues arms off the corporate corpus and counting on
them regenerating into new and profitable SaaS extremities.
Microsoft, in an effort to defend its market position, has pro-
pounded an alternative vision of SaaS, ‘Software plus Services.’ In
this model, ‘thick’ desktop and on-premise applications still pre-
dominate, but are interlinked by a series of services that spread
their tendrils out through the Internet. There are successful exam-
ples of this model; iTunes is the one everyone is most familiar with.
But except in particular niches, the ‘S+S’ model has not taken flight.
The Coming of the Cloud
In 2009, a new marketing meme came to the software industry, the
‘Cloud.’ When we first heard the phrase come into wide usage in the
summer of 2009, we thought that one of the old synonyms for the
Internet (Cloud) was reappearing for reasons that were not clear.
During the 90s, network design products such as NetCracker typi-
cally used a picture of a cloud to represent the Internet.
But some quick digging revealed that the phrase seems to have
a dual origin. One parent is Grid Computing, which in 2007–2008
was quite the hot term. Grid computing popularized the idea of
computing power becoming commoditized and consumed in
much the same way as power and telecommunications. It became
popular to describe grids as ‘clouds of virtualized servers,’ an ap-
propriate and descriptive phrase that caught the fancy of many;
unfortunately for proponents of grids, the Cloud appears to have
devoured its parent in much the same fashion as the Greek god
Zeus snacked on his progenitor, Cronus.
The Cloud’s ‘mother’” may be Eric Schmidt, then CEO of
Google, who used the term ‘cloud computing’ in reference to SaaS
at an SEO conference in 2006. A few weeks later, Amazon debuted
its S3 service and used the word ‘cloud’ in its marketing literature
to help describe the new service. Both parents’ DNA strands inter-
twined over the next several years and the Cloud and ‘cloud com-
puting’ caught fire.
Soon, everyone was talking about the ‘Cloud’ and no one quite
knew what anyone was talking about (a problem that persists to
this day). This is because the term ‘Cloud’ was not accompanied by
the release of any new technology or products to help give the new
buzzword any tangible reality to hang onto. This is somewhat un-
usual in high tech; normally, when a buzzword is introduced into
the general computing lexicon it is preceded by some actual ad-
vance in technology or products. When relational database systems
were introduced into the PC marketplace in the 80s, you could buy
one. When the Internet became widely accessible to the public in
the 90s, you could surf it. But none of this is true of the Cloud. Vir-
tualization, SaaS, middleware and PaaS are all technologies that are
part of ‘cloud computing,’ predating the Cloud by years. The phrase
Introduction 27
is strictly a marketing gambit (and so far, a very successful one).
Insofar as cloud computing has a coherent meaning, it refers to
a group of functional layers often called the ‘cloud stack.’ The differ-
ent layers of the stack are identified by their ‘as-a-Service’ acronyms.
While there are vendors that have tried to leverage the ‘as-a-Service’
phrase specifically for their offerings (storage, identity, etc.), they ul-
timately fall under one of these three layers in the stack.
The Cloud Stack

Infrastructure-as-a-Service (IaaS)
Sitting at the bottom of the cloud stack, IaaS are self-service (in
varying degrees), computing, storage and support infrastructure
resources that have been virtualized for scalability and designed to
replace dedicated servers and network hardware. For infrastruc-
ture firms such as RackSpace, GoDaddy, BlueLock and others,
virtualization allows them to wring every last dollar out of their
hardware investments, and most major hosting systems are moving
to virtualize all their operations where feasible; you can expect that
even if you are not particularly concerned about what type of server
your system resides on, a virtualized box is in your future unless
you specify otherwise.
IaaS’s value to SaaS companies depends very much on the
elasticity of your subscriber base and the need to adjust for sharp
changes in transactions being processed, since virtualized re-
sources are not always priced significantly below those of physical
systems. If during a holiday season your company expects activity
on your system to spike sharply, a virtualized infrastructure may
offer your business tremendous operational flexibility and savings.
On the other hand, if the volume of business running across your
servers tends to be steady across the year, the benefits of virtualized
or ‘cloud infrastructure’ may be far less apparent.
Deep technical knowledge at the system and network adminis-
tration levels, as well as an understanding of at least some level of
programming, is often necessary to adequately leverage IaaS offer-
ings. Some IaaS vendors offer web-based administration tools, and
where those do not exist or lack functionality, third-party vendors
have been quick to bring products to market to help ease the adop-
tion and use of IaaS resources. Technologies such as multi-tenancy
are often implemented at a low-level in an IaaS environment; this
is a key driver that enables Amazon Web Services, for example, to
achieve tremendous economies of scale with their hardware.
Platform-as-a-Service (PaaS)
PaaS is the most difficult level in the stack to define clearly; many
SaaS applications offer impressive levels of built-in flexibility and
could themselves be considered as high-level development plat-
forms. Additionally, some IaaS providers are ‘moving up the stack’
to offer more full-featured bundles of functionality that include
PaaS functionality, as in the case of Servoy, which is offered by Mi-
crosoft on its Azure platform and by IaaS firm Verio. Until it all
shakes out, PaaS is still its own element in the cloud stack, and is
itself generally broken into segments ranging from low-level ab-
straction layers to high-level data-driven business analysis and re-
porting environments.
The lowest-level platforms abstract the underlying infrastruc-
ture from developers to create a complete application deployment
and delivery system that appears to the developer like a standard
runtime environment. These platforms often leverage open tech-
nologies such as programming languages, databases, etc. Examples
of these would be Heroku (Ruby on Rails) and Google App Engine
(Java and Python).
Higher in the stack are those platforms that provide a rapid ap-
plication development environment, complete with web-based
development tools and, in some cases, proprietary programming
languages, APIs and data stores. Force.com is the most success-
ful and visible PaaS at this level, though the platform faces strong
competition from such systems as NetSuite’s SuiteFlex, Microsoft’s
Azure, and other companies eager to replace Microsoft as the ‘One
Platform to Rule Them All.’
Topping off the PaaS stack are those environments that provide a
drag-n-drop interface for non-programmers to build applications.
These offerings, like Zoho Creator or Rollbase, generally abstract
the underlying architecture and source code completely by en-
capsulating the functionality in user-friendly objects. It should be
noted that some vendors offer a ‘PaaS’ that can be installed behind
Introduction 29
a firewall or on public servers in order to build applications rapidly
and abstract the underlying infrastructure from the application de-
velopers. This is more like a next-generation framework or applica-
tion environment, and while perhaps technologically advanced, it
should not be referred to as a PaaS. Once a SaaS product is installed
on a customer’s hardware, by definition you have dropped back to
the licensed model.
Software-as-a-Service (SaaS)
While SaaS is often portrayed at the top of the ‘cloud stack,’ SaaS
applications do not necessarily leverage the PaaS or IaaS layers
below — though they can. Today, the majority of SaaS systems run
on dedicated hardware and are not developed via a PaaS. SaaS can
encompass a wide-range of products, from enterprise applications
such as CRM and ERP, to departmental or line of business appli-
cations, to stand-alone supporting elements such as reporting and
user management. (And let us not forget consumer offerings such
as World of Warcraft and the various gaming and social networks.)
SaaS is the most widely known, and visible, layer of cloud comput-
ing and is often also referred to as ‘on-demand software,’ ‘webware,’
‘cloud applications’ and even still as ASPs (though we strongly urge
you, for marketing purposes, to purge ASP from your sales and
marketing collaterals and vocabulary).
SaaS purists argue that SaaS, as opposed to other ‘on-demand
software models, is web-native, single-instance, and multi-tenant.
‘Single-instance, multi-tenant’ means there is only one version
of the application that all customers use. The most well-known
benefit of this type of architecture is the fact that all subscribers
essentially share the cost of a more efficient infrastructure. Beyond
that benefit, SaaS also allows for unique functionality not avail-
able to legacy software by nature of its ubiquity and the network
effects generated by having everyone share the same application in
a shared environment.
Hosted legacy applications served to clients via ‘virtual desk-
tops’ or ‘desktop sharing’ technologies are not ‘true’ SaaS in that this
type of architectural approach has a limited life span in its ability to
scale. However, as we have noted, to most customers these claims
will normally be translated as technobabble or irrelevant. If your
target market values your adoption of a particular technology, you
will want to highlight it in an appropriate manner.
The stage now set, we’ve provided a quick glossary of the latest
cloud buzzwords with a Buzz Rating of one (think Windows Vista)
to three, with three being maximal buzz (think iPad).
Cloud applications = SaaS. We suggest giving equal weight to both
terms in your marketing literature and be ready to fall back to
SaaS if advisable; while hardly a thing of beauty, the acronym
has gained credibility and is widely understood. We afford cloud
applications a Buzz Rating of 2.
Private cloud = corporate datacenter. This phrase is gaining strength
rapidly and is even gaining traction among corporate CIOs, who
use the term to show they are cool and hip to today’s computing,
though events such as the Amazon’s EC2 April 2011 meltdown has
made it likely that no major corporation is going to shut its internal
datacenter down anytime soon. Buzz Rating of 2.5.
Public cloud = a web hosting company (GoDaddy, Rackspace,
et al) that uses virtualized servers. Not much excitement sur-
rounds the concept; who cares how hosting companies run their
servers? Buzz Rating of 1.5.
Cloud development = PaaS. The revival of the SaaS movement
has reignited the platform wars of the 80s and 90s, which ended
with Microsoft dominant and competitors such as OS/2 and
CPM/86 moribund. Today, Salesforce.com, Microsoft, NetSuite
and others fight anew to be the dominant development platform
for SaaS applications. For application subscribers, a Buzz Rat-
ing of 1; for developers, 2.5. Note that as of this writing, no par-
ticular PaaS has become dominant in the marketplace. We will
be discussing the various PaaS systems in greater detail in the
Development chapter of this book.
Hybrid clouds = internal datacenters that use third party, external
resources for non-critical operations such as archiving. The con-
cept is not that exciting to readers of this book. Buzz Rating of 1.5.
Introduction 31
Contacting Us
In an industry as dynamic and changeable as software, new trends,
ideas and challenges appear constantly. As in the past, we are always
delighted to hear from you and rely on communications with our
readers to help keep us up to speed. If you have a suggestion to make
or a topic you’d like to see covered in greater detail in future editions
of SaaS Entrepreneur: The Definitive Guide to Succeeding in Your
Cloud Application Business, please visit us at www.softletter.com or
www.saasentrepreneur.com and join our community, or contact us
directly via E-mail or phone. We wish you the best of luck!
Acknowledgements
Portions of this book are derived from articles that appeared in past
issues Softletter. We would like to thank the following columnists
and contributors for their help and assistance in creating SaaS En-
trepreneur: The Definitive Guide to Succeeding in Your Cloud Ap-
plication Business.
Jan Aleman, CEO, Servoy for his contributions on the evolving
market for PaaS.
Ted Finch, principal, Chanimal, for his information on channels
and providing most of the channel spreadsheets and related ma-
terial on the SaaS Entrepreneur Virtual DVD.
Hank Galligan, Practice Office Accounting Director BDO for his
contributions on revenue recognition and SaaS.
Laura Roach, director, BlackBaud and Jeff Saling, vice president,
Spectrum Business Technologies, for their assistance in help-
ing shape the Sales Organization and Compensation in SaaS
chapter.
Jay Greenwald, principal, International Revenue Acceleration, for
his insights into SaaS and international venues and much of the
data in the International Markets and SaaS chapter.
Michael Whitener, founder, VistaLaw International, for his legal
commentary in the Legal Issues, SLAs, Taxes and VAT in SaaS
chapter.
chapter 1
SaaS and the Power of Communities
(and the Death of Traditional Software
Product Management)
SaaS — The Software is the Social Network

In many respects, this is most important chapter in the book. If you
decide to read nothing else, read this chapter thoroughly and imple-
ment its suggestions as soon as possible. Failure to do so will first
damage, then destroy, your ability to compete successfully in SaaS.
When pundits and analysts argue over what is the single most
important point of differentiation between SaaS and on-premise,
licensed software, they usually point to:
• The recurring revenue nature of SaaS. In SaaS, you do not
purchase licenses; rather you subscribe for X amount over
X period for the right to use the software. But some software
companies allow you to subscribe to their on-premise soft-
ware.
• The fact that SaaS applications are run in an Internet browser.
But in some cases, SaaS applications are provided via termi-
nal services and in other cases a ‘thin client’ desktop version
of the software is installed on a PC and can both access a re-
mote server and/or run on your PC locally. (And many mo-
bile applications run the same way.)
• The fact that SaaS applications are not installed on a com-
pany’s servers. But a significant number of companies do li-
cense and install SaaS products on their internal servers. This
is often referred to as the hybrid model and while we urge
SaaS companies to avoid it, customer and financial demands
sometimes require you license your products.
33
• There are other issues and technologies that are discussed:
multi-tenancy ; virtualization; agile development. The ‘cloud.’
While these can indeed be differentiators, they miss the crucial
point of SaaS. And that is that SaaS systems, by their very nature,
create communities of customers who can collectively interact with
each other and your company on a 24/7/52. In SaaS, the applica-
tion is the social network. But to benefit from it, you must prepare
to manage and leverage the application network to the maximum
extent.
What Creates the Application Network?

What comprises the application network? Two inherent elements
of SaaS:
The first is that if your SaaS system is properly architected,
you should be able to monitor, capture and analyze every
aspect of a subscriber’s interaction with your product. This
includes keystrokes, functions accessed, functions not ac-
cessed, browser usage, etc.
The second is that because SaaS applications inherently con-
centrate subscribers with a common set of interests in one
virtual ‘place,’ the foundation for a community is already in
place. If you provide the right infrastructure, your commu-
nity of customers will grow, thrive and transmit information
about your product and their usage of it to your company on
a constant basis at an ever increasing bandwidth.
The charts and tables below provides more insight into what
percentage of SaaS firms are adding analytics and community en-
ablement into their systems and the type of information they are
capturing. (Please note that community integration lags behind
analytics, but this number will shift sharply to ‘Yes’ over the next
two to three years.)
We are
planning
Does your product in- to add this
corporate a customer capability
19%
usage tracking analytic
system directly within
the SaaS application en- Yes
vironment? 70%
Figure 1-1. Percentage of SaaS No

firms integrating analytics 30%
into their systems. Source: The
What type of analytics does your measurement system provide?

(Please pick all that apply)
30%
25%
20%
15%
10%
5%
0%
ime
ins
r
d cru sited
SaaS pent
IE
mbs)
Othe
funct es condu rs of
with subscribe ctions
accescted,
aaS s while
sed)
ystem
et al.
syste
m log
vs. Ch ox vs.
ownt
in the f time s
be
i
bers l pages v
rome
fun
r
(num
and d
syste
(Firef
(brea
duct
ions
ing o
the S
evels
er of
sage
eouts
ch
l
used of all pro

by su cking of a
, sear
Track
e
repor sage l
Numb
ser u
by th
m tim
bscri
ts run
cting
Brow
ing
U
Tra
Syste
Track
intera
Figure 1-2. Data points measured by SaaS analytics systems. Source: The 2012
Softletter SaaS Report
SaaS and the Power of Communities 35

We are
planning
to add this
capability
16%
Yes Does your product system incorpo-
20% rate a customer community man-
agement system directly within the
SaaS application environment? (By
“within” we mean the customer can
access the community from within
No
64% the SaaS system via either direct
access to an integrated community
module or a direct link to a third
party module.)
Figure 1-3. Data points measured by SaaS analytics systems. Source: The 2012
What customer community activities are supported and/or ac-

tive on your community management system? (Please pick all
that apply.)
Discussion forums 35%
Reputation management and acknowledgement 9%
Customer administered expert advice and training sessions 9%
Peer to peer customer direct messaging
(think IM integrated into your SaaS system) 9%
Wiki-type functionality for documentation
and best practices documentation management 18%
Social media linking 9%
File sharing and uploading 6%
Other 3%
Figure 1-4. Activities supported by SaaS community systems. Source: The 2012
These twin characteristics give SaaS applications an unmatched

competitive edge over their desktop and on-premise counterparts.
By analyzing customer interaction via an analytics engine, generat-
ing reports and metrics, and then integrating these metrics with
insights and information gathered from your customer commu-
nity, SaaS companies can react to market changes and subscriber
requirements with a speed and accuracy not possible with on-
premise products. On-premise companies simply cannot compete.
(An interesting historical note: there have been attempts to graft
on to on-premise products technologies that are organic to SaaS.
The author of this book consulted early in the new millennium
with an Israeli company that had developed a server-based product
that allowed users of desktop applications to directly message and
communicate with one another. But security issues and the com-
plexity of supporting an almost infinite number of computing envi-
ronments short-circuited the attempt.)
A final component that also needs to be added to your SaaS sys-
tem is a requirements tracking and management system. Increasing
percentages of SaaS companies are adding this ability (though in
some cases this functionality is provided in an analytics package):
Does your product in-
We are
planning corporate a ‘new fea-
to add this tures or capabilities’
capability
19% Yes request mechanism
34%
by customers directly
within the SaaS appli-
cation environment?
Figure 1-5: Percentage of

No
47% SaaS companies incorporat-
ing requirements manage-
ment into their systems.
Source: The 2012 Softletter
SaaS Report
Whether you purchase or buy your requirements management

system, it should possess the following baseline feature set:
• An ‘any’ screen deployment that enables your customers
to submit a feature request from most systemscreens with
which the subscriber interacts.
• A requirements prioritization list feature which, as its name
implies, allows customers to list their features in order of es-
timated importance.
• A ‘desirability’ or weighting option that subscribers can as-
sign to their feature requests.

• A requirements history or log function that enables your
subscribers to track their requests and their resolutions by
your company.
• A cataloging capability that enables your subscribers to submit
feature requests by common topics or area of functionality.
Optional features of great importance are:
• The ability for customers to purchase features based on such
criteria as cost per estimated hour. The case study on Plex
Systems, which uses this model, describes their approach in
greater detail. Whether you will be able to charge for new
feature implementations is dependent on your market and
customer base. Over time, we expect increasing numbers of
SaaS companies to implement this model.
• The ability for customers to vote on new features requests, with
the elected winners receiving increased development priority.
The Age of the Community Manager Dawns

While That of the Product Managers Sets
For a SaaS company to enjoy these benefits, all of which will be
covered in greater detail in our Plex Systems case study later in this
chapter, a profound change in how software companies manage
their internal interactions must occur, in addition to a change in
customer relationships. In SaaS, the concept of traditional product
management must be retired and replaced by community manage-
ment. If you do not do this, you cannot properly leverage your cus-
tomer community and the invaluable analytics it will provide you.
A Brief History of Software Product Management
Before going further, a brief history of product management and a
discussion of its function in software firms is in order. The role and
concept of product managers (PMs) appeared in software as far back
as the late 1970s, as the modern industry was crystallizing around
such systems as the TRS-80 and Apple II and later the IBM PC. The
fundamental idea was lifted from consumer goods companies such
as Procter and Gamble and Johnson & Johnson, where product man-
agers functioned (ideally) as ‘mini CEOs’ of product lines. In theory,
the product manager of a popular toothpaste, as an actual example,
had bottom line responsibility for the sales and profitability of his or
her product and could hire, fire and allocate development resources
to their product in order to increase revenue and profitability. (The
truth is that in many case, this idea was paid a great deal of lip ser-
vice but in practice, upper management kept their PMs on very short
leashes. Still, this was the theoretical ideal.)
In the software industry, product managers, with very few ex-
ceptions, never came close to acting as mini CEOs. To the contrary,
product management has always had an uneasy relationship with the
rest of the company (and upper management) because of the lack of
an ‘organic’ connection to the bottom line. Product managers are not
responsible for the sales of the product they manage in any meaning-
ful sense, and developing measurable benchmarks for the position
has always been a challenge. An article in a Pragmatic Marketing
online publication discussed how to measure product management
success. The author provided benchmarks that included:
• ‘Number/frequency of face-to-face visits with the market.’
• ‘Creation of Buyer and User Personas.’
• ‘Drafts of Problem Statements.’
• ‘Eventually statistically valid market evidence that describes
those Problem Statements by their pervasiveness and ur-
gency.’
None of these are the type of metric that warms the cockles of
the typical CEO’s flinty heart.
And despite exaggerated claims (many made by companies that sell
product management training), product managers are neither ‘strate-
gic’ nor ‘visionary,’ nor are they innovation drivers. Software product
managers do not hire or fire personnel. They do not normally allocate
development, sales, or marketing funds, all requisites for a manage-
ment position to be strategic. They almost never control a budget.
Their primary role is to act as the administrative ‘glue’ during the prod-
uct development cycle and help support sales and marketing after a
product launch. This places a premium on execution, not vision.
That said, what do product managers do? In most software com-
panies, their principal duties consist of:

• Managing the new features list (informally referred to as ‘tick
list’ herding) and, in theory, ensuring that at least X% of it
is incorporated into the next release of the product. Much
of this work is iterated in on-premise companies by MRDs
(marketing requirements documents), PRDs (product re-
quirements documents) and FSs (feature specifications).
While still relevant to desktop/retail and on-premise prod-
ucts, these documents and the processes that create them are
usually a pointless exercise in SaaS firms.
• Acting as a communications liaison between customers and
the company on product development, direction, roadmaps
and philosophy. The introduction of Agile development
methodologies brought increased interest in the idea of
product managers acting as ‘surrogate customers.’ As you’ll
soon read, much of the theorizing around this idea was never
practical, and SaaS requires new thinking about the issue.
• Executing or assisting in carrying out various marketing pro-
grams, determining the pricing of the product, and in making
themselves useful in dozens of undefined and non-measur-
able ways.
One experienced product manager we have known for years
once told us the most useful tool a product manager could have was
a “pom pom.”
Product management titles are typically broken into two main
types — product managers and product marketing managers. Prod-
uct managers are normally tasked with pre-release activities such tick
list herding, assisting in managing beta programs (also irrelevant in
SaaS), and coordinating product release activities. Product market-
ing managers typically assist with post-release tasks such as press
tours and relations, indirect marketing programs, sales assistance
programs and related activities. Over the years, a third title has been
added to the first two: ‘technical product manager,’ also sometimes
referred to as domain or industry experts. Their primary job is to
focus on features and requirements in the context of providing spe-
cial insight and expertise into an industry segment or niche.
Historically, most software companies add a first level of product
management after they have hit several million dollars in revenue.
The reason for this is that the CEO, CTO, and other members of
upper management normally play the role of product manager while
the company is struggling to grow and expand. As the company
gains traction, so does the desire to shift the administrative burden of
product management from upper management to these special ad-
ministrators. Continued growth normally means adding more prod-
uct management titles to the company’s organization chart.
Since, as noted, the various types of managers almost never have
line or budgetary authority for ‘their’ products, their ability to sway
the fate of a software product or product line is limited. Because no
quantifiable metrics are attached to the job (at least metrics the prod-
uct manager can manage, control and ‘own’), it is always difficult for a
product manager to prove the worth of his or her contribution to the
corporate bottom line. This does not stop upper management from
systematically decapitating a hapless product manager when ‘their’
product fails to meet sales expectations. ‘All responsibility, no author-
ity’ is the mantra most associated with the job.
The above model, with different twists and variants, has held sway
in the software industry for over 30 years. The problems, limitations
and frustrations associated with the job are well known and have
been discussed in endless detail. Take for example a website popu-
lar with software product managers, the Cranky Product Manager
(www.crankypm). The site is the bailiwick of the Cranky PM, a ‘fic-
tional person’ who also claims to be the real life alter ego of a female
product manager (yes, we realize the contradiction here but it is not
our site). The site is fun and well written, but reading through its vari-
ous riffs, comments and observations feels like a time travel journey
back to the 80s for anyone who has lived through the industry’s his-
tory and worked as a product manager. The problem of a lack of any
real authority was the same. The lack of solutions was the same. A
product manager for WordStar, Lotus 123, and dBase II, all 80s icons,
would feel very much at home ‘taking over’ the product management
reins of Microsoft Office, PhotoShop, and Oracle. (Well, not really ...)

Figure 1-6: In thirty plus years, the narrative about product management in soft-
ware has not changed.
But then a new savior for product management and managers
appeared — the ‘Agile Product Manager.’
Silly Agility: The Myth of the Agile Product Manager
About three years ago, the agile product manager came to soft-
ware. If you followed such things, you began to read a great deal in
the industry press about this fabulous new creature, followed by a
plethora of new training courses, books and tools from the usual
suspects. These all promised to transform yesterday’s slow and slug-
gish product manager into a new sort of sleek, streamlined super-
hero, somewhat akin to Tony Stark skinned out in his Iron Man suit.
Cloaked with the power of Agility, product managers would now
streak through the sky saving software companies from evil slow
release cycles and insidious blackholes, where lurked horrid crea-
tures, mutant users who were willing to spit up kryptonite to avoid
deinstalling XP from their PC and worship the Dread Dormammu
provided he would save them from yet another IT server upgrade.
Unfortunately, the courses, tools and superhero cloaks are a
waste of time (and money) for SaaS companies. (In our opinion,
they do very little for on-premise software companies, too.)
Why are Agile product managers doomed to be mythical beings,
like comic book superheroes? Because:
• Agile methodologies were never designed nor have they
evolved in any practical way to encompass the job of product
managers.
• Agile methodologies do not address the underlying reality of
the product management title in on-premise software compa-
nies — they cannot create real change because they lack real au-
thority.
• The resistance of businesses (and many consumers) to buy
increasingly complex on- premise and desktop software
is caused by the nature of these products and systems, not
product management methodologies.
Now, before proceeding any further, we would like to urge
you to download the following E-book from Pragmatic Market-
ing, the leading firm in the industry currently offering product
management training courses. It is not really a book, more like a

PowerPoint on steroids, but it makes the case for ‘Agile’ product
management. To be honest, the case it makes is incoherent and il-
logical, but we think it is still the best that can be done with the
topic, and it is a short read. The book is called Living in an Agile
World and can be found on the Pragmatic website or on www.soft-
letter.com. Put it aside for later reading in this chapter.
A Brief History of Agile
At this point, a brief history of software’s Agile movement is in
order. Agile methodologies were conceived as a reaction against
the development processes that dominated the software industry
from the 1950s through the mid-90s. Traditionally, software firms
would develop a product, release it and then have a series of big
sit-downs and meetings to discuss the capabilities the next version
of the product should possess. These sit-downs and meetings were
typically accompanied by heated discussions, temper tantrums,
political knifings, assassinations, underhanded deals, betrayals,
blackmail and other forms of bloodletting normally associated
with high-tech corporate life. (There is a theory that Shakespeare
was inspired to write plays such as “Hamlet,” “Richard III” and “Co-
riolanus” by using occult magic to peer into the future and eaves-
drop on a next-version-planning meeting taking place at a major
software corporation.)
The end result of this cyclical Apocalypse Geek was an agreed-
upon list of requirements that would be incorporated into the next
version of the product. Work would begin, and over the next 12 to
36 months or so, a new version of the product would appear. The
cycle would then repeat itself and proceed along. This approach to
development is often referred to as a ‘waterfall development,’ no
doubt a reference to the rivers of corporate blood that spilled down
the aisles and flowed down the steps of corporate HQs while the
new requirements specification was under development.
Things thus moved along in the world of software until 1995,
which is when word spread throughout the industry of the C3 proj-
ect. a stood for Chrysler Comprehensive Compensation System, a
software development project launched at the carmaker that was an
attempt to build a new, complex software application in a new way.
Specifically, it was to be a payroll application that would replace
several existing systems at the company. This new Agile system was
called ‘XP,’ for extreme programming. (The system is still in use at a
substantial number of SaaS firms.)
XP was an attempt to replace waterfall development approaches
with something new. Instead of a vast requirements framework cre-
ated after much corporate ‘Sturm und Drang,’ development would
focus on short, highly focused periods of development during
which an actual user would sit side by side with the programming
group and provide instant feedback on the code being created by
the developer(s). The Holy Grail of this first Agile project was to
develop code more quickly, with fewer bugs that adhered closely to
the needs of actual users. All Agile methodologies seek this same
Grail.
C3, objectively analyzed, was a failure; after five years the prod-
uct was not completed and the development effort was terminated,
one reason being that the poor schnook who was picked to be the
user sitting next to the programmers literally broke down. But the
industry thought a great many lessons had been learned, and new
Agile methodologies and theories were introduced, debated and
argued over with an often religious ferocity. One point that all these
methodologies agreed upon, however, was the need for intense
user involvement during the development cycle. Real users, when
approached about sharing cubicles with programmers during Agile
development cycles, tended to fake epileptic fits when the topic was
brought up. When pressed, they made loud noises about the 14th
Amendment to the Constitution and the prohibitions against in-
voluntary slavery. The idea was dropped. (There were rumors about
an abortive attempt to breed a race of human clones to fill in, but
the concept seems to have gone nowhere.)
Now, this was a problem, because all Agile methodologies crave
direct customer involvement in the development cycle. What to do,
what to do.
Then, one day an innocent product manager headed down the
wrong aisle in his company’s office complex, ignored several warn-
ing signs, and found himself strolling past a row of programmer
workstations. The desperate coders looked up, spotted the luckless
functionary and had an epiphany. There was a quick ambush and

a brief struggle, followed by some fast DNA resequencing. When
the unfortunate manager finally fought free of his captors, he dis-
covered to his horror that the words ‘Agile Customer Stand In’ now
appeared on his forehead in day-glow lettering. This DNA recon-
figuration soon went viral and product managers everywhere were
now expected to represent customers in Agile frameworks. Which
they were happy to do when they were not doing all the other things
that were required of them — things which took up most of their
time.
Now, this was not as big a problem as it sounds because the flock
of those worshipping at Agile alters remained fairly small despite
the loud sounds the movement made. That’s because while it was
fine to discuss how to rapidly and incrementally improve software
products, the underlying infrastructure of the desktop and client/
server systems are not a great fit to Agile. These platforms still ad-
here to the traditional 12- to 18-month development cycle; in such
a milieu, development agility is not that critical. Waterfalls will do,
and did for about the next 10 years.
The SaaS/Agile connection
This changed with SaaS because SaaS and Agile are a development
marriage made in heaven. The primary driver for this is the ex-
treme pace of development that takes place in the SaaS program-
ming environment, as illustrated in the chart below:
We do not have Other Less than How often do you release
a “timed” or set 2% once a year
release schedule; 9% a “major update” of your
we release new SaaS product to your cus-
features as
they are ready tomers? (A ‘major update’
28% is defined as including
Once significant new features
a year
20% and functionality, not just
incremental improve-
ments and bug fixes.)
Twice
a year Figure 1-7: Major new release
Three or more 15%
frequency of SaaS companies.
times a year Source: The 2012 Softletter SaaS
26%
Report
Note that aggregated, 54% of SaaS companies are releasing
major new versions of their product three or more times a year;
15% are releasing major upgrades twice a year. This frequency of
release was never possible in on-premise markets.
It is vital to realize that this relentless drive to improve and ex-
pand functionality is driven by customer demand. From time to
time, we’ve spoken to ‘voice of the customer’ advocates who argue
that what today’s SaaS customers want are stripped down, mini-
malist applications. In every case we’ve analyzed, the VOC advo-
cates have been proven wrong. SaaS customers, it turns out, want
the right set of features and they want a
lot of them.
Customer demand and fast develop-
ment have thus driven the rapid accep- No
30%
tance of Agile programming methods in
SaaS, as we see below:
Does your company implement “Agile” Yes
70%
methodologies in its R&D?
Figure 1-8: Agile methodology usage by SaaS
Companies. Source: The 2012 Softletter SaaS
Report
When Softletter began publishing this report five years ago,

these numbers were almost completely reversed.
The Product Manager/Agile Methodology Non-Conjunction
It’s time now to crack open that copy of Pragmatic’s Living in an
Agile World. We will interrupt this chapter and give you time to
work through it; a half hour or so should do it...
Good, you’re back. Let us resume.
First, you’ll note that Living talks a great deal about ‘The Prod-
uct Owner.’ The idea of a product owner is an intrinsic part of
Scrum, currently by far the most popular Agile system. In Scrum,
what does a product owner do? To quote the book:
“The product owner is a new role, created and defined by the
Scrum Alliance (www.scrumalliance.org). Product owners live
full-time with development teams — elaborating users’ stories,

managing sprint-level backlogs, expanding specifications and in-
terpreting product vision.”
Some of this sounds like things a product manager might do.
So, is a product manager now a product owner? Not according
to Living:
“And a product manager is now called a Product Owner … right?
Wrong!”
Not everyone agrees with the above (though we think
the book gets it right). For an even more detailed analysis of
Scrum’s product owner concept, visit Jack Milunsky’s blog at
http://agilesoftwaredevelopment.com/blog/jackmilunsky/top-10-
activities-product-owner and read a bit more about the topic.
You’ll note that when Jack raises the question of whether or not
a product owner can be a product manager, his answer is “Yes.”
So, why does Living feel that a product manager cannot be a
product owner? Because:
“In fact, a product owner’s responsibilities are just a small subset
of product management.”
Before going further, we need to more fully discuss what it is
that an Agile product owner does. Let us ask Jack; after all, he is a
certified Scrum master! In his words a product owner:
• “Creates and maintains the product backlog.” (More collo-
quially known as ‘the new features that aren’t done yet.’)
• “Assists with the elaboration of Epics, Themes and Features
into user stories that are granular enough to be achieved in a
single sprint.” (This is shorthand for the creation of simulated
users because the lure of Cheetos and stale Mountain Dew
hasn’t enticed any real users into the development cubicles,
and the product manager is only available to sit down with us
on Thursdays from 1:15p.m. to 2:45 p.m.)
• “Conveys the Vision and Goals at the beginning of every Re-
lease and Sprint. (Hands out the Jolt Cola before beginning
more coding.)
• “Participates in the daily Scrums, Sprint Planning Meetings
and Sprint Reviews and Retrospectives.” (Makes sure that ev-
eryone is in their cubicles and working hard.)
• “Inspects the product progress at the end of every Sprint and
has complete authority to accept or reject work done.” (Looks
for bugs.)
• “Can change the course of the project at the end of every
Sprint.” (Tells the product manager that ‘No! That feature isn’t
making it into this release.’)
• “Terminates a Sprint if it is determined that a drastic change
in direction is required.” (This usually only happens when the
company goes out of business and everyone is laid off.)
Whew! That’s a lot of stuff to do. It seems that what a product
owner does is manage a development team (in other words, herd
cats). In the 1980s and 90s, people with this job were typically
called software project managers and it was very much a full-time
job. And project managers always reported to development.
But wait! That’s not all the product owner does. In addition to all
of the above, the product owner also:
• “Represents the customer, interfaces and engages the cus-
tomer.” (Since the product manager is never available, screw
them. I’ll do this myself).
• “Prioritizes and sequences the Backlog according to business
value or ROI.” (See the above comment.)
Now, it should be apparent why Scrum product owners cannot
be product mangers. The primary function of product owners is
to manage developers, and for that you need another developer.
A programming team will not accept a product manager as their
team leader. Product managers don’t write code, they stink of too
much time spent with marketing and sales, and wouldn’t know
how to break out of a do...while loop if they were given a map and
they’re not qualified to tell us bupkus. Development personnel and
product managers can have good business and interpersonal rela-
tionships, but coders do not take orders from product managers.
But, Living has its own take on what product owner can and
cannot do. According to the folks at Pragmatic:
“Product owners can’t rank backlog based on ROI (in fact,
this task is impossible for anyone to do, since real business
metrics and financial projections don’t exist at the feature/
backlog/item level.” (By the way, this statement by itself

shows just how out of touch current theories about SaaS and
product management are, as increasing numbers of SaaS
companies are doing just this. But the point that Living wants
to make is that the spreadsheet jockey work should be left to
the product managers, not some geek in development.)
And Living doesn’t think product owners are much good at rep-
resenting users to development, either:
“Creating successful benefits and feature descriptions that
truly sell products, requires a detailed understanding of the
technology and a detailed appreciation of the customers’ prob-
lem. This takes lots of practice, hands-on field experience, and
a clear view from both sides. In our experience, internally pro-
moted technical staff members almost never get this right.”
So where does all this Agile theorizing leave us? Right back
where we started. The rest of the book simply repeats the standard
mantra that’s developed around product management in software
for the last thirty-plus years. For example, when talking about the
interaction of product management with Agile teams, we are as-
sured that “Product management is outwardly focused.” Uh, yes.
And we learn that “As Pragmatic Marketing-trained product man-
agers know, you don’t learn anything about the market while sitting
at your desk,” an observation that is wrong for an increasing num-
ber of SaaS firms and steadily becoming ‘wronger.’
And of course, we hear again that “The point of integration for
these teams, though, is a single product manager. When the execu-
tives demand ‘one throat to choke,’ it’s the product manager who is
responsible for overall success of the result.”
That is nice, but choking the throat of someone who, as we have
pointed out, cannot hire/fire personnel, control the budgetary expen-
ditures of ‘their’ products, and measure their performance against
significant quantitative business metrics is akin to punishing a puppy
that has failed to protect the family home from armed burglars. It
seems obvious that demanding responsibility without authority is a
pointless exercise, but people have been tilting at various windmills
for centuries, so we do not expect the process to stop any time soon.
This brings us (back) to the point of this section. Agile prod-
uct development methodologies are exactly that — development
methodologies. They were designed for and by programmers, are
used by programmers, are used to measure programming develop-
ment and do not apply to product managers. There can be no such
thing as an ‘Agile’ product manager because PMs are not program-
mers. And in many cases, the ostensible role of ‘user stand in’ that
product managers are sometimes supposed to play are dedicated to
specialists in development who carry out certain tasks. These tasks
include developing use cases, creating personas and all the other
‘virtual person’ activities that have been developed to cope with the
fact that while the product manager would really like to stand in
for the customer, it is a busy corporate world out there. What is
more, our product manager is leaving with the CEO for a road jun-
ket playing the role of demo dolly in front of the press and some
important analysts. (Again, we speak from personal experience.)
Scratch the Thursday meeting for the next two weeks.
By the way, to further illustrate the point, we do urge you to read
the rest of Living in an Agile Word all the way to the end. You will
note that while it talks a great deal about ‘Agile product managers,’
what an ‘Agile product manger’ does in contrast to a regular old
slug of a product manager is never actually described. And that is
because there is nothing extra for them to do.
Now, it is time to leave the last 30 years behind and look to the
radiant future being ushered in by SaaS.
The New Model for Product

Managers — Community Management
As we have noted, from a business standpoint the most distinguish-
ing facets of SaaS products include their ability to operate 24/7/52,
capture all subscriber interaction with your system, and concen-
trate your subscribers into a natural community (and this will ex-
tend to your reseller channel, assuming you have built one). And to
leverage this ability, you must build community as well as analytics
and requirements management into your product.
Now, let us assume you have incorporated the capabilities you
need to manage, study and learn from your community of custom-
ers. What do you do next?

The first thing to do is decide if the people who will interact with
and manage your community should be called ‘product managers.’
To reorient your company’s thinking, we suggest using the term
‘community manager’ (CM). However, the PM title has been in use
for decades and it is relevant in on-premise software. If you decide
to stick with it, the next thing you need to do is reorient your brain
to accept that while the title may survive, very little of its previous
functions will. It is time to put the pom poms away.
Let us move on to what your community managers should not
be doing:
First, the need for feature requests management should be
handled directly by the SaaS application, with prioritization
driven primarily by the customer community and an ongo-
ing and vibrant communication between your company and
its customers. This means the end of traditional ‘tick list’
herding. Instead, your community managers will spend their
time in this regard analyzing customer requests, prioritizing
them based on community feedback and measurement, ne-
gotiating with the customer community on implementation
schedules and best practices, and providing your develop-
ment group with constant and quantifiable updates on fea-
ture usage and community satisfaction.
Second is that MRDs, PRDs and other related documents
and processes should disappear. These tools have always been
closely tied to the traditional 12 to 18 month software release
cycle prevalent in desktop/retail and on-premise software,
but as we have seen, this cycle has pretty much vanished in
SaaS. In an environment of continuous build, test and release,
no one has time to create or read lengthy MRDs, PRDs (and
the pace of SaaS development tends to make these docu-
ments obsolete before they can be finished). Instead, the on-
going dialog between your company and your community of
users will substitute for these documents and provide a con-
stant narrative of system change, adaptation and evolution.
Internal Wikis, collaboration tools and other systems will be
used to record and manage this narrative.
The third area of radical change is the abandonment of the
stand-in role that product managers have tried to play during
the Agile development cycle. With a community of users, no
middleman is needed to communicate directly with custom-
ers. Tools such as ‘personas,’ which attempt to simulate cus-
tomers, will be less compelling. Instead, use actual customers
or prospective customers from your subscriber community
to directly interact with new versions of the product under
development in ‘sandboxed’ areas of your system that capture
actual clicks and record actual complaints (or kudos), and
allow detailed analyses. Use web-based video conferencing
to assemble and manage focus groups. Remember that in a
properly architected SaaS system, your community is always
observable and manageable from your desktop. Community
managers who submit requests to hop on airplanes so that
they can ‘find out’ what customers think of your software and
how they use it should be told to stop kidding around and get
back to work. (Sorry, air travel fans.)
Instead, a SaaS community manager’s primary function will
be to build and enlarge a customer community, empower it
to manage itself to the extent practical, serve as community
advocate and communications channel to upper manage-
ment, and perform the role of community guide and re-
source provider.
Launch planning is another area of operations that will un-
dergo radical change in SaaS companies. In on-premise mar-
kets, your first product ‘launch’ tends to be your last major
involvement with your customers until the next launch.
But SaaS products, driven by the interaction between your
company and your community, evolve in an almost organic,
real-time fashion. Marketing programs must focus less on
short-term glitz and bling and more on providing access to
trusted experts, building ‘micro promotions’ closely tuned
to your community’s internal business clock and providing
services of ongoing value that can be measured and to which
ROIs can be attached.

Beta programs, which have traditionally functioned as both
testing and marketing programs in the software industry, also
undergo fundamental changes in SaaS. As Google has shown,
the idea of a product entering and leaving beta on a release
schedule built around the assumption of a 12 to 18 month re-
lease cycle is meaningless; Google has kept programs in ‘beta’
for years while still monetizing them in a variety of ways. In
much the same way, a SaaS product as it evolves is always, in a
sense, a beta program because of the near real-time evolution
of the system. While individual features or new modules may
be released in sandboxes for testing and comment before de-
ployment, this is a far cry from the massive beta programs
that industry observers have often seen serve as PR stunts.
For all the CDs dumped into the mail and files downloaded
from servers, these programs often seem to have missed the
point of uncovering problems with and objections to your
software.
Once again, what replaces beta programs is the concept of
leveraging a customer community to provide ongoing feed-
back from that community to your company on the relative
value of your product’s new features and capabilities. An ef-
fective SaaS ‘beta’ program identifies ‘power users,’ domain
experts and industry experts, and listens carefully to their ad-
vice, comments, observations and complaints. It incorporates
these into the ongoing narrative of the product’s evolution. It
publishes this narrative to the entire community. It listens to
the community’s feedback and opinions. And the program
measures and analyzes outcomes and adjusts accordingly.
Roadmaps will remain a factor in your marketing and devel-
opment operations, but their importance will be diminished.
Some subscribers, particularly in markets where your SaaS
product needs to be integrated with other software and sys-
tems, and in cases where your product is mission critical to
their core operations, will want to be kept abreast of future
product developments for technical reasons. However, the
ongoing narrative between your subscribers and your devel-
opment group will unveil product directions early and often.
And in most cases, it will be your community creating the
roadmap. They will know where you are going.
Before this book was written, we blogged about some aspects of
the community management model on the Softletter website and
promptly aroused the wrath of some product management sophis-
ticates. Some of the objections were a bit funny. For the past 30
years, pundits and product management experts have prayed for
extensive “user input into the development process.” Agile proph-
ets have established priesthoods dedicated to worshipping the
user. The first Agile manifesto proclaims, “Our highest priority is
to satisfy the customer through early and continuous delivery of
valuable software,” as well as “Business people and developers must
work together daily throughout the project.” (All quotes are from
the original Agile manifesto.) When SaaS enabled that vision to be-
come reality, suddenly the apotheosis of ‘business people’ stopped.
Instead of demi-gods, software customers suddenly became dolts,
peasant clods who lacked the ability to see the big picture and
needed to be led by the hand into a misty future by a wise techno
elite. Here is an excerpt from a Forrester blog that summarizes what
is perhaps the most cogent objection in this regard:
“And what about market development? Our hypothetical
SaaS vendor has already attracted a particular kind of com-
pany — say, medium-sized eschaton brokerage firms in the
continental United States. But is that the ultimate market
that you, the SaaS vendor, want to reach? By following the
direct feedback of current customers, you may be missing the
features that are important for the next market you want to
enter, where neither streamlined imanetization or improved
reporting may be the cost of entry.”
Excerpted from Tom Grant’s blog site, the Heretech, 06/19/2009. Grant is an
analyst at Forrester Research.
This misses the point. Are you worried that your customers are
not as smart as you? That they are missing the big picture and that
you are missing opportunities because of your focus on the most
communicative and knowledgeable users of your system?

No problem. Nothing about the community manager model
prevents you from adding whatever features you want. Moving into
new markets. Innovating as you see fit. It is your product. And if
you have integrated analytics into your system, you should be able
to measure the activities of the ‘silent majority’ in your subscriber
base. But in a properly architected SaaS product, you’ll be measured
on the acceptance and usage of new capabilities very precisely. Your
community’s complaints about your failure to add functions they
request will become palpable. And remember that as it grows, your
community should also be thought of as active marketing place
that is ‘trading’ in the future of a single commodity — your com-
pany. And markets are the most active predictors of the future ever
developed. But if you feel the road to success ignores the input and
desires of your customers, you can now precisely measure its im-
pact on your business. And be accountable for your decisions.
Another point is that product managers are not tasked with
opening new markets at software firms; that is the job of upper
management, who typically hire business development specialists
or ‘domain experts’ to analyze new opportunities and industries.
Product managers are hired to focus on and optimize the sales and
marketing of ‘their’ product, to the extent they are able. A manager
who spends too much time looking longingly over at another in-
dustry or product is usually assumed to be stuck with a barking dog
wad of code and trying to save their skin before it is scorched off
at a ritual auto de layoff designed to placate the God of Poor Sales.
Community Manager Measurability,
Accountability (and Responsibility)
Now that we know what community mangers should not be doing,
what are the metrics and tasks that will define their new roles and
responsibilities in the era of SaaS customer communities?
Measuring and increasing community satisfaction. Once
a SaaS product has been introduced, it will be vital for its cus-
tomer base to grow quickly into a interactive, self-managing
community; obviously, helping create this dynamic will be the
job of the CM. Measurable metrics will include the size of the
community, percentage of growth, percentage of community in-
volvement by customers, and level of satisfaction with the CM
by the community. Product managers are supposed to crave
constant customer contact; in SaaS, it will be the central facet of
their day-to-day work.
Encouraging community learning and self support. As noted
in the Customer Services chapter of the book, driving down
support costs via community learning will be an important met-
ric with a long lasting impact on the bottom line.
Increasing community monetization. A SaaS community is a
rich potential source of additional and incremental revenue for
a SaaS company. Opportunities include:
• Sales of specialized reports to interested members of the
community.
• Sales of aggregated information (where appropriate) on best
practices and business trends relevant to the businesses ser-
viced by your customers.
• Sales of upgrades as well as cross/upsells from promotions
recommended and, in some cases, implemented by the com-
munity manager — perhaps a ‘community marketing man-
ager.’ (It may prove desirable to separate these two roles lest
the community manager come to be regarded as a sales shill
rather than a community advocate.)
• Fees from new capabilities requested by community mem-
bers who are willing to pay to achieve new levels of function-
ality on an accelerated basis.
• Revenue shares with companies that are building new ser-
vices on top of the SaaS vendor’s API/platform (assuming
your system offers this type of access).
• Organizing and communicating community insights and in-
telligence. A good SaaS community system enables a manager
to collect, analyze and report on community usage of a SaaS
system at a very deep level. Every login and click (and non
click) can be stored, aggregated and measured; SaaS compa-
nies can measure user/product interaction in ways not pos-
sible before. If, for example, the development group (or the

community manager) feels that Feature X should be added to
the system instead of the Feature Y requested by the commu-
nity, it will be possible to measure acceptance (and assign re-
sponsibility) for the success or failure of new feature additions
and subtractions.
Once again, there is a strategic advantage that comes from the
ability to precisely measure community and user acceptance of new
capabilities via the measurements created by the combination of
community input and business analytics derived directly from the
application. It is an advantage that is unique to SaaS firms. Since the
early 80s, endless angst has been generated over the issue of provid-
ing customers with the functionality they truly want in their soft-
ware. SaaS companies are in position to quickly and precisely meet
their needs in ways and time frames never before possible. A SaaS
company can be truly ‘agile’ in all aspects of its operations — de-
velopment, marketing, sales and support when they properly lever-
age their community. Those who learn to do it sooner and better
will prosper and grow more quickly than those who do not. And
in a well-run SaaS company, it should be the community manager
who performs this role while working against a series of quantifi-
able metrics, many of which will have a direct bottom line impact.
In the future, expect to see the power and influence of community
managers increase at SaaS firms.
Of course, with great power comes great responsibility. Many
will struggle with the community manager model as it drives ac-
countability through your company in ways not seen in the indus-
try before. In the past, software companies have been very good at
pointing internal fingers when new releases do not do well. Sales
blames product management for providing unsellable products
(normally, they are too afraid of development to blame them).
Product management blames development for refusing to listen to
their opinions or read their MRDs and PRDs. Development blames
product management for providing poor user input and unrealistic
and vague requirements. Upper management blames all of them.
But in SaaS, all the excuses go way. In a properly structured
SaaS system, accountability and measurability will be pushed out
to every job and function in your company by your community.
Development, marketing, sales and upper management can all be
measured on their prescience and business sense and held account-
able for their decisions. (And we will assume upper management
will continue to blame middle managers when things go wrong; we
are discussing SaaS after all, not Utopia.) The manufactured (and
greatly overused) word ‘customercentric’ takes on a new meaning
and significance in the world of on-demand software.
What will the consequences of these changes mean to the world
of Agile and its devotees? Well, there still will not be any such thing
as an Agile product manager because community mangers will still
not be programmers. But tomorrow’s SaaS community manager
will be able to help guide and streamline the provision of the one
commodity craved by all Agile methodologies — timely, compre-
hensive user input and feedback as a product grows and evolves.
For Agile enthusiasts, this all for the best. The use of product
managers as stand-ins for the customer is and always has been a
second-best choice. The original Agile manifestos do not reference
product managers but rather customers. In an ideal Agile world,
customers and developers are supposed to be in direct, constant
contact with developers, expressing their needs and desire to them.
But SaaS inherently allows customers and developers to constantly
(though virtually, to everyone’s great relief) communicate in just
the fashion envisioned by the original Agile visionaries.

SaaS Entrepreneur Case Study
Apptegic: Providing Business Precision in SaaS
Company: Apptegic
Company HQ: Boston
Market/ SaaS analytics,
Industry: customer engagement analytics
Company Principals: Karl Wirth, CEO, Greg Hinkle, CTO
Founded/ Founded 2010, went beta
Years in Business: with paying customers in May 2011
Company Privately held,
Development Type: privately funded
Number of Employees: 4
% of Revenue Growth Company is in the startup phase
Over Last Years: with paying customers
Notable Customers: Dyn, ConstantContact,
Recorded Future, Vela Systems
Marketing Overview and Challenges
In June of 2009, the author of this book gave a presentation at Soft-
letter’s SaaS University Conference in Chicago during which he
urged all SaaS companies to integrate business analytics into their
systems immediately. It was a stirring call to action, but unless you
were willing to ‘roll your own’ system for capturing and analyzing
analytics, it was not actually possible to follow his advice. At the
time of his invocation, no commercial systems existed that would
allow a SaaS system to quickly plug analytics into their operations.
By 2011, that had changed. Releases from companies including
Apptegic, ToTango and Kontagent (their system is targeted towards
smartphone applications) were coming online.
Apptegic began its life as a concept for an on-premise appli-
cation to assist companies to manage and monitor their growing
portfolios on SaaS applications. Faced with the reality of the expen-
sive and slow sales cycles that are the norm for the type of product,
the company reversed course and instead developed a comprehen-
sive analytics system that can be used by any SaaS firm. The App-
tegic system can monitor:
• Capture usage data (clicks).
• Functions.
• Pathing or bread crumb trail.
• Browser usage.
• Location.
• Demographics.
Information unique to a particular business, such as number of
documents managed, customer age, etc. This can all be tied into
basic usage statistics.
There is no limit on the number of subscribers who can be
tracked. Currently, Apptegic is supporting systems with millions
of customers. The system is very granular, allowing its subscrib-
ers to analyze anything from a complete subscriber base to selected
segments and groups down to an individual account. The system
is implemented via an API and data is accessed via a web interface
that presents as a dashboard. Pricing per month ranges from $200
to $2000 per month.
One of the company’s earliest customers was Dyn, Inc., a pro-
vider of managed DNS and E-mail services, located in Manchester,
NH. While the company’s enterprise offering, Dynect, was growing
strongly, their self-service product, DynDNS.com, was starting to
stagnate, declining from mid-double-digit net growth to the single-
digit. Cory von Wallenstein, Dyn’s vice president of products, was
assigned to find out what the problem was.
The first analyses discovered that the company was suffering
from high customer churn rate, with the percentage hovering at
60% (80% retention is a minimum goal for SaaS firms and 90% is
the goal for companies selling into more niche and vertical mar-
kets). The company was signing up new customers at a healthy clip,
but failing to hold onto them. And because creating a new customer
is approximately three to five times more expensive than keeping
one, the company was spinning its wheels.
To try to understand why the product line was suffering from
such a high churn rate, a project was launched to analyze customer
interaction with their DynDNS system. But to do this, Dyn needed
to develop a means to drill down into and query a dataset that had
millions of users and many more millions of unique interactions.

Dyn first began the analysis process by using a series of ‘do it
yourself ’ tools and processes to handle the analysis. These included:
• The Unix command line for looking at Apache logs with
grep, uniq, wc -l and more.
• Google Analytics, with dozens of custom configured ‘events’
and ‘segments.’
• Plenty of SQL hammering, with reporting code written in
Python and Perl.
• A homegrown tool for graphing a moving average of key
metrics.
• Large quantities of Excel and PivotTables.
As you can imagine, this mix of tools and processes was difficult
to manage. Extracting results from it was equally challenging.
Leveraging Apptegic
Fortunately from Dyn’s standpoint, Apptegic was coming online
and Dyn decided to become one of the company’s first customers.
Compared with what they were doing, Apptegic was simple to get
up and running and its extensive reporting capability allowed Dyn
to rapidly drill down into the data and uncover correlating events
between subscriber interaction churn.
What Dyn discovered was that the problem could be traced to
its renewal process. The company made it too difficult to renew, and
their renewal processes and promotions were not properly aligned
with their subscriber’s schedules. In terms of schedule alignment,
the company found that:
• Subscribers were far more likely to take action on renewing a
service if their reminder email notifications (sent 60, 30, 14, 7,
3 or even just 1 day in advance of expiration) were delivered
on a ‘workweek’ day (Monday, Tuesday, Wednesday or Thurs-
day) versus a ‘weekend’ day (Friday, Saturday or Sunday).
• Correlated to email deliveries of notifications, the ‘final re-
minder’ E-mails delivered the day before expiration of an
annual service had very different success rates for the ‘work-
week’ days vs. the ‘weekend’ days. Accordingly, Dyn stopped
shutting down services on the weekend and pushed all expira-
tions that would fall on a weekend day to the following Tues-
day. This allowed the final ‘day before’ reminder email to be
sent on a Monday, when the subscriber was likely to see it).
In terms of marking it easier to renew, Dyn did the following:
• Made it easier for users to turn on automated renewals on an
initial purchase, so no manual action was require to extend a
subscriber’s renewal.
• Created highly visible renewal calls to action within the ap-
plication itself.
Changed business processes that were preventing easy renewals.
Specifically:
• Dyn created highly visible ‘update your soon-to-expire credit
card now’ calls to action in the applications, as well as sepa-
rate reminder emails for updating credit cards due to soon
expire. This significantly increased the success of automatic
renewals.
The results of Dyn’s deep dive into its analytics were excellent.
Churn rates were raised to 80%, a reasonable median for a SaaS
company in a broad, horizontal market such as Dyn’s. (Again, if the
company were competing in a niche or more vertical industry or
segment, 90% would be the minimum acceptable percentage.)
The company also spent time analyzing the activities of two dif-
ferent classes of subscribers — its most vocal minority and its high
volume customer base that rarely contacted Dyn. The results were
enlightening and had a dramatic impact on the company’s revenues.
Responding to requests from highly engaged customers netted
approximately $100K in additional revenue over 12 months (as well
as generating insights into how the system could be improved). But
Dyn added seven figures to its bottom line after analyzing the ‘silent
majority’ of one of its major product lines.
Dyn has been in business for 14 years and one of its most pop-
ular products is DynDNS Pro, a service that allows you to assign
an easy to remember hostname (such as yourname.dyndns.org) to
your location’s IP address. By installing an update client on a device
at that location, your hostname is automatically updated whenever

the IP address changes, ensuring you can access your device re-
motely at any time. The service has five million subscribers.
When the system was first introduced, it used the ‘freemium’
model. Subscribers could use the system for free as long as they
used it at least once a month. A paid, ‘premium’ subscription
started at $20 a year, with higher paid subscription levels. The rev-
enue model for the service included the assumption that free sub-
scribers would in the main be casual users. If their needs grew, X%
of subscribers would purchase a paid subscription. However, an
analysis of subscriber interaction with the system revealed no such
correlation! Freemium subscribers were just as likely to be heavy
consumers of DynDNS as paid subscribers.
Based on this finding, the company changed its model. New
subscribers had to sign up for a 14 day trial that required they pro-
vide their credit card information for billing. If after this period
they decided they did not want to pay for a premium plan, they
could drop back to a free account. The process of exposing new
accounts to the benefits of a paid plan increased conversion rates
from .24% to 1.01%, a 300% increase that added seven figures to
the Dyn bottom line.
Lessons Learned
The lesson any company can learn from Dyn’s experience is simple.
By integrating analytics into your system, you can quickly learn
how subscribers are using your product, learn what problems they
are having in maximizing their engagement, solve those problems
and raise revenue. A SaaS product without integrated analytics is a
blind product.
Plex Systems: A Pioneer in Community (No Arrows in
the Back). An Interview With Patrick Fetterman
Company: Plex Systems
Company HQ: Auburn, Michigan
Market/Industry: ERP (enterprise resource planning)
for manufacturers
Company Principals: Mark Symonds, CEO; Craig Huke,
CFO; Doug Gregogy, SVP Products
and Services; Patrick Fetterman,
VP of Marketing
Founded/ Founded 1995 as Plexus Systems, LLC;
Years in Business: changed name of company to
Plex Systems, Inc. in 2009
Company Privately held; majority shareholder
Development Type: is Apax Partners LLP
% of Revenue Growth Three year compound
Over Last Three Years: annual growth rate of 32%
Notable Customers: Invensys Controls; Inteva Products,
LLC; IMS Gear GmbH; Magna;
Vornado Air; Serralles Distilleries;
Meijer, Inc.; the company currently
has 661 subscribing companies.
In the summer of 2007, the author of this book attended a software

marketing conference hosted by Software Business Magazine at a
hotel on the Boston 128 corridor. During the program we attended a
panel session on the SaaS industry that included Patrick Fetterman,
Plex System’s marketing chief. During the panel discussion, Patrick
described Plex’s successful transition from an on-premise to a SaaS
model. While discussing how his company managed its develop-
ment cycle, he told the audience that the entire process was now done
without product managers and the traditional product management
framework so common in on-premise software firms. Plex was a pio-
neer in this regard and is being joined by an increasing number of

SaaS companies who are replacing ‘product’ with community man-
agement, for example, Priava in the International chapter. Patrick
Fetterman, who often presents at our Softletter SaaS University
Conferences, is the subject of this interview.
Patrick, you say Plex has no product managers (PMs). Tell us
more. Over the last 30 years, almost without exception, once a
software company reaches a certain size, and certainly within
the enterprise space, it begins to implement a formal product
management process.
“First, let’s define what PMs traditionally do and why; both you
and I have practical experience in this area. They’re usually keep-
ers of the MRD (marketing requirements documents) and the PRD
(the product requirements document). Normally, they spend a lot
of time running around talking to customers and different groups
within the company about what should be on the MRD and par-
ticularly the PRD. The cycle runs about a year or so, and there’s lots
of arguing, negotiating, and winnowing of the feature list. Finally,
something emerges from the process that no one likes and everyone
tries to subvert; then you move forward with your product release.
At Plex, the process wasn’t quite as gruesome as what you describe
earlier on in this chapter, but you weren’t completely exaggerating,
either.
“During the 90s, this process was driven by the realities of the
client/server model. We had to support different OSs, databases,
clients and desktops. We were locked into the 12 to 18 month prod-
uct upgrade cycle by the environment. But once we’d moved to the
SaaS model, after several months we began to realize that tradi-
tional product management practices and methodologies weren’t
relevant to our company. Much of this was driven by the imple-
mentation of Agile methodologies at Plex. As the model took hold,
the changes it created in development rippled out across the entire
operating fabric of the company.”
Do you adhere to any particular school of Agile?
“Our approach mixes several RAD/JAD approaches. We’ve spoken
to Dr. Cockburn, the ‘father’ of use case development, but we don’t
use formal use case analysis.”
Let’s discuss the fate of traditional product management at SaaS.
“As Agile spread through our organization, traditional product
management approaches withered away. MRDs and PRDs didn’t
make sense; the software was evolving too quickly. Preparing for
launches and beta program was pointless; there weren’t any. There
was no typical roadmap. But we had to reconfigure our organiza-
tion for the avalanche of user interaction and requests for new fea-
tures and capabilities that began heading for us on a daily basis.”
How many feature requests are you managing per year?
“The current rate has ramped up to about 100K per year. Of these,
50K we discard quickly because they duplicate existing functional-
ity. 25K we feel are bad ideas in that they don’t fit with the thrust
and philosophy of Plex. That leaves 25% for consideration. Of
these, maybe 25% make it into the product. New feature releases
are an everyday event. We don’t work around product deadlines;
when the new feature is ready, we turn it on.”
What kind of a strain on your bottom line does this development
cycle represent?
“None at all! Development and QA are profit centers at Plex. We
charge for all feature requests. We bill out our engineering services
at industry standard figures over cost [author’s note: $150 to $200
on average] on an hourly basis, with the understanding that new fea-
tures we develop per customer request will be available to all Plex
users; Plex retains the rights to all features we develop. If/when we
decide to implement a feature we always tweak it so it’s useful to the
entire customer base. We’ve had no push back over this issue; any one
customer gets the value from the enhancements requested (and paid
for) by all other customers. Our product is surrounded with a robust
configuration framework; again, this is inherent in SaaS products.
“The number of development hours will obviously depend on
the complexity and scope of the new feature. Customers can make
a request of any type, which is then managed by our team of devel-
opers and implementation specialists. When a customer requests a
specific feature the teams go through the product ‘inventory’ to see
if a current capability is close to the request. Nine times out of ten
we’ll implement a feature a customer requests, except in the case of

a determination that it’s not a best practice; in that event our com-
munity manager will open a dialog with the customer.
“Another facet of the SaaS model we’ve leveraged is that feature
management and testing are directly integrated into Plexus and are
used daily by our project management and testing systems. Our
system has an integrated feature request button on every page of
our product. In a sense, this is a voting mechanism that puts Plexus
directly in contact with our customers. Once a feature is requested
and implemented, it’s tested internally and then turned over to the
customer or a customer team.
“This all takes place in the context of our customer community.
In many companies, product managers are supposed to function
as the voice of the customer, but in a SaaS environment you don’t
need that. The customer can ‘speak’ directly to you via the product
24/7/52. We ask our customers to keep a ‘running’ top 10 feature
requests poll in the system; if they don’t keep that feature in the Top
10, its likelihood of being implemented drops. We’ve also integrated
a community/forum system within Plex that enables subscribers to
create discussion topics of mutual interest and concern. And we’ve
also added a peer to peer communications system that can provide
context-sensitive notifications of changes to the Plex system.
“This approach allows us to react quickly to not only our sub-
scribers but to changes in the industries served by our customers.
We experienced this directly soon after the integrated requirements
system went live. When steel surcharges went crazy in the manu-
facturing industry, we received almost instant feedback from the
system for better management of these charges and we were able to
respond quickly.
“Another important advantage that our ‘charge for feature’ of-
fers Plex is that it naturally winnows out requests that aren’t truly
important to the subscriber. If you want to pay for something, then
it’s important to you; if you don’t, it’s not.
“Our model in this regard is also evolving; for example, we’re
considering:
• A program the enables our subscribers to cost-share localiza-
tion and translation costs to help facilitate our entry into new
international venues.
• A cost-share model for subscribers who want to commission
us to develop major new modules.
• A kick-start program designed to deal with a problem we’ve
seen in our market. When a new industry standard is intro-
duced into a particular industry segment we service, a situa-
tion sometimes arises where multiple customers will hesitate
to ask us to implement new features to meet the standard.
The kick-start program provides the first company that re-
quests the new features the opportunity to obtain them for
free or deeply discounted.
“An interesting fallout from our pay-for-new-features approach
is that customers have become so addicted to our model of en-
hancements that they have flooded us with requests. We currently
have approximately a three month backlog of enhancement re-
quests that customers want to pay for. While a backlog isn’t great
from a customer service point of view, it’s excellent from a product
strategy point of view as we have a database with tens of thousands
of customer requests for enhancements to our product! We are hir-
ing specialists to analyze this database, tease out trends, and help
us prioritize similar requests that also align with the company’s ex-
pansion strategy.
“I’d also like to make the point that our customer community
drives other aspects of our product development beyond features
sets.”
An example?
“Our documentation. As you can imagine, documenting features
and usage for our system is a big job. Plex is a complex piece of
software that’s also mission critical to most of our customers. At
one point, we identified over 10 separate repositories of knowledge
management. Things were spinning out of control. During an open
discussion on our forum system about the problem, a group of 20
customers volunteered to create a Wiki to replace our current sys-
tem; since then, the community has taken the lead in maintaining
and updating what has become the product’s documentation.
“This entire process has taught us a lot about the dynamics of cre-
ating customer community. For example, reputation management

and acknowledgement. The number one contributor to the Wiki
became heavily involved with an internal project at his firm and his
contributions tailed off; in fact, the entire project stalled a bit. We im-
plemented a new system that ranked contributors to the project and
when our customer saw he’d dropped from the number one contribu-
tor spot to number 10 it reenergized him to regain his ‘Top Dog’ spot.
“The entire experience led us to work with the high contributors
on a more proactive basis. We reach out regularly with E-mail, the
phone, and through a program of official recognition at our an-
nual user conference. We provide awards for most contributions to
the documentation Wiki, one for most active Community Adviser,
another one for people who drove product development the most
through their great requests and ideas. Our development group
also gets in the act and nominates and votes on the most interesting
feature request of the year. Awards are plaques and gift certificates
and are given out at our annual user conference; last year it drew
between 700 to 800 people.”
What about the objection that by listening too closely to key cus-
tomers you lose focus on new markets and opportunities?
“That’s an interesting point. We’ve found that our community helps
us identify and learn about new markets and requirements. For
instance, we’ve been looking at new opportunities in the Brazilian
market and reached out to our subscribers to learn more. An ex-
ample of what we’ve learned is that under the Brazilian tax code,
moving products from one location in a warehouse to another can
trigger tax charges; this ties back to their VAT revenue system. It’s
something an ERP for manufacturers needs to know and incorpo-
rate into their software to address local needs. We’ve also imple-
mented a customer advisory board that’s cross industry and cross
company size; this also provides us with insight into areas for busi-
ness expansion.”
What have you replaced your product management system with?
“It’s been an evolving process. We’ve recently created the title of
Community Manager; their role is to engage with and guide the
community along the lines discussed earlier in this chapter. But
more specifically, at Plex, CMs:
• Seed discussions on new topics.
• Identify trends.
• Host webinars and live events.
• Connect prospects to customers.
• Leverage social media with your customers
“The skills background is not that different from that tradition-
ally associated with PMs. Online social skills, likability and knowl-
edge of our customer’s business — more geek chic than geek.”
What about the role of product marketing managers? Tradition-
ally, they’re specialists in post-release marketing.
“The problem is in the question since we don’t have traditional re-
lease cycles. But after much experimentation, the function has sur-
vived, as has the title. What’s changing is the scope and focus of their
jobs. Without new product launches, we’ve had to rethink how we
market. We now look to hire people who are or can become sub-
ject experts in industries and/or localities. Their job revolves around
content creation, subject matter expertise and business develop-
ment. We look to develop publicity and market awareness around
major events, research reports and vertical events that are important
to customers.
“These managers also have the responsibility to investigate and
take our product to new markets. But the process we use relies on
the community mindset. Instead of creating MRDs, our product
marketing managers work with the community to learn more mar-
kets and requirements, feed the information back to interested par-
ticipants, and eventually identify someone in the community who
will engage with Plex and develop a formal request for us to build
new capabilities that help us enter that market.
“It’s the type of bottom-up dynamic that SaaS firms need to un-
derstand and harness. SaaS firms have to stop thinking like software
companies and start thinking like online service companies. At Plex,
we say ‘WWGD.’ That’s short for ‘What would Google do?’”

CivicPlus: A Customer Engagement Company
Decides to Fully Engage With its Customers
Company: CivicPlus
Company HQ: Manhattan, Kansas
Market/Industry: Community engagement and
content management systems
for government
Company Principals: Ward Morgan, CEO,
Deb McNew, VP of Operations
Founded/
Years in Business: Founded 2004
Company Privately held,
Development Type: privately funded
% of Revenue Growth 2009–2010, 42%,
Over Last Three Years: 2010–2011, 42%
Notable Customers: Burleson, Texas, Montrose, Colorado,
Park County, Colorado,
Richmond, California
Marketing Overview and Challenges

CivicPlus originally went into business in 2004 with the vision of
supplying city and county government with specialized content
management systems (CMS), dynamically created websites op-
timized to manage pictures, files, messages, etc. Over time, the
company discovered that the single biggest need of its government
customers was to communicate with local voters and citizens via
these CMS sites. As a result, CivicPlus repositioned its business to
focus on a citizen engagement system that was tightly integrated
into their CMS.
CivicPlus was well aware of the value of communities and before
deciding to build their own community management system, had
made the strategic decision that future product development would
be driven by their subscribers. In evaluating the path the company
should take in picking a community system, CivicPlus had four
basic choices:
• Build its own community management system.
• Use the popular social networks such as LinkedIn, Grouply,
Facebook or similar system.
• Use third party forum and discussion boards.
• Use third party ‘private’ social systems such as Yammer, Le-
verage, Jive, Lithium, Chatter and others.
Each approach has its advantages and drawbacks. If you choose
to develop your own community system, you will hopefully end
with something that is an exact fit to your needs but developing
it may not fall within your core competence and the system may
never be finished and never work quite right. And upgrading and
maintaining a community system may not be what you want your
development group to focus on.
Using an existing and popular social network is tempting. Costs
are low to start and these systems are easy to get up and running.
The problem with them is you do not ‘own’ your community; the so-
cial network provider does. For example, LinkedIn can and has shut
down groups without providing prior warning to group owners for
reasons that later proved to be invalid. Ditto with Facebook accounts.
And in all good conscious, we cannot recommend Facebook for any
B2B company as primary community system, though it can be useful
for marketing purposes and as a way to ‘feed’ your community. The
present security and privacy issues are simply too great and the sys-
tem is not well designed for a more closed social environment.
In addition, social systems may have restrictions you find un-
acceptable or too confining. For example, LinkedIn only permits
one message a week to be sent to your group. It provides almost no
useful metrics that permit you to measure response to your notifi-
cations and promotions.
Third party forums and discussion groups can be useful, but
they often have limited contacts to the social networks, limited
connectivity to external databases, and are regarded in some circles
as ‘old technology.’ But they are relatively inexpensive and often
provide tight control over content posting and behavior.

The abilities of private social systems vary widely. Some are
highly template driven and relatively inflexible. Others are more
free form and can be more easily configured. Data integration and
transferability varies widely from package to package.
Most of the current generation of community management
products do not integrate closely with SaaS analytic systems. Over
time, we expect this situation to improve, but it is a factor you
should take into consideration when deciding what path to take in
implementing your community management.
CivicPlus decide to go with the fourth option and subscribed
to a private social system. After a year, the company decided they
had made a mistake. The system they had picked had many nice
features, but was template-driven and too inflexible. CivicPlus had
ample HTML design and resources internally, but even with these
found it too difficult to customize the social system to meet the
firm’s integration and ‘look and feel’ goals.
Fortunately, the company had learned a great deal about how
communities work by observing how their subscribers interacted
with their subscriber base — voters and citizens. At that point, the
company decided it was time to ‘eat its own dog food’ and use its
own technology to support its own subscribers. One of the prin-
cipal factors in this decision was that CivicPlus’s system was built
around a CMS; this provided it with a great deal of inherent flex-
ibility in creating a more customized appearance.
The CivicPlus community system incorporates the following:
• Discussion forums.
• Social media linking.
• File sharing and uploading.
• Voting systems that allow subscribers to nominate new fea-
tures for development.
• RSS feeds from government oriented sites such as
www.govloop.com, www.govtech.com and
http://americancityandcounty.com.
Figure 1-9. CivicPlus community management subscriber interface.
The community is managed initially by members of the CivicP-

lus’ customer engagement group, which works with its subscribers
and assists them in turn in building engagement with local popu-
laces serviced by a CivicPlus CMS. Promotions to the community
are managed by the marketing side of the company. CivicPlus does
not have product managers but will be adding a community man-
ager title to the organization.
Lessons Learned
Your choice of a community management system should be made
carefully. Make sure you consider the following:
• How much control do you have over your community infra-
structure? Can you back up your community membership,
archives and other materials? What recourse do you have if a

third party shuts down your community? (In the case of the
major social networks, the terms of use terms you agree to
give you practically none.)
• Is the system you pick configurable enough to meet your ap-
pearance as well as scalability needs? If not, how difficult will
be it be to transfer your community content to a new system?
• Can community analytics be integrated with your SaaS sys-
tem analytics? Combining these two capabilities is a mea-
surement and management dream.
YOUR COMPLIMENTARY CHAPTER
Copies of SaaS Entrepreneur: The Definitive Guide to Succeeding in Your Cloud

Application Business can be purchased at goo.gl/CBlBTY
www.progress.com

Saas Entrepreneur Progressbookclub

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Saas Entrepreneur Progressbookclub

Uploaded by

Copyright:

Available Formats

YOUR COMPLIMENTARY CHAPTER

SaaS Entrepreneur: The Definitive Guide to Succeeding in Your Cloud

Zach Nelson is an accomplished software in-

In light of these numbers, do you think mobile/tablet applica-

Thank you for purchasing SaaS Entrepreneur: The Deﬁnitive Guide

What is in SaaS Entrepreneur?

The SaaS Entrepreneur Virtual DVD

Who Should Use SaaS Entrepreneur?

It is worth noting the num-

Why is SaaS Succeeding?

Quickly gain access maintains its number one standing but

Other Contributing Factors to the Growth of SaaS

The Cloud Stack

SaaS — The Software is the Social Network

What Creates the Application Network?

Figure 1-1. Percentage of SaaS No

What type of analytics does your measurement system provide?

used of all pro

SaaS and the Power of Communities 35

What customer community activities are supported and/or ac-

These twin characteristics give SaaS applications an unmatched

Figure 1-5: Percentage of

Whether you purchase or buy your requirements management

SaaS and the Power of Communities 37

The Age of the Community Manager Dawns

SaaS and the Power of Communities 39

SaaS and the Power of Communities 41

SaaS and the Power of Communities 43

SaaS and the Power of Communities 45

When Softletter began publishing this report five years ago,

SaaS and the Power of Communities 47

SaaS and the Power of Communities 49

The New Model for Product

SaaS and the Power of Communities 51

SaaS and the Power of Communities 53

SaaS and the Power of Communities 55

SaaS and the Power of Communities 57

SaaS and the Power of Communities 59

SaaS and the Power of Communities 61

SaaS and the Power of Communities 63

In the summer of 2007, the author of this book attended a software

SaaS and the Power of Communities 65

SaaS and the Power of Communities 67

SaaS and the Power of Communities 69

SaaS and the Power of Communities 71

Marketing Overview and Challenges

SaaS and the Power of Communities 73

The community is managed initially by members of the CivicP-

SaaS and the Power of Communities 75

Copies of SaaS Entrepreneur: The Definitive Guide to Succeeding in Your Cloud

You might also like