For the strategy meeting
Strategy questions
Frameworks tell you what to consider. These pages show what happened when real companies faced the same question: the cases where the answer was yes, the cases where it was no, the conditions that separated them, the strongest argument against the conclusion, and the questions worth asking before you decide. Each draws on the Decision Record and the essays behind it.
- Should we open our platform to outsiders? Open the layer that others need in order to build on you, keep a layer they cannot easily replace, and put the rules somewhere outsiders can trust. Opening wins when complements make you more valuable and a rival offers an open alternative; staying closed wins only while you are clearly ahead and the integration itself is what customers pay for.
- Should we give it away free? Give a product away only when you know exactly who pays instead, and when that payer gains as the free side grows. Free wins when it removes the barrier to adoption and someone else funds it; it fails when the payer is vague, when costs rise with every user, or when the free product teaches customers that the thing has no value.
- Should we build it ourselves, or depend on a partner? Own the capabilities that improve with use and that a partner could turn against you. Depend on partners for what is stable, commoditised or genuinely outside your expertise, and only when the partner credibly cannot or will not compete with you. When you take a capability back, do it before you depend on it, not on the day you switch.
- Should we buy the company that threatens us? Buy young, buy for what the target does that you cannot, and protect the thing that made it grow. Acquisitions work when the buyer understands why the target is winning and leaves it room to keep winning; they fail when the buyer pays for an asset whose value depends on conditions that are about to change, or folds the target into its own product and loses what it bought.
- Should we keep compatibility, or make a clean break? Keep your users’ existing code, files and habits working unless the new design is so much better that they will pay the full cost of moving, and you can carry them through the transition. Clean breaks succeed when the old base is small or failing; against a large, healthy installed base, the compatible path almost always wins, even when it is technically worse.
- When should we abandon the product that made us? Move before the old product stops paying, while it can still fund the new one, and when the evidence that the market has moved comes from your own customers and your own front line rather than from forecasts. The record’s clearest failures held on to protect an identity; its successes left early and redirected people and money to an alternative that already had momentum.
- How big should a new product’s launch be? Launch at the scale of your evidence, not the scale of your vision. New categories that started with one concrete job for one group of users, and widened as users showed what they valued, succeeded far more often than those announced as complete visions to everyone at once.
- How should we roll out a change that cannot fail? Change one thing at a time, go live when the business can absorb a failure, keep a way back, and never treat a new system’s output as proof until it has been checked against reality. Large implementations are the worst record on this site, and almost every failure combined several changes at once, a fixed deadline and too much trust in the new system.