Haut Tech » product development

SaaS U: Increase Your Bottom Line Value with Multi-Tenancy

Michael Dunham — Tue, 15 Jun 2010 19:57:58 +0000

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…

SaaS: Keeping Ahead of Moore’s Law

Michael Dunham — Tue, 08 Jun 2010 21:08:26 +0000

The relentless change brought to us by the consistent doubling of computing power that Moore’s Law describes continues and is now likely to change at least some SaaS applications in the near term. What do I mean? Consider – we now have a very competitive mobile application market and thanks to Google Chrome and now Apple Safari, it has crossed to the desktop on browsers.

Meet the New Paradigm

The event that brought this to mind was the announcements of the release of Safari 5.o. Leaving out the typical “improved performance” claims – two things were apparent – it is now a platform and it is designed for use in a cross-platform, mobile environment. On the platform side, Safari has joined Chrome in providing an extension system that allows developers to in effect, build secure and stable, rich clients into the browser. We’ve seen this for a while in the form of the “app stores” that are proliferating for mobile devices like smart phones and the “iPad” category (however you define it). On the mobile, cross-platform aspect, the browser is now tuned for mobile users. It is very noticeable if you try the new Reader function of Safari. It is quite usable on a desktop or laptop, but it really shines in the limited real estate of mobile devices. Multiple page articles merge seamlessly into one. Space wasting banners, sidebars and menus disappear. The browser becomes a credible, focused article reader for all devices.

What does this mean for SaaS? Take this evolving “browser as a platform” trend together with the announcement of iOS 4 (the artist formally known as the iPhone OS) and the growth of the Google Android and Chrome OS and you have a quickly changing landscape of operating systems tuned for a rich mobile environment and a browser-centric application implementation system. These advancements mean the expansion and adoption of HTML 5.0 is moving even faster than many of us thought. They will make the often tricky environment of JavaScript and Ajax less of an issue and the user experience of properly-tuned SaaS applications much more fluid and “desktop like.” It means that locally-installed, OS dependent applications are becoming ever less relevant and cross-platform, network-delivered services are becoming increasingly rich and useful.

Frankly, as interesting as this news is, it also points out that SaaS is a very fluid environment. Keeping ahead of it is increasingly difficult. Knowing how to manage a SaaS product and chart a plan to navigate development is critical. Knowing what you need to support scalable SaaS operations and what you should embed in the application is critical. Understanding your user environment and what is expected in your market is critical. The list goes on and there has to be a way to understand the landscape and to make the choices easier. And the point of this article is – there is – it is SaaS University.

As a company, Scio has stayed involved with SaaS University because it answers the need our clients and the SaaS community has to have current knowledge about our industry and important issues. Because Softletter produces regional events quarterly, you can plan to attend when and where it makes sense and take advantage of the evolving content as you need to. The tracks and workshops are well attended, but generally sized so the sessions can be interactive and remain relevant. If you’ve been to the larger, vendor-led conferences – SaaS University offers content that is focused on providing valuable insight to SaaS entrepenuers.

The next SaaS University event is in Washington DC, July 20-22, 2010. There is a full two-day agenda of sessions in two tracks covering a wide range of subjects and a third day that offers a choice of four in-depth workshops. On that point in particular, I want to highlight our own workshop, Charting Your Course to SaaS.

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

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?

About Your “Professor”

SaaS: Develop, Price, Operate and Succeed

Michael Dunham — Mon, 12 Apr 2010 22:18:52 +0000

Our workshop with Software Pricing Partners following the SaaS Summit: All About the Cloud is now finalized! Seating is limited so please check the details below and sign up NOW:

SaaS Offerings: How to Develop, Price, Operate, and Succeed

One Day SaaS Executive Workshop Covering Technical and Business Topics
May 13, 2010 at the Donatello Hotel (near Union Square) San Francisco

Executives responsible for succeeding in the SaaS market need to make a series of critical choices in developing, packaging and selling their offerings. This one-day workshop provides the insights and tools needed to make the right choices.

Many of the challenges SaaS companies face can be met by balancing and integrating technical considerations with the business aspects of SaaS. Companies that can do this can bring their products to market rapidly and become cash-flow positive quickly.

This workshop is the first to integrate pricing and business models with development and deployment. The workshop will be held on May 13th, the day after the OpSource and SIIA event SaaS Summit: All About the Cloud at the Westin St Francis Hotel on Union Square in San Francisco. The workshop venue is conveniently located one half-block from the St Francis, at the Donatello Hotel on Post Street.

Which companies 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 pricing 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.
Ensuring the pricing model, development framework and operational plan will work in complex, highly competitive markets.

Topics to be covered:

What Makes the SaaS Model Different and Difficult?
Making Development Choices Strategically
How to Choose an Effective Pricing Metric
Creating a Lean Product Development Roadmap
Using Packaging and Licensing to Increase Success
Finding the Right Price Levels and Discounts
Operating a SaaS Business
Auditing Your Plans with a SaaS Reference Framework

Because of the value of this workshop, the importance of the SIIA/OpSource conference for SaaS providers and the convenience of the venue, this is an excellent opportunity to “put it all together.” The workshop content makes it well suited to a mixed group of business and technical members of your team because it joins the issues of both sides into a single view.

Per Person Pricing

Early Bird price – expires May 3rd	$495
Three or more persons from the same company	$395
Price after May 3rd	$595

Group Promo Codes

Three or more members of the same team:

On or before May 3rd – 57KA5G
After May 3rd – 7GNGBH

All attendees will receive copies of the workshop materials. The workshop fee also includes a “working lunch” and refreshments during the day.

Secure Registration with Acteva.

Hotel

The Donatello Hotel has a limited number of rooms available for workshop attendees at $139 during the period of May 9-14. This is an excellent opportunity to save with a very convenient location if you are also attending SaaS Summit/All About the Cloud Event.

To receive this discounted rate, you must the contact the hotel directly at 415-441-7100 – and ask for In-House Sales and the “SCIO Pricing” discount.

About the Speakers

Michael Dunham, VP of Service Engineering – Scio Consulting
Mike Dunham has more than 20 years of hands-on experience helping major corporations and government agencies succeed in an increasingly technical environment. As Scio’s principal consultant, Dunham provides clients insight into trends that affect business and technology planning so the processes Scio uses can bring clients’ ideas to life. As the VP of Service Engineering, Michael defines Scio’s service products and operational processes. A native of Sacramento, CA, he holds a bachelor’s degree in business administration from the University of California at Davis.

Jim Geisman, Principal and Founder – Software Pricing Partners
Jim is an acknowledged expert in software pricing and, since founding the firm in 1982, has helped several hundred companies develop effective pricing models and strategies. His consulting spans established and emerging software companies delivering B2B solution via desktop, enterprise-class and, more recently Software-as-a-Service / on demand software. Jim has been a board member or advisor to several early stage technology companies. He holds degrees in Electrical Engineering from Tufts University and an MBA from Harvard Business School.

A quick introduction on our podcast:

The 5 Variables of Project Estimation

Michael Dunham — Tue, 06 Apr 2010 14:01:31 +0000

I’ve debated writing this article. Do people expect me to write about Project Management? Well… developing software products does mean you need to plan a project. You need to know and control your risks. So – yeah. I guess it does fit.

My thoughts on this subject come from practical experience. Companies who come to Scio with their projects often come with a multi-megabyte PDF, UML diagrams, and a list of specifications. “Give us a firm, fixed price for getting this project done by June 2nd at 2pm Eastern,” they say.

Their basic idea is:

Software projects have a unenviable record of finishing over budget and way over the estimated completion date – we’ll set those so they can’t creep.
Software outsourcing is risky so we’ll limit our risk by agreeing to a cost and timeframe we can live with and possibly tag onto some event. “Shoot for the June trade show so we have a shiny new product to sell,” Marketing begs.
We don’t have the resources to do the project in house, but we don’t trust any outsourcing group – so we’ll rope them in with a fixed fee and time and put all the risk on them.
We know perfectly well what our product needs to be. If we don’t nail this down, we won’t get what we need for the price we can afford.

The result of this thinking generally speaking is:

Flaming Disaster!

Why? Their basic instinct wasn’t wrong. Software projects do fail to meet their targets with astonishing regularity. They were just trying to limit their exposure. What is happening?

There are five intrinsically linked factors in estimating software product development projects:

The Total Elapsed Time expected to produce the specified product.
The Effort required to produce the product.
The Cost the client expects to expend.
The Resources required for the project – their skills and availability.
The Specifications for the product; the features, functionality and user experience.

In general terms, what clients are trying to do is set a “target.” In project management, the general assumption is you can set any one of the five factors as a target for a project, but when you do, you need to let the other four float to where they need to go to reach the target. So if you set cost, you need to vary time, specifications, effort and/or resources to reach a mix that will achieve the project goals within the target cost.

Instead, clients set two or more factors in an attempt to “hold the line” on all the other factors. They spent a lot of time on those specifications. They need them all!

But in fact, setting more than one factor as fixed creates an almost impossible tension among the remaining factors that almost assures the project will fail to meet its goals. There are no levers left to control the project! It starts out with the best of intentions, but with two or more factors fixed, any change in circumstances during the project creates an imbalance that cannot be corrected with the remaining factors.

Why does this happen? Stepping away from our example of setting time and cost as the fixed factors – think about each of the factors individually and the impact they have on the project:

Time

The elapsed project time from start to finish is always different than the total effort applied. Time is measured by a calendar start to finish. Conversely, effort is the sum of all the time expended on a project by the assigned resources. Total time is never equal to the total effort unless only one resource is assigned, full time.

Software development projects rarely finish on time. Unplanned specification changes, unexpected risks, and resource changes always build up over time and eventually result in a project that is both over budget and beyond the allocated time.

Time to completion can only be estimated and controlled well over short periods. As the time period considered in an estimate increases, the accuracy begins to degrade because of variations in expected effort, the depth and complexity of the specifications involved, the skills and availability of the resources required and the limitations an assumed total cost puts on the project.

It should also be understood that time to project completion is rarely scoped as a direct result of the estimating the effort required. More often, “artificial completion dates” evolve from a point in a product marketing plan, the current product position, and/or customer demands. When this happens, there is usually some consideration of project scope, but is rarely enough to address the situation that arises from not first doing a straight-forward evaluation of the effort required to complete the specified product.

Effort

The accurate estimation of effort is key to successful software project costing and setting a realistic expected time to completion. In practice however, the amount of effort required to actually produce each bit of application functionality always varies from estimates. The more detailed and contingency bound the estimate becomes, the more likely it is to be wrong. Because of this, past experience and general effort assumptions are used across a project estimation, in the belief that in the final outcome everything will average out. Of course the reverse is also true; averages can never address the all risks in an individual project. So, while averages are a practical approach to project estimation, they cannot yield a project quote that can be fixed to a specific figure without risk.

In this situation, risk buffers for variations in specifications and resources are recommended for effort estimation, especially in Agile development methodologies where development iterations are “timeboxed.” Timeboxing iterations means variations in effort will generally cause functionality to be pushed ahead to the next iteration and a “snowball effect” can be produced where the amount of effort required for each iteration increases incrementally beyond estimates over time. If buffers were used, more projects would reach their estimates, but in the drive to reach a more competitive price, they are rarely employed when using assumed effort to arrive at fixed cost. This results in a very narrow margin for error in effort estimation.

In addition, the amount of time required to reach project completion is not directly related to the number of resources available concurrently. Determining effort depends on an experienced assessment of an efficient team size for the project and the methodologies used. Increasing the number of resources and concurrent tasks beyond a certain point increases coordination and communication overhead exponentially. Increased team size tends to increase errors, oversight, and testing cycles without a cost effective increase in total output.

Estimates of effort required tend to be assessed from a straightforward analysis of specifications. During projects, the actual effort required frequently increases beyond estimates because of “fixes” required to bridge the gap between specifications and the product as realized in development. In addition, the elapsed time required for QA by the client team is often under-estimated and can result in either idling development or moving ahead with incorrect assumptions and subsequent rework.

Cost

Software development projects almost never finish under their expected cost from the point of view of clients. A few finish at the client’s target cost, but generally only at the expense of other project factors. As a result when projects do cost what was originally expected, the product is often a failure from an end-user point of view.

For clients, target project cost is generally a function of:

Expected product price and the desired return on investment that could be produced by an estimated number of paying customers in a reasonable period of time. In other words, a string of dependencies that may have little basis in the final analysis.
Available funds and cash flow limitations.
Experience with “similar projects” – However, only rarely do estimates based this way actually work out to be similar in the effort required.

Target cost is never or only rarely based on:

The steps and effort actually required scope and develop a product that is a successful market fit.
Small, incremental steps that can be estimated with a reasonable chance of success.

Specifications

Specifications are almost always assumed to be a known and set factor in fixed cost projects. They are used as the basis for effort estimation and effort estimation ultimately determines quoted cost. Clients generally have a basic expectation that their specifications do not need to be varied from substantially to produce the desired product at the specified cost. Clients often expend great amounts of time producing specifications for bid to assure they will be complete and assumed to be fixed. But in fact, not assuming specifications will need to be varied as over the course of a project to meet fixed cost results in a continuous tension between the effort required, the scope remaining and the time remaining on the project clock.

Most fixed cost projects have intentionally limited options to change scope. Instead, limiting scope change by not providing workable options increases the risk the project will not reach desired goals when actual product is assessed by end-users.

Software development requirements can never be complete enough or communicated well enough to insure understanding and success. Errors in interpretation, over-broad and over-complex specifications result in many “fixes” that are not related to actual code errors by the development team. These fixes are actually elaborations or “clarifications” of project specifications, but in most projects they are assumed to be “bug fixes” in the process of development, testing and QA. In practice this means the actual functionality works as specified but the implementation is not as desired by the client. Fixes of this type generally add to effort and resource allocations without the assumption they should impact specifications, time or cost.

Software development project requirements are by their nature improved by discovery on the part of both the development team and the client team during analysis and development.

In the course of normal work, discovery exposes:

More depth than expected (scope creep).
Different aims and approaches from client and end-user feedback or unexpected insight from seeing the product as it develops.
Technical limitations or alternative approaches that change requirements, the effort and time required.

In most software development projects, there are no assumptions or procedures to handle specification discovery and subsequent changes. This results in many variations from project estimates and is a significant factor in project overruns.

Resources

Resource management is a function of having the right skills available when needed for a specific task in a project. With limited resources and funds, this is a difficult task for software development companies.

Both internally and externally, software development companies have an ongoing need to balance new projects against support, maintenance and enhancement of existing applications. Companies need to decide the level of investment they will put into new technology. Using time from existing work to move to new technology skills is a difficult and expensive proposition. Recruiting for internal resources is a long, expensive process that often fails to yield dependable, trained resources in the long run.

These factors are the leading reasons clients consider outsourcing. But they are also a factor in outsourced projects themselves because at some level, the client team becomes involved directly with the outsourced team and the results of team resource management. The management of new software development projects is difficult by itself. Because of the time and risks involved in recruiting resources with appropriate skills and knowledge, client project/product managers often don’t have a good understanding of the technology and limitations in the project they are managing.

In this situation, outsourcing software development often leads to a confrontational relationship where the client team feels they have lost control and don’t understand the choices the outsourced development team has made or what effort is being applied to produce deliverables. They don’t understand that the estimation for time to completion was figured against assumed effort but the accuracy of that assumption varies according to specification clarity, resource skills and availability.

In Summary

Variations in the five factors during a software development project leads to:

Defensive reactions to clarifications and changes between the client and development team.
Situations where the actual effort in the given time varied depending on specification accuracy and resource skills and availability leads to confrontations. When time to completion is figured for fixed cost, it is generally figured against assumed effort. Without assumptions for what controls are available to deal with variation, the confrontation continues to simmer throughout the life of the project.
Lost opportunities for a partnership-like relationship of shared risk and reward.

The solution could be as simple as not setting more than one factor as fixed, but in practice that is hard to do for many projects. What is really needed is a consultive framework for communication and decision making that is informed by real time reporting during the project and collaborative resolution of issues to reach the client’s goals. It’s easy to say, but it takes understanding, planning and agreement to accomplish.

We’re constantly working on this paradigm everyday – it’s challenging and rewarding. What’s your experience? How do you hold the line? What controls do you have realistically? Have you recognized the five factors in your project estimation process formally? I’d love to hear your thoughts…

SaaS: Irrational Fear of Platforms

Michael Dunham — Tue, 23 Mar 2010 20:24:16 +0000

I find much of what I read in the media about the “issues” involved in developing SaaS products as silly – and sometimes just plain misinformed. Is it just me or are there just too many analysts with nothing else to write about? Hint: Pick up the phone and talk to some people who are actually developing a SaaS product…

SaaS itself is a victim of this type of FUD (Fear, Uncertainty and Doubt). There seems to be a rise again of articles about “continuity assurance” and “source code escrow.” I’m not going to link to any of them – all of them seem to assume that there needs to be some draconian legal answer to the problem of data portability. Let’s be honest people – No Technical “Solution” is Forever . If you’re not taking steps to manage your risk for control of your data and processes from day one you’re in trouble no legal agreement or high-priced lawyer can fix. And yes, a smart SaaS vendor will build portability into their product because they understand the business value it gives – but nothing can force customers to use it and plan properly.

Likewise, I think people who are researching the business and technical issues for developing SaaS products are finding more FUD than substance. Yes, SaaS business operational issues are different, particularly for vendors of traditional “premise-based,” single-tenant applications. Yes, the technical requirements of the Internet-based and “cloud” environments are different. In fact, it would be a good idea to seek help on these issues so you can concentrate on delivering a service with business value. But honestly, I would and have recommend that for anyone developing a software product today. Think lean. Don’t waste money and time developing what you don’t have to – use services and frameworks you can leverage. Spend on developing a product customers will pull into the market. Learn customer-driven product management.

But doing that means leaning on tools, frameworks and yes – platforms so you can focus on your product. Enter the Boogie Man. Analysts produce lists of lists of keywords that capture a perceived issue: “vendor lock-in,” “Opex Vs. Capex,” “proprietary lock-in,” etc. And as anyone who has followed the industry knows – there have been failures. But on the other side of the coin – the number of failures has been quite limited considering the wealth of tools and services available. That isn’t a lot of solace to companies that bet on Coghead – but I have to say they should have seen the writing on the wall a long time before the doors closed. The total lack of data/code portability tied to a vendor that was clearly struggling to get traction and funding (read: no business model – the smell of burning cash) should have caught prospects’ attention.

The real truth is that software development has been depending on tools, frameworks, application servers, services, and platforms since the days when we left assembly code behind. You can’t avoid them. If we were constrained to coding directly for each processor and environment, technical progress would be dismal indeed. Java, C#, HTML, .NET, Apache web server, XML, PHP, Ruby, Python – all of these simple examples are at some level an abstraction of layers below them. But like Microsoft’s Visual Basic – they are all tools that have a lifecycle and will eventually be superseded or folded into the next generation product. Technology moves on. Nothing is forever.

Of course, this doesn’t mean application developers shouldn’t consider where their tools are in their lifecycle and viability of the community of users around them. It doesn’t mean that the business side should ignore the risks of the choices the technical team has made. It doesn’t mean we don’t need to have an idea of what we would do if the worst comes and we need to change our assumptions. How long would it take? What would the most likely alternatives be? What is the real risk of doing nothing because you’ve become a “deer in headlights” with all the choices you have to make – instead of just making decisions, allowing for risks and moving forward to a positive cash flow from a product with a growing, paid user base?

Because we don’t believe “doing nothing” is an option that will lead to success, at Scio we’ve made a conscious choice among the tools available to us. We’ve picked a group that we believe deliver business value to our customers. We have invested our time and resources in this “platform” to develop our delivery expertise and are continuing to do so. I say that not to highlight ourselves – it is what service companies do. They leverage tools to deliver their services better, repeatably and more competitively.

Do I need to say it? SaaS is a service business. Don’t succumb to the irrational fear of tools you can leverage to better deliver your expertise and value to your customers. Learn to evalute and manage risk. You cannot be successful if you are totally risk averse.

If you’d like to know more about how to navigate the operational and technical choices in developing SaaS products – let me make a suggestion: Jim Geisman, of Software Pricing Partners and I will be giving workshops on SaaS following the OpSource/SIIA SaaS Summit 2010 – “All About The Cloud,” May 10-12 in San Francisco. We’re very serious about making this an opportunity that people can take advantage of – so we’re “crowd-sourcing” the workshop configuration before we open registration. We need feedback from people who are either planning to be in the area for SaaS Summit or are just in the region and interested in attending (you don’t have to attend SaaS Summit to attend our workshops – but we encourage it).

Would you give us some feedback on the workshop configuration that would be most useful to you with this survey? We would really appreciate your help on this. And watch for more about the workshop starting next month.

SaaS: Get a Realistic Roadmap

Michael Dunham — Mon, 08 Mar 2010 22:51:57 +0000

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:

Developing a product that customers want, will pay for and will advocate
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…

Lean Software Product Development in 4 Phases

Michael Dunham — Wed, 24 Feb 2010 18:55:59 +0000

When you develop products in a repeatable, production fashion, you have to step back occasionally and take the long view so you can properly discuss the process with clients. We’ve been involved in that exercise recently and I thought it might be useful to share the what and why of our approach to software development for online products.

First, there is one basic idea that informs all of this:

We define “Big Bang” development as:

A basically black box project where significant work is done up front to develop extensive requirements documents which detail the features and functionality in great depth for a software development project that typically lasts from 12 months to two years.
The time expended on requirements development is expected to provide developers with a very specific vision of the product that can be put out for bid, will put a box around scope, cost and time, and will last through out the project.
On release, the exhaustive feature list is expected to drive market adoption and leapfrog existing competitors.

This technique of specifying software product development has been used for years by companies that want to somehow reduce risk on a project they cannot do in house and often because of the technology and complexity, where they cannot provide granular oversight during the project. But regardless of those worthy aims, these projects continue to fail because:

Controlling scope over the life of a project becomes increasingly difficult as the project complexity and time span grows. Prediction accuracy degrades geometrically over time – yielding a project plan that can be relied on at a high level at best.
Technology continues to respond to Moore’s Law. The longer requirement development takes, the longer the project goes on, the less likely it is to meet the expectations of the market on delivery. User expectations, informed by other products they have tried, have moved on. In addition, the technology assumptions at the beginning of a project don’t always work out when development actually takes on the complexity of integrating them. So the choice of a tool, framework, or library may seem like it solves a lot of problems at first, but in practice may turn out to be a black hole into which resource time disappears.
No matter how detailed requirements are – they are limited by two things: point of view (the classic story of the blind men and the elephant is the common point of reference) and actual feedback from end users of the resulting application. No matter how carefully feedback from end users is brought together for requirements, it is only as good as their vision of the final product. As we and others have said many times – if you asked people at the start of the 1900′s what they wanted for personal transportation – the requirements would only lead to better horses. In addition, it is rare for requirements to both anticipate user needs correctly and the complexity of delivering them in a particular way. The risk in requirements actually increases the more detailed they become – if they cannot respond to end user feedback early in the development process.

So – what is the alternative? Consider “Lean Product Development.” We have a general assumption of software product development we have formed over several projects and across several industries:

Lean Product Development (Click on the image to see it in detail)

The phases and their aims break down this way:

Sprint 0 – During this phase, requirements are verified, technology choices are made in detail (architecture, stack), user stories are built (we use Agile development techniques – user stories are roughly equivalent to use cases), and the user experience (more than just interface, how a user will use the product) approach is developed to set interaction standards. The outcome of this phase is a set of technical specifications, personalities (roles to a degree), and prioritized user stories with effort estimates for each story.
Alpha Version – During this phase, the underlying framework is built and core functionality is developed for key end-users. The point of this phase is to verify the product vision with the key audience of the application – the end users who perform the most critical tasks and use the application most. This means the alpha version needs to be actually be tried by the core end-users. This usually requires client partners – which in the case of a new vendor requires getting out into the market and bringing in some early adopters. The outcome is to lower risk. The cost at this point is low, compared to the whole project, so changes can still be absorbed without loss of large portions of developed code and sunk costs. Also, at this point, the approach of the development team in carrying out the vision of their client can be verified early – so that adjustments can be made and trust between the client and the development team can grow. This approach follows the sage advice articulated by Steve Blank - the point of early user validation is to get out your “dark room” and get in front your audience early so they can inform development before costly mistakes are made.
Beta Version – This phase produces the first cut of the market version of a product. It is important to understand that the scope of this version is intentionally limited to just what is necessary to deliver value to end users. In other words – deliver just what they will PAY FOR. This is a critical assessment that is informed by both the vision of the subject experts and the feedback from the Alpha Version. The problem is however, no matter how good the vision and feedback are, there will be additional feedback when the product hits the many different contexts of actual target end-users in the market. The release of the beta version also provides the “kick off” of internal operations for the provider – and in the case of most products – support, sales and marketing. The lessons learned from beta release then inform the next phase so that beta adopters are rewarded (and retained) and operations delivers the message and services needed to drive new customers and user adoption. Because of the incremental nature of Agile release cycles, the actual point when sales are made during this phase varies a lot between products – but development doesn’t stop. What changes is that development is now more directly informed as new customers come on and participate in the beta. Some companies test pricing and marketing more aggressively at this point than others – but the general recommendation is to establish pricing early and test it against the perceived value from users. The outcome isn’t expected to be an adjustment to pricing directly but rather an adjustment of features or packaging to better align with perceived value.
Market Release – This phase marks the release of the full market product and the beginning of “normal” product enhancements to continue to grow functionality in alignment with user feedback. We sometimes add a phase for development up to market release itself that is separate from beta – but for general purposes – development has now slipped into an enhancement mode, rather than full out development unless there is a significant difference from what is planned for release to beta customers and the general market. The outcome of this phase is a product informed by target user feedback, tested business operations and a change of focus from getting the product “out the door” to getting customers and continuing to enhance features and functionality. It is not an end point – it is just the start of the natural evolution and “pull” of a “consumerized” online product.

The outcomes of this process are:

Early release and feedback from the people who count – the users in the field.
Early validation that both the vision and the requirements are resulting in a product that delivers value and will meet market expectations.
Lower up front risk and lower time to profit. Waiting over a year to put a product in the market with real users is a recipe for disaster. Getting into the market, proving operational assumptions and kick starting cash flow as soon as practical is key to success. A good reference on this Joel York’s SaaS Metrics Rule-of-Thumb #4: Company time to profit follows time to break even. You can’t prove your assumptions around operational costs and customer acquisition cost (CAC) until you get into the market. The sooner you get into the market, the more time you have to adjust to reality before your startup cash pile is burned up.
Simple – a higher chance of success measured by what counts – adoption, cash flow from customers and retention of users.

A lot of our customers though face a little more difficult situation – they have an existing product in the field that started life as a traditional premise-based product and is now being pulled to adopt a more dynamic online model. That brings an additional set of issues:

If the development cycle is long, existing clients may jump ship before the full online version is available.
Support and maintenance of the existing product can overwhelm the key members of the product team that need to be available to shape the new product. Finding a point when transition can begin in an orderly fashion, without cannibalizing existing sales is critical.
The new direction provides an opportunity to develop new markets, adopt new pricing levels and transition to a pull-driven feature model (rather than the push of traditional product releases) but timing is key. For a complex product meeting the needs of the top of a vertical market this becomes a huge exercise and is frankly very difficult to break down into manageable pieces.

To deal with that we have a general model that takes the new product template above and turns it into a phased development of a suite of products. In the diagram below – you can think of each of the blue boxes as a modified run of the our typical product develop cycle:

Progressive development for a suite of online software products (Click on image for more detail)

The major steps in this are:

Sprint 0 – A holistic project-level requirements, technical specifications and feature breakdown that sets the stage for the entire project – but doesn’t lock assumptions down. The point of this entire project is as before, get products out early, get feedback and cash flow as soon as practical. This also includes a more detailed look at the first product in the suite.
Web Enhancements – This part of the first product release is optional but worth considering as a way to ensure existing customers stay onboard for the long run and can see the long vision early – so they will become key in feedback as the product progresses through the lifecycle. What form this product takes varies, but the idea is to enhance the existing product with features that suit the Internet environment particularly well and extend it in ways not possible before because of technology or restrictions inherent in the on-premise version.
Broad Market Version – To allow early feedback and to get into the market as soon as possible, the first product needs to be a focused subset of the expertise expressed in the legacy product that addressed the top of the market previously. Generally, this means providing a set of features that will provide value for the 2nd and perhaps 3rd tier of the market. Again, all the points of a typical product release as we first described need to happen in this release so the product is informed by actual end-users in the target market – which coincidentally is a new market for the vendor.
Professional Version – Building on the same code base as the Broad Market Version, the professional version targets the features which will satisfy 80% of their installed base. This sets the stage for migration and broadens potential adoption by a group of customers who will pay significantly more for the value the product delivers. This also marks the point where legacy support and maintenance can begin to turn the corner and clearly move toward the new product.
Enterprise Version – Again, on the same code base, enterprise functionality is added and now the entire “product suite” has reached levels of functionality never achieved in the legacy version. Users pick levels by feature packages within the suite – so if properly architected – there is a lot of variation in pricing and packaging possible to meet needs in different markets.

It should be said that the timeframes proposed here are generalizations and will vary, but – they are based on the assumption that development should focus on delivering features with value to end users. Everywhere else, the simple rule “less is more” should be followed with the leverage of services and frameworks where ever practical. The architecture needs to allow those services to be used as long as necessary, but to be replaced as growth provides the option to drive down the cost of service. It should also be said that features and customization in this approach come from choices of what is made available to roles in market packages and configuration – not separate versions.

Now, I’ll admit this is a big vision and a lot to absorb in any context – either as a startup or a software company with legacy products in the market. And – it is a big shift in how we have looked at software product development. It comes from our own experience of the issues we find repeatedly in the market. I can’t say it is an approach that every development group can provide successfully. It depends on making clear choices that will provide these outcomes and not waffling with half measures.

What do you think? Can you see your company going down this road? Can you see the benefits? Let me know…

Lean into SaaS

Michael Dunham — Tue, 09 Feb 2010 18:10:53 +0000

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:

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

SaaS Case Study: Using Innovation Games for New Products

Luis Aburto — Thu, 19 Nov 2009 19:32:57 +0000

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:

Product Box – day 1, morning
Start your Day – day 1, afternoon
20/20 Vision – day 3, afternoon
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.

SaaS: DIY or Eat Your Own Dog Food?

Michael Dunham — Thu, 12 Nov 2009 15:48:25 +0000

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?

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

Haut Tech » product development

SaaS U: Increase Your Bottom Line Value with Multi-Tenancy

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

Companies that can benefit by attending this workshop:

Company challenges this workshop can help overcome:

Topics to be Covered:

SaaS: Keeping Ahead of Moore’s Law

Meet the New Paradigm

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

Companies that can benefit by attending this workshop:

Company challenges this workshop can help overcome:

Topics to be Covered:

SaaS: Develop, Price, Operate and Succeed

SaaS Offerings: How to Develop, Price, Operate, and Succeed

Which companies can benefit by attending this workshop:

Company challenges this workshop can help overcome:

Per Person Pricing

Early Bird price – expires May 3rd

$495

Three or more persons from the same company

$395

Price after May 3rd

$595

Group Promo Codes

Hotel

About the Speakers

The 5 Variables of Project Estimation

Flaming Disaster!

Time

Effort

Cost

Specifications

Resources

In Summary

SaaS: Irrational Fear of Platforms

SaaS: Get a Realistic Roadmap

Lean Software Product Development in 4 Phases

Lean into SaaS

SaaS Case Study: Using Innovation Games for New Products

SaaS: DIY or Eat Your Own Dog Food?

Addendum -