Insights into how technology and the outsourcing of R&D are changing the software industry

Today I read a good post by CrispWireless CTO, Xavier Facon, entitled “Apps Call, but will your phone answer? Maybe not.” The post was a response to an MSNBC CES article bemoaning the fact that many apps exist on certain platforms, but not others.  This of course is not news.  Apple’s iPhone had 100,000, Google’s Android 20,000 and Palm’s WebOS just over a 1,000 (please make more, I like my Pre and do have app envy).  The fragmentation of the mobile industry across different operating systems and different hardware systems is well documented and is the bane of many software developers and testers across the world.

The crux of Facon’s post seems to provide tacit support a more standards-based approach coalescing around HTML5, but also acknowledging that the industry is not close to supporting a single standard and therefore they try to solve the quandary by re-writing the app across different platforms. At least Crisp seems to focus on keeping the functionality, something that many companies don’t do.  This is an important decision by Crisp because it helps maintain not just common functionality across devices, but also promotes a common design and better usability as users move from one device to another.

But I want to get back to the standards issue.  As much as software engineering teams across the globe would like to have a standard “write once, run anywhere” approach as they’ve been used to with modern languages like Java, I don’t think there is any likelihood of  this happening in the short to medium term.  It’s really not all that dissimilar to creating desktop apps for Mac v. PC, it’s just that there are more options in the mobile world.  The hardware platform providers like Apple, RIM, Google, Nokia and Palm each have different OS’ that they think create differentiation for their platform and provide better performance/user experience.   If you want to take advantage of the full capabilities of the device, you have to write for the platform.  And the reason behind it all is usability.

While using a standard language like HTML5 may make it easier to program across platforms, but it doesn’t allow you to take advantage of the specific capabilities that the OS and hardware allow for.   Plus you have to design for the form factor.  Mobile apps — perhaps I should  say “good mobile apps” — look vastly different from the content on the web.  They’re designed for action more so than information.  For fingers, not mice.  For use by broader segment of the population who may be less tech savvy.  I mean can you even imagine using an iPhone or Palm Pre without multi-touch and gestures?  Look how that changed the entire experience and drove usage through the roof.  In a recent PhoCusWright report Mobile: The Next Platform for Travel, they demonstrate the difference in presentation and usability between a standard web site, a mobile transcoded site and an app.   Now there are many WAP-enabled sites that run in a browser and provide something in-between the transcoded site and an app, but anyone that’s used a WAP site still prefers and app to get the same information.  Usability is what it’s all about.  The App strategy wins over a WAP strategy.

Google wants HTML5 because it wants a web-oriented portable computing device to better leverage the web apps that is the core of its business. Android is more of a strategy to extend it’s platform rather than to create a new one that is optimized for mobile.

Additionally, an app strategy rather than just a mobile web strategy provides a performance advantage. A downloaded app only needs to get refreshed data over the network rather than reloading the entire page each time.  It’s true that 3G and 4G networks are improving (if you have coverage; no apologies to AT&T coming. As tiresome as the Verizon ads have become, Luke Wilson is seriously annoying), performance is extremely important.  Abandon rates on the web are high for a 3 second delay.  Most people would kill for a 3 second delay on their mobile applications.
So while it may be a pain to code for multiple platforms, it’s the only way to go.

What’s your take?  Agree? Disagree?

Well I finally landed a new gig with Ness Technologies.  While still in the outsourced product development space it’s a bit of a different mission for me.

My task is to leverage the experience Ness has garnered in the travel technology space through it’s long-standing work with Amadeus, a leading travel global distribution system (GDS) provider based in Europe.  Essentially it’s a chance to build a business within a business almost completely on my own.  A heck of a challenge and one I’m looking forward to.  I’m ready to take the leap.

Used with permission from Eric Chan (maveric2003)

The fun will be in figuring out yet another new industry with the travel biz.  Already see that there is a lot of lingo to learn, new buyer titles and profiles and emerging market dynamics.  Should be fun.

The good news for me is that there seems to be a lot of potential to leverage topics and technologies that are already near and dear to me (Cloud, SaaS, SOA, social media).

And while I expect that a lot of the posts on the blog should start reflecting issues in the travel technology space, I will continue to put in my two cents — here, on Twitter and in my new role as contributor to eBizQ — on the goings on in the software business and impact of emerging technologies.  In fact, later today I’ll be heading to the Microsoft New England R&D Center for Cloud Camp Boston and hope to emerge with some insights and video to share.

In an earlier post I started to talk about the intrinsic value of usability for software products — the satisfaction and value that customers perceive about the product they bought and how it might map to and made the statement that usability should be viewed as important as any other aspect of the product development lifecycle and gave a few statistics to begin the support of my argument.  Now I want to delve into some specific examples of how excellent software usability principles can provide significant positive impact to achieving a company’s business objectives:

How Usability Impacts a Software Company’s Costs

• Reduced Engineering Costs: From a software company’s perspective this is the first, and often only consideration on usability.  The statistics are there to show that the majority of defects and re-work costs — up to 80% — come from omissions and mis-interpretations of requirements and related errors in design. To mitigate the disconnect, many companies have utilized visualization tools like iRise to help translate the intent of product managers and clarify requirements to software development teams, vastly reducing the number of defects that are injected into the code, which result in more re-work, development and test cycles.  This is especially useful in geographically distributed development organizations where communication and collaboration can be a challenge.  However, visualization is not the same as usability engineering.  It’s merely creates a representation of how one person believes the user interface should look like but does nothing to remove design or navigation flaws which w0uld still need to be fixed later on.  But usability engineering + visualization can make a real impact on the performance of the R&D organization.
• Fewer Support Incidents: For every problem that poor usability creates, resources have to be expended to resolve it and soothe the feelings of the customer and make them feel happy again with their purchase.  Now most companies put a lot of effort into coming up with ways to reduce their cost of delivering support services, using FAQs, self-service options and community-driven support.  But that addresses the symptoms, not the cause. The real, sustainable way to reduce support costs is to reduce the number of incoming service incidents.  Improving the usability of the product, making it easy to find, access and use features can go a long way in achieving that goal.

How Usability Positively Reinforces Your Customer Decision to Purchase

• Faster User Adoption, Improved User Productivity and Lower Training Costs: When companies buy software products they buy the promise that they’ll be able to do great things.  All the demos they’ve seen make it look easy to use.  Especially with enterprise software, they’re promised that their employees will be more efficient and their business will run more smoothly and profitably as a result.  But we know from our own experiences that when the vendor leaves, the implementation rarely looks like the demo.  Sometimes it’s because features aren’t turned on or configured properly, but more often than not it’s because the new software operates differently than the way employees have been performing the business process/task at hand.  There can be a significant learning curve, or worse a requirement that the customer changes their business process to fit the software rather than adapt the software to the process.  And the problem is often that there is a general lack of intuitiveness of how to use the product.  I look at my 5 year-old daughter when she uses my wife’s iPhone.  She picks it up and starts using it.  No training, no pouring through a user guide (although she can read at almost a second grade level…yes I’m a proud papa).  Menu-based navigation often leads users struggling to figure out where a certain function is hidden and almost often lacks contextual guides which automatically puts the next or adjacent activities within easy reach.  If more research and care was put into how users work, training budgets would be slashed dramatically, employees would move up the productivity curve faster, and companies would be able extract the value they thought they purchased more rapidly.
• Advocacy and Loyalty.  Building off the last point, happy customers happily, and often without prompting advocate for products that they enjoy using.  Look at how passionate Mac/iPhone owners are about their products.  Even when they bemoan AT&T, iPhone owners still proclaim the greatness of the device itself.  So in a world where people buy products increasingly based on peer recommendations and social platforms like Twitter give a voice to happy customers and connect them easily with prospective buyers.  They are your best and cheapest advertising.  Moreover, happy customers are fiercely loyal and have a selling cost of close to zero.  And in today’s software industry, where maintenance revenues are 4x new license sales, client retention is KPI #1.

Do you think your company invest enough in usability?  If you’re a product manager, how much of your budget and effort do you allocate to this topic?  Let me know.

Last week I saw a tweet from Oracle OTN architect Bob Rhubart pointing me to a post from the Jake Kuramoto at Oracle AppsLab entitled “Do users want innovation?“  [Editorial note: in the rest of the post I will refer to "users" as "customers".  I think the psychological implications of how you look at the people who buy your products – users = necessary evil, versus customers who you value – is important...at least to me.]  Now without reading the full post, my initial reactions was: “users want value. true #innovation usually = value. But most new features masquerade as innovation but not valuable.”

I thought I’d take the opportunity now to amplifying my thought, especially after closely reading the Oracle blog post.

Too Much Energy Used to ‘Keep the Lights On’

Kuramoto rightly points out the tension in every product development organization: how do I effectively split my resources between:

• fixing yesterdays problems (fixing bugs)
• adapting to environmental factors (e.g. updates to code for regulatory changes)
• finishing what you started (features that didn’t get into the current release); and
• introducing honest-to-goodness innovations.

According to a number of different research sources, the cost of ‘keeping the lights on’ (the first three bullets) can take up in excess of 80-90% of R&D budgets.  That’s a terribly inefficient use of resources (especially in this economic environment).  It ties up resources that would be better used to build tomorrow’s next hit product and adds to margin pressures.  More importantly, it’s not seen as valuable by customers and doesn’t add value to the company – yet it’s where software companies spend most of their money.  These are things that you have to do, but don’t really have much impact on existing customers’ satisfaction or increase the perceived value they’re getting from what they bought.  Yes you’re fixing bugs, but they didn’t want bugs.  They wanted software that worked in the first place!  And more importantly, none of these activities really help attract new customers. Already today many enterprise application companies are looking at Maintenance : New License revenue ratios of 4:1 or higher.  If companies could just convert, even 5% of R&D expenditures to truly innovative, new product development imagine the impact on new license sales and margins.

You Can’t Ask Users to Tell You What they Want

There’s another aspect of the AppsLab post that troubles me.  Kuramoto writes: “So, we yearn to push the envelope and experiment with new technologies, but all our users really want is incremental improvement.”  There are two elements to this statement that I want to address:

1. The first part of the sentence reads as if “innovation” is about experimenting with new technologies.  First let me say that I’m a big fan of experimentation…no matter the subject…and feel that it’s an integral part of developing innovations.  But I think the statement misses a crucial point about innovation.  The biggest innovations have much less to do with technology as they do with behavioral change.  The VCR (or for those of you under 25, the DVR) was a huge success because it enabled viewers to record and watch shows when it was convenient for them, not because they were looking for a replacement for 8mm video to watch home movies. Technology is often an enabler of innovation.  But in the software industry too often the focus is on the technology for it’s own sake, so be sure that you’re stepping back and re-evaluate what you’re doing in terms of meeting your customers’ needs.  This is probably also a good time to differentiate between inventions and innovations.  An invention is a new idea, concept or product, but doesn’t have any intrinsic value.  An innovation is an invention that you can monetize.  If you can’t monetize it, it means that no one sees enough value from the idea to spend money on it and therefore you shouldn’t either.  If you’re consistently wasting time working on things that no one wants to buy, that should tell you something.
2. The back half of the sentence is the other aspect that product managers need to think about.  Of course your product’s current users want minor changes that they may have seen on a competitors’ product or something that is an obvious extension of how they’re using your product today.  Most users of any product can’t see three feet in front of themselves or at least can’t readily articulate what they really want.  So to say that “users really want incremental improvement” doesn’t mean that they don’t want innovation.  I go back to my tweet: Users do want innovation because innovation usually means a significant improvement in the value that they get from the product they own.  But incremental improvements (I’m not even sure that people should use the term incremental innovation anymore – it’s oxymoronic) don’t meet that threshold.  So you need to interpret what changes in behavior will mean for the way they want to use your product.  Look at how they are using your product (and not using it), don’t listen to what they’re telling you.  Especially with SaaS/Web/Cloud-based software, there’s reams of clickstream data that can give you insight to what users want to do.

I think the AppsLab post draws the wrong conclusions from the examples cited, such as Facebook and the integration of social technologies into enterprise applications (nee Enterprise 2.0) .  Facebook’s (and similarly Twitter’s) dramatic success was due to the way that these applications allowed people to interact and engage with others (of similar interests or long-lost friends).  The backlash against Facebook’s redesigns had more to do with the fact that they forced new behaviors and a small element of re-training that seemed to provide no additional value to them (not to mention the associated TOS and data ownership issues).

So I encourage all product managers, CTOs and heads of R&D to find a way to put more resources towards true innovative enhancements to your products and don’t get intellectually trapped by the things your customers vocalize.  Similarly don’t get trapped by waiting for the mega idea.  Clayton Christensen coined the term ‘disruptive innovation’, but not everything has to be truly disruptive to be valuable.  If you think that you have a great idea go for it.  Otherwise you’ll be stuck with empty marketing messages promoting “new and improved” features masquerading as innovation.  It doesn’t often work in consumer packaged goods and frankly most tech buyers are much more knowledgeable about the technology they buy for work versus the laundry detergent they buy at home (Can any of you tell me why Tide is better than Cheer?  I have no clue).

But you can’t wait for your customers to tell you what innovation is.  By the time they do, your competitor has already built it.  The truth is that for most of your customers, innovation is like the judicial definition of pornography…they will know it when they see it – and the market will reward you for it.

The other day I responded to a tweet from James Urquhart that prompted an interesting discussion:

“Does a successful virtualization strategy take away from the ROI of cloud computing?” <- Interesting. Not enough to avoid cloud, me thinks.“

What that made me start to think about was the underlying value proposition and ROI of cloud computing and the juxtoposition of operational and financial goals.

Under Urquhart’s perspective, a company that has deployed a successful VM has a lower Cloud strategy ROI than a company that has not deployed VM.  This may be true from a raw number perspective because the company with the VM strategy is already getting much more benefit from their existing infrastructure.  But they may still fight problems with scalability, depending on the projected use of their application, which might push them towards the cloud.

But it brought me to a very practical question that few are talking about: “How can companies maximize the value from their existing IT infrastructure when planning a cloud strategy?” If the Cloud is all about ROI, how should companies factor in their existing investments?

Now most public cloud advocates talk about the Cloud as if there is no existing infrastructure.  All you hear is No CapEx, Lower OpEx, Unlimited Scalability, Superior Performance.  Yet most of the people they’re trying to sell to have hundreds of thousands, if not millions of dollars in infrastructure investments.  For those companies the ROI of the Cloud is a much more difficult proposition because it leaves them with dead assets.  Yes, they can try to re-purpose those assets to run other systems, but that would require some detailed analysis and planning of their entire infrastructure needs, look closely at when to retire servers or other equipment and build a phased plan to enter the Cloud.  Quite frankly that kind of analysis is probably long overdue anyways.  But in today’s economic environment – which is improving, yet still a long way from boom times – people are trying to figure out how to squeeze more value from what they already have, not how to abandon it more quickly.

And for those who are thinking about evaluating a private cloud strategy (although a cloud on your own infrastructure in my view is not a cloud), they may be able to get more value out of virtualization and other strategies, but they lose the operational efficiencies and instant scalability to match spikes in demand that the Cloud has to offer.  It’s an alternative to the public cloud, but in many cases still doesn’t solve the business problem that moving to the Cloud is supposed to address.  As an aside @krishnan wrote a good post on his own changing views regarding the debate between public and private clouds and helped spark a few ideas for this post.

So it leads me to this.  If “Cash for Clunkers” worked for the car industry (at least to the tune of 690K vehicles), why not bring the concept to the Cloud?  Why not “cash for Infrastructure”? When you think about it, it’s a virtual rush to acquire clients.  While there may not be true lock-in, it’s certainly a hassle to move operations from Cloud to Cloud, so it’s time to lock-up customers.  So why wouldn’t deep-pocked companies like Amazon, Google or Microsoft offer some sort of upfront cash for a company’s existing computing infrastructure assets to lock in a customer now?  Of course companies on the next tier like OpSource, Rackspace or GoGrid probably don’t have the resources to offer it, so they’re at a disadvantage.

Does anyone have the “onions” to make this offer?  I’m sure there are a lot of companies who’d be willing to take them up on it.  If any of the above companies run with my idea, I only want 0.5% of the assets they acquire in compensation

UPDATE: @lmacvittie had a great suggestion on Twitter to improve the idea. It doesn’t have to be cash. Even credits for cloud usage would be a good incentive. Maybe now guys like OpSource and Rackspace have a way to play.