Introduction to Our 2011 Workshop Series

This is the first article in a series I will be writing over the next several weeks with excerpts of this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap.

Background

First, some background on our workshop. The concept behind the workshops comes from our consulting experience at Scio. We provide Nearshore Product Development for SaaS and Cloud products from our Development Center in Morelia, Mexico. Our clients come from a wide range of industries and cover the range from single entrepreneur startups to multi-national corporations. We focus primarily on the Americas because that is where we can leverage our collaborative Nearshore model best, but we also provide services for companies in Europe and Australia where our background with SaaS applications is particularly important to the projects. Our services center around software development for SaaS and Cloud applications, but in the course of developing apps for our clients we also realize it is critical we contribute what we can to their success.

Over the years we have been providing our services we have found that clients repeatedly hitting the same “bumps” in the road to releasing a service. Some of the issues are business and some are technical. In response, we began to develop consulting services that could help our clients avoid those problems and have a clearer picture of the way forward. These services are strong and well-received, but basically focused on the needs of a single client prior to development by our team. They don’t scale in a way that we could easily provide them in a more generic setting to multiple companies. So – to fill that gap – we developed a more formal approach to what we began to call the Cloud Product Roadmap.

The idea of a Product Roadmap is not new and we’re certainly not the only ones to use the idea. Our particular focus however brings a concentration on the factors that are critical to success in the field of SaaS and Cloud Services. Broadly, our roadmap leverages the concepts of Agile Software Development, Lean Product Development, Customer-Driven Product Management, and the collaborative environment they require at all levels of the project. From our experience and a growing number of practitioners in the field, this is the secret sauce behind a growing number of successful SaaS and Cloud products. The elements of this roadmap are increasingly seen as the standard for product development and management in the field.

The workshop itself is an intensive, interactive discussion of the critical issues and decisions that need to be made to launch, manage and maintain a successful SaaS or Cloud application. It covers both the business and technical aspects involved as well as the iterative cycle of decisions that have to be navigated to arrive at a complete roadmap. The events are intentionally small to provide more opportunities for discussion and adjustment to the needs of the attendees.

So – what do we talk about in our workshop? Here is an except from two slides in our Business Model presentation:

Cloud Product Roadmap – Business Model

Excerpt: The Democratization of Entrepreneurship

A successful business model in SaaS and Cloud Products evolves from a series of iterations between the concepts for the product and the business that supports it while deriving income from the value it provides clients. The process has been best conceptualized in the writings of Steve Blank and Eric Ries and identified as the “Lean Startup.”

The key point is that the ideas behind business model development and the process of developing a successful software product have changed in the last few years. Experience and technology have come together in a way that makes it much easier for individual entrepreneurs to enter the field.

Consider the traditional barriers that confronted entrepreneurs:

• Long, technically-driven development cycles – A lot of the basic functionality required didn’t exist. There where no models or platforms to build on. Development required research and highly-skilled, technically creative development teams. Development cycles were long, feature lists were exhaustive, and the risks were high. Imagine a development cycle of more than a year for a platform that has a regular renewal cycle of three years. Add to that an implementation environment that varies from client to client because they are all isolated. There is a lot of risk to absorb in taking on a project like that and most individual entrepreneurs don’t have that kind of resources.
• The high cost of the first customer – In this environment, the first customer implementation carries tremendous cost and risk. If there is a failure in the implementation or the product fails to meet expectations, it becomes very difficult to recover. Is the product wrong or the customer a unique case? It is hard to know. If you go forward assuming this case is unique, you continue to carry the risk that you have spent a lot of money going down the wrong road. If you assume this is a clear indication that your product is at fault, you could increase your total cost and risk even more by spending the effort to fix the perceived problems. This is exactly the risk that high license fees had to address. The entrepreneur fronting the development of a complex product is taking a lot of risk in an installed environment.
• Limited financing options – The high capital needs and limited options available for a pool of thousands of new businesses created a focus on funding rather than the product itself. This was the era of the one-page business model and the endless cycles of meetings with venture firms in Silicon Valley.
• Expertise in entrepreneurship and product development concentrated in a few places – The skills and resources needed to form a successful team concentrated in parallel with the financial firms that could handle the risk and investment. Outside of Silicon Valley and a few other areas, it was very hard to find resources.
• High failure rate – Entrepreneurism is a process of failure. If you are averse to risk and failure, your upside is badly constrained. With the high investment required, only a few could stand the risk of a new project.
• Slow adoption of new technology – By its nature, the success of a software product depends on the adoption of the basic unit of implementation – the computer or platform that runs the software. If the initial cost is high, skilled resources are limited, and the knowledge of the value that can be derived is low – adoption is limited to the few brave souls with the vision and resources to take the plunge. When communication itself was slower and less driven by the individual, it was very hard to build acceptance of new technology.

What has changed?

• Compression of the product development cycle – Instead of trying to cover every possible aspect of a founder’s vision, current product development processes focus on the minimum number of features required to deliver value. Using Agile development techniques, a functional application can be evaluated much sooner and put in front of customers at a much earlier point. Add this to the ubiquitous delivery medium of the Internet and you have the capability to reach a wide range of prospective customers in a very short period of time. This allows you to leverage customer much sooner in the development cycle and correct your course while your risk is still manageable.
• Lower funding requirements – Over time the number of tools and services that lower the effort required to build and implement a product, especially in current cloud configurations, has increased geometrically. This lowers the time-to-market and investment needed, which creates an environment where investment can be forestalled until a ramp up is justified by market acceptance, positive cash flow and real customers.
• Funding tuned to encourage and manage the search for a sustainable and scalable business model – Smaller steps in the development cycle, success-based funding, with a focus on waiting for key investment until a repeatable and sustainable business model is found. In fact, in many business to business models, venture funding is not needed at all. Positive cash flow and traditional business instruments can carry the load.
• Entrepreneurship recognized as a management science - The overarching process and philosophy is well understood. A successful business model is not luck. It is achieved with a roadmap approach that can be repeated over and over.
• The consumer Internet paves the way – The acceptance of the Internet by consumers and the change in their perceptions of technology is becoming part of business DNA.

The Second Installment in this Series is now Available >

So – Are you considering or developing a SaaS or Cloud Product? Are you operating a Service that isn’t reaching it’s potential? Do you want to know more about how you can leverage the success others are having in the field?

• How are you going about the process of business model and product development? Is it serving you?
• What do you know about current techniques and experience in the field? Can you evaluate which ideas could work for you?
• Do you have a product roadmap?  Do you know how to put one together and use it?
• Do you know how to navigate your product to a successful launch while minimizing your cost and risk?
• Do you know what it takes to operate and maintain your service while continuing to respond to your customers needs?

…This workshop answers these questions and many more. It leverages our field experience across many projects and many situations

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register By April 1st for our Denver Workshop and take advantage of our Early Bird Pricing

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Registrations By April 1st, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $100 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave100 when registering for SaaS University.

Go to SaaS University Denver Registration Page

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In this article, “Nearshore” refers to outsourcing software development to providers that are located in foreign countries in the same or adjacent time zones or that are geographically close to a client’s home country. For U.S. companies, this term describes outsourcing to providers located in Canada, Mexico and Central and South America. For companies in Western Europe, nearshore providers are logically located in Eastern Europe, the Middle East or North Africa. At Scio, we work primarily with customers in the U.S. using a combination of U.S.-based and nearshore resources from our Delivery Center in Morelia, Mexico.

The other day I was reading an article about the “Experience Economy.” In the language of economists, the Experience Economy is the next step in the sequence from an agrarian economy, to the industrial economy and the more recent service economy. A basic premise of the Experience Economy is that competitive differentiation between service providers will emerge from positive and memorable customer experiences. In this view, customers will begin to take for granted that top-notch quality of service and work products are widely available. They will begin to make purchase decisions and maintain loyalty based on the quality of their experience of working with a service provider.

After considering the subject, I realized that one of the main advantages of working with readily accessible teams is precisely that it helps provide a better customer experience.

I have found that in the context of software product development, given a choice, people invariably prefer to work with local team members (either internal employees or consultants). After all, the ability to interact face to face greatly enhances the richness of communications, which in turn helps productivity and improves quality. It is usually the promise of lower costs that persuade companies to go through the additional effort of working with a remote team.

Although working with a nearshore team is by no means the same as working with an on-site team, it does provide the possibility of much richer communications between all team members than is possible when the remote team is in opposing time zones. For most practical purposes, it resembles very much working with a team in a neighboring city or state.

A typical day for one of our outsourced product development clients starts with the Daily Scrum Meeting (we are an Agile development shop based on Scrum). Our nearshore team joins the client team in a web meeting and conference call where progress is communicated, plans are updated and action items are identified and assigned. The rest of the day goes by with direct communications (through email, instant messaging or phone calls) between individual members of the Scio team and their counterparts on the client team. When issues arise, the combined team is typically able to address them in real time and resolve them quickly. During planning and review sessions, the client and Scio teams can brainstorm and provide feedback to each other to improve the next Sprint (the name given to iterations in Scrum). So, while these interactions are not as rich as working at the same office, they do provide a level of team integration, rapport and ownership that is far superior to what is possible when the remote team gets all their communications through a designated offshore team representative.

The fact that the entire nearshore team is present during the daily Scrum calls means that there is no loss of fidelity in conveying client ideas and requests to the team; they were all there. Both team and individual team member concerns can be addressed directly. Likewise, the ability to communicate and interact in real time (instead of waiting overnight for a response) helps to foster relationships between the client team and the nearshore team, and thus reduces the time required to reach agreements, and overall helps both teams to get the desired results more quickly and satisfactorily.

With a closer geographical location, a closer cultural affinity also typically follows. For example, in Morelia, Mexico, within ten miles of our Delivery Center, there are local franchises of McDonalds, Burger King, Kentucky Fried Chicken, Domino’s Pizza, Subway, Sam’s Club, Applebees, Chili’s, OfficeDepot, OfficeMax, Costco, Walmart, Nextel, BlockBuster, and others. So, while we could discuss whether globalization takes away from the personality of a city, it is also true that in this particular case it helps create a shared context that enhances communications and mutual understanding.

Television is another example of a medium that creates a shared cultural experience. Cable and satellite TV in Mexico play basically the same shows as in their counterparts in the U.S.; even public broadcast TV channels in Mexico play shows like Desperate Housewives and Lost. (Yes, they are one season behind, but the point is that it is another factor that creates a shared context.)

This is not to say that the national cultures involved are exactly the same. There are significant cultural differences between the US and Mexico that come into play and need to be accounted for (see Geert Hofstede’s Cultural Dimensions for a good comparison of different country cultures), but the cultural gap is much smaller than with more distant countries.

Another element that enables a nearshore team to provide a better customer experience is that by working during similar business hours, the quality of life of the client team members is not affected. There is no need for late-night or early-morning conference calls to be able to synch up with the remote team. Likewise, it is not necessary to wait anxiously all day for a remote developer to finally arrive to the office to be able to talk to her about a particular issue.

Granted, since our engagement model may include nearshore resources, my opinion is biased. And I fully recognize that a nearshore location alone is no guarantee for good quality or better results. However, I think that given two providers that are equally capable, where both have proven methodologies, committed team members and a results oriented attitude, but where one is on a similar time zone and the other is in an opposite time zone, the perceived experience of working with the nearshore provider will overall be better than with the offshore provider.

What is your experience? Do you agree?

Postscript:

It has been brought to my attention that in the last few weeks there has been frequent coverage in the media about the violence in the vicinity of the U.S./Mexico border, arising from the war on drugs. This, naturally, can be of concern to those considering nearshore outsourcing in Mexico.

The situation is indeed very serious in that region and without a doubt it is affecting the ability to conduct bi-national business in the area. However, even though it may seem that the whole country is in a state of emergency, in reality the problem is mostly concentrated in a few locations, like Tijuana and Juarez.

Morelia, where our Delivery Center is located, is about 800 miles away from the closest border point with the U.S. Morelia is the capital of the state of Michoacan, and it is pretty much a college and government town of about one million people. Although some incidents have occurred here, life in the city goes on ordinarily, with its characteristic lively, dynamic atmosphere.

A fact of modern life is that there are no completely safe and risk-free places anymore. From the recent terrorist attacks in Mumbai, India, to the attacks in New York, Madrid, and London, it is becoming difficult to think of places where safety can be entirely and permanently guaranteed. Nevertheless, the risk of being the victim of violent acts is still very small compared to the risk posed by car accidents or unhealthy life habits. So, while it is only common sense to stay out of places where violence is rampant, we must all go on with our lives, striving to make the world a better place.

Going back to the issue of working with resources in Mexico, as Datamonitor put it in a recent article, “it would be futile for both outsourcers and their clients to forsake this country in light of recent worrying media reports, considering its clear advantages and history as a delivery hub”.

It has been a long time coming, but we’ve finally gotten our blog in place. We’ve wanted to have a place to speak to the industry and our customers for quite a while. We hope you find the posts here informative, short and useful.

To beat our own drum – we’ve made a lot of changes recently at Scio. We’ve moved to our new Nearshore Development Lab in Morelia, Michoacan (yes, that is in Mexico). We’ve formalized several of our services to meet the needs we’re finding in the market. And yes, we’ve started this blog.

We’re not going to stop there – so stay tuned. Subscribe to our RSS feed or just bookmark us. Thanks!