I can think of many reasons to be at SaaS University in Washington, DC, July 20-22, beyond my session and Scio´s workshop. But I want to be clear: The sessions at SaaS University are always changing, always relevant to developing SaaS products and successful SaaS businesses. It is the only venue available with a focus on helping SaaS vendors navigate a complex business model.

This time I have the honor to be presenting a session on the second day titled: Increase Your Bottom Line Value with Multi-Tenancy.  Here is the session summary from the University agenda:

There is a lot of debate about multi-tenancy.  Most of us understand its value from a technical point of view, but what can actually translate to our bottom line?  How does it change what we are able to do to increase operational efficiency and customer retention?

Multi-tenancy is not a magic bullet, despite what you may have heard. Implementing your SaaS application with a multi-tenant architecture offers great returns, BUT ONLY if you understand how to leverage it along with metrics, operational automation, your ecosystem, and the network effect of your customer base – effectively.

This session will answer questions concerning the value of:

• Different architectures for implementing multi-tenancy and maintaining flexibility.
• Reliability, scalability, maintenance, and product evolution to your clients.
• Multi-tenancy in operations across your product organization.
• Implementing metrics in a multi-tenant application.
• Your customer and user network, delivery network and ecosystem under multi-tenancy.
• Methods of implementing multi-tenancy without breaking the bank or slowing product release

This session is strategic for C Level executives and product managers planning, implementing, or enhancing a SaaS offering. Participants will come away with a clear understanding of how they can leverage multi-tenancy at every level of their service and increase their bottom line potential.

This session is replacing a similarly titled session by planned Lincoln Murphy because of a scheduling conflict he has encountered. I want to thank him for his recommendation that I take his slot. I must say, although I want to keep the same broad focus for this session, my approach to this subject is different than Lincoln´s. My background with multi-tenancy comes from planning SaaS products with Scio´s customers and many years of working with companies on Internet-based business models.

In itself, multi-tenant architecture is not new.  The same could be said of the SaaS business model. What is still new is the broad market attention to on-demand services and the opportunities that virtualized infrastructure gives to business. The knowledge of how to leverage architecture and technical choices to impact product features, customer value and operational effectiveness is what is lacking in my experience. This is what I will lead discussions on in my session at SaaS University.

In addition, if you aren´t aware of it, SaaS University has a third day of full day workshops that provide a ¨deep dive¨on specific subjects. Our own session is Charting Your Course to SaaS, which will help it´s participants navigate all the choices they face in developing a SaaS product while they develop a road map that can get them to market and positive cash flow sooner.  I can also personally recommend Jim Geisman´s Right Pricing Your SaaS System: Beyond the Basics – Advanced Workshop. Jim and I had the opportunity recently to give a workshop together and I greatly enjoyed the experience, and I know our audience did also. Ideally, product teams should consider sending representatives to both workshops because they are complimentary points of view that are very important to understand.

So, with that background, here is the overview of our one day session at SaaS University for July 22, 2010:

Charting Your Course to SaaS – SaaS University, Washington DC, May 22

This is the third time we’ve offered this comprehensive workshop on SaaS and it continues to evolve as we respond to the needs of our participants. Following our joint workshop with Jim Geisman of Software Pricing Partners, we’ve continued to tighten the content and for SaaS University, will offer a more interactive format for this workshop, especially during the afternoon. The aim is to keep it small enough to allow everyone a chance to move the discussion toward the issues that interest them most.  It remains however, the only workshop that covers the business, operational and development issues that are critical to success in SaaS.

Companies that can benefit by attending this workshop:

• A new venture or as an ISV with on-premise products considering developing a SaaS offering
• A service company with significant vertical expertise than could be delivered and monetized in a SaaS model.
• An existing SaaS provider who made choices opportunistically that now constrain growth and cash flow.
• A SaaS entrepreneur with limited funding that needs to achieve positive cash flow early with products that evolve with the market.

Company challenges this workshop can help overcome:

• Building out a suite of products but are unsure of the strategies, metrics, and operational models needed to grow.
• Developing a framework for sorting out technical and strategic choices required to move to the SaaS business model.
• Facing significant operational problems including efficiency while keeping churn under control in an existing SaaS product.
• Developing a product roadmap and unsure of what can be accomplished and timeframes

Topics to be Covered:

• How is a SaaS Product and Business Different?
• Reference Framework for Creating Your Roadmap
• Making Strategic Development Choices
• Operating A SaaS Business by the Metrics
• 10 Ways to Fail at SaaS
• Applying Lessons Learned to Your Issues

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professor”

Mike Dunham, Vice President, Service Engineering for Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

The workshop costs $695, but you can get an Early Bird Price of $495 when you combine it with your SaaS University registration - total package price of $1290. As a way to bring together a great amount of information in a short period of time, the combined package is a great opportunity. As we get closer to the event, I’ll expand on the agenda, but this is a great time to start planning and get your team together to attend SaaS University in Washington, DC!  I hope to see you there…

At Scio, we’ve been working towards a goal of achieving a “standard” process and platform for developing SaaS products for a long time. Of course, when it comes to services, nothing is ever “done” – it just reaches a point where you know you are achieving goals, satisfying customers and can continue to improve over time.

We’re in the business of developing SaaS products. To develop custom products economically and reliably, you have to build or adopt tools, methodologies and repeatable processes that streamline the process, cut out unnecessary waste, and control risk. We, like many software development groups who have adopted Agile development processes, have realized that much of the business of “manufacturing software” aligns well with the concept of Lean manufacturing and product design.  In fact, the leading Agile consultancy, Poppendieck, has produced a book on the subject.

But what does this have to do with SaaS? Our move down the Lean and Agile road is not an accident. It is our core belief that customers will be more successful if they and their products and business processes are also Lean and Agile. We’re not alone in that thinking. Bessemer Venture Partners, in the latest release of their Top 10 Laws for Cloud Computing, covers the core concepts even if they don’t acknowledge them as Lean specifically. Steve Blank and Eric Ries recognize something they call a “lean startup.”

So – what is the core of Lean as it applies to SaaS?  The original concept of Lean was started in Japan and has been defined as:

• Build only what is needed
• Eliminate anything that does not add value
• Stop if something goes wrong

At Scio, we’ve translated this to:

1. Build only what is needed – Agile and Lean are customer-driven methodologies. Building what is needed assumes you have a customer and you can get feedback directly and honestly from users. This doesn’t mean focus groups however that are just about “improving the current status quo.” As has been said, “If you asked people in the early 1900′s what would improve their personal transportation – we’d all be riding better horses.”  SaaS products are also user driven, as we and others have said many times.  To know what is needed, a SaaS vendor needs to get their product in front of end-users as early as possible and go through a “verification of vision.” This means testing the hypotheses that the product provides value, users will use it productively and customers will pay for it. At Scio, we’ve acted on this idea  by standardizing on SaaS specific platforms, services and frameworks (like SaaSGrid) that eliminate the development of the operational aspects of SaaS and provide a consistent multi-tenant architecture that can be used across multiple products. This, coupled with Agile scrum principles allows our customers to get their core products in front of key customers in three to four months. Because these common aspects of SaaS products are available on a “pay as you go” model, they don’t contribute unnecessary costs to the needed capital to launch a product and they only contribute incrementally to overhead.
2. Eliminate anything that does not add value – Getting a product in front of actual paying customers as soon as possible means not developing features that do not directly add value for end users. This assumes you can field test the feature set early and is the next level of verification just below the first point. It assumes what is known in Lean as “pull-driven” features – features that users need and actively advocate. It also points to the “slow drip of new features” that users expect from online services rather than the “version-driven” approach of traditional software releases. It does not however mean the end-user “defines” the product vision. This is where the first point and the second separate. Innovative products rarely rise directly from customer requirements, but value-driven features can and do.  For us, translates to building on modern extensible architectures that don’t require extensive re-writes to implement new features over time and “post release.”  We also ask our clients to take their assumed feature sets and apply the “80-20 rule” – which simply says that 20% of all features of a product will deliver 80% of the value. In Lean, features that do not add value are considered waste, but there are two forms of waste recognized: Those that do not add value but are unavoidable with current technology and those that create no value and are avoidable with a better design.  This also leads to more concentration on “user-experience” and understanding of the user’s context and avoidance of risky, over-complex projects.
3. Stop if something goes wrong – SaaS products naturally reach different audiences based on marketing, vertical demand, market maturity and the delivery medium of the Internet itself. But, what happens if your development cycle for a complete product is the 12-18 months common projects in traditional software? Your initial cost and risk go up drastically and if your vision is off the mark, failure can be very costly. At Scio, we focus on developing a core product that can reach paid customer release in six months or less. This keeps risk low and insures new products have the potential to reach positive cash flow at the earliest possible point in the product lifecycle.  This also fits with the mantra, “fail early and often.” A product can be a complete failure of vision or there may be just certain aspects that miss the mark. Either way, you need tools to monitor product usage and user feedback and a roadmap that allows you to get market verification early and to avoid “big bang” releases that are costly and not led by “pull” from users.

Lean also leads into continuous improvement – which is part of the service-led concept of SaaS. There is no “perfection” – only continuous improvement over time lead by user pull and innovation. The steady drip of user-led improvement leads to better retention. lower churn and a longer customer lifecycle – key SaaS metrics.  Better understanding of the value stream, another principle in Lean, leads to better pricing and more value recognition by customers.

There is a lot more to cover in terms of the alignment between Lean, Agile and SaaS. Take this as your “introduction” and follow the references I have provided. I’ll be adding more articles about this important subject in the near term – so watch for the Lean tag in our cloud – but in the sprit of Lean – we’ll stop here for now.

When I wrote the recent article “SaaS: 10 Trends for 2010” I used the phrase “Best Case SaaS.” I realized from feedback and some thinking afterward though that many people don’t share my vision of what it is.

What I was trying to say is there really is a path to success for SaaS products through the thicket of options out there.  But since we don’t all share an understanding of all the options – that becomes pretty nebulous.  We’ve written about the 10 Ways to Fail at SaaS – What about Success?

Whether you call it “best practices,” “optimum implementation,” or best case – to have a discussion of what it takes to field a successful product we need to have a common understanding of SaaS itself. One of the people who has been pretty clear about a vision has been Phil Wainewright – but there are several others who are advocating for various aspects. My concern is a lot of them tend to be involved in the technical side of SaaS and not a straight- forward business discussion.  Of course, it takes an understanding of technology to bring a SaaS product to market, but in truth, you can hire that expertise if you have a clear business strategy to back it up.

Before I list the six points I have outlined – let’s get our definition clear.  Software-as-a-Service (SaaS) is not as simple as, “A application delivered over the Internet on a subscription basis.” That definition is what most people think, but in truth it is far to limiting by itself. If you want to keep it simple, you could just say, “an online service” but that might be a little broad. To cover both sides of the fence, vendor and user, I’ve been using, “an application delivered across a network to a client in a pay for service model.” On reflection – even that definition has its faults.

The point of this little exercise in definitions is that we need to realize that what we once called “Business-to-Business (B2B or B-to-B)” or even the slightly more exotic sounding “B2B2C” would be called SaaS today.  Does that mean Priceline is a SaaS product? Well – Yes! The simple end-user travel services they offer are monetized on a transaction basis, but we should also understand that behind that stands an even more important service disposing of excess inventory for the hospitality and travel industry. Somewhere in the middle is an advertising platform that allows the “inventory customers” sell through Priceline directly. Does Priceline care which service you use? Not really, they make money from all sides of the transaction and with any service you select. It truly is a Long Tail offering in every way.  The same could be said of the Amazon platform only more so.

So – really we could just say SaaS is “an online service” or “service automation delivered in a pay for service model” and be accurate? When we do that we begin to realize there is a whole field of service companies that use applications to automate and deliver aspects of their services – but aren’t usually considered as “SaaS companies.”

With that in mind, let’s go forward and look at “Best Case, Successful SaaS.” The points build on each other – so follow along through them and it will make more sense.

6 Points for Successful SaaS

1. Expertise that can be sold to a reasonably large market segment in an online delivery model and can be scaled to meet the market potential over time.

This is of course the “reason for being” for SaaS.  Online services are sold on a “pay as you go model.” No matter how you look at it, if you don’t have a target market large enough to give you a positive return on investment in a reasonable period of time, you aren’t going to be successful in a SaaS business model. In a vertical, this means offering a service that is attractive to at least second and third tier markets. It could also mean “tagging along” with more general offerings that give your service more weight in an “ecosystem” model. Regardless, you cannot ignore the simple economics of online services. You cannot afford to run out of cash before you reach a positive cash flow. That means development has to be planned and controlled to yield just enough of a service to sell successfully as soon as possible. It means that you must have a understanding of SaaS Metrics and the critical Customer Lifetime Value Ratio (CLV). It means you need to have a “proof of market” investigation as a part of product planning and (for heaven’s sake!) development. It means you have to understand (and monetize) the value your end-users perceive. It means your online service must be planned to evolve after release (see point #2).

Now the second part of our first point is what brings up the application model of SaaS. To scale a service economically, it has to be automated. When you get right down to it – SaaS is service automation! We’ve been doing that for years – the most significant difference is that now the Internet offers a delivery vehicle that is pervasive and universally accepted. So – if you’re really going to deliver a service online, plan to automate your own business operations from day one or you won’t scale with enough efficiency to reach positive cash flow in time. You might be able to onboard your first 100 customers manually – but if your market plan says you need to take on 1,000 customers with 20 seats each in your first year – your operational costs will quickly eat your cash reserves – IF you are able to handle the work that involves. (See point #5).

2. A strategic roadmap that allows the product to be brought to market early in the design cycle and to adapt to user and market feedback.

Taking the first point to heart means really understanding you can’t do everything and you shouldn’t if you want to be successful. You need to have a plan, a roadmap. You need to provide a valuable service from day one the market will pay for, but you also need to have a strategic plan for where your service is going over time.  Within that plan, you need to be flexible (see point #3) and responsive to user feedback (see point #4) and market forces.

Bringing the product to market early also means not taking on development of features that don’t support the direct value to end-users. As mentioned in point #1 – you need to automate your service – but do you really need to build all your operational automation (see point #5) to bring a product to market? No. There are many operational services you can leverage to lower your development complexity (risk), time to market and total development cost.  The general rule of thumb is you will save as much as 60% of your development effort and about 40% of your total costs before launch. The services you use become part of your overhead and need to be part of your metrics. Can you develop them into your service at a later date when the cost is justified by growth? If you take point #3 into account – yes.

3. An extensible, service-oriented technical architecture that will support the expected growth and change over the long term, economically.

Before anyone calls me on it – the last word in this point covers a lot of sins that have been visited on the SaaS business model. Let’s be straight-forward. We’re interested in SaaS because we want to MAKE MONEY. If we want to do that we have to be able to operate, deliver and maintain our application economically and reliably over the long run. That means we need a multi-tenant database structure. I don’t know any other way to say it. You cannot scale on individual instances for each customer or maintain them over time and make money.

It doesn’t mean however we have one big spinning top that runs everything forever.  As your service grows, you will use several strategies to extend your application over multiple instances, and to balance your service among several applications perhaps. Do you have the idea that Amazon is one big application? Of course not. Your service might present one “interface” for users – but that doesn’t mean it is just one application. Architecturally, that is just the “presentation layer.” We have to have an understanding of the technical strategies that allow online services to scale, embed other services, extend our services outside the application, and change our service without extensive rewrites over time while continuing to make a profit.

With that understanding, we can plan our roadmap to help us decide the battles we need to take on and when. Do we need to buy infrastructure if we can rent it? Not if the market price, availability and reliability meets our needs. Do we need to build a pricing and settlement system to monetize our service? Not if there is one available at a price that can be incrementally applied as we scale and with the level of maturity we need.  Can we eliminate some maintenance concerns with virtualization? Yes – when it makes business sense – if we have a properly architected application that is built for the online environment.

What about “lock in?” they ask. There are two things to consider: #1 – Can you afford to spend thousands of extra dollars over some extended period of time before you put your service in the water, take on customers and begin making money?  For most of us the answer is no.  #2 – If your application is properly architected and you have developed a roadmap with proper risk avoidance, the services and platforms you use are tools you use to reach your maket sooner and with less up-front investment. Do you want to buy that store on the mall or rent it? If you rent – can buy or build when you have a proven market? In most cases – yes.

All this implies you or your team has technical background in online services. But if you are a entrepreneur or service company without a strong technical team – can you still survive in the SaaS world? Yes. There are companies with services that will fill that void – (shameless plug for the people who bring you this blog) Hello….

4. Customer and user collaboration tools embedded in the service and the business operations that surround it.

If you absorbed the last three points – you should have gotten one thing clearly: Release 1.0 day is not the end of the development cycle for online services. Because of Google, SalesForce, Amazon, and service portals like FedEx operates, we all expect, even require, online services to evolve. It should be no surprise that online services need to evolve dynamically to meet customer needs and stay ahead of the market. The question is how?

Just like nearly everything else in online services, the answer comes with some level of automation. Inside the application, monitoring must be embedded to help evaluate feature use in a user context. We need to know if user admins are able to use the tools they have effectively. We need to know what percent of their day our line of business users spend in the application and how often they use it to complete “high value tasks.” With that information as a baseline, we can evaluate the impact of new features, improved help, better support strategies. Without it – we’re clueless and we might as well be selling licensed software to silos behind firewalls.

To leverage our delivery platform even more we need to embed direct user engagement with blogs, forums and community tools like UserVoice and Get Satisfaction.  These are services you subscribe to (point #3) not build. These are not the endpoint for user engagement however, they are just the tools. As tools, they are used by product management, support, sales and marketing to help guide service development, to retain customers, up sell and grow best practice communities.  What you should be beginning to realize is this really means a successful online service needs to rethink the timeworn model of “key stakeholder engagement” and get directly to the end user. To do that the business organization behind the service needs to be aligned to leverage the tools and integrate what they yield into decisions. (Enter points #5 & 6).

5. Integrated business operations for the service itself embedded in the same delivery model used to deliver to end-users.

Once again – SaaS products are classic service automation. If you are going to sell a service – if you are going to build an application to deliver your services – shouldn’t you also automate the pricing, settlement, onboarding, user management and all the other operational aspects of your business directly in the application itself?

This is a point that seems to have eluded many service companies and ISVs with licensed products. You cannot scale to reach profit in online services with manual or loosely connected internal business processes. SaaS is all about making a profit from volume.  But, as point #2 cautions, you cannot build all the operational aspects of your service directly into the application without placing considerable risk on your costs, application complexity and time to market. If you have planned your product with the architecture discussed in point #3, you can leverage available services that will provide these critical aspects of business operations for you and embed them in the product platform itself. This gives you the best of both worlds – fully integrated business operations using the data and infrastructure you already have online and a cost that is applied incrementally based on use.

6. Agile business philosophy embodied in every aspect of product development, operations and services.

You nearly have it – successful SaaS is all about service automation and dynamic business. It delivers what we need, when we need it, at a cost that is measured by use on every side of the platform. That means you and your customer alike are benefiting from the investment in the application and involved in its continued success intimately.

To handle the continued development and change involved in SaaS, most technical teams use Agile methodologies. To feed development and manage the product roadmap then, we also need to consider an organizational alignment with agile philosophy. When we really consider the organizational impact of being an online service, we start to understand there is really no option. To be successful at SaaS, we need to be an agile business top to botttom.

This is a lot to absorb. It is a different way of doing business. I don’t want to underplay the significance of any one of these six points. We at Scio made a strategic decision last month – we’re alining our services to deliver best case SaaS to our product customers and nothing else.  To help people put this into their own context, we’re giving a workshop on January 28th in Dallas as part of SaaS University. I strongly encourage you to join us if you have any interest in developing an online service in the coming year.

So – what is your take? Did this list suprise you? I hope not – but I’d love to hear your point of view.

People say that marketing for “cloud services” are really over the top right now – selling a lot more promise than can be delivered. If that’s true, social media is somewhere out in the stratosphere of hype – pushed into orbit by leaders like Twitter and Facebook - I’ve heard many people say if they were trying to avoid reading yet another article on the wonders of connecting to “communities” on the web.

If that’s the case for you – I hope you’ll set your prejudice aside and listen to our podcast this month on Haut Tech Conversations. You can download the show and listen to it at your leisure. Our guest was Jonathan Hyland, the Client Relationship Director for iCIMS, a leading SaaS provider of “Talent Management Systems.” Jonathan is deep in the trenches of the user community at iCIMS because he is responsible for managing the client renewal pipeline, user satisfaction, user advocacy, and maintaining visibility of the value proposition their services deliver.

I enjoyed this conversation because social media is still a widely misunderstood subject among SaaS and Cloud Service providers. Many see everything social as an unnecessary and noisy “distraction” that is a waste of resources and time. I understand their point of view because if they come from traditional software marketing, support, and sales environment,  they are part of a legacy that rarely focused on end-users or tried to foster communications among them. And if you’ve ever tried to sip from the Twitter fire hose, you can probably understand their discomfort with jumping on the band wagon.

We covered the many sides of communities in SaaS including:

• Inbound Marketing – Getting found by vertical and best practice communities while building up a presence for your brand and the services it provides.
• Marketing to the Converted – Retaining subscription renewals, up-selling, and evangelizing your existing end-users and the key stakeholders that drive client adoption.
• Product Management – The balancing act that comes from involving end-users in driving product development without crossing into crowd-sourcing and losing your strategic direction.
• Support - Leveraging the community to provide best practices and support while continuing to be strongly involved in providing assistance and guidance.

And finally – how a community relations director can keep from looking like a product shill, serve user needs, retain subscriptions keep the sales funnel full and have time to take off for vacation in a 24/7 product world.

I think the take away from this conversation was very interesting and I don’t want to spoil it for you – but we found that “being social” is a lot more hands-on and face-to-face than you might think. It really is still true you need to be balanced between social tools and more traditional face to face approaches than you might think.

Joining Jonathan on our panel was Jessie Kliza, the Business Development Director for Apprenda and Peter Cohen of SaaS Marketing Strategy Advisors, who also happens to be one of our fraternity of Haut Tech Irregulars.

Our Special Guest -

Jonathan Hyland, M.A., PHR – Client Relationship Director at iCIMS. Jonathan has a background in Industrial and Organizational Psychology, graduated with honors from Monmouth and finished his graduate work at Hofstra University. He started as an intern at Questus but moved up quickly when he came to iCIMS. He now carries responsibility for managing the client renewal pipeline and upsell opportunities, ensuring client satisfaction with internal advocacy, and the development of marketing materials covering the value proposition of the  iCIMS platform.  In that role, he works with user communities at all levels for iCIMS. You can find Jonathan most days on Twitter and read some of his thoughts on his jaHRd blog.

Our Panel –

Jesse Kliza – Director of Marketing at Apprenda, the creators of SaaSGrid, a distributed SaaS platform that eliminates the difficulties of building and delivering Software as a Service.  Prior to joining Apprenda, Jesse was Community Evangelist and Product Manager at SaaS ISV, Autotask.  Among Jesse’s many contributions while at Autotask, he was responsible for the creation and oversight of the Autotask Community  – which won a coveted ITSMA Marketing Excellence award in 2008. Jessie can be found on SaaSBlogs, Appenda’s best practice blog for the SaaS community and his Twitter feed.

For those who are not aware of SaaSGrid, it is a service that greatly reduces the barrier to entry for SaaS by overcoming significant technical hurdles like multi-tenancy and grid scalability, while at the same time providing “out of the box” application services like metering and monetization, billing and subscriber management, and much more. Scio is a Premier Development and Implementation Partner for SaaSGrid.

Peter Cohen - Peter is the founder and managing partner of
SaaS Marketing Strategy Advisors. His firm provides expert guidance to help companies effectively market and sell software-as-a-service (SaaS) solutions to enterprises. The firm’s clients includes several large, well-established clients, looking to enhance their SaaS marketing practices, as well as smaller companies that need guidance in launching a new SaaS solution to the market.

Peter has more than 25 years’ experience developing and implementing successful marketing strategies for technology companies, including Computervision, Lotus Development, IBM, and Authoria. Peter has spoken on the topic of SaaS Marketing for the Massachusetts Technology Leadership Council, and written for widely-distributed publications including MarketingProfs. He publishes a monthly newsletter and a blog, both entitled “Practical Advice on SaaS Marketing.”

So – you can download the show,  you can subscribe to our feed on iTunes or use the widget below. And if you would like to comment here or catch me on Twitter – we’re always interested in extending the conversation.

At Scio, we use Innovation Games with our clients in several contexts, from new product definition to ongoing product management. For a new product design, the games help us work with our client team to uncover customer requirements that are still loosely defined, as well as to help our development team understand the key selling points of a product. For ongoing product management, the games help us work with client product managers to come up with new ideas, develop and prioritize their product roadmap and identify issues hampering their success.

Innovation Games are a series of serious games developed by Enthiosys, an Agile Product Management consultancy based in the Silicon Valley. Enthiosys developed these games to drive innovation by facilitating communication between clients, users and the development team in a structured but fun approach. By using a “game” approach, the activities remove personal agendas and psychological barriers that frequently exist when trying to reach alignment between stakeholders. Luke Hohmann, CEO of Enthiosys, has written a book about the games and methods behind them – Innovation Games: Creating Breakthrough Products Through Collaborative Play.

We recently started a project with a new client from the UK to develop a SaaS application for them using SaaSGrid (SaaSGrid is a SaaS Application Server developed by Apprenda). As part of the project kick-off and Product Design phase, three members of the client team spent a week at our Development Center in Mexico including the their product owner, the project manager and a development manager.

The visit was part of Sprint 0 (product definition and design), which is the first phase of our Agile Development process. The visit had five key objectives:

• Finalize the high-level product requirements.
• Define the technical architecture.
• Define the UI approach and look & feel
• Finalize the project execution plan.
• Get the development team underway with the certainty that they had an accurate understanding of the project goals, the product key features and the overall vision and expectations of our client.

During this visit we used Innovation Games to reach some of the objectives we had in mind. We used four games:

1. Product Box – day 1, morning
2. Start your Day – day 1, afternoon
3. 20/20 Vision – day 3, afternoon
4. Remember the Future – day 4, morning

Our client provided their application requirements as part of their development partner selection process and those were used to estimate project scope and provide our price quote. It was understood at the beginning that the requirements were not 100% complete and some ideas about new requirements or the approach to implementing some elements had changed since the  document was written.

We began our games with Product Box. Our aim was to quickly surface the key features (and key selling points) of the product. After reviewing what came out of that game, we discussed in more detail the full set of application requirements, the company goals, and the overall project expectations.  We then followed with a session of Start Your Day. In preparation for this game, we had printed daily, weekly and yearly calendars on full poster-size paper. We played the game for all Personas, and with this activity we wanted to identify patterns of use for each persona.

On the third day, after we worked on defining user stories in greater detail and across all modules, we played 20/20 Vision. We printed all the features (each feature contained one or more user stories) on letter-size paper, and with masking tape, we started to place them on the wall. The client team went through an iterative process of placing features on the wall and moving them up and down, where the features at the top were deemed to provide more value to end users, and the ones at the bottom less value. This exercise helped us prioritize the product backlog. This prioritization, together with technical dependencies, is used to define the sequence of application development for the user stories.

On the final day of the visit, we worked with the client team in the Remember the Future game. The scenario we set for the game was: “The date is exactly three months after the launch of the product, what will the ideal situation look like?”. This brought up expectations about the number of paying customer they would have, the quality and performance of the application, etc. Then we asked, “what will each of our teams have done to make that happen?”. We worked backwards to bring out all the activities and milestones in marketing, development, testing, etc. that will be needed to get to that ideal situation.

Using Innovation Games was very productive for this project.

• Product Box it helped us see that some of the requirements that we thought were secondary were actually part of the key selling points of the product.
• In Start your Day we realized that some users will concentrate their usage of the system to specific hours of the day, where they will need to process data in batch modes. This suggested that we needed to design a UI optimized for sequential data capture for those users. Additionally, we discovered that we will have peaks in some batch processes, such as invoicing, at certain times during the month, as well as some reporting that needs to be generated once a year for tax return purposes.
• 20/20 Vision was useful to prioritize features using end-user value, rather than how cool a feature would be or how attached a member of the client team was to a piece of functionality.
• Remember the Future helped us see the dependencies between the work that each of us (Scio and Client) has to do to make the project successful, as well as establish a timeline that we will need to adhere to.

When as part of the agenda for the visit, we mentioned that we were going to use “Innovation Games,” our client was of course, curious about the idea. It is easy to imagine a “game” but not necessarily the business value behind it. We explained that the games are strong facilitation techniques that would be fun and productive, so they engaged with enthusiasm and played along happily. The results were great, and at the end of the week we all agreed that we accomplished a lot.

Although it is possible to obtain similar results using other facilitation approaches, using Innovation Games is a more engaging and fun approach to exposing all the different aspects of a product that surface during the games, which would otherwise be missed or discovered too late.

So let’s keep on playing – Serious games that is.

I’ve noticed there are broadly two camps when it comes to developing new services for the Internet: Those entrepreneurs that feel they must do everything themselves regardless of the hurdles they face and those that want to focus on their core expertise and leverage outside services where possible.

Of course, there are also those that sit on the fence and never make a clear decision either way, but since for the most part the fence-sitters haven’t and won’t develop a service anytime soon – they fall outside the scope of this discussion. And frankly – they are hard to address until they make a choice that works for them.

The DIY (Do-It-Yourself) mindset comes from a long tradition in software development. The idea of the lone visionary, working in a makeshift office in the garage late at night against all odds, is an iconic image for Silicon Valley entrepreneurs. The folks who took that route are the stuff of legends in the business – and rightfully so.

But today’s business is a lot different from the days when people like Bill Hewlett, Dave Packard, Steve Jobs and Bill Gates started. There are options, services and alternatives that can be strategically leveraged on the road to product release that didn’t exist just a few years ago. We’ve gone through many cycles of change and innovation that have both raised user expectations and created a number of issues that entrepreneurs are expected to understand and deal with at an early stage.

Since I focus on helping “as a Service” and cloud-based businesses – I also have to point out another interesting aspect of this strategic choice for entrepreneurs. If you are expecting to sell a service delivered on the Internet – are you taking your own medicine? Are you considering services you can leverage to help you deliver your service more efficiently, faster and with more options than you might otherwise be able to offer with a reasonable compromise between cost and effort? If you’re not – are you in a good position to advocate someone else should make a different decision when they look at your new service? It’s an interesting thought…

To add one more log to the fire – the first rule of Bessemer Venture Partners Top 10 Laws of Cloud Computing and SaaS is:

BESSEMER CLOUD COMPUTING LAW #1: Less is more!

Leverage the cloud everywhere you practically can, both for your internal systems as well as for your own product offering(s) and “just say no” to on-premises deployments! This will not only give you a direct understanding of the customer experience and best-of-breed strategies of Cloud Businesses, but it will free up your technical resources and balance sheet to focus on your core product and customers.

There is another side of the discussion too – There is a large segment of the SaaS market that is made up of service-based businesses that use custom applications to manage and extend their services to their clients. These companies often don’t see the applications they use as more than an aspect of their service. They do not see themselves as software developers but they do develop, integrate and leverage application-based services for their service offerings. In today’s environment, many of these companies are extending their services to the Internet in one way or another.

What are some of the options available as services to developers of “as a Service” products today?

• Infrastructure Virtualization – Whether you call them “cloud services” or Infrastructure as a Service (IaaS) or virtualization, there is a broad set of services available to eliminate the need to own, provision, maintain and scale the servers, CPU, memory, storage, networks, databases and operating systems required to offer a service on the internet. In the best case, these services are use-based and can scale up and down with demand. They can eliminate or lower the costs of buying and deploying infrastructure and the resources necessary to operate and maintain it. On the resource side, this may be a expensive skill set not present in the existing vendor team that could be less burdensome if many of the tasks are automated. That said, IaaS is an often abused term in my opinion. Just as everything on the Internet is being identified as a “cloud service” – infrastructure services come in many shapes and flavors and some deliver more promises than value. Knowing what is possible, what you are actually getting and what you need is key when you begin to engage with cloud providers.
• Operational Services – This is another broad class that covers what we often call the “plumbing” of an on-demand service. It includes areas like billing and settlement, pricing, client administration, reporting, integration, user community management, sales automation, product management, and content management. If developed from scratch, the combined effort to put these services into a product can easily reach 60% of the cost of a project. In fact, because of the cost and expertise required, these services often end up being very constrained or left to manual processes which greatly impede growth and reliability of the product.
• Platform Services – If IaaS is an often abused term, Platform as a Service (PaaS) is rarely ever described in terms that actually speak to their business value for as a Service companies. 90% of what is offered today as PaaS is either a development environment or a BPM (business process management or workflow) system. I don’t want to disparage the value of those two approaches to a software development effort – but - they need to be separated from the PaaS offerings that also address the operational needs of a service-based business as described above. A PaaS that addresses operational needs does several things for a new service – it lowers the effort and cost required for development and it lowers the time to market and risk associated with larger, more complex development efforts. In addition, most PaaS offerings include levels of infrastructure virtualization that lower the need to deploy and manage the servers and their associated hardware, software and networks.
• Resources – While outsourced development is a very obvious option for building the application (Scio is after all, a software development provider) , there are many types of resources available for specific tasks such as planning, marketing, sales, and support. It is critical that the selected service provider understands the issues that “as a service” businesses face, but when they do they can greatly reduce risk, false starts and strategic errors. In considering outsourced resources it is important to remember there will always be a “cheaper” resource somewhere. The provider you select needs to deliver value for cost and in SaaS and cloud-based businesses that comes from knowledge and practical field experience.

So, let’s say you’re one of the entrepreneurs that are either considering or actively leveraging services as a part of your product strategy. What do you need to understand to be successful at picking or using services?

1. Pick for Value, Not Cost – Value can be measured many ways but the key in services is not the cost, it is value delivered. In most cases this should be realized in lowered or offset development effort, risk, complexity, time to market, or increased expertise (or all of the above). Depending on the type of service, the offset could be in the form of on-going overhead – as it would be if you use a billing service for instance. In the best case, all overhead for service-based businesses should be tied to use. This means the overhead cost per period can be divided by the number clients or users so it can be understood and budgeted as an operational cost. In this scenario, the cost should also fall if the basis (users or amount of bandwidth or whatever the metric is) also goes down. A service cost that only rises in stair steps can quickly become a serious liability if there is a lot of subscription churn or usage variability in your product.
2. Build for Flexibility - Just as the features you offer in your product today will invariably need to change over time, so too will your service strategy. When you have reached a point in your growth curve that it makes sense to recapture the overhead devoted to a service, you may decide to build that function into your application directly. If you have built on a flexible architecture, this should be a choice that is available to you whenever you decide the time is right. This same line of thought addresses changes in service providers. Just as you might decide to change your bank to capture a better interest rate or more services, you should also be able to change your service provider if competition puts a better choice in front of you or your existing provider goes under. This is a risk in every aspect of business and part of the trade-offs you have to consider. Not planning for risks is wrong but expecting you have eliminated all risks by taking on the responsibility yourself is equally shortsighted. Properly balanced service usage and risk planning is a serious competitive advantage in the long run.
3. Pick Your Battles - Understanding service value means really knowing what your business needs. You will not have every use case for pricing in place the day you roll out your service. Building a pricing engine at that point means you may have to completely redesign your system while doing manual workarounds when it is realized you need a different pricing strategy. In this case, a feature-rich service could provide a window into many approaches you hadn’t considered. On the other hand, if your service requires a great deal of analytics, a library of analytic routines may be of value to lower development overhead, but if you do not completely understand how the library works and the results are obtained, it could be providing unreliable results. Just as in selecting features, you need to understand what your service needs to be effective and pick your battles carefully. Don’t build what you don’t have to but don’t accept black boxes that you don’t understand. Do proof of concept runs and don’t accept marketing at face value. What works for another provider may be entirely different in your context.
4. Focus on Delivering Your Expertise and Satisfying Your Customers – Really this is just part of picking your battles, but it is a core strategy just the same. The point of an effective services strategy is that it must free your team to focus on the value you provide to your customers . If managing a service is more work than doing it yourself, there is something wrong. Effective services clear out operational hurdles, provide market-led options, and grow with you. This also means understanding your core expertise and not extending yourself into areas where you don’t need to go to be successful. Service-based business is quite different than providing licensed software. Leverage service providers who have the field expertise you need while you continue to define and deliver the value your customers are paying for. Would you want your airline pilot to also be the maintenance team that keeps a modern passenger jet operational? It might sound good on the surface, but in reality, there is enough in each field that it just isn’t practical or safe. Focus on what you need to do to keep your customers and let qualified resources keep the engines running.

I would be remiss if I didn’t also say that we help our clients pick services everyday. There is no one size fits all and every choice has a trade-off. We spend a fair amount of time dissecting services and trying to understand the technical and business cases for their use. I can’t recommend a set of services that will work in every situation – but I hope these “pointers” will give you an idea of what is involved in the choices you have.

What have you found? What situations have you faced? Join the conversation and let me know.

Addendum -

I’m going to the Cloud Futures conference in San Jose, December 7-8, 2009. If you’re going to be there let me know on Twitter or by leaving me a comment here. I’d love to get a chance to meet with some of the community there and heaven knows, none of us have gotten out to many conferences in the last couple of years.

SaaS is not a “one-size-fits-all” business. There are many options now for platforms and services you can use and the number is increasing every day. A lot of the information available is laden with marketing hype. How do you make the right decisions?

We’ve been helping companies transition to SaaS as startups and from traditional licensed software for several years and we’ve build up a practice we use repeatedly to navigate the choices. We’re bringing our practice to the Dallas SaaS University event as a workshop to help SaaS executives and entrepreneurs make the right choices for their business. We’re passionate about helping companies succeed in SaaS and we’d like to pass some of our knowledge on to you.

You can take this workshop combined with your signup to the University event or separately, but I encourage you to take advantage of the combined pricing that is available. This is not a “technical” workshop – we will be covering how the technical and business decisions SaaS requires impact your business and product strategy. We’ll be using interactive exercises to help you put the concepts into your context and build something you can take back to your team. It is a full day with a catered lunch and will be a limited group so you will have plenty of opportunity to ask questions and be involved.

UpDate! – Use Discount Code: SCIO100

Here’s the outline:

Charting Your Course to SaaS

Making the Right Decisions for Your SaaS Product

Overview – How is a SaaS Product and Business “Different”?

• Leaving 30 years of industry history behind
• Transitioning to a service-led model
• 10 ways to fail

Your Service is Different

• What does making the right choices mean?
• Understanding your market, product strategy, roadmap, supporting technologies, and skills needed.
• Knowing flexibility is key in SaaS

Sell the Right Product

• Map your core product and customer assumptions
• Consider test marketing plans
• Developing a go-to-market feature set

Make Strategic Development Choices

• Selecting services and platforms
• Selecting a technical architecture
• Making development and deployment choices

Operating a SaaS Business

• Understanding service-led business requirements
• Leveraging operational metrics
• Understanding end-user interaction in SaaS and product management

Who Should Attend?

This workshop and seminar is important for anyone considering a SaaS product, in the process of developing a product or offering a product that hasn’t reached its potential, including: Entrepreneurs, CXO’s, product managers and key executives in startups, vendors moving to SaaS or existing SaaS companies.

About Your “Professors”
Luis Aburto, CEO of Scio Consulting, is a veteran of international technology and engineering consulting for corporate and government clients in the U.S. and Latin America. Mr. Aburto is the founder of Scio Consulting, and in 2006 was responsible for focusing the direction of the company on SaaS enablement services. Luis has worked with a multitude of software companies of all sizes and across many industries, helping them make the transition to SaaS.

Mike Dunham, Principal Consultant of Scio Consulting, has over 25 years background in the development and introduction of new technology working with startups, government and the largest enterprise software companies. He has worked with Scio for five years, regularly authors articles on SaaS and the software industry and hosts a series of podcasts on SaaS best practices. Mike leads Scio’s professional services helping companies develop and bring to market new SaaS offerings.

As I mentioned – there are several ways you can join us in this workshop and I very happy we have the opportunity to bring it to SaaS University. I’m looking forward to meeting many of my friends at SaaS University for the event. If you would like to know more about what we’re going to be doing or some help building the case so you can get company support to go, just let me know. See you there!

In Part 1 of this list we covered the first five points – so if you haven’t read that already, I encourage you to go and read that first. For everyone else – here’s the remaining five points in my hit parade:

6. Plan a yearly release cycle in conjunction with industry trade shows.

For marketing, product managers and developers with any experience in the software industry – this is a natural tendency. For the past 30 years, release schedules have rode the waves of industry events like clockwork. Because of the close association with end-users, a subscription renewal cycle which is frequently 30 days, and the “standards” set by industry leaders like Salesforce, Amazon, and Google – SaaS users expect a steady drip of improvements that have no set schedule. Waiting for some arbitrary “release date” is unnecessary and counterproductive. If the application is properly maintained and architected, the update will take place without any disruption to service.

Unlike upgrades to locally maintained applications – where IT departments had to schedule and plan for application upgrades and possible failures – those issues are now considered to be the domain of the service vendor. It has been outsourced – this is a core part of the service clients are paying for. Frankly – end users don’t care how it is done as long as there is no significant business disruption. Instead they are delighted to find a new feature that solves one of their problems – assuming all parts of the SaaS operation are meshed and working properly. The steady drip of improvement builds user loyalty and increases application “stickiness.”

7. Provide customized versions and features for specific customers.

In software development, this is known as “forking” your development or branching to produce a different, but concurrent, version of an application. Developers try to avoid it like the plague because it greatly increases risk – later changes may not be compatible with the customization done for a specific instance. In traditional installed software, with long release cycles, it was often done by system integrators or vendor professional services. It is an expensive practice that necessarily limits the ability of the customer installation to take the next version. So – they “sandbox” new versions and thoroughly test them before deployment. This may put them several months behind the release schedule of new versions, but it has always been considered a necessary evil in enterprise software deployment.

In SaaS, the tactical reasons for allowing individual instances and customer specific customization become operational nightmares. Now the steady flow of upgrades (point 6) becomes a significant cost issue for service maintenance. It requires more resources, planning, and risk. With the narrow margin of most SaaS operations, it can quickly become an issue that impacts reliability and profitability.

Proper SaaS product management provides two ways to get around this potential bump in the road:

• SaaS applications are architected to be configurable (rather than one-off customizations) to meet the demands of their market. Available configurations are consistent across the application and limited (if at all) only by feature bundling and pricing. Configurations are tested as a part of the normal development cycle without any special conditions. If a new customer requires a new element in configuration, product development evaluates the market and development effort required and makes a decision at the strategic level as to when and if the new configuration might be available. When it is completed – it is available to all clients and part of the standard application.
• If the customization would be to enable integration with other applications in the client portfolio – this is handled at the API level and possibly by external services (like Boomi) that can transform data for specific purposes. This separates the client side needs from the application and allows them to be “loosely coupled” instead of tightly integrated. Product development has to insure that the API remains consistent or at least clients with API integration are notified before critical changes – but beyond that – the service is available to all users consistently – not a limited few who have special needs that have to be evaluated individually.

8. Start with a free version to test the market.

This has been a common mistake by SaaS vendors – led by the many general consumer services available from companies like Google. Few vendors have the income of a Google and advertising-led income is really only possible for the most successful consumer applications.

Let’s say it clearly - The initial assumption of worth is equal to what you charge. If you charge nothing, you will get a lot of drive-by users who have no interest beyond trying to see what the service is all about. Taking input from free “hanger-ons” that have no intention of becoming paid subscribers is very dangerous. Where they want to lead you has nothing to do with profit and user retention at the subscribed end of the market.

That doesn’t mean a 30 day free trial is not a great way to onboard users initially. But – there still has to be a limitation and a stated worth. Users may decide it isn’t worth the price after trying for a few days. They will allow their test subscription to lapse and they will drop off. The rate of conversion from trial to subscribed becomes a clear indicator of the effectiveness of marketing (funnel formation) and product development (trial conversion and subscriber retention). It also doesn’t mean that “Freemium” packages can’t work – where the basic application is free but key services have a cost.

Pricing is a delicate dance between value received and money paid. In service offerings, the best case is always to provide more perceived value than the service costs. At worst, they can be roughly equal – but if they are out of balance to the cost side, subscriber retention will suffer greatly.

9. Build the richest, most complex offering for day one.

This approach is symptomatic of technical marketing and traditional software sales. For years, applications have been sold as technology with comparisons of feature lists. So, the natural tendency is to say – “We do it all! We’ve got all the bases covered!”

This approach leads to several issues in SaaS:

• Long, costly development cycles that produce a large feature set with no user-driven demand. How do we know the features we’re building are critical? What tells us the money and time spent will be returned in subscriptions? Go back to point 2 in this article. 80% of value is derived from 20% of features. There are always features that are necessary regardless of value, but as they rise, they increase cost and complexity for end-users.
• Developing new features into a very complex application becomes increasingly difficult over time. A smart SaaS vendor will generally break out potentially complex new capabilities into additional but separate services as Salesforce has done with Force.com. This keeps the core application focused and allows the new offering to “stand on its” own and seek its own audience.
• Complex applications require more time for users to become productive, training, and support. These are all costs, whether they are borne by the vendor or the client. They reduce adoption and put retention at risk. If the complexity is truly necessary it needs to be compartmentalized so that users can either take it on gradually or upgrade to “professional” versions when they are comfortable with basic functionality. Time to initial productivity with a service needs to be as near zero as possible.
• Complexity doesn’t sell itself. In fact – it drives people away. Think “Evolution – Not Revolution.”

10. Ignore change and agility.

Taking the sum of all the previous points, you should be able to see one thing stand out – A SaaS business is not your father’s software business. It is driven by change and renewal. It responds organically to market and user demands. It grows based on successful market adaption. I call this an agile business and so do many others. It is nothing less than a complete rethinking of how a business organization “works” at every level. It is both cultural and process-led.

This is not the Agile Manifesto – while still acknowledging it comes out of the same guiding principles. Putting a homily up in reception will not make it happen. Ignoring the issue will not make it go away. You can let the issue grind you down over time or you can accept it, plan for it and execute strategically.

So – that’s my list. What’s yours? What’s tops on your agenda?

They say everybody likes lists. Miles of virtual paper have been inked in pursuit of the “best recipes for chocolate chip cookies,” the “worst airline food,” and to complete the theme – the best diet plans. Ok then- we’ve got a list:

Ten Ways to Fail as a SaaS Company

Introduction

This little list comes from reading some recent blog entries like the post our friend Abe Sultan of Apprenda wrote for Datamation – How to Fail Miserably as a SaaS Company and my own conversations with software company executives. Before anybody says it – it is not every way there is to fail at SaaS. And like any limited list covering a big subject – the items are over broad and not necessarily indicative of the most common ways to fail.

But that said, these are the things that really irritate me and I’m sure irritate those who have lived these errors – as happens in the life of an entrepreneur. So, if you are or are considering offering a product with the SaaS business and delivery model, you might want to think about these common trip points:

1. Provide your licensed software in a hosted delivery model

I put this one first because it is probably one of the most common errors I see and one that we and a lot of other consultants in the field have, in one way or another, suggested at one time. I don’t suggest it anymore because I have seen what happens all to often when what started out as a simple little test exercise becomes a raging white elephant. What’s wrong with this idea?

• Your licensed product is very unlikely to be a good candidate for a SaaS product. This is a “test” of something you can never sell, maintain, operate or scale to reach a decent market. So – what are you testing? This is what is known as SoSaaS. Vendors of licensed products, especially high-value, line of business applications, typically aim their product at the top of their vertical market. It’s just more cost efficient for sales and marketing. The product is loaded with features that satisfy that end of the market and tuned for skilled install by client IT personnel. If it penetrates the 100 top accounts – it’s golden. SaaS products are built to sell and scale to a much wider market. If you can’t do that you are very unlikely to recover your hosting and maintenance costs – much less further development costs in a SaaS model.
• If your experiment is successful at even a minimum level, it will eat your licensed sales. This is equivalent to killing your milk cow for food right after the new calf is born. Best case is to design your initial SaaS offering to reach the needs of the “second tier” and maybe a larger section of the market. This is where the general rule of thumb “80% of value is derived from 20% of the features” comes into play. Leave the rest of the features, that continue to be of value to the top end of the market, off the list. Those customers with the licensed product won’t abandon ship overnight for the more focused SaaS product.
• And the biggest reason – these initiatives tend to color thoughts about moving to a full SaaS offering. The longer they go on, the more you focus on making the failed ASP model of service work. Don’t be Sisyphus. There is nothing to be learned here that you can’t figure out on a spreadsheet with a few links to articles. Costs won’t work out, maintainability won’t emerge and if customers do sign up in droves it will kill you. …And no, ASP in the Clouds is not a magic pill. You just automated part of a bad choice. Chutes and ladders only make the process of rolling the rock up the hill slightly less onerous.

2. Don’t test your market.

I love this one. It is so simple but somehow so counterintuitive to the culture of innovation that has built up over the years. We’ve all seen it. We’re invited to talk about a product from a new startup and the first thing we’re asked to do is sign an NDA. The office is dark and there are gatekeepers to insure competitors can’t get in. There is a sense that we have a new truth hidden in our product and when we release it to the world customers will smile and run to our door. We just don’t want someone to steal it before we finish it and release before we do!

This is an old technical/patent-pending/hardware product approach. 99% of SaaS does not and never will bring forth new technology, software process patents not withstanding. SaaS is expertise wrapped in an on-demand delivery system. It is a service and should be sold as such.

As Steve Blank as so elegantly put it – there are no truths inside your office. Get out and meet the target market before you spend on developing the product whether it is entirely new or a 2nd tier offering of an existing product. Talk to end-users. Show them demos, ask them if they see the value of what you are offering. What would they pay? What doesn’t it do that would make it more valuable? Listen. Take notes, make changes, recycle. After the process reaches a logical conclusion you will have something you can specify and sell. In fact you will already have your beta test pool.

Yes, maybe your competitors will get wind of what you are considering. I hope they do. I hope they short cut the process and spend thousands on bringing out a product without a verified market. Tell them they can’t wait. Go into that dark room and scope that product right now…

3. Ignore business operations.

This source of common failure is so broad it can cover a many articles. And it has. A SaaS operation is different at every level – marketing, sales, implementation, support, maintenance, development – and much of the operations side is expressed as part of the application itself. The online marketing site needs to hook directly to payment, provisioning, implementation and client admin so the new user can get authenticated and in front of the application right after paying. Subscription renewals are automated. Feature bundling and pricing is updated once and is expressed through out operations immediately. Community feedback is integrated into support and product development. None of these operations exist in a traditional software business.

Metrics can guide operations, but the organization itself needs to be aligned with new practices to take advantage of what the metrics tell you. “We have many users dropping off their company accounts before they have recovered the cost of acquisition.” Ok. This is not a bullet point in a slide – it is a question: Why? Someone has to track down the reason and fix it before we burn through a lot of cash. A successful SaaS business is about being proactive. If you wait to feel the pain, it is already too late.

4. Ignore architecture, services, environments and/or reliability

This is another point that is frankly too broad. Such is the nature of lists. This breaks down to a few points:

• SaaS products need to be brought to market economically. See point 2. Your product is going to have to change after release. There is no ultimate truth or one size fits all development solution for SaaS products. Operations (point 3) typically take as much as 60% of development effort if they are developed as part of the product from the beginning. If you can take advantage of a service or platform or tool or outsourcing to lower your risk, development cost and time to market – do it. If your product is properly architected, you can add critical services when you have a proven market and it makes sense to offset income temporarily to capture an ongoing service cost.
• SaaS products need to be architected to be maintainable, tunable, configurable, and stable across the growth pattern expected of a successful product. We change the tires on properly architected SaaS products going down the freeway at 70 miles an hour all the time. We don’t change the framework and drive train without serious consideration. It means pulling over and stopping and that is a hit against reliability.
• SaaS product planning is not software development as usual. You need to know the pitfalls and getting it wrong can be very costly. Get help. Do proof of concept runs. Don’t stumble about in the dark trying to deliver a product. You will find out too late if you are wrong and need to re-architect the product.

5. Ignore end users.

This is the one that broadsides traditional software vendors. Vendors of locally-installed, licensed business products sell to purchasing and key executives. Traditional product users receive what they are given. It is already paid for. Unless it is tragically flawed, they will be trained to use it productively . If they fail training they are moved to other work or let go as “untrainable.” Conversations with end-users are limited to a few words at trade shows and association meetings.

SaaS may be purchased in much the same way, although increasingly line of business users are tasked to do the research and build the internal business case themselves. But, once the subscription is purchased, the clock starts ticking. This subscription is an ongoing part of overhead. What is it contributing to productivity? Is everyone using it? End-user feedback is now front and center. There is seldom any training. A SaaS product is expected to be intuitive and the uptake is expected to be measured in hours if not minutes. If it takes days or weeks to bring new users online, it is a failed experiment from the beginning.

SaaS product management is also tightly linked to end-users. There is a lot to consider in the delicate dance of product strategy and user-led response and we will cover those issues in coming podcasts and articles – the point for now is that SaaS vendors are directly responsible to end-users for their experience. There is no IT department operating as the go-between while fielding first level support questions. If end-users are not satisfied, they will do one of two things – invent their own workarounds or return to their previous tools. Either way they will cease to advocate the service and in many cases will actively lobby to have it shut off. In the case of an on-going overhead cost – they will be successful.That means ultimately the SaaS vendor will lose revenue and may not cover costs. When cost of customer acquisition exceeds lifetime value or end-user loss exceeds new customer uptake – the cost of operation will start exceeding profit very quickly.

Sadly, we’ve reached the logical limit for number of words in an article that people can digest in a reasonable period of time. So, there will be a part two of this article where we will cover the other five points of the ten. Can you already guess what they are? Join us in part two.

Pricing services – how do you do it? Is there a rational process? Can you tie it to value? Cost? Developing a price is one of trickiest parts putting a new service online. Prospective customers have to believe the value can be realized and existing customers must find the value exceeds the subscription. A monthly subscription is easier for prospects to swallow but a yearly provides a bigger hit for cash flow and maybe higher retention. Which is better in the long run?

These are just some of the issues facing services vendors in the growing SaaS and cloud services market. In our September 8th podcast on Haut Tech Conversations, we’ll address those questions with our guest, Jim Geisman of Software Pricing Partners. Jim spoke at the first SaaS Summit. His firm has focused on software pricing since 1987 and has consulted internationally on issues of software pricing and deal structuring. He has written extensively on software pricing and is a frequent speaker.

More recently, his firm has helped companies price and package their on-demand/SaaS products or helped them transition to SaaS. Jim has been a co-founder, director, or advisor to early stage companies. He sits on the Board of the Professional Pricing Society and is a co-chair of the Mass Technology Leadership Council’s SaaS Cluster.

Joining Jim on our panel will be two of our Haut Tech Irregulars (well, they were both on the first show so that makes them at least irregulars!) – Steve Plunkett of Servitizer and Lincoln Murphy of Sixteen Ventures. Steve has started a blog series about services pricing and has some products coming out in that space so I know he will have some interesting thoughts to bring to the conversation. Lincoln always has something up his sleeve so I’m sure he will add a lot to the mix as well. And we will have Justin Pirie, an experienced SaaS Product Manager and startup entrepreneur to bring his field experience and real world questions to the discussion. It is going to be a very interesting conversation – so please – JOIN US.

Our panel of Industry Insiders:

Steve Plunkett, CTO of Servitizer – Steve is a technologist and innovator with eighteen years experience. He has worked with and held leadership positions in large enterprises, service providers, network operators, product manufacturers and government agencies. Specializing in solution and service innovation he has architected systems, networks and products and worked with customers, companies and partners around the world. Steve has lead initiatives within large organizations to transition from a product to a solutions and services model. He has a strong track record of identifying emerging and disruptive technology trends and harnessing them through solution and service innovation. Steve blogs for Servitizer on – what else – the Servitizer Blog.

Lincoln Murphy is the Founder of Sixteen Ventures and blogs on his business site. You can also find him on Twitter here and here. Lincoln Murphy brings over 15 years experience in on-demand software product development and Business Architecture, focusing exclusively on SaaS since 2004. Working with clients of all sizes, and both SaaS pure-plays and ISVs transitioning to SaaS, Lincoln helps companies recognize and execute on opportunities to generate or enhance revenue through the SaaS Business Architecture.

Justin Pirie is a SaaS and Cloud product manager and marketer who has been working in subscription software for over four years. He specializes in working closely with companies to create successful SaaS products using the latest techniques and industry best practice. He is based in the UK but has recently returned from consulting in the US for a VC-funded SaaS startup. You can follow him on Twitter here.

Haut Tech Conversations played live on Blog Talk Radio – September 8th, 2009. If you missed the live show, an MP3 is available to download and play at your leisure. We will also write up the major points of the conversation here on the blog and follow the conversation as it moves out across social media.