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

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

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

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

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

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

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

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

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

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

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

Using Innovation Games was very productive for this project.

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

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

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

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

The question I pose in the title of this article is the theme of the podcast we did this month for Haut Tech Conversations. It turned out to be quite a conversation and you can download it and listen to it in its entirety here. Our panel and guest brought up so many excellent points that I’m going to take the time to summarize and extend them in this “post interview” so they are not lost.

Giving credit where it is due: Our guest was Steve Plunkett, CTO of Servitizer. He has studied the concept of delivering services over the Internet and has a depth of understanding and experience few in the field can claim. I recommend his blog as a continuing series of insightful articles on the business of delivering services in an on-demand world.

Giving more depth and points of view, our panel was stellar. Luis Aburto, CEO of Scio Consulting provided a clear summary of the intersection of technology and business concerns that make up service offerings in this field. Mikael Blaisdell of MBaisdell & Associates brought up a range of issues that are rarely if ever considered in planning and developing a service. Lincoln Murphy of Sixteen Ventures broadened the business side of the discussion many times over.

The conversation exceeded my expectations and I encourage you to listen when you can. But I felt that the key points can be easily lost because an hour seems like a long time when you just think about it – when listening to the conversation there is a lot of information coming all at once. So – this series is an attempt to summarize and extend the wealth of insight and ideas we covered.

First – let me cover the title of this article with a few words. The subject of this article is service offerings on the Internet – broadly. This means not just Software as a Service (SaaS) or Platforms (PaaS) or Infrastructure (IaaS) – it includes all the various types of service products available now on a subscription or fee for use basis. This is often referred to as “X”aaS – whatever you might want to put in front of the words “as a Service” and includes the various cloud services and application services extensions for things like billing, metering, integration, etc.

The Gartner Group has recently said we’re at the peak of the hype cycle for these offerings. I agree and I also believe that many services today are “immature” at best as pointed out by a independent study mentioned in a recent article by Dave Rosenberg. That leads to the “trough of disillusionment” as Gartner calls it – when early adopters find the services are not yet where their marketing said they should be and they “push back” against the vendors to deliver at a level consistent with critical business needs.

It is the realization that much of the promise in the XaaS market is still to often just that – a vague promise – that I think united all our guests. The “Service” in many service offerings on the Internet is still poorly defined and poorly delivered, even by major players. And I think i can speak for everyone when I say we are not just standing on the sidelines booing when we say that – we’re all all personally and professionally committed to helping our clients and the industry get to the level of maturity that is necessary for long-term success.

Steve Plunkett kicked off the conversation with some background on “servitization” in industry and an example that struck me – Rolls Royce Aviation provides jet engines for much of the commercial aircraft fleet in service today. But they don’t do it by “selling” the engines – they provide them as a service-based on the number of miles flown, along with all the maintenance and support necessary to operate them, to their customers. When you take an example of a service like that you immediately see that there is more to it than just putting engines on planes – this is the entire operational assurance that goes with the operation of an aircraft and the critical service it is providing its customers. As Steve pointed out – our industry is still very naive when it comes to providing this level of direct services to customers. In the past, it was enough to provide a CD and an install script. It was someone else’s responsibility to properly size, secure, and provide access to the server where it was installed. Service was limited to second or third-level calls to the help desk. But as Phil Wainewright of ZDNet recently pointed out – this isn’t because a service-based approach is new to the industry. If nothing else, it could be said that licensed software started in earnest because of US anti-trust actions against IBM.

The core issue for the industry and SaaS vendors is there is a great lack of understanding when it comes to approaching the business of becoming a service provider, especially for companies that started out as straight-forward “product providers” – meaning those who provide software and a license but don’t provide any of the delivery and operational mechanisms that allow people or other systems to use the application. In fact, it could be said that it is much easier to be a XaaS startup than to transition from being a traditional ISV to SaaS. Going back to the quote from Gartner, if we don’t address this problem, it will greatly impede – if not sink – XaaS as an alternative in the market.

This leads to another point Steve made quite strongly. We are talking about the industry as a whole when we say this. There are a lot of vested interests, that as always in the face of disruptive change (like the current debate on healthcare), will advocate for the least amount of change if not avoid it altogether – the “do nothing option.” These objections come in a lot of forms:

• Product managers will say you can’t control a product development cycle driven by direct customer involvement – as customers expect on the Internet.
• Your Value-Added Reseller (VAR) will tell you there is no way you can sell direct in your market – and maybe they are right – but did you ask if they were ready to become Value-Added-Service Providers? What value will they add to a service-led offering to assure their place in the chain?
• Your IT department will tell you they are not ready to provide the level of service and reliability customers expect for critical line of business applications. But – have they identified the requirements so they can figure out what it takes and who can?
• Your sales group will say they cannot transition from large up front license sales to incremental subscriptions.
• Your marketing group will tell you they cannot imagine how they will operate without the “big bang” of a new feature list for their next trade show.
• Your outsourcing group will tell you they can help you get to where you need to go but they can’t offer a model of interaction and reliability that reflects a more service-led approach.

These same issues are echoed across the industry by naysayers who say security and reliability problems are too great, integration or customization is beyond SaaS, and the business model is too hard to make a profit with. The issue is getting them all to acknowledge that providing a service instead of a packaged application is yes, inherently different from the current “norm” but in many ways just part of the larger business push toward “servitization.” On balance, I think our answer is, “Get over it.” This is a business opportunity and you will either find ways to take advantage of it or get left by the wayside.

In the early days of the industry companies like IBM and HP provided much, if not all the IT services needed by major enterprises. The aforementioned anti-trust action along with the rise of commodity desktop computers and servers provided an alternative that allowed a lower point of entry brought a great deal of disruption that companies like Microsoft took full advantage of as they moved into a place of dominance. Just like today, there were many changes and many players who felt a sense of entitlement in their roles who were ultimately displaced when they couldn’t make the transition.

A big part the change is the place and role of the service provider (the former software vendor). Now end-users look to the service directly when they have questions about how the application is “supposed to function” and internal IT resources (rightfully) expect their direct support role to be measurably diminished. This is the service that is being paid for after all. Gone are the days when the IT service desk made the decision to push the call “up” to the second or third level support with the vendor. Now the IT department expects the calls to come from the vendor and then only when they cannot resolve a local communication or desktop configuration issue. In fact, increasingly the role of the IT department is to set the standards and expectations that fit the business case for a line of business service and then hold the vendor accountable.

Lincoln Murphy pointed out that within servitized products, it is the service that keeps commoditization at bay. A successful vendor becomes more directly involved and responsible to the end-user both as the service provider and the subject matter expert in the field they represent. As Lincoln pointed out – we can go to our personal computer and start “Word 2003″ and it will work just fine – just as it did in 2003. But if Word was online, we would expect it to seamlessly evolve and be something more that it was six years ago – just as iGoogle is a clear line of evolution from the iconic single search box we all came to love when it first began. In the same way, “Infrastructure as a Service” needs to be more than a commoditized server. If it is not – it isn’t going to displace local servers.

And to extend the concept – a service on the Internet has a “responsibility” to carry the model to include the level of communication the delivery medium allows. Is a platform or infrastructure service benefitting you enough if you can’t leverage the ecosystem or community that revolves around it? What is left “off the table” when the community around a line of business application cannot leverage a forum or even list server to communicate best practices, voice concerns and answer questions? These things certainly exist for premise-based products, but they aren’t baked into the business model and certainly not part of the application itself. The question should be – why aren’t they in a XaaS offering?

Moving yet deeper, Lincoln pointed out that XaaS offerings must leverage their ability to monitor their customer interactions with their product to ensure features are of value and meeting customer expectations. Security concerns aside, generalized usage metadata allows service providers a level of understanding of user interaction. Rather than shying away from monitoring customers, it is a responsibility to users to ensure the service will continue to deliver value and to the brand to ensure it stays ahead of competitive offerings.

This means an XaaS offering has to be much more than a new technology. In fact, I would have to say marketing any XaaS product as a technology alone is an error. Of course, the delivery system itself is technical. The expertise and services that are on top of the delivery are enabled by technology, but if they do not stand on their own, they cannot go beyond simply surviving and move to thriving. An excellent product without the technical underpinnings that provide reliability and scalability will fail to reach its potential. In the same way, the mediocre product with excellent technology will be replaced by competitors in no time, especially when that product is delivered on the Internet. There is simply no real barrier to prevent it.

With that we have set the stage to get deeper into the conversation with Mikael Blaisedell taking us into another aspect of the question – what does “as a Service” really mean? But, this article has reached as much length as I think readers can handle so you will have to join us in Part 2 of our series or – download and listen to the podcast. And – feel free to extend the conversation in your own way – here in comments or on your own blog. We’ll be listening…