
Chief Product Officer and EVP at VRChat, ex-Meta, ex-CPO at Headspace, ex-GM at Zynga
Chandra Janakiraman is Chief Product Officer at VRChat, formerly a product leader at Meta, CPO at Headspace and GM at Zynga. The thing most worth learning from him is a repeatable eight to twelve week process that forces a choice of three focus areas, builds team alignment as it goes, and treats results from execution as the only proof the strategy was good.
Intrinsically strategy has no business value. It's basically a document with a few words. And I think it starts accumulating value as you generate business impact and results.
An operator’s guide to product strategy | Chandra Janakiraman (CPO at VRChat, ex-Meta, Headspace)
Chandra wrote Headspace's first strategy after the CEO saw the team lacked a why. The founders had set a mission and vision, and Chandra had set goals and a buttoned up roadmap. The CEO told him many people did not understand why the team worked on what it did, and Chandra checked and found he was right.
A board member with a product background helped him see that the company needed a strategy, not just a plan.
That first strategy remade Headspace and made him its first CPO. It produced Next Generation Headspace, which turned a meditation app into a broader health and wellness service with a full content library, a personalized home experience and motivational elements.
He watched the process "in an out of body way", and that started his effort to make strategy teachable.
He rejects the idea that strategy is an inborn gift. Many people believe in a "strategy gene" you must be born with. Chandra built a procedural playbook to show it can be learned, aimed at product people who think they are weak at strategy or were told so.
He wanted to close the divide between "the haves and the have-nots". The playbook is an operator's synthesis of Sun Tzu, Porter, Rumelt's Good Strategy Bad Strategy and Lafley and Martin's Playing to Win, not a new theory.
His career ran from Amazon and Zynga through Meta and Headspace to VRChat. He was a senior PM at Amazon, a GM at Zynga, a product leader at Meta, CPO at Headspace and is now CPO at VRChat.
He has run the process five or six times, including several times at Meta, and tuned it each round.
Strategy is a forced choice about where scarce resources go. It sits between mission and vision above and the roadmap below, at company or team level. It has three parts: a handful of pillars, many explicit non-focus areas, and the why behind both.
In his words, it "forces choice to deploy scarce resources to generate maximum impact".
He holds the line at three pillars, not five. Three gives more clarity and focus, and each pillar should be differentiated. He says to try hard to hold it at three rather than three to five.
Differentiation test: if another team or company could build it better, it is probably not differentiated.
He uses resonance from physics to explain product-market fit. Most frequencies barely move an object, but one near its natural frequency makes it vibrate far more. A product that matches its market gets the same outsized response.
Zynga ran on three clear pillars and clear non-focus areas. Every game shared viral loops, paying to complete and a cross-promotion network. High-fidelity graphics and complex game mechanics were explicitly out. Zynga was the fastest company to a billion dollars in revenue at the time.
Systems reinforced the pillars: strong data infrastructure and a Central Product Management function spread best practices. The shift to mobile temporarily broke the fit between product and market.
Chandra budgets the full eight to twelve weeks up front. Preparation takes about four weeks, the strategy sprint one week, the design sprint one week, document writing one to two weeks and rollout two to three.
People expect a couple of weeks, but iteration stretches it anyway, and a strategy pays back over about two years. If a CEO wants it in two weeks he looks for shortcuts but pushes for the time.
He builds a small cross-functional working group, not a solo PM effort. Engineering, product, design and data are the minimum, with product marketing and user research as a bonus. The PM facilitates, but the group co-writes the strategy.
Because the work comes from the team's leads, it feels "familiar and easy to accept" at rollout.
He interviews leaders first, to avoid the mango, apple, banana cycle. Each member interviews a leader on what success and failure look like, how success is measured, which principles to keep in mind, and their favorite ideas.
A leader who rejects a mango, an apple and a banana in turn is best asked first, "Do you even like fruits?" Leaders often hold back pet ideas to avoid seeming to micromanage, and they enjoy the conversation.
He condenses existing knowledge into one private master readout. Six parallel workstreams run alongside day jobs: past analyses, user research synthesis, leadership interviews, competitor stack charts, adjacent team roadmaps and user observations. All merge into one comprehensive preparation readout, shared with no one before the strategy sprint.
Competitor stack charts are read from what rivals release, since their strategies are unknown. Watching or interviewing a real user builds empathy and softens preconceived ideas about what to build.
Day one puts the whole group in the same state of understanding. Each person shares what they collected, and everyone writes down user problems, blockers to growth and weak spots in the business. The process is built around problems on purpose.
Day two is where the choice gets made. The group logs problems in a spreadsheet and clusters them into 10 to 15 areas. Each cluster is renamed as an opportunity, for example difficulty finding things becomes discovery. The top three become pillars and the rest are explicit non-focus areas.
He calls it "the most important day in the entire 8 to 12 weeks because that's where you actually make the choice".
He scores opportunities on impact, certainty, levers and differentiation. High, medium and low scores are fine when data is thin. The value is in the group debating why a score should be higher or lower.
Certainty asks how concrete the evidence is, and clarity of levers asks whether you know how to solve it. The table goes in the doc appendix so the choice stays defensible.
Each pillar becomes two or three how might we questions. This takes about an hour. The phrasing opens the mind to ideas more than "how do we", and designers already know it.
Day three sets a two-year aspiration through newspaper headlines. Everyone writes the headline a journalist would run in 18 to 24 months about progress on the pillars, in plain language naming the benefit to the world. Common words merge into one statement.
At Meta, the privacy team's version was that Facebook had moved the needle on consumer trust. Everyone sees their own words in the result, which helps buy-in.
The design sprint turns pillars into concepts, not features. The design lead runs it for a week with the PM in the back seat. Input is the pillars and how might we questions, and output is many illustrative mocks.
The goal is explicitly not feature-ready designs. Concepts answer "what exactly are you going to build?" and later sit inside each pillar's section of the doc.
The PM writes the doc alone, in one to two weeks. The insights, pillars, questions, aspiration and concepts already exist, so the work is editing them into one story. The working group sees a draft at the end only, sparing their cycles.
He admits it does not make the job easy, because weaving a good story is still hard.
He keeps the doc to three or four pages and leaves out the roadmap. It runs: leader context, insights and analysis, pillars with the why, the winning aspiration with concepts embedded, then alignment questions. The scoring table and extra concepts go in the appendix.
Resourcing is a roadmap question, so it stays out of the strategy phase. At most an illustrative roadmap goes in the appendix.
He rolls out in three layers, starting with gatekeepers. First comes a one-on-one with the two or three people whose blessing is required, then key stakeholders async or in a group, then roadshows of eight to 10 people.
"The purpose of this stage is to land it. It's not to seek too much feedback." He clarifies and updates the doc but defends the three pillars with the criteria, and in five or six attempts the pillars have not changed.
He keeps his manager lightly in sync throughout. He interviews the manager early, pre-flights the pillars and what will not be done on day two of the sprint, and later enlists them in bigger meetings.
The touch should be super light and adjusted to each person's style.
Zynga's clear strategy left him without the skill of making one. He only had to produce new games that applied the existing strategy, so he never exercised the muscle. That became his blind spot at Headspace.
He uses the fish parable: you don't notice the water until it is gone.
The same process gave opposite outcomes for Oculus and Portal at Meta. He stood up product growth teams for both, aiming to drive hardware sales through software features, with nearly identical pillars. After 18 months Oculus graduated into the VR division and Portal was sunset.
Features included the Oculus Referrals Program and Portal Memories integration. The Portal team was redeployed to other initiatives.
He judges a strategy by its results and pivots honestly. It takes intellectual honesty, humility and courage to say what is working. Parts of a strategy may work and parts may not, so pivot away from some and double down on others.
He says to spend as little time as possible to reach a strong hypothesis, since small S should take no more than two or three months.
Small S fixes present problems, and big S adds an aspirational future. Small S works "present forward" on a two-year horizon and is typically led by product managers. Big S works "future backward" on a three, five or ten year horizon and can take up to about six months.
He cites Elon Musk: life has to be about more than just solving problems. The roadmap combines both, like building a bridge from both sides of a river.
Big S ends in three distinct futures built as concept cars. It starts from mission and cultural, social, competitive and technological trends, then interviews on what a user's day and the product look like in five to 10 years. Prototypes are tested with a handful of users through UXR, then winners go into live product tests.
Concept cars are never commercialized but inspire, and a feature may move into production. For travel, the three futures could be autonomous, extreme speed or virtual.
He picks low-ego integrators to lead the open-ended work. Design and UXR lead big S, not PMs, and the leaders should be blue-sky people who connect diverse viewpoints, not people who first ask how it moves a metric.
Both processes bring dead ends and self-doubt before they satisfy, so he keeps a playful touch. At VRChat, small S and big S are "two tributaries that ultimately merge into one river".
He uses AI as a research assistant in preparation. It can run trend analysis on competitor release notes, analyze competitor reviews and build head-to-head heat maps. Open questions like why a new product is succeeding usually return good hypotheses.
AI mock strategies are useful input, but humans must choose. Asked what VRChat should do to grow, the tool gave a well-informed draft. Its weakness is that it recommends investment in a vast number of areas, while strategy must be focused.
The down-select needs judgment specific to the company, which is why he calls it a "mock" strategy.
He pairs generative AI with bandit experiments for onboarding. Multi-armed bandits find winning variations fast, but the variations are still human generated. Generative AI could produce them and may find an onboarding no human imagined, possibly different per user or territory.
He expects AI to eventually beat human judgment at strategy. He foresees a crossover point where processing many signals together beats human judgment. He compares a Tesla on full self-driving using six cameras at a turn with a human looking one way and then the other.
He sees the PM's job shifting toward architecting bigger pieces of product for agents.
He reads creativity books to think about how great products get built. He cites Walt Disney's biography, where Disney loved theme parks because he could keep tinkering and watch real reactions, Ed Catmull's Creativity Inc and Tom Kelly's The Ten Faces of Innovation.
He describes Disney's tinkering as A/B testing before the term existed.
He treats ease in a build as a warning sign. Citing a 1995 Steve Jobs interview, he says great craftsmanship lies between a great idea and a great product. He asks whether there is enough pain in a build, as a proxy for whether it is great.
He asks people to treat his framework as open source, test it, modify it and share what worked, since the community owns it.
A repeatable five-phase, 8 to 12 week operator's playbook for building a product strategy: a small working group, leadership interviews, a problem-clustering sprint that picks three pillars, a design sprint, a short doc and a staged rollout. He used it five or six times, including at Meta, and it came out of a Headspace strategy that helped relaunch the product and earned him the first CPO role.
Chandra wrote Headspace's first strategy after the CEO saw the team lacked a why. The founders had set a mission and vision, and Chandra had set goals and a buttoned up roadmap. The CEO told him many people did not understand why the team worked on what it did, and Chandra checked and found he was right.
A board member with a product background helped him see that the company needed a strategy, not just a plan.
That first strategy remade Headspace and made him its first CPO. It produced Next Generation Headspace, which turned a meditation app into a broader health and wellness service with a full content library, a personalized home experience and motivational elements.
He watched the process "in an out of body way", and that started his effort to make strategy teachable.
He rejects the idea that strategy is an inborn gift. Many people believe in a "strategy gene" you must be born with. Chandra built a procedural playbook to show it can be learned, aimed at product people who think they are weak at strategy or were told so.
He wanted to close the divide between "the haves and the have-nots". The playbook is an operator's synthesis of Sun Tzu, Porter, Rumelt's Good Strategy Bad Strategy and Lafley and Martin's Playing to Win, not a new theory.
His career ran from Amazon and Zynga through Meta and Headspace to VRChat. He was a senior PM at Amazon, a GM at Zynga, a product leader at Meta, CPO at Headspace and is now CPO at VRChat.
He has run the process five or six times, including several times at Meta, and tuned it each round.
Strategy is a forced choice about where scarce resources go. It sits between mission and vision above and the roadmap below, at company or team level. It has three parts: a handful of pillars, many explicit non-focus areas, and the why behind both.
In his words, it "forces choice to deploy scarce resources to generate maximum impact".
He holds the line at three pillars, not five. Three gives more clarity and focus, and each pillar should be differentiated. He says to try hard to hold it at three rather than three to five.
Differentiation test: if another team or company could build it better, it is probably not differentiated.
He uses resonance from physics to explain product-market fit. Most frequencies barely move an object, but one near its natural frequency makes it vibrate far more. A product that matches its market gets the same outsized response.
Zynga ran on three clear pillars and clear non-focus areas. Every game shared viral loops, paying to complete and a cross-promotion network. High-fidelity graphics and complex game mechanics were explicitly out. Zynga was the fastest company to a billion dollars in revenue at the time.
Systems reinforced the pillars: strong data infrastructure and a Central Product Management function spread best practices. The shift to mobile temporarily broke the fit between product and market.
Chandra budgets the full eight to twelve weeks up front. Preparation takes about four weeks, the strategy sprint one week, the design sprint one week, document writing one to two weeks and rollout two to three.
People expect a couple of weeks, but iteration stretches it anyway, and a strategy pays back over about two years. If a CEO wants it in two weeks he looks for shortcuts but pushes for the time.
He builds a small cross-functional working group, not a solo PM effort. Engineering, product, design and data are the minimum, with product marketing and user research as a bonus. The PM facilitates, but the group co-writes the strategy.
Because the work comes from the team's leads, it feels "familiar and easy to accept" at rollout.
He interviews leaders first, to avoid the mango, apple, banana cycle. Each member interviews a leader on what success and failure look like, how success is measured, which principles to keep in mind, and their favorite ideas.
A leader who rejects a mango, an apple and a banana in turn is best asked first, "Do you even like fruits?" Leaders often hold back pet ideas to avoid seeming to micromanage, and they enjoy the conversation.
He condenses existing knowledge into one private master readout. Six parallel workstreams run alongside day jobs: past analyses, user research synthesis, leadership interviews, competitor stack charts, adjacent team roadmaps and user observations. All merge into one comprehensive preparation readout, shared with no one before the strategy sprint.
Competitor stack charts are read from what rivals release, since their strategies are unknown. Watching or interviewing a real user builds empathy and softens preconceived ideas about what to build.
Day one puts the whole group in the same state of understanding. Each person shares what they collected, and everyone writes down user problems, blockers to growth and weak spots in the business. The process is built around problems on purpose.
Day two is where the choice gets made. The group logs problems in a spreadsheet and clusters them into 10 to 15 areas. Each cluster is renamed as an opportunity, for example difficulty finding things becomes discovery. The top three become pillars and the rest are explicit non-focus areas.
He calls it "the most important day in the entire 8 to 12 weeks because that's where you actually make the choice".
He scores opportunities on impact, certainty, levers and differentiation. High, medium and low scores are fine when data is thin. The value is in the group debating why a score should be higher or lower.
Certainty asks how concrete the evidence is, and clarity of levers asks whether you know how to solve it. The table goes in the doc appendix so the choice stays defensible.
Each pillar becomes two or three how might we questions. This takes about an hour. The phrasing opens the mind to ideas more than "how do we", and designers already know it.
Day three sets a two-year aspiration through newspaper headlines. Everyone writes the headline a journalist would run in 18 to 24 months about progress on the pillars, in plain language naming the benefit to the world. Common words merge into one statement.
At Meta, the privacy team's version was that Facebook had moved the needle on consumer trust. Everyone sees their own words in the result, which helps buy-in.
The design sprint turns pillars into concepts, not features. The design lead runs it for a week with the PM in the back seat. Input is the pillars and how might we questions, and output is many illustrative mocks.
The goal is explicitly not feature-ready designs. Concepts answer "what exactly are you going to build?" and later sit inside each pillar's section of the doc.
The PM writes the doc alone, in one to two weeks. The insights, pillars, questions, aspiration and concepts already exist, so the work is editing them into one story. The working group sees a draft at the end only, sparing their cycles.
He admits it does not make the job easy, because weaving a good story is still hard.
He keeps the doc to three or four pages and leaves out the roadmap. It runs: leader context, insights and analysis, pillars with the why, the winning aspiration with concepts embedded, then alignment questions. The scoring table and extra concepts go in the appendix.
Resourcing is a roadmap question, so it stays out of the strategy phase. At most an illustrative roadmap goes in the appendix.
He rolls out in three layers, starting with gatekeepers. First comes a one-on-one with the two or three people whose blessing is required, then key stakeholders async or in a group, then roadshows of eight to 10 people.
"The purpose of this stage is to land it. It's not to seek too much feedback." He clarifies and updates the doc but defends the three pillars with the criteria, and in five or six attempts the pillars have not changed.
He keeps his manager lightly in sync throughout. He interviews the manager early, pre-flights the pillars and what will not be done on day two of the sprint, and later enlists them in bigger meetings.
The touch should be super light and adjusted to each person's style.
Zynga's clear strategy left him without the skill of making one. He only had to produce new games that applied the existing strategy, so he never exercised the muscle. That became his blind spot at Headspace.
He uses the fish parable: you don't notice the water until it is gone.
The same process gave opposite outcomes for Oculus and Portal at Meta. He stood up product growth teams for both, aiming to drive hardware sales through software features, with nearly identical pillars. After 18 months Oculus graduated into the VR division and Portal was sunset.
Features included the Oculus Referrals Program and Portal Memories integration. The Portal team was redeployed to other initiatives.
He judges a strategy by its results and pivots honestly. It takes intellectual honesty, humility and courage to say what is working. Parts of a strategy may work and parts may not, so pivot away from some and double down on others.
He says to spend as little time as possible to reach a strong hypothesis, since small S should take no more than two or three months.
Small S fixes present problems, and big S adds an aspirational future. Small S works "present forward" on a two-year horizon and is typically led by product managers. Big S works "future backward" on a three, five or ten year horizon and can take up to about six months.
He cites Elon Musk: life has to be about more than just solving problems. The roadmap combines both, like building a bridge from both sides of a river.
Big S ends in three distinct futures built as concept cars. It starts from mission and cultural, social, competitive and technological trends, then interviews on what a user's day and the product look like in five to 10 years. Prototypes are tested with a handful of users through UXR, then winners go into live product tests.
Concept cars are never commercialized but inspire, and a feature may move into production. For travel, the three futures could be autonomous, extreme speed or virtual.
He picks low-ego integrators to lead the open-ended work. Design and UXR lead big S, not PMs, and the leaders should be blue-sky people who connect diverse viewpoints, not people who first ask how it moves a metric.
Both processes bring dead ends and self-doubt before they satisfy, so he keeps a playful touch. At VRChat, small S and big S are "two tributaries that ultimately merge into one river".
He uses AI as a research assistant in preparation. It can run trend analysis on competitor release notes, analyze competitor reviews and build head-to-head heat maps. Open questions like why a new product is succeeding usually return good hypotheses.
AI mock strategies are useful input, but humans must choose. Asked what VRChat should do to grow, the tool gave a well-informed draft. Its weakness is that it recommends investment in a vast number of areas, while strategy must be focused.
The down-select needs judgment specific to the company, which is why he calls it a "mock" strategy.
He pairs generative AI with bandit experiments for onboarding. Multi-armed bandits find winning variations fast, but the variations are still human generated. Generative AI could produce them and may find an onboarding no human imagined, possibly different per user or territory.
He expects AI to eventually beat human judgment at strategy. He foresees a crossover point where processing many signals together beats human judgment. He compares a Tesla on full self-driving using six cameras at a turn with a human looking one way and then the other.
He sees the PM's job shifting toward architecting bigger pieces of product for agents.
He reads creativity books to think about how great products get built. He cites Walt Disney's biography, where Disney loved theme parks because he could keep tinkering and watch real reactions, Ed Catmull's Creativity Inc and Tom Kelly's The Ten Faces of Innovation.
He describes Disney's tinkering as A/B testing before the term existed.
He treats ease in a build as a warning sign. Citing a 1995 Steve Jobs interview, he says great craftsmanship lies between a great idea and a great product. He asks whether there is enough pain in a build, as a proxy for whether it is great.
He asks people to treat his framework as open source, test it, modify it and share what worked, since the community owns it.