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!