We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Fewer PMs doesn't mean less product work
Ravi Mehta argues that a PM-to-engineer ratio "does not measure the PM's talent, bandwidth, or importance. It measures the organization around the PM" . The same 1:30 ratio can mean a founder with a clear strategy and designers close to customers. It can also mean "an exhausted ticket writer" building whatever sales or the loudest customer asks for . When companies treat PMs as overhead and cut them, the job shrinks to execution. Then nobody talks to customers, owns the vision, connects features to outcomes, or protects the quality bar .
His view is that AI "shifts the bottleneck from building products to judging what deserves to ship." So PMs should spend more time deciding direction and probably less time building . He offers a diagnostic built on his 12 product competencies. For each one, ask who is accountable, who contributes, what evidence shows the work is happening, and what would close the gap . The goal is not a target ratio: "You can eliminate the PM role… But the work remains" .
Aakash Gupta's examples of the "full-stack builder" model point the other way. LinkedIn replaced its APM program with an Associate Product Builder program. Rippling's CPO moved planning decks to markdown in a git repo. Some Freshworks teams went from 1 PM per 20 engineers to 1:1 .
Practitioners describe the cost when nobody picks up that work. A widely shared r/ProductManagement thread describes "slop bombs" from adjacent teams. Leadership is pleased by the higher output and asks, "Why do you need to spend time on discovery" . One commenter blames workload more than the tools: PMs are "asked to do multiple PMs worth of work" with no room to think . Another says people stopped reading docs because they can't trust them. A one-pager where every claim has a source or is marked as a guess still gets read . Lenny Rachitsky shared a related line from Marty Cagan: "I did not appreciate the lengths that people would go to in order to avoid thinking" .
Vistaly's AI rebuild of opportunity solution trees
On Just Now Possible, Teresa Torres and Vistaly's founders walk through V2. It is a ground-up rewrite: users upload interviews, get a snapshot of each, and an agentic workflow drafts and updates the opportunity solution tree . Nearly all of V1's functionality was rebuilt in two and a half months, after three years of building V1, and V1 signups were shut off to protect the rewrite . Lessons for AI PMs:
- Errors compound. If an interview snapshot is wrong, every layer above it inherits the error .
- Prompt changes run out. Balancing two opposing error modes took a repair loop in the orchestration, not a better prompt. A cheap code check (a node with too many children) screens cases before the costlier LLM judge, and the eval became a production guardrail .
- Answer first, then correct. Users want the answer and the ability to fix it, not step-by-step collaboration. The hardest problem is helping them understand what changed .
- Model upgrades aren't drop-in. Prompts are specific to each model and version .
On a similar note, a practitioner told someone switching into AI PM to spend three weeks on evaluation rather than vocabulary. Their advice: decide how you'd judge an agent's output as acceptable, wrong, or needing a human .
Building product sense
Deb Liu argues that product sense is learned through repeated feedback, "a comment on a document or feedback on a slide" . Her warning is that AI makes it easy to skip that loop and never learn from mistakes . Her advice: draft the spec yourself, ask "What is one thing I could have done differently?", and get your reps .
Model and subscription costs
The Product Compass tested models on 105 real bugs. Opus 5.5 nearly matched Fable 5.1 (41.7 vs 43) at two-thirds of the cost . GPT-6.1 Sol was slightly stronger and over 10x cheaper than GPT-5.6 Sol on complex tasks, mostly because it needed fewer turns . Separately, the author used up part of several plans' weekly allowances and priced each model call at public API list prices. The chart puts SuperGrok at 190x its price, Claude Max 20x at 45.3x, and ChatGPT's $100 and $200 plans at 10.25x .
Lenny called a DevDay announcement the "sleeper hit" : ChatGPT subscribers can now use their included usage in more than 16 partner products, including Devin and Notion, by signing in with ChatGPT .
Quick hits
- GitHub for AI PM candidates. Gupta says AI PM hiring managers check a linked GitHub. His rule: build one small thing a week .
- "Average Intelligence." Elena Verna: having an average marketer, engineer, analyst, and designer on hand is "better than some of the teams I've had" .
- Reusable research. Hiten Shah demos a product on Oct 2 that carries findings across tasks, so a competitor's packaging change found in a pricing review doesn't have to be re-explained for a launch .
- Vistaly rebuilt V2 around AI rather than layering AI onto V1, turned off V1 signups to focus on the new product, and reached early alpha users in 2.5 months. V2 turns three interviews into individual snapshots and an initial opportunity solution tree (OST), then synthesizes later interviews into tree updates. V2 also replaced V1’s overwhelming view of all OSTs with separate opportunity spaces; Teresa describes a company-wide KPI tree with a separate OST for each outcome as a more manageable model.
- Vistaly found that guided AI chat reviewing insights one at a time felt slow, so it shifted toward automatically extracting insights and linking them to the tree. Teresa’s observation was that many teams skip rigorous synthesis because it is difficult; in that context, AI doing the synthesis can improve on shallow synthesis, though the team is still exploring how to support collaboration and corrections.
- Tree quality depends on multiple analysis layers, from identifying key moments and opportunities in each interview to consolidating them across interviews. Vistaly encountered leading questions, non-interview transcripts, and apparently synthetic transcripts, prompting concern that weak evidence could produce trees that look authoritative; Teresa raised the possibility of flagging weak signals and coaching users toward better interviews.
- Teresa’s tree-generation evaluation found that prompt changes alone could not balance adding useful subgroups with framing their parent opportunities well. A targeted repair loop for nodes with too many children let the team address subgrouping separately from parent framing.
- As trees grow, users need to understand what changed rather than reread the entire tree, but large updates can be difficult to review as a dense set of changes. Vistaly was still working out how to give users a useful overview while allowing them to correct changes, and identified rollback/versioning as important when agents edit shared trees.
- In a two-repository test of 105 bugs that frontier models had missed, Opus 5.5 scored 41.7 versus Fable 5.1’s 43 for $58.53 versus $87.18; the newsletter also reports GPT-6.1 Sol as slightly stronger and over 10× cheaper than GPT-5.6 Sol on complex tasks, with fewer turns contributing to the cost difference. Its cache reads were 4× cheaper under a 95% discount the author said might be temporary.
- Sonnet 5.5 max scored 51.3/105, but used 1,497 turns over 287 minutes versus GPT-6 Astra’s 270 turns over 90 minutes; the author cautions that this run was too slow and expensive for agentic coding and its gains may not carry over to standard tasks.
- Pricing model calls from a slice of several plans’ weekly allowances at public API list prices, the newsletter reports API-value multiples of 190× for SuperGrok, 114× for Muse Code High Usage (Contributor), 45.3× for Claude Max 20×, and 10.25× for ChatGPT’s $100/$200 plans. These are sample-based figures; the exact Claude Max 20× allowance is unknown, and its multiplier applies to a five-hour window. The author notes that Meta’s Contributor option involves sharing data with Meta.
- Vistaly’s V2 is a ground-up rebuild of its continuous-discovery canvas: users upload interviews, get an individual snapshot for each, then use an agentic workflow to draft and update an opportunity solution tree. The team rebuilt nearly all V1 functionality in two and a half months after a three-year build, and stopped V1 signups to protect the rewrite.
- AI reliability depends on the whole analysis chain: an incorrect interview snapshot propagates into the tree. Vistaly tested four evals across 16 variants to address a tradeoff between missing subgroupings and badly framed parent opportunities; it used a code assertion as a cheap prefilter before an LLM judge, then fixed the seesaw with an orchestration-level agentic repair loop rather than prompt changes, turning the eval into a production guardrail.
- Vistaly’s UX approach is answer-first correction, not step-by-step AI collaboration. It taught the agent to log semantic moves such as merge, move, and reframe because a final tree diff can have multiple valid interpretations; helping users understand what changed remains the hardest problem.
- Data-residency requirements pushed Vistaly to Bedrock, including EU-hosted inference for European customers; model upgrades are not drop-in because prompts vary by model and version, and Bedrock imposes independent token limits.
Shreyas Doshi shared a free private playlist of 23 candid career Q&A videos, including guidance topics relevant to PMs: promotion to Director, choosing between IC and people-management paths, setting vision and roadmaps without deep domain knowledge, building credibility and visibility, and why startup PMs may have short tenures.
A software engineer with about two years of mainly frontend experience landed a PM internship at a well-known B2B SaaS startup without focused PM preparation. They worry about full-time conversion because former interns reportedly did not transition when headcount was unavailable, and say they need to build core PM skills from scratch. They applied directly, drew on startup experience for a basic understanding of PM, and kept interviewing while learning what was going wrong, but still struggle with APM interviews.
Marty Cagan says fundamentally good product work is about thinking, and he was struck by how far people go to avoid it. The full talk is linked here.
- A PM-to-engineer ratio does not measure a PM’s talent or importance; it reflects how product work is distributed. A high ratio can coexist with a strong culture where other functions share product work, or with a weak one where PMs are reduced to execution and nobody owns customer insight, vision, business outcomes, or quality.
- AI can accelerate coding, research synthesis, prototyping, and specification writing, shifting the bottleneck from building to judging what merits shipping. As building gets faster, customer understanding, strategy, quality, and judgment become more important—not less.
- PM roles can be eliminated or responsibilities distributed, but the work remains. Treat the 12 competencies as work a product organization must do: identify who is accountable, who contributes, what evidence shows it is happening, and where gaps need to be closed; the goal is not a target PM-to-engineer ratio.
- As media choices expanded, KCRW shifted its focus from making media to building a community, asking what would keep people connected and make them care enough to support it.
- KCRW resists assuming public radio should be boring and pairs journalism with cultural and entertaining material; Ferro argues fact-based media must be made as interesting and exciting as competing offerings.
- Apply a candid quality bar: say when an offering is boring, make hard decisions, and move on from what is not working to try something new.
Elena Verna characterizes current AI as “Average Intelligence,” rather than AGI: having average-level marketing, engineering, analytics, and design help readily available is still highly powerful, and she says it can be better than some teams she has worked with.
Product sense develops through repeated exposure to quality and feedback, not a fixed checklist; feedback on documents and slides helped the author build judgment. To strengthen that judgment, PMs should draft specs and presentations themselves, ask for small, frequent, honest feedback, and keep shipping to build experience. As AI makes it easier to outsource work, skipping the feedback loop can leave mistakes uncorrected and hinder learning.
Lenny Rachitsky called ChatGPT subscription access across partner products a “sleeper hit” from DevDay. Subscribers can use their included usage in more than 16 partner products, including Devin, OpenCode, and Notion, by signing in with ChatGPT.
The product concept is to preserve useful work when the question changes: a competitor packaging change found during a pricing review should carry into launch planning without needing to be explained again. The post says the product would be demonstrated tomorrow at 10 AM PT.
A PM managing two designers and 10 engineers said one designer on future initiatives gave updates only in 1:1s and seemed to be progressing slowly. Replies advised asking directly for progress on a regular cadence and probing timeline concerns; one commenter stressed that delivery outcomes remain the PM’s responsibility and suggested escalating if the designer is unresponsive or still not meeting expectations. A weekly show-and-tell where the designer brings deliverables was suggested as a concrete checkpoint.
- Docset differentiates itself from conventional VPNs with a managed mesh network: its founder says it spans 196 domains outside the public internet and lets users register domains, lease addresses, and set policy; it supports encrypted peer-to-peer calling, video, and chat . The founder says transfers run directly between phones without a server in the middle, with 20 GB given as an example .
- Its onboarding hides cryptographic complexity behind a familiar friend-invite flow: users solve a puzzle to prove they are human, receive a token, and share a certificate; trusting a friend unlocks direct phone-to-phone features .
- An early-stage B2B SaaS team approaching its fourth or fifth customer had three backend engineers, one frontend engineer, and shared quality work across developers, product/ops testing, and founder validation, with automated tests used where possible; the founder’s concern was whether growing workflow complexity and edge-case costs would outstrip that model.
- One proposed signal for hiring QA was an increase in corrections after validation as workflows and customers grow, particularly problems at the edges between workflows. The commenter recommended writing acceptance criteria before development, with developers testing their work and QA validating against the criteria and looking across the system.
- Counterpoint: a commenter argued against adding dedicated QA by default, warning that it can create handoffs and weaken shared ownership; they described a 60-engineer, ten-team organization with no QAs and quality owned by product teams. Another commenter recommended investing early in test automation, including end-to-end tests, while keeping quality, scalability, and performance with the builders.
Abliteration joined a16z Speedrun, with its product positioned as AI with user-controlled guardrails—“unrestricted, not ungoverned.”
Hiten Shah open-sourced 16 competitive-intelligence skills for AI, covering market briefings, positioning, pricing, launches, battlecards, deal prep, and win/loss; each skill teaches a different method . He teased a product built around the skills that would let those methods draw on market knowledge, but did not yet describe the product .
- PMs in the discussion report that AI-driven speed expectations alongside reduced staffing and heavier workloads can produce poorly validated PRDs and features, leaving teams to decipher proposals and start discovery under pressure. One commenter argues the core problem is being asked to do multiple PMs’ work without time to think, rather than AI itself.
- Suggested quality controls include requiring discovery or validation before supporting use cases, scoring AI-generated PRDs or other assets and requiring human review before approval, and making one-pagers distinguish sourced claims from guesses.
- A complementary way to use AI is to organize customer evidence and connect roadmap recommendations to measurable revenue impact—such as churn reasons or lost sales—so teams can prioritize engineering time rather than simply increase feature throughput.
For a three-week AI product management upskilling plan, prioritize evaluating outputs over learning vocabulary: choose an agent task and define what counts as acceptable, wrong, or requiring human review. A practitioner in deep-domain B2B says this evaluation question takes most of their time, with the jargon following from it.
Hiten Shah open-sourced 16 competitive-intelligence skills and said he would show a product built around them, with the aim of reusing market knowledge as the work changes instead of relearning the market each time.
Product management is not optional
At Meta, I found something surprising: PMs used to brag about how many engineers they worked with, like gym rats comparing their bench press.
I remember one conversation vividly. It started with the idea that the typical 1:5 PM-to-engineer ratio makes sense for the average PM, but the best PMs can handle much more. One PM bragged that he was working with 10 engineers and barely breaking a sweat. Someone else jumped in: “No, no, no. The best PM I ever worked with had 30 engineers.”
This got me wondering.
Was the PM supporting 30 engineers really three times smarter, better, or faster than the PM supporting 10?
At TripAdvisor, we stayed pretty close to the 1:5 PM-to-engineer ratio. Many of the PMs on my team then are now VPs and CPOs. It certainly was not a talent issue.
That debate has since moved beyond ratios. The question is no longer: How many engineers can a PM support? It is:
Do we even need PMs at all?
Build products customers can’t live without
The free Product Competency Toolkit dives deep into the 12 competencies that turn good product builders into remarkable ones. Updated entirely for the AI era, it explains how each competency is evolving — whether you want to improve your own craft, coach your team, or help your entire organization level up.
It’s for anyone building products across product, design, engineering, marketing, leadership, or a venture of their own.
The death of product management is greatly exaggerated
Claire Vo put the argument bluntly: “Product Management Is Dead (opens in new tab).” AI, she argued, can draft documents, process feedback, prioritize features, and generate wireframes. The traditional product trio is giving way to smaller teams of “AI-powered triple threats” who work across product, design, and engineering.
Brian Chesky created a similar stir when he said Airbnb had “got rid of the classic product management function (opens in new tab).”
Then Tom Verrilli, Whatnot’s chief product officer, went further: “We regret that product management exists (opens in new tab).”
The line sounds like an obituary. His actual argument is more interesting. Whatnot refuses to hire a PM simply because an engineering team exists. It adds one when there is a specific need. Verrilli believes engineers and designers should have enough customer and business context to make good product decisions themselves. Otherwise, a large PM function can “infantilize” capable partners by shielding them from that work.
Similarly, Brian Chesky’s view is more nuanced. Airbnb did not get rid of product work. It combined product management with product marketing, elevated design, and asked product managers to understand not only how to develop a product, but how to explain it.
The product role is shifting. That part is true. As AI takes on more coordination, documentation, and synthesis, the PM as project coordinator, requirements writer, and professional meeting attendee will fade.
What remains is the work that always mattered: judgment, strategy, and a deep understanding of customers. AI raises the stakes for all three. A team moving at 100 miles an hour needs stronger steering than one moving at 10. As building accelerates, knowing where you’re going becomes more important — not less.
A team moving at 100 miles an hour needs stronger steering than one moving at 10.

AI gets us to the hard part faster.
But that work does not have to live inside a traditionally defined PM role — and increasingly won’t. In the strongest product cultures, founders, designers, engineers, researchers, marketers, and others play an important part.
Which brings us back to the ratio question: When one PM supports 30 engineers, what’s really going on?
The PM-to-engineer ratio tells you where the work lives
A PM-to-engineer ratio does not measure the PM’s talent, bandwidth, or importance.
It measures the organization around the PM.

The more engineers per PM, the more product work the rest of the org has to carry.
A PM supporting 30 engineers might work in an organization where the founder sets a clear strategy, designers stay close to customers, engineers help define the product, researchers surface unmet needs, and marketers understand how the product will reach the market.
Or that PM might be an exhausted ticket writer supporting 30 engineers who build whatever sales, executives, or the loudest customer requests.
The ratio is identical. The product cultures are opposites.
The least and most product-centric companies can both end up with fewer PMs — for very different reasons.

Same headcount, opposite product cultures.
The least product-centric companies see PMs as overhead. In the name of efficiency, they cut headcount, whittling away at the role while encouraging everyone to build and ship. The visible work survives because it must. Tickets still need to be written. Questions still need answers. Releases still need coordination.
The job collapses to execution.

Urgent work fills the week; the important work gets squeezed out.
The important but less urgent work slips away:
Nobody talks to customers.
Nobody owns the vision.
Nobody connects features to business outcomes.
Nobody protects the quality bar.
The team focuses on building, not deciding what to build.
The most product-centric companies arrive at fewer PMs from the opposite direction. Product thinking is not trapped inside the PM function. Founders, designers, engineers, researchers, marketers, and other partners share the work. Their contributions amplify each PM rather than leave the PM stretched thin.
These companies have not eliminated product management. They have built a culture around it.
The 12 activities that cannot disappear
I originally created the Product Competency Toolkit (opens in new tab) as an individual development model. PMs use it to understand their strengths and gaps. Managers use it to coach people, evaluate teams, and make better hiring decisions.
But the framework can be read another way. The 12 competencies are not merely the skills of a strong PM. They are the work a strong product organization must do.

The 12 product competencies: the work a strong product organization must do.
The system covers Product Execution, Customer Insight, Product Strategy, and Influencing People.
There is a lot to master — and inherent tension in the work. Product builders must be empathetic and analytical, qualitative and quantitative. They need fastidious attention to detail and the ability to think in broad abstractions. The best are creative innovators and rigorous optimizers.
Join the Top 1% Builder Series
The Top 1% Builder Series is a free 12-part live workshop series (one week per competency) with Ravi for product managers, leaders, founders, designers, engineers, and builders who want to ship products customers love — with AI amplifying the judgment they already have. Live attendance is free. Replays and slides are available to paid Top 1% Builder Club members.
Product management is a team sport
Product management is consequential work, too broad for any one person to master. Remarkable products are built by teams. Each person contributes from a different vantage point, bringing the expertise, insight, and relationships needed to make the product better.

Product management draws on people across the company. Each ring shows who shares the work.
Engineering contributes to Product Definition, Delivery, and Quality. Design and research contribute to Voice of the Customer and User Experience Design. Data science brings Fluency with Data. Sales, marketing, operations, and finance help connect strategy to business outcomes. Team Leadership and Managing Up draw on everyone.
These people are not peripheral stakeholders for a PM to “manage.” They are part of the product system.
This is why strong product companies can run with very different ratios. A PM does not need to spend hours combing through data when the team has an excellent data scientist. A designer who is deeply connected to customers may shoulder more of the discovery work. An engineer can shape the product through prototypes, technical judgment, and a clear understanding of the user.
Lots of people can contribute, but someone still needs to own the outcome. Each activity needs the right people involved and a way to make sure the work happens consistently. Otherwise “everyone owns it” becomes another way to say nobody does.
Strong product organizations make this division of labor explicit. Weak ones copy the org chart, but miss the point.
When building gets cheaper, judgment gets more valuable
AI changes both the speed of product development and who can participate in it. It can generate code, synthesize research, create prototypes, and draft specifications. An engineer, designer, marketer, or founder can now bring a working prototype to the table instead of an opinion.
When building was expensive, capacity imposed discipline. Teams had to choose carefully because every direction consumed scarce engineering time. As that constraint weakens, teams can explore more ideas and produce more versions faster.
AI shifts the bottleneck from building products to judging what deserves to ship.

AI shifts the bottleneck from building products to judging what deserves to ship.
The challenge is no longer generating another option. It is knowing which option solves a meaningful customer problem, fits the strategy, meets the quality bar, and deserves to reach customers. Empathy, judgment, strategy, alignment, culture, and taste are not secondary to building. They determine whether faster building creates progress or noise.
The idea that everyone should be rolling up their sleeves and building is exactly the wrong one. We don’t need every PM putting a little extra pressure on the gas pedal. We actually need PMs and product orgs spending more time figuring out where we should be going — and probably less time building.
For teams that have been constrained by build capacity for as long as they can remember, the idea that not everyone should contribute to that build capacity is disorienting. But it is absolutely the thing that will separate the companies building what their customers want from companies that are just force-feeding their customers new features to clear their backlog.
Is your product culture shrinking?
The least and most product-centric companies can arrive at the same conclusion — fewer PMs — for entirely different reasons.
After rounds of layoffs, I worry many companies are watching their product culture shrink. The remaining PMs do not have enough bandwidth to do the full job, and the rest of the organization is not picking up the work.
The 12 product management competencies can help diagnose the problem and decide how to solve it.
Take the 12 competencies and ask:
Who is accountable for each one?
Who contributes?
What evidence shows that the work is happening?
Where does it slow down or disappear?
What closes the gap: sharper priorities, clear ownership, more people, or stronger partners?

Five questions to ask of each of the 12 competencies.
Be honest. Do not write “Product owns strategy” if nobody can explain the strategy. Do not write “Engineering owns quality” if bugs are piling up. Do not write “Everyone talks to customers” if nobody actually does.
The goal is not to return to a particular PM:eng ratio. It is to make sure the work to create remarkable products still gets done.
You can eliminate the PM role. You can flatten the team. You can distribute the responsibilities. But the work remains.
Product managers may be optional — but only if the rest of your company is ready to do the work.
Product management is not.
Top 1% Builder with Ravi is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
- A PM-to-engineer ratio does not measure a PM’s talent or importance; it reflects how product work is distributed. A high ratio can coexist with a strong culture where other functions share product work, or with a weak one where PMs are reduced to execution and nobody owns customer insight, vision, business outcomes, or quality.
- AI can accelerate coding, research synthesis, prototyping, and specification writing, shifting the bottleneck from building to judging what merits shipping. As building gets faster, customer understanding, strategy, quality, and judgment become more important—not less.
- PM roles can be eliminated or responsibilities distributed, but the work remains. Treat the 12 competencies as work a product organization must do: identify who is accountable, who contributes, what evidence shows it is happening, and where gaps need to be closed; the goal is not a target PM-to-engineer ratio.