Strategy taxes can be incidental or they can wreck projects. One example is getting caught up by brand values, where an overriding idea like 'no violence' or 'must be educational' or 'must have a story' hampers the game to the point that it breaks. Another example is the choice of technology and platform. Adopting a cross-platform solution (like HTML5, Unity or Flash ) for fear of being left behind seems smart, but not if the overhead that the solution imposes makes the game run too slowly.

Strategy tax is a great term to describe a kind of cruft that creeps into many games. Strategy taxes are self-imposed constraints which limit, or even harm, a game for a loftier goal. Game makers accept them as trade-offs in service of a bigger play like capturing a market, being available across all platforms, or promising to investors that the game will be in profit on day one.

The question is whether the trade-off is really worth it, and the answer is often 'no' because big play strategies usually fail. You may see your game becoming a multi-platform brand some day and consider it smart to be thinking about that early in the process, but that's really just an extended form of Waterfall planning.

Complicated and strategy-tax-driven planning weighs a project down until, like the donkey in the above image, it is no longer grounded. You might require that the game needs to have X features on Y platforms, include Z metrics and say 'but the game has to be good' and then look to your developers to fill that gap. And they look back at you and your requirements and have no idea what you want them to do. It no longer resembles a fun thing to play, just a mess.

Making games is highly iterative by necessity because creating a fun dynamic happens by trial and error. Imposing too many strategy taxes on that process exponentially reduces the likelihood that you will get there, and yet getting there should always be the goal. Like any creative enterprise, it's important to allow discovery to happen and to experiment. And, when the signs of a game start to emerge, to chase that idea and see where it leads. Not shut it down because it doesn't quite fit a bullet point from a document written six months previously.

The final product may not fit the model you had in mind. The technology may prove a bit complicated to port to other platforms down the line. So what? Some-day plans always expire when they come into contact with reality. Why bind yourself to them any earlier than is necessary? Why prevent yourself, your team, your studio or your whole multi-milion dollar corporation from discovering that next game just because it doesn't fit some mental schema that's likely half-baked anyway?

Let the big plans wait. Solve the problem at hand (usually 'make a great game') and worry about strategy once you have a product worth worrying about.