缺了中间层，产品团队再忙也推不动指标

Perri tells the host that she has met many organizations convinced their main issue is training their people, but in her experience 99% of the time the problem is how they set goals and deploy strategy; once people are trained, they still lack context for what to work toward. She frames transformations as holistic: either someone inside must own the work, or leaders must be ready to move when outside help arrives. The issue is not simply skill acquisition but the direction and priorities that give skill a purpose.

By the time of the conversation, Perri says she has worked with north of 4,000 PMs—approaching 5,000—and more than 30 companies in deep consulting through Products Labs, plus hundreds more through training. Her current focus is training and education: she teaches second-year MBAs at Harvard Business School, runs Product Institute, an online school started in 2016 that has trained almost all Fortune 100 companies, and created CPO Accelerator for VPs and heads of product moving into the C-suite. She is also writing a book on product operations with Denise, her former VP of product at Products Labs.

Perri's consulting has spanned high-growth SaaS companies—including interim CPO work with Insight Venture Partners—as well as banks, pharmaceutical companies, and other organizations setting up product management for the first time. That range lets her distinguish between software-native teams that already treat product as central and companies still figuring out how software fits. In both settings, the recurring question is how to prioritize product work and connect it to company strategy.

For SaaS companies that already understand software, Perri sees the biggest product-management issue at the pivotal scale-up from product-market fit to rapid growth. At that point the company moves from a single product to a multi-product portfolio, must rethink its entire strategy, and has to focus instead of taking everything off the backlog. This is often the first time the company has to form a comprehensive, prioritized strategy and deploy it to hundreds—then thousands—of employees.

Some companies bypass that early growth phase because they can already see their second and third products and scale quickly, but Perri says they eventually plateau and face the same problem: rethinking and reprioritizing the portfolio. The recurring issue is how to set strategy, deploy it, communicate it well, and make sure product and technology work ladders up to a well-prioritized company strategy. For Perri, that is the biggest issue she sees in companies that already understand software but need to double down, build the org, and find the right people.

Perri says the need for a CPO often appears after the founder-led or junior product leader phase, when the company must pull together an all-encompassing product strategy and create strong communication between product and the executive team. A clear sign is when boards or executives say they do not know what is happening in tech or product and cannot tell whether goals are being achieved; if the person communicating those things is not operating at CPO level, that is a problem. To diagnose it, Perri asks teams what they are working on and why, then tries to ladder their answers into a strategy herself and see whether the connections exist.

If the ladder does not connect, she concludes that someone is not formulating and deploying strategy at the top—either there is no CPO or the current CPO is not right for the job. On org design, she looks for great PMs who are frustrated by a lack of direction, trouble hiring PMs, or many junior PMs without training, process, or a learning path; any of those points to a leadership gap at the product level. In her view, those symptoms are organizational, not individual.

Perri hesitates to give a single PM count, but says the critical junctions are more about strategy: around $20 million to $30 million in ARR in a high-growth company is often when a CPO arrives, and a portfolio with more than two products, geographic expansion, drastically new markets, a major transformation, or a merger can also trigger the hire. She would usually look at roughly seven to eight PMs as a starting point, depending on what else reports to the role. A CPO may oversee design, product operations, analytics, or even engineering when strong engineering leadership is missing and product needs to lead technology.

Perri treats head of product and VP of product as largely interchangeable functional leaders who implement processes, pull roadmaps together, and train lower-level PMs. The step to CPO is about interfacing with the board, understanding financials deeply, projecting revenue from roadmap and strategy, and working closely with the chief revenue officer, head of sales, and CFO. CPOs are also senior enough to oversee multiple functions, which is why a complex multi-product or platform strategy is where she starts looking for one.

Perri says she hopes companies never need her, but she is called in when a CEO is unsure what a product person does or whether one is needed. She talks through the CEO's challenges and shows which ones are caused by missing a product partner who could take work off the CEO's plate and free them for vision, fundraising, and other responsibilities. Consultants can advise, but Perri's stated goal is to put herself out of business by leaving strong product leadership behind.

She spent years doing deeply embedded transformation work—org design, strategy deployment, and teaching organizations how to do product management—before shifting to growth-stage companies with an objective to get in and out as fast as possible and bring in the right leaders. That experience taught her that someone must be at the helm consistently and must be able to make decisions, because hiring a consultant and ignoring the consultant changes nothing. She has seen companies hire her and then refuse to act, or expect her to do the leader's job for them.

With Insight Venture Partners, the premise became that Products Labs would never be hands-on in a company for more than three months. Within that time, the team aimed to hire a CPO, play an interim CPO role, keep delivery and growth on track, train people, implement some processes, and assemble the customer, strategy, roadmap, and interview context a new CPO would need. The new leader could then take time to build a strategy while teams kept moving.

Perri tells companies they are not ready for help unless they are ready to take action, sometimes drastic action: changing people, hiring more senior leaders to train the masses, reevaluating strategy, and setting a new course. She has met many organizations that think their issue is training, but 99% of the time she sees goal-setting and strategy deployment as the real problem. Training without that context leaves people unsure what to work toward, so transformation has to be holistic.

Perri's first sign that a company lacks strategy is teams working like dogs—80-hour weeks, constant crunch, and release after release—while none of the metrics move. Executives then ask what product and tech do all day, treating them as a black box. The missing piece is the middle layer that connects what each team is building to the company's vision, objectives, and goals.

She clarifies that there is usually some strategy, but it lives in people's heads and leaders are bad at writing it down. To surface it, she interrogates leaders: if we hit these numbers, is that good or bad, and why; if we release this thing, what numbers or behaviors will change; how will this make us better? That can pull out beliefs about goals, and sometimes reveals that different parts of the organization give different answers, which shows a lack of alignment.

At a healthcare company, Perri asked the executive team for the vision and heard “to be the backbone of healthcare.” When she asked what that meant, nobody could elaborate; she calls that a tagline, not a vision. A real vision explains what the company is becoming, what it will and will not do, who it wants to be in five to ten years, and how it will be different from today. Those things are often not written down or clearly communicated.

When strategy is absent, Perri has CEOs write two-pagers covering where the company came from, how it is different today, external threats, competition, what to care about and ignore, and what it will and will not do. They then prioritize strategic intents—big business movers for the next two to three years, such as going upmarket, going downmarket, expanding geographically, or innovating into a new market. Without that missing middle, teams spread too thin across many initiatives, and a shipped feature that no one knows about barely counts as shipped.

Perri's practical test is to ask every team what it is doing and why. If teams tell a similar story—we are working on X and Y because it feeds this initiative, creates this customer value, and helps us enter these markets—then they can connect tactical work all the way to business metrics. If people keep asking why they are building something, the leader has not explained what the company is after.

Well-deployed strategy also reduces infighting among stakeholders and executives. Perri sees trouble when executives have different goals—for example, sales chasing net-new logos without alignment to product roadmap priorities—or when a CEO pits executives against each other instead of making them one team. When everyone shares the same business goals, trade-off conversations become calmer and more objective: if we choose strategic intent one, we do not get intent two, and the team can decide whether that is acceptable.

Perri does not insist on a rigid template; she uses a company's existing format when it has one. The memo she describes is about two pages: the vision, how the company is positioned against competition, where it is today, what it will prioritize to get there, and what outcomes it seeks. She writes at different levels—executives write strategic intents, product leadership writes product initiatives, and teams write the solutions or options they will build—so the documents can be linked into a strategy tree.

She distinguishes product initiatives as meaty, problem-oriented efforts made of multiple epics, while team-level solutions are the specific things built to solve user problems and hit strategic intents. Each level can have a one- or two-pager explaining what it is doing and why, not a 20-page requirements document. Those pages live in Google Docs or a wiki and link upward so anyone can read the strategy tree.

Perri likes writing as the backbone of vision, but she has seen visual presentations work powerfully too. At athenahealth, a head of UX and a VP of product mocked up prototypes and diagrams of how customers interact with the ecosystem, which aligned people even though the visuals were not tested or final. She recommends combining a presentation with writing, especially because executives are often visually oriented; even rough sketches or ecosystem diagrams add color.

A vision should be concrete enough that people can picture it, but lofty enough that it is not achieved by shipping one thing. It should not describe what the company is today; if it does, the company has already hit the vision and is only tweaking or exploiting it. People should be able to say they can see how the company will get there one day even if they do not know the path today.

Perri's writing process starts with a brain dump: what competitors do that the company does not want to imitate, what value it could provide, who future customers should be, how the value differs from today, how it differs from competitors, and why it is better—not just “better” but the specific ways it will win. Good visions also say what the company does not want to do, which prevents teams from defaulting to copying a competitor.

Perri shares advice from a CPO who graduated from her program: even before she had strategy responsibility, she imagined what she would do in the CPO's position. Perri recommends that PMs pretend they are the CPO, ask what they would do differently, dig into data, and ask questions to build reps. They should also talk to people who understand the market and financials, ask leaders how they set priorities and analyzed trade-offs, and study how companies like Netflix moved from point A to point B; frameworks differ, but the common thread is asking questions, looking at data, and understanding customers and markets.

For leaders, Perri says a major issue is lack of data: many have never set strategy and do not know where to start. She tells them to start with internal data, hire a data analyst who can crunch numbers and surface patterns, bring customer research up to leadership, and put company goals in context. Strategy is asking how to win and get closer to the vision while staying grounded in where the company is now and what it can execute; leaders will not be 100% certain, so they must make the best-informed choice and correct course when information changes.

Product operations emerged from Perri's scaling work because standardized processes, comparable roadmaps, career ladders, meeting hygiene, data access, and customer research broke down at scale; at athenahealth, 350 PMs were hitting the same hospital contacts repeatedly. Perri describes three parts: an internal data and insights team that surfaces financial and user-analytics data for tracking OKRs and strategy; customer and market research that standardizes and records interviews so PMs can do research without duplicating outreach; and standardized cadences and processes for roadmap check-ins, quarterly planning, and interfaces with sales and product marketing. She does not want to standardize a team's own stand-ups—only the cross-functional interfaces and cadences. Not every company needs all three parts, and the starting point depends on where the company is.

For PMs overwhelmed by advice, Perri says the best learning comes from execution: focus on doing the job, analyze what is working and not working, and then deep-dive into specific skill gaps. She describes going down a rabbit hole on agile after seeing product owners write 8,000 user stories for tiny features, interviewing people who wrote the Agile Manifesto and taught Scrum to understand where the practice came from. PMs should build their own toolbox, run a personal retrospective, and drop processes—even dogmatic Scrum practices—that do not serve them, because everything is meant to be iterated and adapted.