enthiosys agile product management - agile product management, motivated from within

You Want Actionable, Not Final

 

We’ve just launched Innovation Games online at www.innovationgames.com. YEAH. It has been a labor of love. And while our fledgling software needs so many improvements in so many dimensions, we’re still amazed at the results our games can produce.

One of the design principles that we used in creating innovationgames.com occurred when I found myself editing a document a client had emailed that had the word “final” in the document name.

• Why do people continue to put the world “final” into their “heavy desktop” document names, especially when we know that chances are pretty good we’re going to keep editing the document?
• Why don’t we use the word “final” in the documents and artifacts that we create in the cloud?

I invite you to think about this for a few minutes before reading further. I’ve been thinking about it quite a bit, and, like I stated earlier, the realizations of what this means has informed the design of innovationgames.com.Here are some of the reasons I brainstormed about why people put the word “final” into documents:

• They want to send a signal to others that they are “finished” (more on this later).
• Perhaps more importantly, they want to signal to others that trivial changes or improvements are no longer accepted. Instead, only really big “problems” are going to motivate additional edits.
• They don’t have good versioning tools, so they need to embed versioning information into the file name (Note: I do this quite a lot).
• They want to make it easy to find the last “version”.

I think the big issue is that we substitute the word “final” when we really mean “actionable”.

Consider a business plan. I’ve never written a truly “final” business plan. I’ve written business plans that were actionable, in that they motivated an organization to take action against the information in the plan. But they weren’t final.

I think this means that instead of saying: “Here is our final business plan. Let’s fund this product / project.”, we should train ourselves to instead say: “Here is an actionable business plan. And the action we should take is funding this product / product.”Because in both cases we know that we’re going to update the business plan with new information.

But something seems to be happening that is profoundly great about the cloud. We’re starting to see people adjust their workflows to be more about actionable artifacts than final artifacts. They create something online, interact it with it, and then take action. And then, based on the results of that action, they can return to that artifact, and continue working on it.

The difference between actionable and final has been carefully woven into innovationgames.com in a way that supports creating stable, “final” artifacts that enable you to take action, and then providing tools to enable you to continue working on these artifacts when “final” isn’t what you want. To illustrate, let’s say that your Parker, our Product Manager persona from the Agile2009 conference, and you want to solicit “big ideas” for potential inclusion in your product roadmap from your customers. Since a roadmap is a “living” (actionable) document, you want to structure your work so that you can both obtain feedback, integrate and interpret the feedback into an actionable result, and then, in the future, return to that result and do it again (and again, and again).

We support this workflow at innovationgames.com as follows. The first phase is preparing a game definition. (I decided to put the workflow of images for this at the end of the document).

• Parker logs into innovationgames.com and creates a Prune the Product Tree game. Prune the Product Tree is our game for enabling Product Managers to visually collaborate with their customers.
• Parker selects a tree image and the number of items.
• Parker places any initial items on the tree. These items represent ideas that Parker may already have on his roadmap.

Parker can continue to edit this tree until he is ready to play. Eventually, though, Parker will want to take the next step: inviting customers to play his game.

• Parker logs into innovationgames.com and creates a Party. A Party is a form of game play that allows Parker to invite specifically named customers to play the game.
• Once Parker starts the game, customers can add, move, and even delete the items that Parker and other players have created, visually collaborating on a tree that represents how they think product should grow.
• We’ve found that a game takes about an hour to play, and participants clearly signal when they’re done. Once they’re done, Parker stops the game.
• Once the game is stopped the results are no longer editable.

Once the game has started, the game definition is no longer editable. This allows Parker to play the same game as many times as he wants, with each group of customers always seeing the same starting condition.

The final phase is post-processing the results. To support Parker in this phase we’ve created interpretations. Here is how they work.

• Parker logs into innovationgames.com. He selects any number of game results and creates an interpretation.
• The system merges the results of each game into a single, editable artifact.
• Parker can now leverage the results and ideas of his customers, moving items around as needed to create an actionable result.

Oh – and this is really cool: Parker can select any game result or any interpretation and clone it to create a new game definition that can be played with other customers. Which means that Parker can take action against his interpretation and return to the same system to start the process again using the foundation of the previous results. 

To recap:

• Game definitions are editable until they are played.
• Game results are never editable because they represent actual player behavior.
• Game interpretations are formed by merging one or more game results and are editable.
• Any game result or interpretation can be cloned to create a new game definition.

This means:

• You can start with as much or as little detail as you want in your game definition.
• You can play the game as many times with internal and external stakeholders / customers to obtain rich feedback from targeted customers.
• You can create one or more interpretations of the results, exploring the best ways to mine and leverage the data.
• You can take action on your interpretation and use it as the foundation for new games in the future.

We think that you want actionable, not final. And we’re going to work hard to make that as actionable as we can. Because good software is never final. It is just periodically released.

Here the workflow I described in screen shots.

Parker creating the initial game:

Parker creating initial items:

Playing the game:

Parker looks at where items are placed:

Parker creating an interpretation:

Return to insights-tools