Full disclaimer: VersionOne has been a client of Enthiosys. We’ve helped them prioritize their product backlog with Innovation Games® online. Several VersionOne employees are trained Innovation Games® facilitators. And, VersionOne employees have also attended a variety of classes I’ve taught in my role as a Strategic Advisor on Product Management and Strategy for OpenView Partners.

More importantly, I appreciated exploring Bob’s vision for how this offering will evolve. Like all good product managers,  Bob has some excellent ideas on how to extend the initial version. His vision is compelling, and I was able to directly advocate for many of the more advanced roadmapping techniques that we use with our clients, including radar roadmaps and variable time scales. Bob absorbed all of this.

I am encouraged by what I saw and am looking forward to seeing how their offering will evolve.

Certification is Discrimination

[we worked then at SmartPatents, Inc. which was later renamed to Aurigin Systems, Inc., and acquired by Thomson].

“So here’s the question for you: if you and your colleagues are about to have massive
licensing and certification restrictions imposed upon your ability to call yourself a
programmer, and upon the way you carry out your trade, what things would be most
important to include or exclude for such certification regulations? If you don’t express an
opinion, then you’ve abdicated and you’ll just have to live with whatever bone-headed
rules the politicians come up with.”
— Ed Yourdon, private email to Luke Hohmann

Introduction

• The most important thing is not what is certified or licensed, but who is subject to it, who grants it, and who controls that process.


• Different communities and application domains within the software industry have very different views about what should constitute certification or licensing for them.


• While technical people tend to think of certification in terms of competence, the issue will more likely be forced upon us as a way to promote accountability for work, rather than good work, per se.


• Many parts of our field are still too diverse, and changing too quickly to achieve consensus about what constitutes competence.


• When software people are licensed, they will take far less risk, software will cost much more, and technology development will slow to a crawl. Is that a better world?

Certification != Licensing

A certification is a statement of fact. It provides a basis for making other decisions. A license is a granted privilege. Licensing provides control.

We are not opposed to certification or licensing… in principle. It’s hard to be opposed to the basic idea of certification or licensing. Friendship, for example, involves a form of certification (“You’re okay in my book…”). By publishing this article, Ed has “certified” that it meets the editorial requirements for American Programmer. We grant “licenses” in the form of privileges to our co-workers or spouses. By sending this article to Ed, we granted him a license to publish it. The basic utility of certification and licensing concepts on a personal level are beyond question.

The controversy begins when these ideas are pursued by companies, industries, or governments; when we have to decide as a group how to evaluate and regulate ourselves. That’s when discrimination becomes a matter of grave concern and debate. Formal certification and licensing of programmers means creating what is essentially a new professional ruling class.

Certain groups of people are bound to be disenfranchised by that process, and some of the “in crowd” are bound to use their franchise to as a way to drive up the price of their services. The obstetric profession is a good example of this. After decades of treating all pregnancies as if they were serious illnesses, and all midwives as if they were criminals, research is finally showing that, for the majority of women, having a baby at home with the aid of a trained midwife is actually safer than going to the hospital (note that professional midwives pre-qualify their patients and work with medical backup nearby to handle serious complications). Since the majority of pregnant women are healthy enough to expect an uncomplicated labor, the obstetric profession would be in for big competition if more of their patients were aware of this research. Midwives make as little as $10,000 a year, compared to the $150,000-$200,000 salaries of obstetricians.

In business, it’s impossible to live without the raw concepts of certification and licensing. But realize that in practice those concepts require us to discriminate between who is in and who is out.

On what basis to license?

Competency: We might give licenses to practice only to those people who meet a minimum standard of competence. How do we certify competence? A “competency certified” practitioner has passed some sort of test that verifies his or her ability to perform. Genuine competency certification is rare. More likely, certification means that the practitioner has merely survived some sort of obstacle course that is presumed to be related to competence. They took enough credit hours to earn a degree, or they passed tests that required the mere recitation of facts, rather than prove their ability to apply that knowledge to real problems (e.g. the American Society for Quality’s Certified Software Quality Engineer program requires eight years of experience and passing a multiple choice test).

Obstacle-course certification is popular because it’s much less expensive to verify, and it involves far less subjective judgment than does the certific ation of actual competency. Although obstacle -course certification is not the same as certified competency, we worry that those not intimately familiar with the domain will mistake such a certification for a guarantee of genuine competence or even professionalism. In that way, certification becomes mere tokenism that distracts us from the pursuit of excellence. There are professions, such as medicine and law, that work very hard to assure that their certification processes are related to competence. Is our field ready to work that hard?

Our biggest concern about competency certification is the glacial pace at which such certification standards evolve. Once codified, so many vested interests vie for control of the standard that innovation becomes virtually impossible, and real change is driven not by the technical community at large, but rather by bureaucrats and professional lobbyists.

Accountability: We could also grant licenses based upon a certification of accountability sidestepping many of the problems of competency-based certification. Accountability certification may involve nothing more than a demonstrated understanding of a programmer’s responsibilities under the law (this should be simple, since there are so few to understand!), and perhaps professional liability insurance. We can imagine, in this wild-eyed Y2K season, a law being passed that required programmers to be listed in a national registry, and to uphold a code of ethics, such as that of the IEEE or ACM.

The ACM code is very demanding. It would certainly introduce interesting new dynamics into software projects if each programmer were legally obligated to adhere to it. One effect might be that programmers would lose any incentive for low-balling schedules, and project managers would get much more visible feedback about the realism of their scheduling suggestions (“You want to ship this next week? First I must advise you of the potential risks in accordance with section 2.5 of the ACM code.”). Another effect might be that some programmers will be more passionate about team programming (in order to distribute their legal risk) or more passionately opposed to it (in order not to be held liable for someone else’s mistakes). We’d fully expect malpractice insurance for programmers to do booming business, and software companies would have to pick up the tab (and pass it on the their customers). Independent programming consultants and small software companies would be hard hit by the new expenses.

Again, if we accept Ed’s premise that certification and licensing will be forced upon us by an angry public, then accountability certification seems to us to address the matter more directly than does certification based on competency.

Money: Licenses could simply be purchased. If they were expensive enough, say $10,000 a year, a lot of money would be generated that could go to further the development of our craft. Expensive licenses would encourage the development of software development guilds who would pay for the licenses on behalf of their members. These guilds would have tremendous influence over the kind of software that got developed and over programming practices. Expensive licenses would also fuel a thriving underground of unlicensed programmers who would telecommute, perhaps from offshore, or work for fly-by-night contracting firms. Similarly illegal labor already plays an important part in the agriculture and garment industries.

Other: We could grant a license based on some other attribute, such as gender or age. Sounds inconceivable, right? Well, it wasn’t all that long ago that it was considered acceptable practice to discriminate based on ethnicity. Who is to say that in the mad dash for licensing that we won’t pick an equally absurd attribute by which we license programmers.

It ain’t what, it’s who

Who is “we”? There is no consensus on which set of people represent the “in” and the “out” crowd in the software industry. In Silicon Valley, the “in” crowd is certainly not the creators or followers of the SEI-CMM, while in Pittsburgh “Good Enough Software” are fighting words.

This industry is composed of many different communities: academic research, embedded systems, MIS, medical systems, system software, telecommunications, utilities, games, multimedia, client server enterprise systems, military, government systems. The list goes on. We don’t yet have even a consensus about what communities even exist, much less a consensus on what standards apply to them. One of us (Bach) was a member of the ASQ CSQE team team, and was surprised to find that the standard was designed around a model of one unified field, without reflecting our diversity at all (Cem Kaner, another member of the team, discusses that process in his paper Software Negligence and Testing Coverage, Proceedings of STAR96, Orlando, Fl., May 1996, see http://www.kaner.com). But we know that technologies, quality standards, processes, market dynamics and cultures vary substantially between communities. Thus, it appears hopeless to us that a universally meaningful form of competency certification could be achieved. Each community will be on its own.

Who should be accountable?

Good luck! We suspect that efforts to certify and license programmers that do not also address the issues of software management, documentation, component suppliers, SQA, SCM, technical support, and software quality itself will do little to address the fundamental issue of bad software.

How licensing and certification might affect you

Then again, maybe it won’t matter much. There are already laws under which you can be sued for negligence, even without any certification, licensing, or formal recognition as a professional. Yet, in the history of the US, there is record of only five such lawsuits. Is Ed stirring up an empty hornets’ nest with this question? Isn’t the real issue, no matter how you consider this issue, your personal ethics and your own sense of professionalism?

Will we pay?

The whole concept of certification and licensing may not be an issue at all once the rage and frustration of Y2K has died down. The extra costs will bring people back to Earth. If I am a certified software developer, I’m going to expect to be paid more money. If I am licensed, I’m going to take more time in creating software systems to ensure that I’m not sued for malpractice.

Will the marketplace accept these greater costs? Does the world really want us to slow down and stop cutting corners? For certain problem domains, yes, it will. But for many others, perhaps even most others, the answer is “No.” The phenomenal development of Internet technology is a testament to the value of speculative, chaotic innovation. It has its place.

So even if the software industry is certifiable (Webster’s: “to officially attest to the insanity of”) the inmates are going run the asylum for a while to come.

Acknowledgements

The authors thank Cem Kaner for his review and critique.

[At the time of writing, the author’s biographies were:]
James Bach is the Manager of Software Process Support at SmartPatents, Inc., the leading provider of analytical software tools for intellectual property management. James is also the editor of the IEEE Computer Software Realities department. Author of dozens of technical articles, he
can be reached at j.bach@computer.org.

Luke Hohmann is Vice President of Engineering at SmartPatents, Inc., the leading provider of analytical software tools for intellectual property management. Author of Journey of the Software Professional: A Sociology of Software Development, he can be reached through his
web site at http://members.aol.com/lhohmann.

The Slippery Slope to Less Innovation

When an executive calls us looking for help, we typically ask a few broad questions. Executives at organizations who have been practicing Agile for some time usually report that quality is greatly improved, the development organization is happier, releases are more predictable, and the overall organization, including such things as putting software into production, just runs more efficiently.

So what’s wrong? When I ask executives “Are you being innovative?” – meaning – are you creating and delivering “big chunk” innovations that continue to establish or maintain market leading positions, the executives typically exclaim “That’s it! We’re more Agile, but we’re less innovative!”. In one case, an executive admitted that he didn’t think  they’d delivered anything genuinely innovative in over a year. That’s unacceptable, and it was a good thing that this executives “spidey sense” tripped.

The slippery slope to less innovation begins when teams adopt many common – and very good agile practices: Creating and prioritizing a backlog and producing potentially shippable, working software in 2-4 week time boxes (in Scrum-speak, a Sprint).

Sounds good, right?

Well, it can be more than good. It can be great. Teams creating working software in predictable chunks? What can be better than that?

Innovation is Not Predictable

One problem is that innovation isn’t predictable. It is a bit messy. As your teams gets better and better at hitting every iteration, they can inadvertently start to favor small pieces of work that always get done. Heck – we tell people that SMALL stuff is good and have a wonderful acronym invented by Bill Wake: INVEST. So, people create small stuff. Big chunky innovations get dropped. They are, after all, risky. They don’t always work. They can negatively impact velocity. In fairness, it is entirely understandable that teams start focus on small, safe stuff.

From a product improvement perspective, customers do indeed enjoy small, incremental improvements along a number of dimensions. My friend Jeff Patton teaches this brilliantly when he explains why iterations are critical to successful Agile development.

Unfortunately, while customers often enjoy small, incremental improvements, what they really want are “big chunky innovations” to solve their ever-changing landscape of hard problems. And big chunky innovations are not small, incremental, are not iterative, and don’t fit into one sprint. (And don’t waste your time flaming me about the idea that customers enjoy small improvements. Sure, we all enjoy small improvements to our favorite applications. But that’s not enough. And you know it.).

Epics are NOT big, chunky innovations

The Agile community has readily adopted the term “epic” to mean something that takes longer than a sprint. Typically decomposed into many user stories and related requirements (in creating our online Innovation Games® some of our own epics have exploded into more than 50 user stories and even more related requirements), epics are important for capturing big pieces of work.

But epics are not equivalent to the big, chunky innovations that I’m talking about.

Roadmaps capture big, chunky innovations

The big, chunky innovations that I’m talking about are best captured by your roadmap. Which is needed, because your roadmap is your antidote to the lack of innovation that can creep into Agile teams.

Which brings me full circle to the start of this post. Inevitably, when executives tell me that their Agile teams are being less innovative, they also tell me that they don’t have a roadmap, or that their roadmap only extends a meager 6 months into the future.

Keep all the power and greatness of Agile AND maintain your ability to deliver big, chunky, innovations into your market. Create a market-driven agile roadmap, make sure it captures big, chunky innovations, and use it as the first step in setting the direction of your team.

Finally, don’t get so hung up on “perfect” velocity. In fact, if your teams are always hitting “done, done” in every iteration, start to worry.

PS. Thanks to my friend Ron Lunde for pointing out much needed edits to the original post.

Team: Having worked with me since 2004, first as a consultant, then as President of Enthiosys, starting in 2006, Scott Gilbert has been invaluable in growing Enthiosys into the leading Agile Product Management Consulting firm it is today.  After years of helping other companies and teams understand and succeed with Agile, he is going back into a senior product management role where he can practice what he’s been preaching, test out new ideas and move the Agile PM tribe forward.  This fits with the Enthiosys’ core value of being able to speak from experience, not just quote ideas and theories created by others.

Rich Mironov also excelled during his tenure as CMO for the firm. Rich was instrumental in honing our service offerings into a cohesive and coordinated set of engagements, improving our messaging, and providing terrific services to our clients. Rich is returning to his solo consulting practice, where he’ll continue to write Product Bytes, champion agile product management causes and work with Enthiosys on selected projects. On a personal note, I was proud to have Enthiosys sponsor the production and publication of Rich’s book The Art of Product Management. Rich continues to provide product management leadership for the upcoming Product Camp Silicon Valley and the product management stage at Agile 2010 – both of which were started and nurtured through Enthiosys. It is especially gratifying to see the amazing and rapid growth of Product Camps around the world.

I sincerely thank Scott and Rich for all of the help they have provided me and the firm during their time with the company and I wish them both the best in their future endeavors.

I welcome Jason Tanner to the staff as President. Jason spent part of 2008 and all of 2009 in the field serving two of our largest customers helping them transition to Agile practices. Jason lived the transition from a ‘traditional’ product manager to an Agile Product Manager and has leveraged his experiences into quality service to our clients. Jason has embraced Innovation Games® in creative ways to increase collaboration for clients and other groups from the Product Camp RTP to the DFW Scrum Users Group.

Vision: While we will maintain a focus on Agile Product Management, this year we plan to expand our scope to Agile product delivery. In 2009, our customers asked us for more than product management consulting. They desired more complete services to build and start exceptional teams with great product managers and terrific coaches. They asked for assistance with development and testing practices with longer time horizons for continuous improvement. As a result, we broadened our network of senior consultants to provide a targeted combination of services to delight our customers. This subtle and important evolution will continue this year. Our offerings will grow with a new selection of services, training courses and content to address customer needs. You should also expect to see us continue to leverage our partners to increase our ability to deliver a full suite of services. Our vision also include increasing the emphasis on our training offerings.

Structure: We launched online Innovation Games® last year and grew the games team to continue enhancing the platform while increasing adoption of the games. Along the way, we started to notice that our clients and other consultants were using the games to solve a variety of serious problems in areas of sales management & execution and corporate strategy—in themselves novel and exciting uses of the games. To better position ourselves to capture these emerging growth opportunities, this year we will spin out The Innovation Games® Company as a separate business entity.

In many ways, these changes reflect the natural evolution and growth of our organization, including the natural growth of Innovation Games®. We’re very excited about 2010, and look forward to serving you as you create breakthrough products and services.

Joel’s latest post, Figuring out what your company is all about is just awesome. He references another of my favorite bloggers and authors, Kathy Sierra, who, as Joel describes, challenges us to explain our mission in the in the form, “We help $TYPE_OF_PERSON be awesome at $THING”.

Here at Enthiosys, we can answer that simply and directly: We help Product Managers be awesome at Agile Product Management.

When we focus on our Innovation Games practice area, we find that who we help and how we help them be awesome becomes even richer.

• Innovation Games help sales teams develop the deep customer relationships that result in sustainable, mutually beneficial transactions.

• Innovation Games help strategic planning teams develop their strategy, and then the games help these teams negotiate and select the projects that align most effectively to the firms strategy.

• Innovation Games help corporate leaders who want to engage their global workforcein tackling the issues that are challenging us all through serious, collaborative play.

• Innovation Games help market researchers generate the insights that result in breakthrough products and services.

• Innovation Games help product teams create richer, more accurate project plans, improve their development processes, and manage the evolution of their products and services.

Whew! That’s a lot! Stay tuned, because we’ll be expanding on how our games accomplish all of these things over the next few months.

I’ll start with my memories of the Apple Knowledge Navigator, in which a handsome (of course) and unbelievably smart (naturally) actor plays a university professor who collaborates with a colleague to develop and share some critical new insights into global warming, to the plethora of tools that are being created that enable “instantaneous” collaboration with a group of people. As is common in these videos, the collaboration between the professor and his colleague:

• happens in real-time;

• with a colleague who is completely ready for the collaboration (was she psychic?);

• where both of them have all of the information they need, easily obtained available with powerful, context driven, natural language search.

Now, of course I can’t really fault Apple for creating a brilliant vision of the future of collaborative work. This video was, and still is, an amazing vision of the future, not unlike Doug Engelbart’s original demonstration of the collaborative work in 1968 (which, in many ways ways, we’ve only just begun to realize in our systems).

Variations of this notion of collaborative work can be seen in some of the visions about large scale collaborative work and crowdsourcing, including Wikipedia. Note though, that these collaborations don’t occur in real-time, and that the number of people involved in the collaboration are typically small even though the potential pool of collaborators is large (e.g, lots of editors at Wikipedia, but only a small fraction of them edit a given article). That’s OK, because the meaningful communication that is required for collaborative work breaks down after 8 people or so are involved in the work.

If we take a step back, I’m noticing a fairly large number of incorrect assumptions about ad hoc collaboration. The moment you identify the need to collaborate with others to solve a problem is rarely the moment you’re ready to collaborate with others about the “thing” that you want to collaborate about. When the task is complex, to effectively collaborate you need to create the right context and prepare yourself and your collaborators so that you can collaborate effectively. You also need to give some thought to who is going to be involved, the goals that you’ve established (e.g., why are you working as a group?) and the tools that you’re going to use. You’ve got to schedule time for people to prepare (research, reflect), collaborate, and then, as needed, continue to take action against the goals.

All of this taken together means that for many “ad hoc collaborative tasks” (aka, unstructured work flow), we’re simply not going to be running around with our PDAs, instantly ready to  join forces and collaborate. Instead, we’re going to see an increasingly powerful set of tools that enable us to collaborate more effectively, which is good. But not instantaneously.

Before you think I’m dissing your favorite collaborative tool, think again:  start with a user-centered design perspective of what’s happening in the moment of the collaborative process. When I’m collaborating, I really do enjoy the many tools that have been developed to help me, from simple white boards to much more sophisticated solutions. And, I fully expect that collaborative technologies will continue to evolve to make it really easy for me to select and use the right tool in the moment of collaboration, just like I expect scheduling systems to become increasingly smart about recommending the right participants and coordinating our busy schedules. But that’s a really, really different concept than ad hoc, instantaneous collaboration.

Here is how these concepts have influenced the design of Innovation Games online both now, and in the future.

• The most important influence is that we don’t provide just one game and expect it to solve all of your needs. We provide several different in-person and online games, each tuned to the problem you’re trying to solve. To help you select the right game we provide books, educational classes, a wonderfully supportive LinkedIn group, and other forums for discussion on planning, playing, and post-processing the results of the right game for your needs.

• Our system provides a specific scheduling mechanism where planners can schedule the games with participants. This is important because many times game participants simply can’t join a game on the fly. They need time to prepare for the game. And coordinating the schedules of players can be pretty demanding. And while this scheduling mechanism works well enough, we’ve also had requests for “in the moment” / “instantaneous” games. This is natural evolution of our offering, and we’ve got this on our roadmap.

• We also have been struck that planning for an Innovation Game is NOT a solitary activity. Instead, planning for a game is also a collaborative game. So, we’re going to improve our planning process to allow for collaboration.

• We already provide tools to help planners reflect and process the results of games. I’ve described our approach for this here.

• We enable facilitators to prepare a group for playing a game by assembling the group in a lobby before the game begins. This helps create a better result by providing the facilitator with a means to explain the goals of the game, answer any questions about the structure / goals of the game, and prepare the players.

As you consider how the Collaborative Web is going to affect your business, keep in mind that the future of work is NOT going to be based on interrupt driven, ad hoc, and semi-randomized collaboration. We’re still going to have to define goals and select tools that help us achieve these goals, schedule meetings, help people prepare for the act of collaborating, help them in performing the work, and so forth.

I recently worked on a client project where they asked me: “What is a market problem?” I was a bit surprised by this answer, since the seems a bit obvious. Yet, as we talked, I realized that many of us talk about market problems without really clarifying what we mean by the term. This post attempts to clarify these terms, explain why market problems are indeed important, and suggest some ways in which you can act in relationship to these concepts. I look forward to your feedback.

Let’s start with some definitions.

• A problem is a situation, matter, or person that presents perplexity or difficulty [http://www.thefreedictionary.com/problem].
• With that foundation, let’s call a customer problem a problem that you’ve discovered or validated through research. While we’d prefer that the discovery process includes primary research (such as through the Innovation Games The Apprentice or Me and My Shadow), we can certainly accept that smart, experienced people can leverage their experience to hypothesize about potential customer problems. Of course, because they are smart and experienced, they also validate their hypothesis: confirming with at least one person outside their organization indeed has this problem.
• A market problem is a problem that you’ve validated as being held by enough people who are willing to pay enough money to get it solved to justify attempting to solve it once you’ve further confirmed that you can do this in a sustainably profitable way.

Not every problem is a customer problem. Not every customer problem is worth solving. And market problems are so special that we have to work at shaping them to the point where they should be solved. And the bigger the company, the more special a market problem becomes—just ask anyone who strives, in good faith, to follow their gate-based development processes.

Not every problem can be “solved”. Some problems can only be “satisficed”. A solvable problem is one that can be solved, either permanently, or solved in such a way that I consider it permanently solved. A “satisficable” problem is one that can’t be “solved” in the current paradigm. It can only be improved on a set of dimensions to the point where the total is “good enough”.

Satisfiable problems tend be much harder and more complex to solve than solvable problems. To illustrate the concept, let’s refer to an example from Tuned In, the book from the Pragmatic Marketing team. (I L-O-V-E this book). The example of the finding a Magnavox remote control was a solvable market problem. But many other problems are not solvable unless the market paradigm changes. For example, consider the trucking industry. A trucking company wants better better fuel economy and safer drivers. Always. You can give a trucking company 10mpg and they’ll want 15mpg. You can give the trucking company 0.8 accidents per 100K mikes and they’ll want 0.7. But, if you offer them 30 mpg and an accident rate of 11.5 accidents per 100K, they’ll probably prefer 7mpg and 0.7 accidents per 100K miles. They are satisficing a complex set of factors.

You can identify satisficable problems in your research, because customers will tell you (if you’re listening) about the various dimensions. As one trucking executive once told me: “Every trucking company cares about the same 12 things. We just care about them in different amounts”. Naturally, you’d ask this executive to not only list the dimensions but to help you understand how the executive makes tradeoffs between the dimensions.

And, because your customers, the market, and the larger ecosystem in which you work are all constantly changing, you need to continuously engage with your customers so that you can both identify solvable market problems (“find my remote”) and the mix of satisfaction that is required in satisficeable market problems in order to sustain your solution in the market. And there is no other way to get this done than (mostly primary) market research.

Thus, it really does matter if you’re working on problems, customer problems, or market problems. Because if you’re not working on market problems, and you can’t demonstrate you’re working on at least a customer problem, you’re probably just running off and building against your own, potentially bad, ideas.

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:

To see what I mean, let’s consider an executive who wants to solicit ideas / feedback from their customers. They install an idea submission system. If the system doesn’t have a lot of use, then they’ll have few ideas. It will be managable. Unfortunately, the power law of contribution says that only a small number of their customers are submitting ideas. So this may not produce insightful or actionable results.

Let’s say the opposite happens. They install an idea submission system and they get a tremendously large number of ideas. Thousands and thousands. The power law of contribution suggests that a small number of active and vocal users are making most of the submissions. But, to get a large number of submissions, many, many users will be contributing. That’s good, because it now means that the total set of ideas is much more reflective of the customers who are using the system, which means that the ideas should be more actionable, more insightful, and more reflective of the broader needs of the market the company is serving.

Except managing thousands of ideas in these systems is a Herculean task. “Death by a thousand ideas” that you don’t have time to understand or process is not a good way to gather market insights. I’ll be exploring this theme in several related posts over the next few months and suggesting better ways to both gather, process, and act on market feedback.

How are you using idea submission systems? How are they working for you?

• Who we’re serving (e.g., target markets, market segments)
• Why they care (e.g., benefits of product often expressed in ROI)
• Why we care (e.g., market size, total available market, total addressable market, growth, and share)
• How we’ll reach them (e.g., sales channels, partner structures)
• Our sustainable competitive advantage
• The competitive landscape
• Personas
• and… ???

My point is that even the most minimalistic approach to Product Management has a Product Manager creating a fairly large number of documents. Which doesn’t concern me, because these are quite sensible documents to create.

What does concern me is that I’ve seeing an increasing number of product managers who are avoiding creating these basic artifacts. The conversation goes something like this:

Luke: “Francesca, can you show me your personas?”
Francesca: “Oh yeah—personas. They’re really great. I like the cooper format, but I also think the format I learned from Pragmatic Marketing is really neat”.
Luke: “Yes, both formats are quite useful. I’ll be OK with either. Can you show me your personas?”
Francesca: “Well, you see, that’s the thing. We don’t have personas. You see, we really didn’t have all the time we wanted to create the persona format that we thought would be great. And since we couldn’t create a really great persona we decided just to skip it.”

Push the big red button labeled “STOP”.

Just because you can’t create a “really great” anything does not mean you should skip it.

Yes, I know. Writing a really great persona is hard. But a really great persona is merely better than a good persona. And a good persona (which looks “bad” in comparison to a really great persona) is MUCH, MUCH, MUCH better than a bad persona. Logically:

“bad” Product Management deliverable >> NO deliverable

“really great” Product Management deliverable > “good” Product Management deliverable

To help get you started, I hereby proclaim that creating “bad” deliverables is OK. Specifically:

• It is OK to have a persona without just the right picture.
• It is OK to define your Total Addressable Market as a “reasonable guess” Low-to-High estimate of your Total Available Market
• It is OK to have a roadmap that only projects 12 months into the future
• It is OK to define your initial market segment as the “customers who bought from us”
• It is MORE than OK to define your ROI in less than 12 lines of Excel
• It is OK to focus more on your customers and than your competitors

What do you need permission to create badly? Send me a note.