When massive multiplayer online gamers work together as a team (called “Raids”) to defeat fantasy targets (called “Bosses”) they are repeatedly performing the steps of a Lean Startup – Build, Measure and Learn.
For raiders, “build” is working together to achieve the desired outcome of defeating the boss. They have a meta hypothesis – that the boss can in fact be killed and that once killed an item of superior value will be earned by one or more of the raid members. In the Lean Startup world there is also a meta hypothesis – that you can make a revenue generating business. In both cases it is possible to fail at this meta-hypothesis and disband the team never to try again.
But the incremental hypotheses is where it gets really interesting. Raid teams generally know how to operate together as a group. They have their own specialised roles. Additionally some people are able to be multi-disciplinary and can take on the roles of others. When first placed against a boss (who in business terms is a potential revenue generating customer) they will be armed with an initial hypothesis. It may be something as simple as what is called “tank and spank”. In a gaming world this means taking a standard stance of having one person taking the bosses attention, a few healers helping top him up and the rest of the team doing damage to take the boss down. In a Lean Startup world this would be starting off with a homepage and seeing who rocks up to the site and seeing what areas of interest they click on. For a very easy boss (or customer who has infinite time and interests) this might be a suitable strategy, but for a majority it will fail. What it will tell you though is some very basic information, potentially enough to start a new hypothesis.
You may have learnt that it will require another specialised “tank” role or that you need to reposition the team. In Lean Startup terms this would be a feature potentially being searched for very often but not implemented yet. This new hypothesis is then implemented. The team look at the results of their work. They use observation and actual data to determine where to improve and what to try next. Actual data for raids is obtained through tools such as combat logs and parsers that aggregate and display graphs of what is happening as the fight, or user experience across multiple customers for Lean Startups, is occurring.
For raiding teams it can take dozens of hypotheses before they defeat a boss. It takes a lot of analysing the data and re-execution of the fight in order to know whether you are on the right track or not. Teams may have a strategy built on multiple hypotheses that will consistently get the boss to 10 or 15% but never go past that amount. Ultimately they haven’t crossed the chasm. It is at this point in time that the team will need to pivot, drop their strategy and a large number of hypotheses and take a completely different tack. Only then is it possible to succeed. This is a very hard thing for a raid team to do. They have been pushing this set of hypotheses now for several hours. There is emotional attachment to the strategy. There is blame. There is tiredness. To change is hard when so much has been invested.
But if they do change, and they do succeed the rewards are sweet. There is a pride in having achieved the outcome and finally getting the hypotheses realised.
Interestingly raiding isn’t for everyone who games. The effort of having to work together as a team, of almost constantly being defeated, of looking at the metrics and not having a clue what tactic to take next – these are things that a lot of people just don’t have the guts for. They would rather sit on easy street and take on items that are immediately achievable, they don’t have an element of failure. That is fine, small risk reveals small rewards. For those that want to take risks there is the chance of bigger rewards.
Thinking you are suited to kickoff a Lean Startup? Maybe you should take on raiding within online multiple games and see whether you have the drive, committment and guts to keep failing before succeeding.
Agile Forest 