skip to main content

Rick's Blog on SaaS - Main Page

How to Spot the SaaS Newbie

Posted by: Rick Chapman on 1/14/2011

How to Spot a SaaS Newbie

Looking to hire a grizzled SaaS veteran for your shiny new "Cloud" startup? Not sure if that claim of 10 years experience in the business trenches of on-demand is true? Want to put your doubts to rest?

Then have your candidate take The SaaS Newbie Test. It's simple, easy, and quick! Just ask them this one question. I use it to separate the wise men from the pretenders and it hasn't failed me yet. The question is:

"What is the difference between SaaS (Software as a Service) and ASPs (Application Service Providers)?

If they're a SaaS newbie, the answers will vary. Most often you'll hear the following:

  • Multi-tenancy (ASPs didn't have it.)
  • Scalability (ASPs couldn't.)
  • Hosting (as in ASPs were basically all about letting you host stuff on the Internet. That's a REAL newbie response; some of the most famous ASP failures such as HotOffice and Red Gorilla had nothing to do with the hosting biz.)

And variants thereof.

You may also read bits of boilerplate such as the following:

"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 a completely PROPRIETARY solution architecture and their clients were required to implement that proprietary architecture in order to interoperate."

Clark Sanford, Software + Services LinkedIn Group

"The main difference is that an ASP provider may or may not be providing a SaaS architecture solution. They could possibly be providing a web based solution that is operating via a remote on-premises server that is unique to each customer including individual customizations."

Jim Kubera, Software + Services LinkedIn Group

All of this is wrong and allows you to immediately spot the SaaS newbie. Based on the above, you can safely estimate their experience in SaaS probably goes back to no more than 2007 and 2008 is probably a safer guess. Why this time frame? Because this period coincides with the SaaS movement moving from its comeback stage to its current explosive growth. Beginning in 2007, SaaS companies began to get serious about things such as MT 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, god bless 'em,  is simply telling you what he/she has recently learned. And, if they're technology-driven, seizing on the latest, hottest, shiniest bit of coding-bling to sell their company and themselves.

The correct answer to The SaaS Newbie Test is of course "The difference between SaaS and ASPs is that SaaS companies make money and ASPs didn't."

No, I'm not being funny (though the reality is grimly humorous). As the ASP market collapsed in 2001, the SaaS newbie will not be aware of the following facts:

  • There were ASP firms implementing mult-tenancy (MT) that failed.
  • There were ASP firms NOT implementing MT that survived.
  • While high-speed bandwidth connections were far more problematic a decade+ ago than today, they were available, most companies did have access to high speed bandwidth, and the ASP movement did not collapse because of dial up connections.
  • MT 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 understood the underlying concept of creating a "Big Cube" of data and "virtually" stacking more cubes on top of one another). (Online gaming companies particularly understood the value of MT, as they used the technology to support the myriads of customers who signed up to slay orcs, fight dragons, and virtually marry cute mythical creatures such as elves and fairies. Not that there's anything wrong with that!)

Backing up these facts is another one. And that fact is that is in 2006, in the midst of the ASP (now renamed SaaS) recovery, Softletter released the first edition of its SaaS Report. That first edition, as have all subsequent editions, asked SaaS providers if they implemented MT 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 the next year (2007), 50% of SaaS firms had not yet implemented MT into their systems.

Now, your SaaS Newbie is also not going to know when SaaS replaced ASP as the official designation for on demand software and why. If you ask, you'll hear more babble about "scalability," "MT," "hosting," et al. The answer to this can be found in the immortal (as the author, I assure you this is an unbiased opinion) 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 technology was picking itself up off the canvas. Here's an excerpt from ISOS II 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. ISOS II was published in 2006, and has been translated into seven languages and been in continuous print since 2001, though most new sales now take place on Kindle and other E-formats. This excerpt 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 acronym. Taking its place were a plethora of new alphabetical appellations—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 designation 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 me in 2005; the rest of the paragraph is from the 2001 first edition.)

Of course, the logical next question is if wasn't MT, infrastructure, scalability, "open standards," and all the rest of it, what killed the ASP movement?

The simple answer is, of course, a lack of customers! As I was writing the first edition of ISOS in 2000-2001 I 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 lack of enough people signing up for the ASP offering. The SaaS newbie will frequently start to natter on about "scalability," but for those of us who were there and paying attention, there was a conspicuous lack of press reporting on ASP firms dying because they were being crushed under the weight of all those customers rushing to subscribe. No one I interviewed in that time period reported their firm had face planted because of too much business; it was a problem they would have been glad to have. (BTW, if you're going to claim that your company died for just that reason, your word isn't going to be good enough to convince me. I'd 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't provide them, I don't believe you.)

Why was there a lack of customers for ASP products in the 1999-2001 time frame? Hmmm. For the complete answer, you need to pick up a copy of ISOS II. Read Chapter 11, obviously, then turn to Chapter 14, "Stupid Analyses," page 324. Read the section on the Disruption Model carefully. This will help bring the era into focus.

But I don't want 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 markets 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.)
  • 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 shouldn't have. In the period leading up to the 2001 meltdown, the VC community lost its collective mind and threw money into firms with stupid business models that had no prayer of succeeding. 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.

So, there it is. The SaaS Newbie Test! Use it to distinguish between the callow poseurs and the real veterans!

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 2012 Conferences.

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

2013 U.S. Sessions: