I’ve seen a lot of different “roadmaps” for SaaS products lately. Some of them are good guides for specific questions. Some are simply misleading or poorly focused. But only a few of us are talking about the two guiding thoughts behind a realistic roadmap that are critical to success:

1. Developing a product that customers want, will pay for and will advocate
2. Finding and scaling an economically viable business model without wasted time or money

These two points form the basis for a slowly building consensus among founders of successful (and some failed) SaaS companies and those of us who have been involved in multiple projects over time. If you haven’t come across them, you will if you need to go for funding of any kind or show a business model these days. These folks are in the business of making money from the SaaS business model and developing companies with a worth that is many times their investment.

People who are unfamiliar with the Lean concept often think that it means developing a product that is at best, minimal and at worst, a product that is too basic and that no one will actually want. We’re used to the idea that it can easily require a two-year development cycle to get a fully-featured product to market. So, when someone says, “We can develop a SaaS product in six months or less!” there is a tendency to dismiss them as novice product managers or marketers.

If this has been your thought, I don’t blame you.  You should question what is behind that type of claim. If it is just the size of the development team that can be brought to bear on the project, I would remind you of the old joke in production engineering:

“While we know that it is true a woman can produce a baby in nine months, this does not mean it is also true nine women can produce a baby in one month.”

For our own part, we’ve developed our concept of lean product development based on careful analysis of what we could provide to our customers to help them be successful. Rather than repeat the entire mantra – let me call out some leading references you should be familiar with for evaluating your roadmap:

• Bessemer Cloud Computing Law #1 – Less is More! Leverage the cloud. Don’t spend money to build features that don’t provide direct value to the end user.  Go into the market and “rent” services. Services allow you to concentrate your resources (time, talent and money) on your core value. They will in fact be richer and more cost effective than anything you can afford to develop.
• Steve Blank – Perfection by Subtraction – Having a clear, tight vision helps to keep development scope down, but it isn’t the key to the “minimum viable product” often mentioned in discussions about product development.  The key is to get a product in front of customers who can understand the vision and who can become evangelists for it because – They have a problem your vision will solve. They understand they have the problem. They have been actively looking for a solution. They have put together some parts of a solution themselves. They have or can get a budget for something that solves the problem.  These customers can validate the vision and will actively pull it into the shape that fits their context. With them behind you – you can develop a beta product that is much closer to what the market needs.  This is also part of Bessemer’s Law #5 – Build Employee Software – which talks about the “consumerization of software” that SaaS has enabled.
• David Skok – Why Startups Fail – The business model is just as important as the feature set in the end. We’ve all heard of great products that never sold enough to return their investment before failing. Learning if you have a market fit, if you can actually scale your operations profitably, if the cost of acquiring a customer (CAC) is less than the average lifetime value (LTV), and if you are going to have enough cash when it comes time to hit the marketing accelerator pedal – these are differences between success and crash and burn. They come down to having a roadmap that gets you into the market early, allows you to test your business model and your product before you have burned all your cash.
• Eric Reis – The Promise of the Lean Startup – Leverage the Agile methodology and philosophy to develop progressively based on customer pull rather than a miracle of market anticipation. We’d all like to be Apple, but we’re not – and getting there is a lot harder and more expensive than we need to expend ourselves on.  The SaaS multi-tenant model allows incremental releases and fixes, usage monitoring, and real feedback-driven products that customers pay for. Eric has a very good presentation with the difference between two companies he was with – that brought him into Lean thinking.
• And finally – Evangelous Simoudis – Criteria for Determining a Company’s SaaSyness – This brings all the previous ideas together with having a successful business model and product BEFORE you go for funding. This puts funding when it will do the most good – when you can use the extra acceleration to get the proven product in the market and when in the classic hockey stick market model, it will be easier to get cash with attractive terms.

But – that means having a roadmap that allows you to make these things happen with a reasonable investment. It means signing up customers and getting cashflow before you reach what you might otherwise think was a full-featured product. It means a company with a product in a licensed model will have to think a little differently than a startup to retain their existing customers, but the larger picture should remain stable.

So, coming back to the premise of this article – a realistic roadmap for SaaS should allow you to -

• Validate your vision with early adopter/evangelist customers as soon as you can show them your the core of your product’s business value.
• Test your marketing, sales and operations during a beta that is still less than a full-market version, but allows you to show your vision to the broader market and get further feedback.
• Leverage services and products that allow you to focus on developing the core value and keep your choices in line with business outcomes – lower initial cost and faster time to market.
• Keep your investment to a reasonable level, particularly in advance of breakeven, and allow high power funding to come when it can do the most good – when you have a proven product and customers.
• Allow early cashflow by having a product driven by paid customer demand.
• Be Agile and flexible in both your product development and your business model.

At Scio – we have used these points to come up with a general roadmap that we customize for each customer’s situation.

Our choice of methodologies, tools and technologies is similarly aligned to ensure we can execute successfully at each stage. Every outsourcing company will decide where they need to focus but for us this means:

• Using the .NET framework as our core techology base. This allows us to apply common skills across a variety of devices and applications and to tap into a much larger commercial resource pool for staffing. It also keeps costs low because we can focus on building best practices and development patterns while leveraging a large pool of libraries that are available for .Net.
• Building on a SaaS application server – SaaSGrid – that lowers the total cost of development and provides the common SaaS monitoring and operational needs. Sticking to one “best of breed” application server that we understand the internals of lowers risk and “discovery” associated with learning new development patterns and allows us to focus on the problem of delivering business value to end users.
• Leveraging Agile and Lean methodologies internally to allow us to deliver useable software early with feedback from customers and operate with high efficiency.
• Use a Nearshore model to put us in closer contact with our customer base and to better enable the promise of collaborative software development embodied in Agile.
• A production model that can apply consistent approaches and learning across engagements rather than approaching each project as a “one-time shot.”
• And finally – a business model that not coincidentally has a lot in parallel with the concepts we expect our customers to embrace.

That is just the choices we’ve made.  Making these choices is a lot like we ask our customers to do when picking a feature set. We purposely left “opportunistic” approaches off the table that would mean we had to spread ourselves a lot thinner to support them at the same level as our core. It also means we can concentrate on improving our core value set without compromising the services we deliver.  We concentrate on our core – developing successful SaaS products repeatably, economically, and quickly – and let our customers do the same for their clients.

So what is your roadmap? Does it align with the ideas we and others have offered in recent articles on developing Internet-based products? It’s all about using the delivery technology that underlies SaaS products to your best advantage in the end.  Whether you develop your product in house or with a product developer like Scio – I strongly suggest you consider your roadmap and the driving vision behind it. It can save you a great deal and lower your risk greatly.  Worth considering…

In the fourth article of our series about SaaS and The Long Tail, we are exploring the tail that according to some sources – wags the SaaS dog. At the ultimate end of The Long Tail is the individual – the “me” we all embody. Strategies for SaaS that employ The Long Tail concept, all leverage the power of the Internet to satisfy the individual without addressing them directly. Is it magic? Smoke and mirrors?

If you have been following this series and have grasped the concept of The Long Tail and how it applies to SaaS – you know that the best implementations take in a wide range of needs within a market, but still enable individuals within that market to find what they need or accomplish their specific tasks within the application’s framework. In the eCommerce world, implementations allow sellers to reach individual buyers “transparently” and Amazon is the most used example. But business tools like Salesforce, the CRM powerhouse, and Plex, the SaaS ERP for manufacturers, have also leveraged a single online platform to serve both different industry segments and different line of business (LOB) areas.

These examples represent two, non-exclusive, threads we see in SaaS vendors reaching the “tail” of their customer base successfully:

• In the Community Model – keyword search, recommendations, reviews, vendors, and communities within the platform provide ways to reach out to an individual, tap into their desires and help them satisfy their needs using an “opt-in” approach.
• In the LOB Model – a single platform carries modules, features, and embedded processes that can be leveraged and customized to satisfy particular needs and give users specific roles and views, without creating multiple versions of the application.

This is not a “one way or the other” proposition. A specific service may utilize elements of both approaches – as Salesforce does in many respects. The community model is inherently “noisy” and so has to leverage the tail in many ways to limit the noise to a segment so that it is useful to an individual. The LOB model is inherently complex and requires administration, roles and processes that can be customized to fit specific business areas and organizations.

LOB applications have long utilized workflow or “business process management” (BPM) to provide process capture and automation. However, implementation and customization could be a long and expensive process. In the SaaS world, the difference is that the primary changes needed for something like supply chain operations for a specific industry have been implemented on the core platform and marketed directly to a vertical by the ISV. This lowers the time to implement and adopt the application for customers and provides a managed approach to product development and marketing that is easier for the ISV to handle. These applications also allow a customer to continue the customization to “the last mile” to adapt specific processes, terminology preferences and internal standards while they continue to embrace industry “best practices.”

The community model is relatively new, although it is an outgrowth of many so-called “social media” applications that have been developing for a long time. Some of the key technical concepts are:

• Adaptive Search (example – Google and Amazon)
• Personal Digital Publishing (weblogs, microblogging – examples Blogger, Twitter, WordPress)
• Recommendations and Reviews (community and individual rating systems – examples Yelp, BizRate, Epinions)
• Forums (examples – Yahoo! Groups, Google Groups, Amazon Forum)
• Communities (examples Ning, Facebook, Second Life)

A SaaS offering may adapt some or all of these concepts to reach their customers and marketing may adapt them either on or off the platform (or both) as a way to broaden their audience while reaching specific segments. Using social media for external marketing and customer contact is something we will explore in future articles. Using social media within a SaaS platform to help users find and evaluate services and products, provide support and to increase customer retention are the primary uses we’re seeing adapted now.

Consider the restaurant review and guidebook service, Zagat. From a company that started as a restaurant guide publisher 30 years ago, this service provides user-driven ratings and reviews, voting, discussion boards, news, video, and yes – online purchases of the original guide series. Zagat has built itself into a community with aspects of every concept in our list. Together they become an indispensable and trusted guide for users with a low subscription cost and very personal approach. The same service provides vendors with advertising, online reservations, menu presentation, and ordering – all of which can be monetized in some way.

On the business side, Salesforce has adapted the community model in several directions. For customers, it provides discussion forums, user groups, best practices, and blogs. For partners it provides an Appexchange where they can demonstrate and sell custom solutions to Salesforce customers and leverage the Salesforce platform to provide their own applications. For developers from both customer organizations and vendor partners, it provides Developerforce which is a community onto itself. Few business SaaS providers have been able to adapt the community model so completely to their platforms because if it isn’t carefully considered, it can become unwanted “noise” in the environment. But as this vendor has successfully shown, it can become a value that completes the product in many ways.

Building a service that embraces these concepts is something that takes a lot of planning. In truth, none of the examples I’ve mentioned “sprang full-fledged” as the services they are today. But as SaaS “matures,” more providers are considering these aspects up front and including them in their business plans from the beginning, whether they are included as features in “Version 1.0″ or not. At this point, I think every “would be SaaS entrepreneur” must consider them or face the fact that their competition will use them to take customers and prospects.

This is the last article in this four part series but certainly not the last time we will cover The Long Tail. In future series, we expect to be looking into platforms that enable SaaS ISVs to concentrate more on their product and less on the developing their business back end and social marketing. Stay tuned!

Useful? Copy, save and Tweet it!

SaaS: At the End of The Long Tail – ME! http://bit.ly/p5d5

It seems sometimes like being in technology means learning a new acronym every day. And to make matters worse, every marketing department is busy trying to think up the next “market-leading, self-defining, world-beating…” term to define their version of “the ultimate truth.”

Right now in the areas we work in we have terms like SaaS, PaaS, IaaS, Cloud, Agile, Scrum, Xtreme, and that is just the beginning. When I try to talk to clients about the “options” they have for their products today – it is in part an exercise in term definition to insure we are all on the same page. Just in the area of SaaS, there are literally hundreds of different approaches to what is considered to be a relatively new product configuration.

Recently, in scanning the web, I have seen a whole new crop of bloggers redefining terms we’ve been using for several years. It is becoming a self-defeating exercise. But, this morning I did come across an article about “cloud computing” in general that begins to make some sense and, at least for me, erase some of the difficulty. Admittedly, the author has his own drum to beat – he’s the VP of Products for Appistry, a cloud provider – but in his post, “The Blind Men and the Cloud,” he makes some good points. According to Sam, from a “user perspective” cloud computing should be defined as:

Cloud Computing is the evolution and convergence of many seemingly independent computing trends:

• Commoditization
• Internet Delivery
• Virtualization
• Grid Computing
• SOA
• Data Center Automation
• SaaS, PaaS, IaaS, XaaS
• Utility Computing
• Distributed Computing
• Web 2.0
• IT Outsourcing
• Storage

He goes on to use the blind man and the elephant as an analogy in a poem – which I strongly urge you to read in the context of his article. His points are valid – it is all part of one trend regardless of how it is described. To his list I would also add the ever-popular “On-Demand” which is another aspect of how offerings “in the cloud” are viewed.

So, once again, I’m going to rethink my definitions – is IT outsourcing just resources in the cloud? Is SaaS really a definitive term with so many different (and valid) approaches? What is XaaS by the way? (It is just a general term for “anything as a service” thought up to avoid the rapidly growing list of yada-yada as a service). …And does it really matter?

What really does matter is what makes up the service and on that point I think many marketing groups are missing their marks. For some reason, the reliability of the service (SLAs), security (audits and standards), data portability, and those underlying but critical service aspects of the application are tucked under the bed in marketing. Yes, the line-of-business folks can test the user interface and workflow and pronounce the application worthy, but what is keeping it afloat? These are features – no? It all comes back to the basics – forget the acronyms because they are telling us nothing of significance. Tell us what this thing does for us and how it enables us to do our work and be successful. End of story.