战略不是天赋：一套 8 到 12 周就能跑完的五阶段打法

Janakiraman traces his obsession with strategy to a Monday at Headspace, about ten years ago. He was a fairly new VP of product with a polished roadmap tied to the company's mission, when the founder-CEO mentioned that many people did not understand why the team was working on what it was working on. A few conversations confirmed it, and the realization was a "bubble bursting" moment.

Working with a board member who had a product background, he built Headspace's first written product strategy. That work led to a re-imagined product, the "Next Generation Headspace", with a broad content library, a personalized home experience and motivational elements. It turned a meditation app into a broader health and wellness service, and it earned him the role of the company's first CPO.

What stayed with him was a perception that some people have a "strategy gene" and others do not. He wanted to know whether that divide between the haves and have-nots could be closed with a procedural approach, and his answer is yes. He stresses that this is an operator's interpretation of Sun Tzu, Porter, Rumelt's *Good Strategy Bad Strategy* and *Playing to Win*, not a new theory, and that he has run the playbook five or six times, including at Meta.

Janakiraman places strategy between the mission and vision, which describe why a company exists, and the plan, which is an ordered roadmap. Its job is to force choices that deploy scarce resources for maximum impact. It can live at the company or team level.

He borrows an analogy from physics: apply a frequency close to an object's natural frequency and its vibration grows disproportionately, while other frequencies do almost nothing. Strategy, in his telling, is selecting the frequency that creates resonance between product and market.

A good strategy ideally has three components. The first is a handful of strategic pillars, the second is a longer list of areas that are explicitly not the focus, and the third is the why behind both lists. Lenny agrees that being clear about what the team is *not* doing is a recurring theme of successful teams.

The five phases are preparation (about four weeks), a strategy sprint (up to a week), a design sprint (a week), document writing (one to two weeks) and rollout (two to three weeks). Preparation is the longest but not full-time. It begins with forming a strategy working group, at minimum engineering, product design and data, with the PM driving the process and optionally product marketing or user research joining.

At the kickoff, each member gets discrete deliverables: a meta-analysis of past behavioral analyses from the data lead, a synthesis of UX research and support or social signals from the design lead, competitive analysis, a summary of adjacent teams' roadmaps, and user observation. The point of watching or interviewing a user is not to act on the findings but to build empathy and soften preconceived notions.

The most memorable input is leadership interviews, illustrated by the fruit story. A PM brings a mango, then an apple, then a banana, and the reviewer rejects each, when the PM should have asked whether the reviewer even likes fruit. Janakiraman suggests asking leaders what success and failure look like, how it will be measured, which principles to keep in mind, and what their favorite ideas are. Senior leaders usually enjoy these conversations, and asking is a sign of strength.

Everything goes into one comprehensive preparation readout. It stays secret within the working group until the strategy sprint, because the sprint, not the deck, is where decisions get made. Lenny sums up the logic: the quality of the output is determined by the quality of the input.

The strategy sprint is "the heart of the process" and runs three to five days. Day one is a share-out in which each person presents what they collected while everyone else writes down problems for users, obstacles to growth and business weaknesses. It brings the group to a shared view of the state of the union, and it is deliberately problem-focused.

Day two is, in Janakiraman's words, the most important day of the entire eight to twelve weeks. The group dumps problems into a spreadsheet, clusters them into ten to fifteen groups, and renames each cluster as an opportunity: "difficulty finding things" becomes discovery, unwanted content becomes relevance, and loneliness becomes social connection.

The opportunities are then scored against four criteria: expected impact, certainty of impact (how concrete the evidence is), clarity of levers (do we know how we would solve it), and whether the levers are unique to this team or company. Qualitative high, medium and low scores are fine. The real value is in debating the scores together, which creates alignment. Summing the scores yields the top three pillars and the remaining areas that are not the focus.

Once the pillars are chosen, the team writes a few "how might we" questions for each, which takes about an hour. Lenny notes that the phrasing is powerful because it opens the mind in a way "how do we improve discovery?" does not, and Janakiraman adds that designers already know it well, so it feeds smoothly into the design sprint.

After a break, day three moves to a creative exercise called winning aspiration. Everyone imagines a newspaper article two years out about progress on the pillars and writes its headline, in plain language and focused on the benefit to the world. The headlines go "into a blender": they are put on one slide, common words emerge like a word cloud, and the group converges on a single aspiration.

For the privacy team at Meta, the pillars were about specific features, but the winning aspiration was moving consumer trust, with a headline along the lines of "Facebook has moved the needle on consumer trust." At the end of the sprint the team has three pillars, the how-might-we questions, the reasons for what was excluded, and the aspiration. Janakiraman concedes the pillars rarely change during the sprint, though execution may force a course correction later.

The design sprint is led by the designer while the PM takes a back seat, with engineering optional but welcome. Its input is the three pillars and their how-might-we questions, and its output is a large set of illustrative concepts, not feature-ready designs. Janakiraman says a picture is worth a thousand words, because readers of a strategy doc often wonder what you will actually build.

Document writing is then a solo job for the PM, taking one to two weeks. The building blocks already exist, so creator's block is gone, but weaving them into a cohesive story is still work. He suggests starting with leadership context, then key insights, the pillars and their rationale, the winning aspiration with embedded concepts, and ending with alignment questions. The full scoring table goes in the appendix as defensibility.

The doc should run about three or four pages, with an appendix for the table and extra concepts. He warns against putting a roadmap in it, since strategy is a companion to the roadmap rather than a part of it, although an illustrative roadmap in the appendix is acceptable. Resourcing is also left out and handled in roadmapping, where you decide what share of engineering goes to each pillar.

Rollout starts with two or three gatekeepers whose one-on-one blessing is essential, then a wider group of key stakeholders, either asynchronously or in a group review. After that come team roadshows of eight to ten people, where the format is conversational. The purpose is to land the strategy, not to solicit endless feedback, so clarifications can be added but the three pillars should be defended unless someone makes a strong case against the ranking criteria.

For an individual-contributor PM, he advises keeping the manager lightly in sync: interview them as a leader, pre-flight the pillars after day two, and enlist their help in larger meetings. The process is then summarized with three reasons it works. Alignment is built in because the strategy comes from the working group and leadership inputs rather than one PM, results improve because more minds work on the problem, and the criteria make the output defensible.

Janakiraman ties the first point to psychology: ideas that come from you feel more familiar and easier to accept. Lenny adds that no method guarantees a winning strategy, echoing the idea that no plan survives first contact with the customer. Janakiraman agrees that the strategy still has to be tested through execution.

Janakiraman calls Zynga's strategic clarity impressive. Every game shared three elements: viral game loops that needed an active social network, paying to complete things rather than skip them, and a cross-promotional network where the Zynga network mattered more than any single game. Focus on high-fidelity graphics or complex mechanics was explicitly excluded. Systems such as strong data infrastructure and a central product management function reinforced the pillars, and the company reached a billion dollars in revenue faster than any before it.

The fit between product and market was lost temporarily when the industry shifted to mobile. Janakiraman also reflects that Zynga's clarity left him with a blind spot: because the strategy was already in place, he never exercised the muscle of creating one, which became obvious when he joined Headspace. Lenny compares it to the fish that doesn't know what water is, and highlights the power of focus and of having only three bets.

At Meta's Reality Labs he stood up product growth teams for Oculus (the Quest 2 era) and Portal, using the process described above, and got nearly identical pillars for both. Features included the Oculus referrals program and Portal's Facebook Memories integration. After about 18 months, Oculus was so successful that it graduated into the VR division, while Portal did not move the needle and was sunset, with the team redeployed.

His conclusion is that strategy has no intrinsic business value, since it is a document with a few words. It accumulates value only when execution produces impact, which takes intellectual honesty, humility and courage to say what is and is not working. Lenny adds that the goal is to reach a strong hypothesis quickly, which is why small-S work should take no more than two or three months.

Everything so far is "small S": problem-focused, present-forward, usually PM-led. Citing Elon Musk's line that life has to be about more than solving problems, Janakiraman says every company needs an aspirational component too. Big S can take up to six months and starts from the company's mission and vision plus backdrop research on cultural, social, competitive and technological trends.

Leaders are interviewed with future-oriented questions, such as what a day in a user's life looks like in five years and why the world is better in ten. The answers are clustered into about three distinct futures; his example for travel is autonomous, extremely fast, or virtual. Each future becomes a prototype with learning goals, which he compares to concept cars: rarely commercialized but a source of inspiration and features. Prototypes are tested with research users, the winners go into live product tests, and the process is typically led by design and UX research.

At VRChat the product team leads small S while design leads big S, as parallel streams that flow "like two tributaries" into one roadmap. Lenny advises making sure blue-sky people lead big S. Janakiraman closes the section with three notes: expect frustration and self-doubt along the way, choose a lead who is a low-ego integrator of diverse viewpoints, and keep a lighter, playful touch to fight fatigue.

Janakiraman says he is not an AI futurist but sees two immediate uses. In the preparation phase, AI can analyze competitors' release notes for investment themes, review user sentiment, produce head-to-head heat maps, and offer hypotheses about why a new product is succeeding.

The second use is generating a "mock strategy": almost the answer, but not quite. Asked what VRChat should do, the tool produced something surprisingly well-informed, but its comprehensiveness is also its weakness because it recommends investment in many areas. Strategy needs focus, so the team must still choose which areas matter, using company-specific judgment.

Looking further out, he imagines a multi-agent model with strategy, roadmap and engineering agents iterating together. His example is onboarding: multi-armed bandit experiments are sophisticated, but the variations are still human-written, and generative AI could supply them, perhaps tailored per user or region. Lenny envisions an onboarding agent constantly proposing and shipping experiments.

On whether AI will be best or worst at strategy, Janakiraman sees a crossover point where machines that process many signals in parallel will beat human judgment, much as a self-driving car with six cameras handles a turn better than a person looking both ways. He expects manual processes like his to look archaic, but thinks the fundamentals will keep a long shelf life.

Janakiraman recaps that strategy sits between mission and plan, forces choice for maximum impact, and has pillars, non-focus areas and reasons. Small S is present-forward, two-year, five-stage and eight to twelve weeks, while big S is future-backward, three to ten years and up to six months. The roadmap is built from both, like a bridge built from both sides of a river.

In the lightning round he recommends books on creativity: a Walt Disney biography (he notes Disney loved theme parks because he could tinker and observe reactions), Ed Catmull's *Creativity Inc*, and Tom Kelly's *The Ten Faces of Innovation*. His life motto comes from a 1995 Steve Jobs interview about the craftsmanship between a great idea and a great product: if it's easy, it's probably not that special.

He asks listeners to treat his playbook "as a bit of an open source model": test it, remix it, and share what worked or didn't. His hope is to create a ripple of success across teams and products, and he points people to LinkedIn to reach him. He also offered to share the process flowchart and a document template.