We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI is widening the gap between output and understanding. Aakash Gupta describes teams where specs, code, tests, PRDs, tickets, and resolutions are generated while people work 12-hour days and nobody reads; his counterpoint is that AI is excellent at divergent exploration, but PMs still have to decide what ships and what “good” means. The practical response is to make convergence explicit: read the prototypes, bring concrete observations about where they break, define evals, and use a taste filter to kill most ideas after dogfooding.
Hiten Shah calls the underlying capability orientation: maintaining a useful picture of reality while it changes, then asking where the company is, what is actually happening, what matters, what changed, what was learned, what comes next, and what can be ignored. Run those questions for ten minutes before an important decision, during planning, or after a launch; keep the questions stable while the answers change.
Enterprise AI is separating decision work from generation. Productify’s analysis frames Jev as an example of a cheap, fast layer for high-volume typed judgments, with frontier models reserved for generation and complex reasoning. Before adopting that pattern, audit 10,000 API calls: measure short outputs, find regex- or enum-parsed decisions, identify reasoning that gets discarded, and price the cost of one wrong decision. The article cautions that its savings figures are assumptions and that vendor comparisons remain incompletely verified. Model routing is therefore a product decision about error cost and failure visibility, not just an infrastructure optimization.
Tactical Playbook
Turn sales feature requests into demand tests rather than roadmap commitments.
- Talk directly with customers, find common denominators across requests, and connect them to an end-to-end use case that customers or the team can pressure-test.
- Ask whether a promise to build the feature would change a contract; whether it blocks a near-fit deal or is one item among many; whether it creates meaningful value for existing customers; and how frequently prospects request it.
- Validate the underlying problem independently. Buyers may cite competitor features to negotiate price, so sales-reported demand is a hypothesis, not proof. Focus on the size of the problem, not merely the wording of the request.
The output should be a deliberate choice to strengthen the core, broaden the market, or reject the noise—with evidence for whichever path you take.
Case Studies & Lessons
Aha! changed its roadmap at the prototype-to-production boundary. PMs repeatedly asked for prototypes to integrate with other systems and perform real work. Aha! responded by building tools that let PMs with no coding experience build, run, and operate working applications instead of handing them to engineering. The lesson is to evaluate prototypes against operational ownership and real workflow integration, not only whether the demo looks convincing.
Career Corner
The Senior PM-to-Director path is not a standardized title ladder. The roles between Senior PM and Head or Director—Lead, Group, Principal, and Product Lead—vary widely or do not exist at all. One new Director reports that their previous company had no succession structure, so they moved externally, acknowledged gaps, and learned that the job also includes hiring, team development, tools and suppliers, and stakeholder management across directors. Map those gaps before applying and target a role with real support; an external move may create promotion and compensation leverage, but leadership experience is what makes the move credible.
Tools & Resources
Use scoped context, not a giant CLAUDE.md. Aakash Gupta says an exhaustive context file hit limits quickly; the fix was to decide what each agent is allowed to see and maintain a map rather than forcing every agent to hold the entire history. He cites a DoorDash example where one query used about 3% of the context window and retrieved a three-month-old decision in roughly 15 seconds. Pair that approach with a shared, queryable Team OS containing documents, metrics, and customer calls so AI output remains traceable.
Build for autonomy, not default collaboration. Sellis argues that collaboration carries coordination costs that can make a system move as slowly as its slowest node; at high-growth companies, PMs should be empowered to make decisions founders would have made six months to two years earlier. Give the organization a shared, memorable strategic ideology plus explicit decision owners and decision rights, allowing teams to act without constant coordination.
Define core product value as both a sentence and a measurement system. Translate a compact promise into component behaviors and causal metrics: Snap framed its value as the fastest way to share a moment with people you care about, while Discord framed it as the best way to talk and hang out with friends before, during, and after playing games. Use the phrase in roadmap decisions, define operational metrics tied to retention, and repeat it in onboarding so PMs, engineers, and data scientists share the same operating model.
Look for growth in the core before expanding. For network-effect consumer products, improve performance, relevance, and frequency for existing users; even small DAU/MAU gains can outperform acquiring new monthly users because DAU/MAU is a form of next-day retention. At Snap, refocusing after the 2018 redesign on Android performance for existing users led to a multi-year growth renaissance; at Discord, the 2024 focus on making multiplayer gaming better before, during, and after play produced what Sellis described as among its fastest post-pandemic growth.
Use evidence-led adjacency and backcasting for new bets. Expand in concentric circles from the core capability, and treat unexpected use or user workarounds as evidence of demand worth making easier. For more radical bets, backcast from the ideal future experience rather than forecast incrementally from current technology—for example, asking what the best way to share a moment would be without assuming today’s phone is the interface can point toward products such as smart glasses.
Make systems thinking operational. Rather than treating systems thinking as only asking “why” repeatedly, map the system in a spreadsheet: variables, inputs and outputs, levers, and the distributions behind those levers. Sellis says the model can clarify the system even if it is never used beyond the team’s shared drive.
Treat product restraint as a PM skill, especially with AI. Sellis assesses taste partly by asking about high-quality ideas or prototypes that a candidate deliberately did not ship; a curator who puts the entire collection on the wall has not curated. As AI tends to add features rather than remove them, product teams need to push back on low-value additions and actively decide what to cut.
Hire for productive contradictions. A strong PM combines confidence and conviction with humility and precise credit-giving; process discipline with comfort in ambiguity; and long-term system-building with urgent day-to-day bias for action.
Manage high performers through stretch and trust. Sellis describes giving consistently strong people more decisions until they begin making bad ones, defending them publicly, and treating limited intervention as trust when he knows they can execute; he also cautions that inattention must not be mistaken for failure.
Separate product love from monetization fit. Snap’s advertising challenge was structural: its disproportionately young audience faced tighter ad tracking and targeting constraints, its camera-first creation flow had no natural ad slot, and messaging apps lacked strong ad formats. The product lesson is to evaluate monetization against user intent and interaction model, not engagement alone; Snap could have a highly successful consumer product while still struggling to build a much larger advertising business. For ad products, Sellis’s “long-term greedy” rule is to optimize advertiser ROI today—even at some short-term revenue cost—because ROI supports retention, larger future budgets, and long-term revenue.
- Operating model, not PM capability, is often the failure point. One commenter argues that PM has not inherently become project management; rather, companies can create an operating model where limited customer access and little influence over what gets built turn PM work into managing tickets, timelines, and stakeholder requests. A practitioner at a well-known tech company reports executives mandating features users did not want, with those features quietly sunset after roughly 12 months, while an F500 practitioner says a handful of executives make product decisions based on opinion alone.
- Automation is accelerating execution without replacing discovery or reducing PM load. A practitioner at a large European tech firm reports automated workflows that produce mockups, check requirements against existing code and documentation, draft feature-related text, and generate acceptance criteria and use cases; they say validation, strategy, and decision-making have changed little, and a one-hour customer meeting still takes one hour. Another practitioner says they can build five times as much with fewer collaborators, but now drive five initiatives that each require the same non-building product work, leading to exhaustion and insecurity.
- Practical discovery tactic: To get past sales and management gatekeepers, one commenter recommends asking to attend sales, retention, and customer-support calls, observing the first few, and then building trust by demonstrating value when customers raise product-specific questions.
- Reclaiming PM agency can require an explicit career bet. A practitioner says they asked their manager and manager’s manager for control of the roadmap and prioritization of larger work; they describe this as staking their reputation and job, with looking elsewhere as an option if the organization refuses to grant that responsibility. The same commenter reports that domain knowledge helps PMs catch low-quality AI-generated work and that the market increasingly expects a broader technical, analysis, project, and product skill set.
- Domain expertise versus transferable PM skill remains context-dependent. A mature-business product leader says junior PMs need little domain experience, while mid-level and senior hires need it because fundamentals and process are teachable but 5–10 years of domain experience are not; they would waive the requirement for a novel capability such as agent orchestration. A different hiring perspective prefers a strong PM who thinks in user needs over a vertical insider who may reproduce competitors’ products, while an infrastructure-product leader says PMs need to stay current on the domain because their customers are other engineers.
- Output metrics can displace outcomes. A fractional PM with experience across industries reports seeing analytics tools used as validators of opinion rather than drivers of insight, KPIs treated as quotas, shipping volume rewarded regardless of user or business relevance, and PM roles absorbing program and delivery work.
- Design teams for autonomy: Peter Cis argues that collaboration carries coordination costs and can make an organization move as slowly as its slowest node. His alternative is a strongly shared ideology or mission, short repeatable strategy language, and explicit decision ownership through directly responsible or single-threaded individuals, so teams can act without constant coordination.
- Operationalize core product value: Define core product value both as a memorable statement and as metrics causally linked to retention. Snap used a formulation around being the fastest way to share a moment with close friends, while Discord defined its value around talking and hanging out with friends before, during, and after games. Use the phrase and metrics together to test roadmap priorities, onboard new hires, and align product, engineering, and data teams; a phrase without metrics is hard to action, while metrics without a shared story are weakly motivating.
- Find growth in the core before expanding: For network-effect consumer products, Cis recommends increasing daily use and the DAU/MAU ratio among existing users rather than defaulting to acquiring more monthly users. At Snap, a post-2018 redesign flattened DAU, and a renewed focus on Android performance for existing users led to a multi-year growth renaissance. At Discord, concentrating in 2024 on making the core gaming experience better before, during, and after play produced what Cis describes as some of its fastest growth since the pandemic, including movement from roughly 10 to 11–13 usage days per month among core users.
- Expand through evidence and backcasting: To move beyond the core, map the product’s strongest capability to adjacent cohorts, and treat users who overcome significant friction to use the product in a new way as evidence of real demand. For more radical bets, backcast from the ideal future way to accomplish the user’s job rather than merely remixing current technology and constraints.
- Make systems thinking concrete: Model a product system in a spreadsheet by listing its variables, inputs, outputs, levers, and underlying distributions; thinking in stocks and flows and repeatedly asking why can expose first principles even if the model is never used operationally.
- Develop the paired traits of a strong PM: Cis describes great PMs as combining confidence with humility, process discipline with comfort in ambiguity, and long-term thinking with a highly urgent bias for action. The confidence also helps them give precise credit to designers, engineers, and other collaborators without feeling that recognition diminishes their own contribution.
- Treat restraint as a product skill in the AI era: Product taste is demonstrated not only by good ideas but by shelving high-quality prototypes that should not ship; Cis recommends probing candidates about ideas they built and deliberately held back. As AI makes creation easier and tends to add rather than remove, PMs increasingly need to challenge unnecessary additions and preserve only what merits user attention.
- Use a long-term-greedy monetization principle: In advertising products, prioritize advertiser ROI today even when that sacrifices short-term revenue, because ROI supports future revenue through advertiser retention and larger budgets. Cis used this principle at Snap, Discord, and in advisory work to create organizational permission for long-term decisions under revenue pressure.
The thread centers on a cybersecurity PM who reports that emerging LLM-based reverse engineering could undermine the security value his product provides, while he is six months into product management and struggling to prioritize the roadmap alongside competing work.
- Treat AI disruption as a strategy and portfolio problem, not just a feature backlog. Use PESTLE to model future operating environments, map their effects to Porter’s Five Forces, compare the product with rivals through SWOT, and revisit product, price, promotion, and place; the roadmap should show how strategy will be delivered rather than simply list features in time order. If analysis indicates that a currently profitable product will soon become loss-making, explicitly consider end-of-life instead of letting sunk costs delay the decision.
- Run security resilience as a parallel delivery track. Separate security hardening from the customer-facing roadmap, fund it through maintenance where possible, align fixes with roadmap milestones, obtain sign-off on known gaps and temporary mitigations, and maintain a longer-term communication plan.
- Build defensibility beyond easily reproduced code. Prioritize domain expertise, customer trust, and market understanding; use AI to help engineering ship faster while exploring AI-led product capabilities. For products with sufficient scale, differentiation, and complexity, purpose-built agents can provide the operational logic, controls, and evaluation work customers would otherwise have to design themselves; a generic app or MCP leaves that operational burden with the customer, and the commenter cautions that products replaceable with a few weeks of coding have a weak moat. If the underlying code is readily reproducible, enterprise support, customization, and managed services are proposed alternative value models.
- Keep quality and governance in the cybersecurity product strategy. One practitioner warns that AI-based code analysis can have very high false-positive and false-negative rates, while classification and proof of exploitability are harder and more expensive than detection; language coverage, data governance, and IT-regulatory support remain important.
- AI product architecture: Separate high-volume, decision-only work from generation and complex reasoning: use a fast structured-output layer for tasks such as support routing, fraud flags, security triage, invoice approval, and agent action selection, while reserving frontier models for richer outputs.
- Economics and caveat: In an illustrative support-routing scenario, shifting 45% of a 100-billion-token monthly workload to Jev reduces the modeled monthly cost by about $65,610, or 44% of the total routing bill; these are calculations based on stated assumptions, not observed results. The article recommends treating the broader 30–70% savings range as a planning scenario because independent benchmarks are limited and several vendor claims could not be independently verified.
- Build-versus-buy trade-off: A decision-layer model offers pay-per-decision economics and no infrastructure or training loop, whereas a fine-tuned open model may be cheaper at extreme scale and provides weight control when a team has strong MLOps capacity; frontier APIs remain the broadest but most expensive buy option. The main product risks are unauditable wrong decisions, calibration drift, labelled-data and continuous-sampling requirements, added routing complexity, and vendor lock-in.
- Evaluation and rollout method: Before adoption, audit 10,000 API calls; measure how many return fewer than about 20 output tokens, identify regex- or enum-parsed outputs, locate reasoning that is generated but discarded, and quantify the financial cost of one wrong decision. Use those findings to select a single workload for a pilot rather than migrating broadly.
- Use orientation as a recurring product-prioritization loop. Orientation means maintaining an accurate enough picture of current reality to decide what deserves attention. The core review asks: where are we, what is happening, what matters now, what changed, what did we learn, what should we do next, and what can be ignored? Run the questions lightly before important decisions, during planning, and after launches; keep the questions stable while updating the answers.
- Ground roadmap decisions in observed behavior, not summaries. Separate the company’s current state from the story people tell about it, then investigate customer workarounds, repeated sales objections, internal spreadsheets, and actual feature usage. Multiple layers of summarization can turn a useful customer signal into an inaccurate roadmap item, so reconstruct what happened close to the work.
- Prioritize constraints while continuously revisiting assumptions. Find the problem limiting the system, but reassess it after each intervention because solving one constraint can expose another and make the previous framework a source of inertia. Explicitly ask what is true today that was not true six months ago—and what stopped being true—because strategy can expire as markets, capabilities, or workflows change. Treat learning as evidence that changes the team’s model of the world, and favor actions such as narrow launches or pricing changes that both advance the product and test an important assumption.
- Optimize for update speed and attention efficiency. The OODA loop frames orientation as the step where new information meets assumptions and mental models; update speed is the gap between evidence arriving and the company changing its mind. Make being wrong cheaper so teams can surface statements such as “we misunderstood this customer” or “this feature is not working” early enough to act. Since attention is limited, leave requests and opportunities below the current cost-of-attention threshold alone when orientation shows they do not deserve a response yet.
- Aha! encountered a recurring “prototype meets production” gap: product managers wanted prototypes to integrate with other systems and perform real functions.
- In response, Aha! reshaped its roadmap to build tooling that enables PMs with zero coding experience to build, run, and operate working applications themselves instead of handing the app to an engineer.
- Peter Ellis frames product taste as restraint: knowing when to stop and shelving strong ideas that feel premature, rather than only abandoning ideas after poor test results.
- A practical interview tactic is to ask candidates about high-quality things they built but never shipped; a strong answer can reveal whether they have exercised the judgment to say no.
- Andrew Chen flags on-device AI-native mobile functionality as an emerging product direction, but notes that strong LLMs remain difficult to run on phones because of slow memory bandwidth, the need for highly quantized MoE models, and power/heat constraints; next-generation mobile NPUs are targeting more modestly sized LLMs.
- The nearer-term product opportunity is fast, low-cost AI decision models embedded in mobile UX, including notifications, typing/texting, inboxes, and calendars. A longer-term hardware approach would encode an older but still useful model directly into the phone chip, though the post presents this as a possibility rather than a validated roadmap.
- AI model launches may face near-immediate open-weight competition: Following Jev’s launch, Andrew Chen observed U.S. AI developers shipping their own open-weight models within a few days, was tracking 2–3 early efforts, and anticipated additional alternatives from Chinese developers. For AI PMs, this signals that launch planning and differentiation assumptions may need to account for a very short competitive window.
- Treat incoming feature requests as problem signals rather than roadmap commitments: talk to customers, identify common denominators, and connect them to an end-to-end use case or experience that is pressure-tested with customers or through internal dogfooding. Also focus on the underlying problem, using data to identify a problem of significant size before solutioning it.
- Evaluate demand with four checks: whether customers would sign if the feature were promised, whether it blocks near-fit deals or is merely one of many requirements, whether it adds meaningful value for existing customers, and whether it strengthens the core product or broadens market fit; also track how frequently prospects request it.
- Treat sales-reported feature requests as hypotheses requiring independent validation: buyers may cite competitor features as a price-negotiation tactic, so conduct your own user and customer research before committing the roadmap.
- Role scope varies by organization: PM and PO responsibilities can be bundled into one role or split across strategic product management and tactical backlog execution; titles alone do not reliably indicate where a role sits on the strategy-to-execution continuum. In top-down organizations, the decisions about whether and when to build may already be made, while bottom-up organizations give PMs more responsibility for bringing those answers to leadership.
- Core PM responsibility: identify valuable customer problems, decide what, why, and when to build, align the people needed to execute, and determine whether the shipped work solved the problem and created business value.
- Execution spans customer, technical, and business work: PMs may research customer pain and value, navigate engineering trade-offs, test with customers, and handle business requirements such as pricing, regulatory awareness, internal operations, sales training, marketing plans, and cost of goods.
- Stakeholder management is a central practical skill: when sales, marketing, or content stakeholders insist on a solution that research does not support, treat them like customers—understand their motivations and goals, show how an alternative serves those goals, make them feel heard, and escalate to leadership when they remain unreasonable. The commenter estimates this approach works about 90% of the time and builds trust for future prioritization discussions.
- Career progression becomes less standardized after Senior PM: Lead PM, Group PM, Principal PM, Product Lead, Head of Product, Director, and Distinguished PM titles vary substantially by company, and some firms omit intermediate levels entirely.
- Changing companies can be a practical route to advancement: one new Director reported that moving externally was easier for securing the promotion and created more salary-negotiation leverage, while another commenter described leaving for a higher-title role or fast-growing startup and later “boomeranging” back as a way to build credible leadership experience. Internal promotion remains valuable because the organization already knows the candidate’s readiness; external hiring without demonstrated leadership or management experience is viewed as a gamble.
- The shift from PM to Director requires more than strategy and roadmapping: the role includes selecting tools and suppliers, hiring and managing people, conducting 1:1s, team building, employee career development, leadership meetings, and stakeholder management across directors. A practical transition plan is to identify strengths and gaps, build a learning plan, be candid about missing experience while demonstrating willingness to learn, and target an organization with strong process, structure, and support.
- Peter Ellis’s product advice emphasizes that growth usually comes from strengthening the core product, and that strong product taste includes knowing when to stop pursuing an idea.
- The app positioned its product around a continuous health-understanding experience—combining dashboards, tracking, pattern detection, and proactive AI—rather than treating health as another topic for an AI chatbot. The planned proactive release would remember context, maintain history, notice changes, follow up, and surface suggestions, alongside onboarding and app redesigns.
- A positioning experiment can preserve broad functionality while narrowing the market-facing wedge: focus the landing page, terminology, content, and use cases on a specific segment, then expand if that segment responds. Niching should be used to discover which use case resonates, not necessarily to delete features from the underlying product.
- Product validation should be separated into stages: competitors with paying customers indicate category willingness to pay; usage and retention test product usefulness; conversion, retention, churn, and revenue test the viability of the business itself. The case also treats recurring post-launch use as stronger evidence than surveys or hypothetical purchase intent, and recommends using user behavior to decide which part of a broad product becomes core instead of continuously adding features.
- Privacy can serve as a product wedge in a sensitive category: the team says it does not store medical data on its servers, keeps uploaded bloodwork locally, and is investing in a more privacy-preserving architecture. A regional wedge was also considered: because the startup is Europe-based and the competing service was not yet available there, it considered focusing on Europe rather than competing head-on in the US.
AI-assisted product development: AI mandates can create teams where specs, code, tests, PRDs, tickets, and resolutions are generated while people work long hours and nobody reads the output; the core failure is using AI without enough human judgment. AI is strong at divergent exploration—such as rapidly producing prototypes—but PMs still need to converge by prioritizing what ships and defining what “good” means. A practical operating model is to: read prototypes and bring three concrete observations about where they break; use evals to define what “passing” means rather than arguing about speed, with Ankur Goyal citing 12.8 eval experiments per day for leading AI teams; maintain a taste filter that supports high prototype volume while killing most concepts after dogfooding; and build a shared Team OS containing docs, metrics, and customer calls so AI output is grounded and traceable.
PM interview preparation: Reframe judgment stories as technical evaluation stories. One example involved pausing a pricing feature for a full quarter after a model produced different prices along racial lines without an explainable cause; the author says the decision was followed by a promotion the next cycle. Structure the story around what failure looks like, who decides, and the threshold that stops a launch. Candidates should map their six strongest stories to the interview rounds they actually answer instead of repeatedly preparing them as generic behavioral responses.
Scoped context for AI-enabled teams: An exhaustive
CLAUDE.mdcan hit context limits quickly; the corrective approach is to decide what each agent is allowed to see and maintain a map rather than forcing every agent to hold the full history. Hannah Stulberg’s DoorDash team reportedly queries about 3% of the context window, enabling a new engineer to retrieve a three-month-old decision in roughly 15 seconds without asking anyone.
- Start with the user need, not conventional feasibility: The foundation was created because its founders believed artists needed both financial support and recognition; Nas argued that simply giving people money would not work for this community, leading to an award-show model that honored contributors. Recipients later joined the committee that selected future honorees, extending user participation into ongoing governance.
- Treat trust as a product requirement: Early outreach faced strong skepticism—some recipients thought the program was a scam or refused the award. Reframing the offer around celebration, dignity, and deserved recognition rather than a handout helped the program gain acceptance, while the first event and community circulation provided credibility.
- Launch rough, then refine through real-world learning: The organizers described the first event as a duct-taped startup launch; they learned from it, tightened and improved the experience, and by year four believed it was ready for wider reach.
- Track whether the service changes users’ lives: One recipient said the five-year grant enabled him to buy a house, move out of the projects, and gain a financial cushion after years of day-to-day instability.
The gap between a rough demo and a working product is continuing to shrink, according to Hiten Shah.
- A community prompt is gathering recurring workflow pain points from product, marketing, and analytics teams to identify opportunities for automation; suggested examples include A/B-test analysis and determining next steps.
- The author highlights current AI-tool constraints for complex, data-heavy workflows: cost, substantial user input and model tuning, and wait times.
- The proposed approach is to build and freely share tools addressing the most common pain points, with a colleague’s team participating.
- A B2B-focused tool automates the customer-feedback-to-Jira workflow: users upload a transcript or recording, extract feature requests and bugs, review and clean up the findings, create a Jira ticket containing quotes, speaker attribution, and notes, and receive a status update when the ticket is completed for follow-up with the requester.
- The tool is still early-stage: it can misattribute speakers and requires noise filtering, and it does not yet offer Teams or Slack bots.