This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games.
One significant element of the game StarCraft is using is a “fog of war.” As opposed to games like chess, where the whole situation is visible and you can act strategically, in StarCraft, you have to constantly visit the enemy’s bases to check what they are doing. Only with constant feedback can you adapt your own strategy to be ready when they try to attack you. You need to have the right force, at the right time and place, to counter your enemy. In business, it is the same. It may be with the difference that you have a lot more time to “scout” your competitors, but it is often much harder to get reliable information.
Given that your competitor also scouts you, this results in an interesting dynamic. Depending on how fast and competitive the industry you are working in generally is and how reliably information can be gathered, this can require different approaches. Often, over time, the most flexible and adaptive product wins. If you can change strategies quickly, you have an easier time countering your enemy’s change of strategy (or adapting more quickly to a changing demand from the market). Kanban can help when those changes are coming from the demand side pulling through the company, or by small changes (e.g., turnover) within the company, which are also manageable by the Kanban workflow.
In terms of investment into market research, you might want to wait until you have scouted the enemy before you decide what type of units you will build. This way, you keep the risk to a minimum. On the other hand, when you have scouted the enemy and have the information, it might be too late to react. You might have some sort of product life cycle management (PLM) in place to first determine the feasibility of the product. This is sometimes easy to do when all you have to manage is resources. Sometimes, though, you are wandering in the unknown and only by implementing your plan will it show if it is feasible or not; an example would be engineering (cars, scientific instruments, rockets, etc.). Now, this is similar to scouting. While you can certainly make projections that the enemy will not attack you with a battle cruiser within the first few minutes because you know precisely with what resources they have started, you do not know their exact strategy.
Ultimately, you have to make a balancing choice. If risk is what you want to minimize, wait with any choice or investment until you have the information you need, until you know what is feasible. Your product will be on the market later, but you will save any initial investment you might have lost if it turns out it is not feasible. But keep in mind that risk stems not just from feasibility, but also from the marketplace. If you miss the window of opportunity to sell your product, you will have spent a lot more money and get no return.
The best approach is to divide your product into modules whose feasibility can be determined independently. Once the feasibility of one module is established, you can start with its implementation while you are still determining the feasibility of the next. You would already have begun building your resource gatherers, supply depots, and basic technological buildings even though you have not established the feasibility of your strategy. It is a risk, but a lower risk than if you waited.
