skip to main content

Rick's Blog on SaaS - Main Page

Why Do Customers Buy SaaS?

Posted by: Rick Chapman on 9/25/2011

There's been a lot written over the years about why businesses are purchasing SaaS. If you like to spend time on the Linked In systems and peruse the various SaaS and Cloud groups, you'll often read references to Capex vs. Opex (capital expenditures vs. operating expenditures) as the primary driver of SaaS purchases. (For some reason, I've note that commentators from India seem to focus heavily on this metric, a reflection, perhaps, of their local market conditions.  I'd be interested in hearing more on this topic from Indian SaaS companies.)  The idea behind this is that by shifting software expenditures from capital budgets to operating ones, the flinty hearts of CFOs everywhere will be warmed and SaaS expenditures are more likely to be approved.

If you spend time reading through the various IT publications, you'll certainly develop the impression that it's the CIOs and their attendant geek squads that hold the fate of SaaS in their hands. Over the last several years there's been an unending stream of articles with headlines such as "SaaS adoption in IT," "What do CIO's think of SaaS?" "CIO's embrace SaaS" "CIOs fear SaaS" "CIOs Believe SaaS is Evil Plot," "CIOs Believe SaaS Presages the Rapture" and so on. Perhaps the best example of this dynamic in action was The Gartner Group's June 14th  announcement on its newsroom site that: 

"Software as a service (SaaS) will have a role in the future of IT, but not the dominant future that was first thought, according to Gartner, Inc. Organizations should carefully assess their software needs in light of the current promises delivered on by SaaS. 

'In 2009, within enterprise applications, SaaS represented 3.4 percent of total enterprise spending, slightly up from 2008 at 2.8 percent,” said David Cearley, vice president and fellow at Gartner. Gartner predicts that this market will reach $8.8 billion in 2010." (http://www.gartner.com/it/page.jsp?id=1385813) 

This sounds rather gloomy, especially when compared to this 2008 observation: 

Worldwide software-as-a-service (SaaS) revenue in the enterprise application markets* is on pace to surpass $6.4 billion in 2008, a 27 per cent increase from 2007 revenue of $5.1 billion, according to Gartner, Inc. The market is expected to more than double with SaaS revenue reaching $14.8 billion in 2012. (http://www.gartner.com/it/page.jsp?id=783212) 

But no matter.  By July 27th, things were looking better than ever for SaaS according to Gartner as it told us that:

SaaS Market Growing by Leaps and Bounds (http://itmanagement.earthweb.com/entdev/article.php/3895101/SaaS-Market-Growing-by-Leaps-and-Bounds-Gartner.htm)

But again, no matter. The fact is that the growth of SaaS has not been driven by either IT enterprise acceptance or Capex vs. Opex, though both of these do a play a part in the growth of SaaS. 

Since 2006, Softletter has been surveying SaaS companies and asking them what we regard as the most important question in the survey. This question is: 

What do you believe is the primary reason your customers choose to subscribe to a SaaS system?

 Here are the answers from 2010:

A) Customers can quickly gain access to new capabilities and functions that they cannot obtain by purchasing existing software products and services 40%
B) Customers wish to replace existing licensed and/or client/server applications with SaaS applications to reduce overall IT operations and complexity at their company or business unit 19%
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 13%
D) SaaS applications are counted as an operating expense, not as a capital investment 16%
E) Other (These were in all cases a mix of A and the other choices)
11%

As you can see, "Quickly gain access to new capabilities" is the response leader by a strong plurality. In fact, in the previous three reports, this answer was always the majority response (last year the "Quickly gain" came in at just over 50%). What accounts for the shift in numbers this year?

One answer to why the shift in numbers is that the uptake of SaaS in the enterprise is indeed increasing, driven by the recession and the consequent need of companies to continue to modernize their business operations and increase flexibility while also conserving cash. But note that the Capex vs. Opex answer comes in at 16%; last year, this response came at 19%.  Over the four years of the survey and report, the response to this question has ranged between 15% to 19%, with a mean of 16%. 

Another factor driving the change is that for the 2010 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 become increasingly fragile and difficult to maintain, leading to a counter 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 element's of  a company's business operations should stay in place for many years into the future, in much the same fashion as COBOL applications 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, as Microsoft, Oracle, and other companies built around desktop/retail and client/server models are finding. 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're doing and it's cheaper and best to just leave them alone to keep on doing what they do best. And it's als probably best to leave the server's on which these applications in states that are stable and easily maintainable, 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, which was:

What do you believe is the main secondary reason your customers choose to subscribe to a SaaS system?

A) Customers can quickly gain access to new capabilities and functions that they cannot obtain by purchasing existing software products and services 31%
B) Customers wish to replace existing licensed and/or client/server applications with SaaS applications to reduce overall IT operations and complexity at their company or business unit 24%
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 11%
D) SaaS applications are counted as an operating expense, not as a capital investment 18%
E) Other (These were in all cases a mix of A and the other choices)
11%
F) There is no secondary reason 6%

"Quickly gain access" maintains its number one standing but loses ground to "reduce IT complexity." "Capex" stays stable; clearly, it's important to a significant segment of customers but it's never a main driving factor. 

But the world is not standing still and the need for new applications to address new needs is not going away. And herein lies the primary reason for the growth of SaaS over the last seven years, since the market began to recover from the ASP meltdown of 1999-2001. The on demand  mode inherently opens up new markets and opportunities that simply can't be adequately serviced by existing client/server applications. 

Let me provide you with a practical example of what we mean. At our recent SaaS University conference in Washington, DC, we met a representative of a company that provides a service that enables states to meet the requirements established by the various state "Megan's Law" requirements to track the locations of released sex offenders. These laws have been passed with a great deal of acclaim and fanfare over the years but the reality has been their effectiveness is sharply limited in client/server computing environment. For these systems to work, a wide variety of state municipalities, locations, and regions must have access to the software in order to provide up-to-date information on an offender's status and location. However, many town, counties, villages, etc, etc, are simply incapable or unable to install and maintain client/server applications in their locales (and may not have the hardware on which to load the software or the ability to maintain it once they do).  However, even the smallest village will have governmental resources that can access a web browser on a PC. In a SaaS-based world, implementing a sex offender tracking database, or elections management system, or wide area emergency notification to a college campus, or in store retail electronic kiosk management all become viable markets. 

Salesforce.com, the poster child for SaaS for over a decade, grew to its current $1b+ status via a related dynamic. What is now called CRM began in the late 80s as a series of desktop/retail class products with names such as Telemagic, Act, Maximizer, and Goldmine. To sales and marketing departments, these applications were as compelling to  sales and marketing departments as VisiCalc and Lotus 123 had been to finance groups years earlier. By the 90s, there were few heads of sales or marketing who weren't aware of how useful desktop CRM packages were and didn't wanted them in their departments, but it was often impractical. While client/server versions of these product were available, installing them on departmental computers (their usual destination) was a painful process and didn't scale well (I speak from personal experience).  If you were a big company, you could spend millions on a Siebel installation but that obviously wasn't practical for most firms. Salesforce.com saw the opportunity and ran with it.

This dynamic is still the primary driver of SaaS growth and will remain so for at least the next decade.

Create a trackback from your own site.

0 Comments

Leave A Comment



CAPTCHA image
Please enter the CAPTCHA phrase above.



  

Comments on the blog

"

+++ Rick, I think you're hung up on labels and political baggage here. +++

This seems to be completely off point. An observation that product management practices and theories as currently practiced are becoming irrelevant in SaaS doesn't seem the least political to me. I don't work for these companies, have no animus towards them, and don't really compete with them.

+++Forget what Pragmatic Marketing says, which apparently is a sensitive issue for you. +++

Pragmatic is simply the largest company in this spacd and therefore used an exmplar.

+++ When a "community of customers . . . talk[s] directly with development", the team weighs the input, probes in some cases for deeper understanding, applies business judgment, decides what to implement, and leverages quick feedback loops. You can't get away from the fact that these activities happen. +++

Get away from what? My articles and posting on these say that's EXACTLY what will happen in a SaaS environment! Haven't you been reading what I've said? The point is that they CAN happen in a SaaS milieu because the model inherently makes it easy. SaaS product naturally capture all user interaction and concentrate customers into one manageable, observable "space". This is not true of desktop and various on premise, client/applications. Again, I point you back to Pragmantic's own writings on the subject. Zero content on what an "Agile Product Manager" does. And PM's do not run scurm teams. And developers don't do very well trying to be marketers.

rick

" Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"Somehow I agree. I didn't read the article in the very detail. You see things simply as they are ... Agile is for development teams as well as the Scrum. The Scrum defines the product manager as chick and maybe he can act as product owner but I don't believe this makes lot of sense. The Scrum simply defines that the Scrum master is not responsible for the time estimated, he is responsible for the complexity a team is in the position to handle in an iteration and to guide the team to see the effort and to improve this process. The goal is to get a realistic picture of what can be achieved in the next iteration. In another dimension the product owner and the team form a group of people that share the idea of the collective owner ship to a certain product and the the estimation in time and on the other hand ressources to be spent on a specific story or result as in increment. Spoken little radical. The idea of the Scrum is - keep the business people a way from the production process and let them participate in a well defined border. I can only say the discussion about waterfall, prototyping, V-modell, RUP, Spice compared to Agile is really something different. The moment you give up the vain idea of MDA und create an instance of the Unified Meta Process (RUP is on way to do things) you will end up with something that comes very close to Scrum. What happens now is the beginning of the end of Scrum. You cannot run a company that produces SAAS Services and products like a chemical plant that produces liquid products in a continous process. What happens now ... what is taken - aha we can produce with half or less the people, better quality and the aim is to manage to a) reduce the interation time and b) we will make it that we can achieve with one 4 man team the same as with 20, because this numbers were written down in a book (aim to show the effictiveness of stories - but this is forgotten...). Now the product manager has the weapon to produce what didn't pay before ... This is not a prodcut managers job. Why did most of the other approach fail. People took them picked out what they liked and applied it somehow. The moment you apply prototyping to a big lazy organization results in getting nothing done in cycles - the original idea was just - don't produce just one increment and big iteration over months - show the people something very soon and you get better input - Berry Boehm did not say a lot more - but it was revolutionary these days... The moment you beginn to apply the Scrum more than on micro level you get back the urgency immediatly - the aim of the Scrum is to avoid urgency. Agaile approachs are a very fragile way of producing. Many other approaches are very robust. But I fully undertand and I have seen many people that did not like me this moment, when I told them - guys it is nice that you are here - but now you have the choice - be part of it and take over responsibilty in the development process or just leave - nice to meet you. And in the only those who are commited remain - the product owner - the team (developers scrum master). The Scrum is not so effictive if it is applied in general than it was when applied to projects where web artists who had no idea about the domain had to implement and application that was not document centric. " Read more
by Michael Thuma on Silly Agility: The Myth of the SaaS Agile Product Manager

"Rick, I think you're hung up on labels and political baggage here. Forget the labels "product manager" and "developer". Forget formal departmental distinctions. Forget what Pragmatic Marketing says, which apparently is a sensitive issue for you. When a "community of customers . . . talk[s] directly with development", the team weighs the input, probes in some cases for deeper understanding, applies business judgment, decides what to implement, and leverages quick feedback loops. You can't get away from the fact that these activities happen. If you disagree, I welcome you to state which of these activities doesn't happen in the approach you're advocating. If you agree, then it seems our only disagreement is whether to apply the "Agile product management" label to such activities." Read more
by Roger L. Cauvin on Silly Agility: The Myth of the SaaS Agile Product Manager

"

Roger, I fear you are arguing from the past against a dawn that is already rising. Plex is doing what I describe. I am personally working with SaaS companies to help implement this new approach. What I describe is happening; it's not theory.

And at least it's new. When I visit PM sites such as the CrankyPM's, I'm frankly bored at reading endless rehashes of problems, gripes, and observations that were made 30 years ago. It's time to move on.

rick

 

" Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"

+++ Rick, I'm not sure where we disagree. +++

Well, I THINK we disagree on this fundamental point. You believe in the concept of the "Agile Product Manager." I believe the concept is fairly useless in client/server environments and completely off the point when it comes to SaaS companies. I also believe the various programs, training courses, books on the concept are pretty much a waste of time in terms of providing PMs any real skills or abilities they can use in executing their tasks. One caveat: IF these courses are intended to educate PMs on what development does during, say, a Scrum cycle, they can have educational value. But PMs aren't going to be Scrum Masters; if they are, they'll be leaving PM and moving over to development!

+++ I maintain that a healthy product development organization needs one or more people with the skills to perform duties related to market facilitation and application of marketing principles. +++

I don't think this makes much sense. Product development organizations don't normally incorporate product management. When this is tried, product management becomes even more attenuated and directionless. Now, as we both know, some software organizations incorporate technical product managers or requirements specialists; their focus is on use case development, modeling, etc. But they don't spend much time marketing.

Nor is it the role of PMs to apply "marketing principles" to developers. They're coders, not customers.

This leads us back to the problem of the current, prevailing view of product management. Again, you return to the idea of the PM as some sort of surrogate for customers. This is an obsolete approach in SaaS. Think instead of enabling a community of customers to talk directly with development (and thus achieve the Agile ideal). (And remember that development will be in a position to be held just as accountable as CMs for their decisions. Ignore the community of customers? Substitute what you want for what THEY want. Fine! But you can now be judged on the results.)

Forget MRDs and PRDs; no one has time to read or even create them in environments where major releases are coming multiple times a year. Instead, it is the job of community managers to facilitate an ongoing narrative between customers and developments in which the CM uses the SaaS system itself to track, manage, and support this narrative. PMs are not needed to manage tick lists in SaaS; a good requirements system built into the software should handle most, if not all of the heavy listing. Feeling "strategic?" "Innovative?" Great. Go be so and be prepared to be measured on the results!

+++ But none of these things renders the notion of "Agile product management" silly, nonsensical, or invalid. +++

Most of these things render the notion of "Agile product management" silly. I refer you back to the Pragmatic "book." It has almost zero content on what an "Agile Product Manager" does. It postulates some concepts that are directly contradicted by an expert on Scrum. No one takes seriously the idea that a PM is going to run an Agile development team. And, as I've pointed out AND as the numbers we present demonstrate, SaaS companies are starting to integrate abilities directly into their systems that make traditional PM responsibilities pointless.

rick" Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"Rick, I'm not sure where we disagree. I maintain that a healthy product development organization needs one or more people with the skills to perform duties related to market facilitation and application of marketing principles. Those duties are typically associated with the product manager role, and they benefit greatly from Agile methods (particularly frequent "releasable" iterations) - to the point that a product manager arguably has a greater interest in championing an Agile approach than developers. Sure, we can snipe at the Agilists who underemphasized these aspects and instead focused more on the effects on development. We can also rightly point out that the SaaS model makes aspects of Agile much more practical and efficient to apply. But none of these things renders the notion of "Agile product management" silly, nonsensical, or invalid. BTW, there is no contradiction in holding each customer up as an expert on her particular situation and challenges, while at the same time recognizing that most of them are not experts in product design." Read more
by Roger L. Cauvin on Silly Agility: The Myth of the SaaS Agile Product Manager

"

+++ An Agile product manager recognizes that short iterations are critical to understanding the market. +++

Roger, when Softletter first began our SaaS survey series, the large majority of SaaS companies were NOT using Agile. Why is this? Well, we asked the companies we surveyed. And almost invariably, the answer was that the developers had come out of desktop and client/server markets and they didn't use Agile. Oh, everyone knew what it was, but very few paid the idea much attention. In a 12 to 18 month development cycle, Agile just isn't that necessary. And customers often don't WANT rapid iterations of products. They don't WANT their servers being messed with at all, and many, many IT departments regard upgrades and revisions with dread (and sometimes they have good reasons for that dread).

+++ Ensure that the content of each iteration delivers functionality that she can demonstrate to customers and get real (instead of hypothetical) requirements feedback +++

I hope you realize that in SaaS, this is finally practical? Without jumping on airplanes? A properly architected SaaS system allows direct presentations of prototypes, direct analysis of customer usage, and direct customer input without leaving your desk.

I just don't think you fully grasp what I'm telling and you have left your mind a generation behind.

+++ Seen in this light, Agile product management isn't a "silly" term for a product manager that co-exists in an Agile environment +++

Seen in this light, of what relevance are PRDs, MRDs, jumping on airplanes, surveys, etc, etc in an environment where customer communities, integrated usage analytics, integrated requirements gathering, management, and reporting are intrinsic to the environment? Just why are PMs needed to explain what customers want when customers are able to talk to development directly?

Again, reset your mind. The PM or CM of the future will be an enabler and analyst of a community of customers, not a surrogate. The future of PMs lie in their adapting to this new world and building careers around the metrics it enables, not the mushy, unmeasurable mess of ill-defined and contradictory responsibilities and theories traditionally associated with the job. "Responsibility without authority." "Drive revenue with no P/L power." "Coordinate and manage groups with no ability to hire/fire."

It was always silly, but in SaaS, a lot of the silliness goes away.

rick

" Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"

+++Rick, there are plenty of people outside of the training business who believe that "Agile product management" is a meaningful and useful concept. +++

I'm sure that's true, but to date, I haven't seen much information that reinforces that belief. Even SaaS companies four years ago were not large consumers of Agile; that has changed, as Softletter documents. But please note that the change that has driven SaaS in these firms also obsoletes much of what PMs did in the 80s, 90s, and still do in C/S and desktop firms today.

+++ While it's true that the original focus of Agile methods was to address the risks of big up-front design (BUFD), Agilists later realized that big up-front requirements (BUFR) is arguably a greater risk than BUFD. +++

The original manifesto makes no such distinction and that wasn't the (original) focus of Agile. The customer (user) was literally supposed to sit alongside the programmer telling them what they needed and if it worked. There was no bifurcation of design and requirements as you postulate.

+++ Thus Agile was recognized as a way to better understand market needs. +++

Yes, yes, that's what everyone says, We want to know what customers want. We need customers to communicate with us. Oh, woe is us, we can't persuade customers to sit in cubicles with us and eat stale cheetos and drink flat Jolt Cola and share their wishes and dreams with us! Alack and alas!

Yet, when it actually becomes possible for this to take place in a SaaS environment, look what happens! All of a sudden:

+++ The problems with the direct customer/development model of communication include: 1. Without proper facilitation, customers will not provide reliable and useful information. (E.g., customers will ask for a faster horse.) 2. Someone must aggregate and balance the needs of prospective and existing customers. 3. Someone must make strategic product decisions that, to be sound, require knowledge of marketing and branding principles. +++

First, the contradiction of this should be immediately apparent. Everyone wants direct communciation with customers until they actually have to live with the reality of that; then, instead of being deities, customers (you know, the market) become purblind idiots who need to be queued up and slapped around till they learn what's good for them.

Let's address these objections. First, a properly architected SaaS system should support requirements management, 24/7 analysis of product usage, and community feedback. That's an awful lot of facilitation.

+++ Someone must aggregate and balance the needs of prospective and existing customers. +++

As the article says, no one is stopping any company from adding any feature (or pulling one out) of any SaaS product.

The difference is you can now be precisely measured on just how smart you think you are. If more people buy, good for you! If more people don't buy, bad for you. But it will be possible for upper management to obtain metrics on performance not available to them previously. And now, as a PM, you can be held directly responsible.

+++ Someone must make strategic product decisions that, to be sound, require knowledge of marketing and branding principles. +++

Yes. As I said, I've been a PM. The peope who make strategic decisions at software companies are the people who hire, fire, and control budgets. Middle managers do what they're told.

rick

" Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"Rick, there are plenty of people outside of the training business who believe that "Agile product management" is a meaningful and useful concept. While it's true that the original focus of Agile methods was to address the risks of big up-front design (BUFD), Agilists later realized that big up-front requirements (BUFR) is arguably a greater risk than BUFD. Thus Agile was recognized as a way to better understand market needs. The problems with the direct customer/development model of communication include: 1. Without proper facilitation, customers will not provide reliable and useful information. (E.g., customers will ask for a faster horse.) 2. Someone must aggregate and balance the needs of prospective and existing customers. 3. Someone must make strategic product decisions that, to be sound, require knowledge of marketing and branding principles. No doubt that SaaS enables the person who is carrying out these activities to more easily deliver iteratively and obtain feedback. But certain talents and skills are necessary to carry out these acitivities. I call such a person with such talents and skills a "product manager". Most developers do not happen to possess them. " Read more
by Roger L. Cauvin on Silly Agility: The Myth of the SaaS Agile Product Manager

"+++ You portray the role of "Agile product manager" solely as if it were a confused blend of product owner and a traditional product manager. +++

Roger, I don't confuse the two; I've simply pointed out the confusion about the role presented by OTHER people. I don't believe there is any such thing as an "Agile Product Manager." I believe that attempts to sell the concept are simply ways for the PM training firms to earn more training dollars.

+++ Furthermore, you conclude that Agile is purely a development methodology and does not apply to product managment.+++

That's not a conclusion, that's a fact. I quote directly from the original manifesto; do YOU see any mention of product managers there? No. Now, I am very well aware that PMs have been assigned the role of surrogate customer by many software firms and I describe, in real life detail, why that doesn't work very well. It has NEVER worked well. And until the advent of SaaS, the number of companies using and interested in Agile was not that high. Agile sounds nice, but in a client/server environment, it's more talked about than used. In a SaaS environment, Agile makes perfect sense, and I present the numbers to prove it.

+++ Note the premise that development drives the Agile process and that product management adapts. +++

Roger, I've worked as a PM in the real world. In client/serve land, development drives the process, not product managers. The important point that you need to understand (and apparently still haven't grasped) is that in the SaaS milieu, it WILL be increasingly the CUSTOMER who drives development. Agile, ideally, has always wanted this but it was always a lip service concept in C/S land. Not so in SaaS.

++++product management benefits greatly from Agile and should drive the Agile process +++

Customers are supposed to drive the Agile process. That was always the ultimate goal. Now, it's achievable in SaaS. You need to ponder those stats I provide more closely and reset your brain.

rick " Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"

+++ You seem to have this innate knack of continuously bashing people that don't fit into your square hole and all while continuously hawking your SoftLetter +++

I'm not going to bother replying to this display of holding one's breath and throwing yourself to the ground while furiously stamping the tips of your patent leather shoes against the earth. Suffice it to say that if this is the extent of your ability to reason and discourse and you were working for me, I'd fire you.

Also, the fact that you posted anonymously says a great deal as well.

rick

" Read more
by Rick Chapman on Silly Agility: The Myth of the SaaS Agile Product Manager

"Just a quick summary of what the concept of "Agile product management" really is: An Agile product manager recognizes that short iterations are critical to understanding the market. She thus insists that development and the rest of the product team: 1. Deliver in short iterations. 2. Ensure that the content of each iteration delivers functionality that she can demonstrate to customers and get real (instead of hypothetical) requirements feedback. 3. Develop (via test plans) the means of measuring the extent to which the product is meeting the requirements. Seen in this light, Agile product management isn't a "silly" term for a product manager that co-exists in an Agile environment. On the contrary - Agile product management largely sets the agenda for the rest of the team, to the benefit of superior market and requirements understanding." Read more
by Roger L. Cauvin on Silly Agility: The Myth of the SaaS Agile Product Manager

"This article makes a lot of valid points but I think you make one crucial mistake, Rick. You portray the role of "Agile product manager" solely as if it were a confused blend of product owner and a traditional product manager. Furthermore, you conclude that Agile is purely a development methodology and does not apply to product managment. Note the premise that development drives the Agile process and that product management adapts. I argue precisely the opposite: product management benefits greatly from Agile and should drive the Agile process. The bottom line: Agile is not just a development methodology." Read more
by Roger L. Cauvin on Silly Agility: The Myth of the SaaS Agile Product Manager

"You seem to have this inate knack of continously bashing people that don't fit into your square hole and all while continously hawking your SoftLetter NewsLetter. It seems like lot of your assumptions are based on some surveys you conduct - many of the responses for which you don't even know are true to "let-me-get-this-over-with" responses. It is one thing for someone with some industry expertise to say something - just making outrageous statements and creating noise seems to be your model." Read more
by agile product manager on Silly Agility: The Myth of the SaaS Agile Product Manager

"It seems like you keep getting stupid things all the time. Hmm! wonder why? Maybe they are sending it to people who look stupid." Read more
by Anonymous on A Stupid E-mail

  

Add this blog to your RSS feed

Upcoming Events

Click Here to find out more about Softletter's Software as a Service 2011 Conferences.

The Premier Event for those who need to succeed in SaaS.
 

2011/2012 U.S. Sessions:

Denver, CO  (2011), April 26 -28