SmoothSpan Blog

For Executives, Entrepreneurs, and other Digerati who need to know about SaaS and Web 2.0.

Archive for March 2nd, 2008

Empathy Bridges the Gap Between UsWare and ThemWare

Posted by Bob Warfield on March 2, 2008

Jeff Atwood writes of UsWare and ThemWare:

  1. MeWare
    The developer creates software. The developer uses it. Nobody else does.
  2. ThemWare
    The developer creates software. Other people use it. The developer does not.
  3. UsWare
    The developer creates software. Other people use it. The developer uses it too.

These ideas originated with Eric Sink, but the discussion is based on Jakob Nielsen’s First Rule of Usability: Don’t Listen to Users.

The question is not whether to ignore your users, but how to listen to them.  Users are often too literal in what they want.  They want to tell you about the feature or change that you must make to your software, rather than the real problem they need to solve.  This is treating the symptoms and not the disease. 

Often they don’t know the real problem they want to solve.  This is where empathy can bridge the gap.  With UsWare, we don’t need empathy so much, because we developers are the users.  With ThemWare, we run the risk of following the wrong suggestions, or following the right suggestions too literally because we have no compass to guide our decisionmaking about features.  Anyone who has seen software built by the classic Product Management triage and prioritization approach knows it is a recipe doomed to create mediocre software:

– Canvas the user groups for what they want.

– Prioritize according to some metric.  All too often the metric is whatever the Product Manager thinks is cool.  Ideally the metric has some relationship to the business results the Software company hopes to achieve.  It’s very easy to get bogged down in these metrics with Balanced Scorecards and a host of other contrivances that stand in for true understanding and empathy.

– Put it all down on stone tablets called “Product Requirement Documents” and hand those to Engineering with the proviso to implement them precisely as they are written and don’t ask too many questions.

By contrast, Empathy means we have some sort of true understanding of why users want what they do.  This helps us to know things like:

– Which things can and should be safely ignored.

– Which things will really change the user experience for the broadest market.

– Which things will be interesting “almost good enough” features that are demoed often but seldom used.

Empathy is a bit different than Vision.  It’s deeper because it’s rooted in the Domain.  Find someone with Empathy in your Domain and that someone will be completely comfortable conversing with your users about their problems.  They’ll be able to persuade those users they are right, albeit perhaps requiring a prototype or two to get there.  The reason?  They speak the user’s language.  They get it.

Make sure someone on your team has this Empathy for your market or you’ll have a very difficult time.

Posted in user interface | 2 Comments »

Microsoft Switching Office to SaaS? Makes Total Financial Sense!

Posted by Bob Warfield on March 2, 2008

Nick Carr and Michael Arrington are both saying Microsoft is about to start switching over all of its offerings to SaaS.  The news, if true, would be a bold move for Microsoft.  I think the timing makes a lot of sense.  Here’s why:  people are mostly done upgrading, the market is saturated, and Microsoft’s product cycles are very slow. 

In the old days, Moore’s Law meant that every 18 months or so computers got twice as fast.  That was a compelling argument to buy a new computer every couple years.  Things have slowed way down on that front, which has led to the multicore crisis.  But it’s also led to another factor.  For a desktop software company, in the old days, driving big growth meant driving rapid upgrades and new purchases.  The new purchases would take care of themselves via Moore’s Law, especially since most businesses bought more copies of the software for new machines.  the upgrade cycle could be used to help juice things further.  But as Moore’s Law has changed from faster PC’s to more cores, the drive to upgrade machines has slowed.  Meanwhile, Microsoft has always been getting slower and slower on their upgrade cycle:  Office 95, Office 97, Office 2000, Office XP, Office 2003, and Office 2007.  At this rate, the next Office update wouldn’t be due until say 2011.

So what’s a poor monopolist to do in order to keep the revenue and growth fires blazing?  Switch to SaaS, that’s what.

Let’s speculate a bit on what they might charge.  A typical formula for SaaS is to charge enough so the vendor is ahead versus license after 36 months.  That would mean on a $399 Office 2007 package to charge about $11 a month.  Hey, that even sounds like it might be reasonable for a “real” MS Office product.  There is talk of ad supported versions, and that’s a possible alternative too.  My bet is they won’t go cold turkey to adds, but rather there will be different versions.  It makes sense to pay more to eliminate the ads, or pay a little and put up with ads. 

Okay, now the next thing to do to understand the sense of this is to compare the two options.  I’ve graphed a scenario I dreamed up to compare the two:


The red line is SaaS, and as you can see, it quickly overtakes the blue perpetual license line.  How does that work?  I’m graphing cumulative revenue, which is $11/month for the SaaS version.  For the perpetual/retail version, it’s a little different.  Here I have factored in the upgrade cycle.  I assume we have a brand new version of the software in year 1, and that 50% of the installed base upgrades that first year, 20% the next year, 10% the next, and 5% in the fourth year, followed by another new release in Year 5 and the same cycle starting over again.  As you can see, perpetual has a temporary advantage when the early big upgrades occur, and that peters out.

Now you can clearly see why this is a great time to introduce the SaaS version: they’re past the early big upgrade wins.  The cream has already been skimmed.  By introducing SaaS now, they have a chance to have their cake and eat it too.  Of course the revenue advantage will not be as dramatic as what I’ve painted.  There will be a changeover period of some kind where part of the revenue is perpetual, and part of it is SaaS.  The important thing is that Microsoft has several years to manage that transition, and with a little care, they can make sure it only means further growth moving forward.

Ryan Stewart goes onto tie all this up with the offline version of Silverlight that’s expected.  I wouldn’t be surprised if there is a delay before any SaaS announcements are made.  It is a necessary move, but it is also one that will make some parties nervous.  Investors, in particular, will want to understand the full financial ramifications SaaS will have on Microsoft’s financials.  They’re already fairly upset at the loss in Market Cap the Yahoo debacle has caused.  It’ll be interesting to see whether this delays any SaaS moves, whether they just work harder to explain it, or whether they just go for it and investors be damned.

Posted in saas, strategy | 6 Comments »

%d bloggers like this: