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 moving PM work from document-first to evidence-first. Sachin Rekhi describes five shifts: teams replace weeks of detailed specs with prototype refinement; put prototypes in front of customers before internal review; let PMs and designers make small AI-assisted code or copy fixes; shorten roadmaps to six months; and have specialists build agents for analysis, research, and design. The practical change is to make the prototype the first learning artifact: use it to test behavior, discard weak directions cheaply, and write heavier documentation around decisions that survive customer contact.
Throughput is becoming cheap; judgment and exception handling are not. Anish Acharya says one Google team compressed two years of roadmap into three months and found the harder question was what to add. He describes loops that take input through reproduction, fix, review, risk-based approval, and deployment; humans remain needed for strategy, sales, support, exceptions, and out-of-distribution thinking. A current operating example from Aakash Gupta: OLX Uzbekistan’s CPO has run a shared agent for five months that answers feature, result, and roadmap questions; a personal assistant handles 70% of recruiting, and he estimates AI now takes on work that used to consume 50% of his time. The proposed architecture separates identity, memory, recurring skills, and tools.
Tactical Playbook
Run enterprise vision as decision extraction, not executive brainstorming.
- Start with people closest to workflows and users; map current-state gaps with the other PMs before asking executives for strategy.
- In the session, align on the business outcome, affected user, current cost, materially better state, and acceptable trade-offs. Return with a proposed vision, not a blank-page exercise.
- Keep the artifact small—outcomes, target experience, principles, capability gaps, and non-goals—and delay individual feature requests. Translate vague goals such as “improve customer experience” into a measurable outcome such as an NPS or PSAT change.
Make the source of truth earn its keep. Product knowledge scattered across PRDs, Slack, memos, and unwritten rules can create misunderstanding, onboarding friction, and unclear dependencies. A lean pattern is one frequently updated product document with a table of contents and timestamps, plus searchable decision records; practitioners say AI can help maintain and navigate the canonical record. But others report that a Confluence initiative became unused overhead and that junior-PM time disappeared into document organization. Apply the smallest artifact that answers repeated questions, then audit whether people actually use it.
Case Studies & Lessons
Sell the economic outcome, not “AI automation.” A legal engineer had built time-saving tools, but months of outreach, ads, and offer experiments produced no business; they were considering a free first automation. Community feedback suggests the blocker may be buyer economics: billable-hour firms may not retain the value of time saved, while in-house and flat-fee practices do. The recommended test is a paid, fixed-scope pilot with an NDA and a measurable before/after—hours saved, error rate, or billable time recovered—not free work. Treat this as a segmentation experiment, not proof that the new segment will convert.
Test the delayed value loop. An ecommerce founder tested checkout, emails, and the thank-you page, but a “subscription” was actually a one-time purchase; renewals never fired and the number of lost customers remained unknown. For recurring billing, add a daily reconciliation between the app’s active-subscriber list and Stripe’s subscription objects so a mismatch is caught before the next renewal.
Career Corner
Price ownership against lifestyle, not just title or cash. An eight-year PM is weighing a remote consulting role with brand, bonuses, and limited product ownership against a zero-to-one agentic-AI role with a roughly 60% raise and CEO visibility—but poor prior culture, three office days, and a commute of two-plus hours each way. The useful decision rule from the discussion is phase-of-life dependent: score decision rights, learning, manager quality, health and commute, and compensation separately; a demanding role can still be the better move when the work is more aligned.
AI-native operating model. Treat each job function as an input-to-impact loop; Anish Acharya describes a progression from agents—models with tools, memory, and skill files—to task loops and then cascades across functions and business units. A coding example runs from bug report to reproduction, fix, review, risk-based human approval, deployment, and customer notification in about five minutes. Humans remain essential for sales, support, strategy, and exceptions because loops plateau at local maxima and still need out-of-distribution judgment to identify the next hill.
Build measurable loops with human escalation. For growth, generate every experiment variant, measure each one, merge and ship after statistical significance, maintain a long-term holdout, and start the next experiment; reserve human intuition for escaping the resulting local maximum. When an agent gets stuck, have it call a human, coach it through the case, capture the trace, and treat the blockage as a knowledge or data gap to close with more context and direction.
Reframe PM throughput and judgment. In one anecdote, a Google executive said AI let the team compress two years of roadmap into three months, shifting the hard problem toward deciding what to add. Acharya argues that if every product story and feature can be tried or simulated, the winning idea need not be the one sold best to executives, and many PMs may discover they are better at developing a strong idea than inventing a weak one.
Allocate models by upside, not prestige. Use expensive frontier models where an extra unit of intelligence could unlock unbounded value, such as drug discovery; use cheaper, specialized or open-weight models for bounded functions such as legal or finance, while recognizing that even customer support can surface a strategic breadcrumb that warrants frontier reasoning.
Build durability through product and distribution. Moats are often discovered rather than designed: Cursor was initially criticized for lacking one, then accumulated reasoning traces and trained its own models; classic moats such as network effects, scale, brand, proprietary data, and cornered resources still apply. In a crowded launch environment, organic word of mouth across X, YouTube, and Instagram functions as a key third-party network effect, so teams should build products worth remarking on and ask whether a supposed growth problem is actually a product or ambition problem.
Design consumer AI around human needs. Acharya argues that people may want to spend time rather than merely save it, creating opportunities around feeling connected and loved, making progress, and having fun; he frames this as a product-design challenge, with cost, the gap between chat and more accessible interfaces, and an excessive focus on productivity as current constraints.
Career and sequencing tactics. Build a low-stakes project as a chassis for trying models, and ship something every week—even a small personal artifact—to build intuition; a useful starting point is something that brings joy or helps someone else. For startups, Acharya’s product lesson is not to build a product and a platform simultaneously: choose one.
- Design product and business work as AI-assisted loops, not fully autonomous systems. A loop can take an input such as a bug report through reproduction, fix generation, review, and deployment, with human approval for high-risk changes and automatic shipping for low-risk ones. The same pattern applies to growth: generate experiment variants, measure them, ship statistically significant winners, maintain a long-term holdout, and begin the next experiment. Humans remain essential for strategy, exceptions, sales, support, and ideas outside the model’s training distribution; when an agent gets stuck, a person should coach it, turning the interaction into reusable traces that close a knowledge or data gap.
- For AI consumer products, optimize for human outcomes rather than productivity alone. Strong opportunities address connection, feeling loved, progress, health, or fun; the speaker frames this primarily as a product-design challenge rather than a model-capability challenge. Chat may suit highly agentic users, but mainstream products likely need an interface between chat and TikTok; cheaper open-weight models and broader interaction patterns make this opportunity more accessible.
- Choose models according to the upside and economics of the job. Use expensive frontier intelligence where one additional capability point could unlock very large value, such as research, engineering, sales, or support; use cheaper, specialized or open-weight models for bounded-upside work where adequate performance is sufficient. The qualification is that even a routine support interaction can reveal a strategic breakthrough, so organizations may still need frontier-capable review paths for high-leverage signals.
- Treat moats as something to discover through shipping. Early momentum, craft, and growing engagement can justify building before a formal durability story exists; usage can reveal proprietary data or reasoning traces that later strengthen the product. Classic advantages—network effects, scale, brand, and proprietary data—remain relevant, while user experience and product harnesses can buy time to discover a deeper moat. In a crowded launch environment, organic word of mouth across social and video channels is a particularly valuable distribution path, but it depends on making something remarkable enough to discuss.
- Raise the ambition bar and test the strongest version of the product. The investor says ideas that once seemed too ambitious are now more attractive, while ideas that are too small may not justify engagement; a useful exercise is to ask what a dramatically more valuable—or even very expensive—version of the product would need to do.
- Build AI fluency through frequent shipping. Product people should choose a small project as a practical chassis for trying models, developing intuition, and learning through execution; the recommended cadence is to ship something every week, even if it is personally useful rather than commercially important. A related founder lesson is to avoid building a product and a platform simultaneously: choose one focus.
- BlockDex addresses a discovery problem: developers can search within a known shadcn registry, but first have to determine which registry to use. The product crawls public registries nightly and indexes individual components, blocks, hooks, themes, and utilities with install commands and dependencies; it reports 76,685 items across 978 registries, compared with 292 in the official directory.
-
Its pricing classification uses the exact item endpoint that installation would fetch: a returned source is labeled free, a
401response paid, and registries with no endpoint remain unverified. The reported inventory was 31,328 free, 10,943 paid, and 34,414 unverified; keeping unknown items out of the free count is a useful trust and measurement choice. - Coverage is designed as an iterative feedback loop: registries are discovered through seeds, GitHub code search, registry topics, and an ecosystem awesome-list, while users are invited to report omissions. The product also emphasizes no sponsored placement, an open API, and a public methodology.
- Use a decision-oriented, outcome-first workshop for cross-system enterprise vision. Rather than asking executives to invent a future state from a blank page, walk each major workflow through the target business outcome, who experiences the problem, current cost or consequence, what materially better looks like, and acceptable trade-offs; synthesize the answers into a proposed vision for leadership validation.
- Ground the vision in workflow evidence before translating it into delivery. Start with the people closest to the workflows and users, map current-state capabilities and gaps, model future-state workflows and requirements with other PMs, and inspect team backlogs for work that traces to the enterprise-wide problem. Convert vague goals such as improving customer experience into measurable outcomes—for example, an NPS or PSAT increase—rather than treating feature requests as the objective.
- Capture a compact decision artifact and delay local feature optimization. Record the outcomes, target experience, strategic principles, major capability gaps, and explicit non-goals; derive architecture and initiatives afterward, and avoid prioritizing individual feature requests too early because that can produce locally optimized lists without resolving the cross-system issue.
- Make the business case legible to executives. One proposed lens is to anchor the product frame to how the company makes money and use a mini-ROI: quantify manual workarounds or redundancies by volume, time, and resources to estimate dollar waste, while checking for lost revenue from workflow gaps.
- Product knowledge spread across memos, PRDs, Slack conversations, and unwritten rules can create cross-team misunderstandings, onboarding friction, and unclear dependencies.
- A practical single-source-of-truth pattern is one frequently updated product document with a table of contents and last-updated timestamps for each major section, used as the cross-functional reference when the PM is unavailable. A complementary wiki can link to dashboards and other teams’ information, while documenting the domain, value drivers, North Star, ICPs, and key user journeys; “super epics” can connect that context to backlog epics and improve alignment and handoffs.
- Make decisions searchable: one practitioner reports that hard-to-find decision records cause settled questions to reopen, while AI improved the maintenance and navigation of canonical records; another describes a lightweight AI-assisted wiki for recurring questions.
- Guard against documentation becoming process overhead. PMs report that a Confluence initiative became unused overhead and that junior-PM time was wasted on document organization; for current-state communication, a short deck that is reused, adjusted, and updated may be enough. Documentation should complement—not replace—the PM’s cross-functional presence, since product work is described as a function distributed across other departments rather than an insular department.
Hiten Shah says Instinct exposed a product boundary by pushing bots through it, framing the episode as continued experimentation until products improve. A linked activity log reports roughly 100–115 API requests per hour from continuous 4 Charles availability sweeps and 200–375 requests during morning drop bursts.
- The discussion offers four product-strategy prompts for AI-era PMs: identify a “/loop make me happier” opportunity, treat every company as a series of loops, assume moats are discovered rather than designed, and ask what the “Birkin bag version” of the product is.
- As a counter-signal to the “permanent underclass” and AI job-loss narrative, illscience, identified as an a16z general partner, says demand for radiologists continues rising despite long-running displacement claims, open engineering roles are at all-time highs, and every AI-stack layer has roughly 20 strong competitors.
- A product-building lens frames company building as creating a series of loops, with an AI opportunity described as “/loop make me happier.”
- The same discussion argues that moats are discovered rather than designed and prompts teams to identify the “Birkin bag version” of their product—an aspirational reference point for product differentiation.
- The discussion challenges the idea of a permanent AI-driven labor underclass: the job-loss narrative has not unfolded as expected, radiology demand has continued rising despite long-running automation fears, open engineering roles are reportedly at an all-time high, and each AI-stack layer has roughly 20 strong competitors rather than a mobile-era winner-take-all structure.
- It frames several product-strategy questions for AI builders: designing products around “loops” that make users happier, viewing companies as collections of loops, discovering rather than deliberately designing moats, and identifying the premium or status-defining version of a product—the “Birkin bag” equivalent.
Hiten Shah is gathering concrete workflow data from people with multi-Mac setups by asking what they open on remote Macs and how often, while recruiting a small group of early Beam users. This illustrates a lightweight product-discovery tactic: investigate real, nonstandard user workflows and recruit a focused early-user cohort.
- The discussion presents several product-strategy prompts for AI-era products: look for “/loop make me happier” opportunities, model every company as a series of loops, and treat moats as something discovered through the product rather than designed upfront.
- An AI labor-market counter-signal challenges permanent-displacement narratives: the discussion cites continued demand for radiologists despite long-running automation concerns, record-high open engineering roles, and roughly 20 strong competitors at each AI-stack layer. This suggests PMs should account for sustained demand and fragmented competition rather than assuming a single AI winner or inevitable job collapse.
- Hiten Shah’s hypothesis is that Instinct is using a free, compute-intensive product subsidized by $350M in venture funding to normalize a new agent-based behavior, echoing Uber’s early strategy of paying to establish usage habits. For PMs, this represents a deliberate trade-off between near-term economics and adoption.
- Instinct may also be building a data flywheel: each task reveals user intent, agent failure points, corrections, and successful resolutions. Greater access increases usefulness, while each successful task earns the agent an opportunity to handle the next one; this makes privacy a central product trade-off because more access drives both utility and learning.
- A concrete consulting-to-product career trade-off: after about eight years of experience, the author is weighing a fully remote strategy-consulting product/platform role with a strong brand, global exposure, good bonuses, limited product ownership, and weak salary progression against leading a CEO-visible, zero-to-one agentic-AI product at a former B2B SaaS company for an approximately 60% pay increase.
- The potential move exchanges flexibility for ownership: the new role involves a company with poor prior culture, a less prestigious brand, three office days per week, and a 40 km commute that could take more than two hours each way, while the current role offers remote work and a relatively relaxed lifestyle.
- The community perspective is to evaluate the decision against current life priorities and appetite for career growth; one commenter also reports that a more demanding role can still produce greater satisfaction when the work is more aligned with what the person wants to do.
Responses to a product interview request about reducing mundane PM work highlighted adoption risks. One commenter argued that very few PMs have the operating budget or willingness to navigate the purchasing process for a new tool, while another described teams that recognize the need for a tool but avoid finding one as “playing hot potato.” Another commenter warned that a product perceived as merely a rewrapped Claude would be ignored, underscoring the need for clear differentiation beyond a generic AI wrapper.
- A legal AI-automation agency had built custom tools that saved legal practices substantial time, but months of cold outreach, ads, and offer-positioning experiments had produced no business. For products that require customer education, first verify that prospects recognize the problem; the suggested discovery path includes time to explain the use case and hands-on work before presenting the solution.
- Segment the product around the customer’s economic incentive: in-house legal teams and flat-fee practices retain the value of time saved, while billable-hour firms are more likely to buy when automation addresses a capacity bottleneck they cannot hire for. A suggested initial segment is lean in-house teams with one or two attorneys and no legal-operations function.
- Replace a free-first offer with a paid, fixed-scope pilot focused on one painful workflow and a measurable before/after—such as hours saved, error-rate reduction, or billable time recovered. Use an NDA and clear scope to address confidentiality, liability for incorrect output, and concerns about what happens if the provider disappears.
- Validate the offer with a redacted case note, a verifiable customer result or reference call, and a walkthrough with the person who owns the workflow; track which roles respond and which workflows they mention, then change the buyer or workflow when outreach produces no replies.
- A product-adjacent professional with 5+ years across commercial analytics, strategy consulting, a founder’s office at a consumer AI startup, and some product-management work is seeking founder’s office, chief of staff, corporate/commercial strategy, or product-strategy roles. They are open to startups or large companies, relocation from Gurgaon, and fully remote work.
A UK healthcare Project Manager earning approximately £90k, with a healthcare/clinical operations background and experience running IT and software rollouts, is seeking advice on moving into UK HealthTech product work and progressing toward HENRY status.
A recent B.Tech CSE graduate is targeting an Associate Product Manager role and is seeking guidance on which skills to learn, what projects to build, and how to secure a first PM opportunity.
- Mikhail Shcheglov, CPO at OLX Uzbekistan, has run an AI “Company OS” for five months: one agent is available across the company for feature suggestions, feature-result queries, and roadmap questions. His personal assistant also flags important emails, manages his calendar, and handles 70% of his recruiting workflow; he estimates AI now absorbs work that previously took 50% of his time.
- The implementation model has four parts: SOUL (system prompt and identity), memory (raw transcripts → vector database → knowledge graph), skills (recurring procedures), and tools (systems the agent can access). Hermes provides self-improving skills and harness cleanup, while OpenClaw provides multi-channel messaging and a 24/7 heartbeat; the selection principle is to adopt infrastructure that removes maintenance burden rather than choosing tools for novelty.
- A founder paused a niche SaaS after completing much of the technical work because its economics did not make sense, then reconsidered it after technology and costs changed; meanwhile, a friend built a working product for essentially the same market, problem, and customers and planned a commercial launch.
- The decision framework suggested by the discussion is to clarify the overlap through an honest conversation before choosing a path: determine whether the friend forgot the earlier discussion, considers the approach materially different, or intentionally copied it; avoid partnering if the copying was deliberate, but consider collaboration on fair terms if the friend acknowledges the history.
- The central product-strategy lesson is that an idea has limited value without execution; a viable startup depends on executing well and combining multiple strong product decisions, while market timing and economics can change whether an earlier concept becomes worth pursuing.
r/ProductManagement post by u/chthonodynamis
Need guidance on establishing executive enterprise vision
I’m a Product Owner working across several interconnected enterprise applications, and I’ve hit a problem I’d love some coaching from people who have dealt with this before.
We have a number of systems and teams that have evolved somewhat independently over the years. Increasingly, the business wants experiences and workflows that span those boundaries.
The problem is that I feel like we’re trying to solve this backwards.
Individual stakeholders can tell us things they want (a feature, an integration, a new workflow, a pain point they want fixed) but we don’t have a clearly articulated enterprise vision for what the business ultimately wants the experience to be.
Without that, our Digital Services teams are left trying to infer the larger strategy from individual requests. We can design solutions, integrations, architecture, operating models, etc., but I feel like those decisions should be made in service of a business vision rather than IT effectively inventing the vision itself.
Where I’m stuck is figuring out how to help executives define that vision.
When I ask some version of:
«“What should the future enterprise experience look like?”»
the question is understandably too abstract and overwhelming.
I’m considering facilitating the conversation in a more structured way:
- Show them the major capabilities/workflows that exist today and ask where the gaps are.
- Ask stakeholders about the biggest pain points and desired business outcomes.
- Describe some of the cross-system problems we already see and have them prioritize which outcomes matter.
- Use those discussions to synthesize a proposed future-state vision and bring it back to leadership for validation.
But I’m also conscious of the danger of leading the witnesses too much. I don’t want Digital Services to quietly define business strategy simply because we’re better positioned to articulate the problem.
So for people who have done enterprise product management, architecture, transformation, or strategy work:
How do you actually facilitate this conversation?
How do you take executives from relatively vague statements like “make things seamless,” “improve the customer experience,” or individual feature requests to a sufficiently concrete vision that technology teams can derive capabilities, architecture, and a roadmap from it?
I’m interested in:
- Frameworks or workshop formats you’ve found effective
- Whether you start with current-state capabilities, pain points, business outcomes, or something else
- How much of the future state you propose versus expecting executives to articulate themselves
- How you distinguish an Executive Vision from detailed product/technical requirements
- What artifact you ultimately produce to capture the vision
- Who in a healthy organization normally owns/facilitates this process
I feel like I understand pretty well how to go from vision > capabilities > architecture > initiatives, but I’m struggling with the step before that: helping the organization actually articulate the vision.
Would appreciate any advice from people who have been through this.
Thank you
No insights reference this document yet.