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.

In part one of this series, we proposed two situations that are occurring in this tough economy:

• Startups with experienced founders and a strong product idea for a new software application but limited funds and time to build a team.
• ISVs with existing software products who are faced with dwindling sales, lowered product development budgets and increased pressure to roll out new versions and extensions for their product line.

We posed outsourced product development (OPD) as one possible solution, but also exposed a few of significant risks involved. So what issues do you have to consider when judging OPD vendors?

According to the CTO forum – one of the biggest concerns is intellectual property (IP) security. The second is that when engaging an “end-to-end” consultancy that also provides software development, product development may not be a core practice within their services.

I would say there should be several other concerns that are generally only exposed by actually going down the OPD road. IP security and practice development are certainly important. Covering those questions first, what would an experienced product manager would also consider before engaging an OPD vendor? -

• Is IP security sufficiently covered in both national laws and treaties? Is it covered in the standard contractual language found in the vendor’s agreements? Do the vendor’s internal development practices reflect the difference between “best practices” – common base elements in code development and outright code copying between customer projects?
• Is the vendor really aware of product development disciplines, aware of best practices as they are applied to software products, and able to work collaboratively with the in-house team? More than that – in the current economy – can the vendor approach the project collaboratively using Agile techniques so that results can be seen early and judged before the project goes too far off track? This applies across the entire product development cycle. Agile techniques provide early prototyping, clear identification of in-house “product owners” and validation of concepts at points where they can be assessed against the product requirements and roadmap.
• Is the vendor’s team stable, experienced and available? Can you interview proposed team members? Are their language skills and understanding of your business culture up to your standards? Many times proposals are sent with a pile of “representative resumes” which may or may not actually represent the team offered when the contract is signed. Can you specify a dedicated team that will be available for on-going work, enhancements, bug fixes, and maintenance? Switching team members in mid-stream is sometimes more difficult to hand with remote teams than it is with in-house.
• What is their QA and release system? If the vendor is handling several projects – test and release may be a very busy asset in the company that is quite separate from development. Understanding the differences between various types of business models (licensed, downloadable, on-demand, etc) and the impact of releases on each time is critical. How are bugs handled? How transparent are their results? How complete is their testing cycle?
• Is collaboration a core value within the team? Does the vendor have the tools, practices and procedures in place to provide the platform necessary for good collaboration?
• How will collaboration actually play out? Typically, offshore that are several time zones away teams will say, “we are working while you are sleeping” which indicates a 24 hour working cycle. But how is collaboration between the remote team and the in-house team really taking place? If it is limited to emails and voice mails the messages can easily end up in a frustrating cycle of cross communication. Many offshore vendors will provide a project manager with overlapping hours for both the in-house team and the remote team. This can still lead to a “telephone game” syndrome where the remote team is never completely “in the loop.” Bringing the remote team or project manager on site for a period of time can be difficult and costly if they are several time zones away, which lowers the value of an outsourced solution. Consideration of a national or nearshore provider should be part of the list to evaluate the approaches to this issue. In full disclosure, Scio is a nearshore provider to the Western hemisphere, but is important consideration none the less. Throwing critical product development work “over the wall” is difficult process to manage well regardless so any improvements that can be made are worth evaluating.
• And in line with evaluation – does the vendor offer a range of engagement options that allow you to both look at your needs in discrete sections and evaluate the team, the approach and deliverables in a way that you can avoid bitting off more than you can chew? If the first response back from a vendor is an end-to-end proposal – are there ways to do shorter, tighter engagements that will allow you to see how the team works and judge if it is a good match? Well-defined, short engagements that will still give you useful deliverables a good way to “move the ball ahead,” avoid risk and get a feeling for what you are getting into.
• Is the development environment open and flexible? If you want your developers to work “side-by-side” with the remote team, can they work and share a common environment and code base? Even if you are not a developer by trade, is the work assignment system open and clear so you can understand what is currently in work and what is in the queue?
• How well versed is the vendor team in the technologies you need to employ? Can they offer a range of approaches with clear value cases for each? If your project involves collaboration with your in-house team, it is critical that the technologies and environments used leverage your teams knowledge base. A good prospect will be clear about their domain and will place boundaries around what is in their sphere and will take more time to work with. Limited experience may not always be a disqualifying factor if the team is aware of their limitations and can take appropriate measures to remediate, but simply indicating “we can do anything” can be dangerous.
• How much attention will your project get from your OPD vendor? If your project requires a team of five or ten, will it be considered a priority with a vendor that has more than 1,000 staff members? Feeling comfortable with the level of interaction you’re going to have with your vendor has a lot to do with how important your project is to them in the “big scheme of things.” If typical team sizes range increments of 10′s or 100′s you have to be concerned about how dedicated your team will actually be.

So – with that insight, is OPD for everyone? No. Does it have any more or less risk than other outsourcing? No. If you understand the risks, you can deal with them by both planning projects properly and selecting the right partner. And in the end, that is the point. An OPD vendor needs to be a team you feel comfortable approaching as a partner. There are many companies today that have only a handful of direct staff members who do quite well with an end-to-end OPD team. They concentrate on their market, sales, customer satisfaction and the leadership of their product development teams – regardless of where they are. They have learned to work fully with product development “in the cloud.”

Useful? Copy, paste and Tweet It!

OPD – Product Development “In the Cloud” http://bit.ly/32P3

This is a tough time to be starting a business, but many people in technology or with deep industry experience who have been recently laid off are doing just that. Companies with existing product lines are facing tough choices too. Can you afford to sit on your hands while your sales dwindle? So let’s imagine you’re one of those folks…

A little depressing in these times but...

You’ve just been laid off. You have great experience in your field. You have an idea of what you want to do. You think a cloud/on-demand business is the way to implement the idea, especially in this economy. You know the venture capital market is pretty tight for new startups (!!!). Between the severance you got when you walked out the door, money from the three F’s (Friends, Family & Fools), and what you might be able to get from a second on the house (if the banks will cooperate) you could get going, but from what you’ve heard, you don’t have anywhere near the $3-4 million startups used to get in their “first round.”

Or let’s take the another way: You have an existing software product. With the economy in the tank, your license renewals and new sales are not meeting quota and the budget you had for your next version is no longer possible. You really need the boost the new modules in your product plan could give your sales, but it looks like you’re just going to have to wait it out and cut costs. Meanwhile a competitor, that released their latest version in early summer, is also struggling, but at least they are getting sales – by targeting your base.

In one way, both these folks are faced with the same problem – they have to innovate their way out of a tough time. Their solutions are likely to be somewhat different, but their underlying issues are much the same. Hiring staff, heading off on a new venture that can leverage their experience and the issues in this economy seems to be beyond their reach. In the end though, the smart ones will innovate their way out of it.

I read an article today in Manufacturing Business Technology from Sidney Hill. He alternatively takes the side of the potential customers and the ISVs – and points out that:

“This will indeed be good for a number of the companies on our emerging vendors list—companies like Plexus Systems, which offers a SaaS-based ERP suite; and New Momentum, with a SaaS-based product that helps manufacturers reduce myriad supply chain risk factors.

If you read our emerging vendors coverage, you will notice that the SaaS model is not the only innovation in the manufacturing software space. You’ll learn about companies like River Logic, a newer vendor offering a solution with a new twist on supply chain optimization; and Zontec, an established vendor of statistical process control (SPC) software that now makes SPC results available through mobile devices like the iPhone.

This issue proves that innovation continues in all economic climates. Let’s just hope that the Emergency Economic Stabilization Act of 2008 clears this current storm sooner rather than later.”

The smart approaches we’ve mentioned before, building to the long tail. knowing your market, and developing a strong, service-based approach remain key and will save cash, but there is one additional tool which is also worth consideration – many companies today are leveraging outsourcing services for product development. It is certainly beating our own drum, it is in fact one of our core services. But from that point of view, there are some important points to consider before going down this road.

Companies that provide Outsourced Product Development (OPD) for software-based products fall into two broad categories:

• Classic product management consulting for the front end of the project – market analysis, product definition, feature prioritization, and specification phases.
• “End-to-end” OPD practices within software development consultancies that offer at least some portion of the front end (there is a lot of variance) tied to the in-house software development team.

Each approach has its downsides…

A management consulting approach tends to be more expensive for the front end, but it may offer specialized market analysis and vertical expertise not available elsewhere. Once the “front-end” part of the project is done, you are then faced with either developing the resulting product specs in-house or finding a development team that can translate the product specs into technical specs and project plans. That can involve several iterations as both the product specs and the development plans are rationalized. Depending on the approach the consultancy uses, your team may be less involved than you would like. Time and cost constraints can limit collaboration with the management consulting team.

An end-to-end practice can greatly streamline the translation of the product specs to technical specs and project plans. If the development team is integrated into the product definition process, many of the downsides of projecting impractical features or configurations can be exposed early. But, if the OPD team is remote and not easily accessible during the process – poor communication and the lack of collaboration with the in-house team can result in the proverbial “camel – a horse designed by a committee” situation. Worse, if the development is begun before the problems are completely understood, the expensive camels can be packed up and ready for market before you realize what is in the box. And yes… It happens a lot more than we like to think.

But let’s say you’re not scared off by these possible downsides. You’ve been around the block a few times and you know that issue mitigation is necessary regardless of how you approach the problem. The key is knowing the issues and making appropriate judgements as you go along. Is there a simple bulleted list of issues to watch for that would help make a judgement?

Yes – there is. And you can find it in the second installment in this series as we explore the critical considerations you need to know when selecting an OPD team. Join us for the second article in this series: OPD – Product Development “In the Cloud.”

Useful? Copy, paste and Tweet It!

When the Going Gets Tough – Innovate!! http://bit.ly/4GnV