In this post, I want to discuss some ideas I have had on how to dramatically increase the market penetration of simulations, where it is possible, which offers some insights into why I believe my new project, SimsUShare, is going to be big (and you should sign up here!). That having been said, what I put here is only a first effort at putting down my thoughts so as to better evolve them.
While my growing experience in simulation-based training and product simulation marketing have continued to move me closer to recognizing solutions to underlying issues preventing widespread adoption of simulation today, I had trouble articulating the issues clearly. Last year, I think I was able to do so. I believe that widespread adoption and benefit from simulation is held back largely because:
- It takes too much time/expense to create simulations;
- There is no efficient way to share and localize existing simulations; and,
- Current tools often require IT support for installation and maintenance.
As luck would have it, as I was developing my ideas further, I came across Clark Aldrich’s blog post from June, 2010, “The Next Step for Simulations and Serious Games: Multi-Genre Authoring Tools and a Vibrant Marketplace“, that really summed up this yearning beautifully:
“…the process to create [simulations] today is too long and too expensive for most organizations to use them beyond the 5% to 10% of their high value/mission critical and external facing courses today. Further, the marketplace for selling and otherwise sharing them is too fragmented to provide reliable returns to attract many content creators. This has resulted in an identified, but unfulfilled need….What is now needed are powerful, flexible, and accessible simulation creation tools as well as a viable, persistent simulation repository and marketplace.”
One of the nagging things I walked away from this quote with was the question: why is the penetration stuck in the 5-10% range, and how can it be extended? The idea of making more powerful tools is the mantra for many technologists — make more features, that’ll get them buying chopsticks (please excuse the Eddie Murphy reference). I think Clark really nailed the issues — a combination of tools, repository, and marketplace.
On a slight digression, ever since I met David Castillo (my co-author) in about 2000, we have been discussing whether creating a simulation-building tool based on statecharts would bring statecharts and simulations more into the mainstream by making it easier to create simulations (particularly around equipment). We looked at the Rapid CBT example–a beautiful tool, which seemed to garner more success for its services arm than for its own product sales–and we wondered if having a Flash-based tool would take this further. Though it went unstated, I hesitated to go ‘all in’ on something like that because I didn’t feel we really nailed the idea of how a Flash-based (or HTML5, or whatever) tool would solve the market problem. In my heart of hearts, it couldn’t just be about improving the tool itself — there had to be at least a community component.
Distilling Experience into Key Dimensions
Having the years to ponder these thoughts, I have come up with three dimensions that can help me give this problem something visual to work from:
- Content Creation Simplicity. How easy is it to use the tool to create appropriate simulation content, that is, what kind of functions does the tool provide to make the task of creating content simpler. This can range from all content has to be created from scratch, to an ideal, perfect tool in which content can be magically reassembled with no effort. Clearly, neither extreme is plausible in reality, but there is a great continuum between these points.
- Cost – I don’t mean purely the purchase price, rather, a more overarching resource cost for what it takes to acquire and apply the tool in the workplace.
- Community Sharing Proclivity (CSP). A term I just made up meaning some measure of how inclined the community is to share existing work.
The last dimension requires more explanation and probably more thought to flesh out. One could argue that if a tool made it easier to share work (i.e., going higher on the scale for #1), then the community sharing would be easier and therefore impact #3. However, I am aiming at a more subtle definition of #3 — how likely would the community be to share any material generated. For example, if the community consists of commercial competitors, then making a tool simpler will not affect the CSP.
One of my first observations was that the “community” is not anywhere near a single community. I even have some trouble circumscribing exactly what is a community. For my purposes, it is a group of people and businesses that seek to solve a set of common problems. Therefore, a community can be very specific, or very general. How you define the community issues is going to be a big factor in how close you can get to the perfect combination, or 100% market penetration (though I assume virtually no practical community could reach 100%). Maybe that is pretty obvious. Different communities have different needs and assumptions regarding simulations, and therefore trying to answer how to increase penetration for simulations as a whole is going to fail.
My Hypothesis
My hypothesis is that the potential penetration of simulation in a community is proportional to the closest distance between values assigned for a particular set of tools and the intersection of lines at the maximum of each of those 3 dimensions. The purpose of declaring a hypothesis is to use it to understand how much we can improve market penetration practically.
Here is a rough sketch of what I propose:
The blue rectangular prism is a range of what one would consider practically achievable for a given community, since it is impossible to reach the perfect target.
To use this practically, you have to assign values (I would say qualitative) to:
- Tool or set of tools (along the Content Creation Simplicity axis): Farthest from the perfect target along this axis is a tool in which you have to re-create everything to make a simulation, and closest is a tool in which everything is provided magically so that simulation assembly is effortless
- How inclined is the community to share work product (Community Sharing Proclivity): Farthest from the perfect target along this axis is a community that refuses to share anything; closest is the community that shares everything
- The resource costs for implementing simulation solutions (Cost). Farthest from the perfect target is a tool with infinite cost (acquisition and resources); closest is a tool that has no resource costs.
To reiterate my hypothesis, I believe that given some tool (which embodies a methodology and process), given a measure of its cost to implement for an individual or organization in the community, and given some measure of how cooperative the community is at sharing, you can derive a distance to the ‘perfect target’, or maximum of all dimension values.
The Purpose: What the Hypothesis Suggests
Market penetration is important both commercially, for the tool producers, and the community, to help solve problems. The purpose of defining these dimensions is to permit questions about:
- What is the best description of a community fit to the tools/processes (for the tool vendor, who is really your target customers and target users? For the community members, who are the people you need to associate with closer to increase the CSP?)
- How can we decrease the distance to the perfect target, and thereby increase the market penetration.
Ultimately, by examining the values we assign, and the “maximum values” we determine for each axis given the community’s issues, we need to ask ourselves how difficult it would be to increase each value. Depending on the extent of this space, we may be able to prioritize increases in which dimension(s) bring us closer to the perfect target at the least effort. Improving tools may only go so far if the resource costs and the proclivity are working against us. Similarly, the greatest intentions of a community to share (CSP) can be sidetracked if the tool costs too much to implement, or is not sufficiently easy to accomplish the needs of the community.
This is really a first stab at something that has been gnawing at me for some time. I hope you can provide some feedback as to the soundness of these ideas and how your own thoughts might influence the direction I’m heading.