Produce a real, defensible 1-2 page positioning document for your main product: who it is for and who it is not for, what category it competes in, what the competitive alternatives are, what its unique attributes are, what value those deliver to whom, and what walk-away signals would tell you the positioning is wrong. Develop the muscle of deciding what something is, rather than describing it. Positioning is API surface design: a minimal coherent interface that lets the consumer understand what this is and why to pick it over the alternatives. A badly positioned product is a badly designed API — too many surfaces, none obvious, documentation that describes capabilities instead of use cases. You already know how to write a good README; positioning is the README for the user, not the implementer. Strategy is architecture: Rumelt's diagnosis / guiding policy / coherent actions maps one-to-one onto the constraint we're under / the principle we operate by / the design decisions that follow. Most strategy documents fail exactly the way most architecture documents fail — listing components without naming the constraints that drove the choices. And portfolio strategy is monorepo governance: which modules are first-class, which are deprecated, which share infrastructure, which get extracted, which get retired. The decisions are emotional for products in a way they aren't for code. The shape is identical.
This course unlocks once you've finished its prerequisite. Open prerequisite →
This is the module I expect you'll find the most surprisingly enjoyable, and I want to flag the reason before you start, because the enjoyment is misleading. Strategy and position…
Most engineer-founder products have weak positioning, which is to say: they describe themselves in terms of features rather than in terms of the alternative the customer will pick…
Approach: Essential
Approach: Essential
Approach: Important
Approach: Important
Approach: Essential
Applied to your main real product plus your whole real portfolio.
8 lessons. Read in order; spiral back when you need to. By the end you'll have used the core ideas twice — once on the abstract, once on something you'll meet at work next week.