The Point of a Strategy

Q: How do you win a soccer match?

A: Score more goals than the other team.

This is a dumb strategy, right? But why?

Compared to a more reasonable strategy like start preparing with plenty of time to spare, invest in a good team, hire a good coach and what not, why is scoring more goals a dumb strategy? That’s because the bad strategy didn’t reduce risk.

The whole point of a strategy is to mitigate risk. One could imagine gathering up a bunch of random people and somehow lucking out at the game and winning it. You need a strategy if you don’t want to leave everything to chance.

That’s why the next strategy you write down needs to account for these:

1. State your goal clearly.

   A good goal should clearly articulate the outcome, and constraints. E.g. MVP available for limited testing (the outcome) by end of Q4 (the constraint).

   It should be obvious to anyone when the goal has been reached. This is by design, since there should not be any question of what you are collectively trying to accomplish.

2. Identify the risks.

   Mitigating risks begin by identifying them. Some risks are obvouls, but still write them down because you need to address them.

   Failing to meet the goal is an obvious risk, but why would you fail to meet the goal?

   A common reasons is simply that you need more time. E.g. you are at risk of not meeting the constraints due to underestimating the amount of work required.

   Another reason could be technology you are using not performing as expected due to bugs. Every part of your tech stack is a gamble. A part that you don’t own is a specially big risk because you may not be able to fix it or work around a problem.

3. Figure out how to mitigate the risks.

   At risk of schedules slipping? Have intermediate deliverables and milestones along the way. Instead of everything falling apart at the end, you’ll know when things are not going to schedule much earlier in the product life cycle. Knowing early means that you can address them before failures snowball into a giant ball of trouble.

   Unreliable tech-stack? Choose stacks that have a solid user base and support structure. A project with bugs that are getting addressed is a lower risk than one that hasn’t seen any updates in a year.

4. Stack up your goal, risks, and mitigations.

   There’s your strategy.

It’s not a strategy is risks are not identified and mitigated.

A common mistake is to write down a list of steps that, if followed, achieve a stated goal. A good first step. But the unless the strategy can reduce risk, it is not a useful.