We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Agents are crossing from assistance into commerce—and their distribution may be social. Instinct says purchasing users spend more than $1,300/month on average through the product and is partnering with Stripe; its examples include international travel, groceries, appointments, and price discovery. Grok Bot now completes online purchases after a user connects Link. At the same time, bots are becoming shareable artifacts: one student shared copyable, tailor-able bots for chief-of-staff, job-finding, and PM workflows, while Hiten Shah argues that “Do you have a bot for that?” could make people the discovery layer.
For PMs, this shifts the core loop from ask and answer to authorize → execute → recover → share. Instrument completed jobs, repeat usage, payment failures, and referral activation—not just chat volume.
Context is a delegation metric. A Company OS approach pairs OpenClaw’s Slack/Telegram gateways, scheduler, and persistent identity with Hermes, which turns repeated requests into skills. Its “product context coverage” test scores industry, business, and customers; it forces five unknowns per area, counts only knowledge retrievable without guessing, and prioritizes the three gaps that raise coverage fastest. The guide’s example treats 54% as suitable for backlog decisions and 70–90% as a target for strategy-level work. Use coverage as a gate: delegate drafting at low coverage, but require human review for decisions until context, permissions, and evidence are sufficient.
Tactical Playbook
Treat early churn as a research signal. RemindMe’s builder had four real users stop, no response, and no business-owner interviews. A practical sequence from the thread: (1) ask former users what they were trying to do when they opened it—or what they use instead now; (2) speak to problem-holders without pitching; (3) run the B2B confirmation log manually for two businesses for a month. If nobody wants the manual service, stop adding software.
Make design critique about fit, not taste. Separate craft—spacing, color, wording—from fit—whether the screen survives the real workflow. Tie choices to discovery-defined jobs and prompt/ability/desire; test edge states such as 4,000 rows, read-only roles, failed syncs, and empty accounts.
Case Studies & Lessons
A purpose-built renewal agent made proprietary context scalable. The team avoided generic sales agents for renewals because they lacked account-specific data; its sub-agent combined Salesforce contracts, LTV, and engagement with social, podcast, website, and Gmail context, then generated branded decks through Gamma. It extended comparable collateral to every sponsor, including smaller accounts, and produced 20–30 customized pitches versus roughly two before AI.
The operating pattern matters more than the deck: use a generic agent for re-engagement, collect feedback, have the specialized agent propose a narrative, review it with a human, then generate the collateral. The episode reports an A/B test in which this sequence worked better than one-shot customization. The agent still invented numbers despite explicit instructions, so numerical guardrails and human review remain part of the product.
Agentic coding needs gates, not just speed. Slack Code creates a project channel with the agent’s plan, line-by-line diffs, and live preview; participants can pause, redirect, or stop it, and production still requires human signoff. The episode cites a 2026 report finding exploitable vulnerabilities in roughly 44% of AI code-generation tasks even as AI-assisted developers committed code 3–4x faster. For PMs, use the workflow as a prototype-contribution model—tag an engineer before approval—and keep standard pull-request/release gates, permission checks, and reviewer ownership.
Career Corner
Build synthetic experience, not just a title. Aakash Gupta’s ladder is courses → a model-using product at a live URL with evals → real users → freelance/consulting → shipping AI as a PM. He says only one in eight jobs require production AI experience, so Levels 1–4 can create evidence before a formal AI-PM role. The practical artifact is a live workflow with users, evaluation results, and a decision log—not a certificate alone.
Tools & Resources
Product Quest is a community-recommended practice platform built around realistic scenarios in prioritization, discovery, metrics, strategy, and stakeholders, with learning paths and simulated career progression. It is worth testing as deliberate practice for interviews or a transition—not as a substitute for shipping.
- Purpose-built renewal-agent pattern: The team built a dedicated renewal sub-agent because generic sales agents lacked the proprietary, cross-channel context needed for highly specific renewal collateral. It combined Salesforce contracts, account ownership, historical spend/LTV, email and call engagement, event data, website/social/podcast mentions, and Gmail context, then used Gamma through its API to generate branded account-specific decks. This addressed a manual process that previously forced the team to prioritize high-value sponsors and neglect smaller accounts.
- Hybrid execution framework: The workflow used a generic agent for initial outreach and re-engagement, gathered the prospect’s feedback, had the purpose-built agent propose a renewal narrative, required human review of that pitch, and then generated the customized deck as a follow-up. An A/B test found this staged approach worked better than asking the initial agent to include the full customized case in its first message.
- Early impact and guardrails: The workflow let the team create comparable-quality renewal collateral for every sponsor, including low-ACV accounts, rather than only the largest customers. They reported sending roughly 20–30 customized pitches, versus an estimated two that would have been produced before AI, and receiving more recent responses from some silver sponsors than from diamond sponsors. A sample deck surfaced event lead results and 5.9 million social-media impressions. Despite instructing the agent never to invent numbers, the team said it still did so, making human review and explicit numerical guardrails necessary.
- System-of-record product trade-off: Their agents wrote about 40 GB into Salesforce, while the hosts estimated agentic workflows could generate roughly 100 times more data annually than pre-agent systems. Headless CRM access automated tasks such as creating opportunities and updating stages while allowing the assistant to combine data from multiple systems without routine Salesforce logins. The resulting trade-off is between the value and integrity of centralized CRM data and the storage/API cost of keeping it there; the hosts warn that higher API charges could push data into external systems and create synchronization problems.
- Use an outcome-based UX lens. During UX review, map each design choice to a discovery-defined job to be done, then assess whether it improves the prompt, the user’s ability to act—including by reducing friction—or the desire to act.
- Separate craft from fit. Treat spacing, color, and wording as design craft; have the PM focus on whether the screen survives the real workflow. For deep-domain B2B products, review states such as 4,000 rows, read-only roles, half-finished records, failed syncs, and day-one empty accounts, using customer and CS data rather than taste.
- Demand rationale and evidence. Ask why Design X was chosen over Design Y, and ground feedback in customer needs, user input, success metrics, analytics, OKRs/KPIs, and design-system alignment; use A/B tests for basic UI choices that could be impactful.
- Set the PM–design boundary and improve the process. PMs remain accountable for the product and should ask questions, understand rationale, decide where appropriate, and influence where necessary; pixel-level criticism should not be based on personal taste, particularly when a senior designer’s work meets requirements. Define vision, requirements, and desired outcomes, review prototypes or wireframes before major effort is sunk, and use smaller, safer discussions to preserve open feedback and morale.
- High-compensation, low-stress PM roles are possible but uncommon and context-dependent. Commenters point to two paths: an established or “boring” large-company product on autopilot, mainly involving backlog management for steady, low, or negative growth; or a senior IC/consultant-style role that shapes product-line strategy through briefs without owning delivery. Reported examples include a principal PM at a 1,200-person fintech earning about $300k, working roughly 45 hours per week, and describing the role as low stress after about 20 years in PM and leadership, plus a non-FAANG big-tech PM reporting $550k–$570k and rarely working more than 40 hours per week.
- The more repeatable path is to build operating leverage rather than seek a “coast” title. One PM says they spent one to two years building trust, reputation, and a machine that runs mostly on autopilot, after which their work is mainly course correction. Another frames PM compensation around strategic decisions that multiply the output of capital and people, rather than hours worked, and says PMs must get roughly 80% of those decisions right.
- The trade-off is unstable and increasingly shaped by automation. One commenter reports a $400k role that lasted two years at 15–20 hours per week but became boring, followed by a $530k FAANG role requiring 50–55 hours per week. Other comments say higher seniority can bring more stress and less hands-on product work, while layoffs can leave PMs doing the work of four people. An above-$200k principal PM reports 10+ hour days with 80% of their time on Claude Code and Codex, finding the work more enjoyable but also exhausting; another senior PM says they have not worked a Friday in four months because of automation.
- Slack Code launch: Salesforce announced Slack Code as a collaborative AI-coding workspace in which tagging an agent automatically creates a project-specific channel with tabs for the conversation, agent plan, line-by-line diffs, and live preview; participants can pause, redirect, or stop the agent, while a human must approve anything before production.
- Actionable PM workflow: Product managers can use vibe coding to build working prototypes or code contributions, tag an engineer before approval, incorporate the engineer’s technical feedback through another agent pass, and keep existing pull-request review and release gates in place. The episode presents this as a way for nontechnical PMs to contribute code without pretending to be engineers.
- Speed requires explicit quality controls: The episode cites a 2026 security report finding that roughly 44% of AI code-generation tasks introduced an exploitable vulnerability, with a 56% average security-pass rate, even as AI-assisted developers committed code three to four times faster; reported monthly security findings rose from about 1,000 to more than 10,000 in six months.
- Governance and platform-selection checklist: Slack says agents act with the invoking user’s existing access and cannot see channels that user cannot access; the described coding agent also uses an isolated sandbox, minimum viable access, an optional zero-internet mode, and standard GitHub pull requests. The episode recommends evaluating permissions and reviewer ownership alongside features, and notes that Slack’s workspace-level, multi-agent strategy could influence which agents and defaults companies standardize on—especially after Claude became the default model across Slack and Salesforce.
- AI-era MVP discipline: AI makes it easier than ever to produce polished prototypes, but a cool-looking prototype has no value by itself; an MVP’s purpose is learning through the Build–Measure–Learn loop. Learning cannot be outsourced to a development agency or AI, so PMs should build a testable prototype, show it to people, learn what customers actually want, and iterate toward the proper product.
- Mission as a product-company operating system: Eric Ries’s “new governance” has three dimensions—purpose, coherence, and integrity: encode the company’s purpose in its charter, direct organizational resources toward it, and establish a mission guardian or governance fortress that can resist external pressure. A mission statement that is not reflected in the corporate charter does not represent the company’s actual purpose.
- Post-product-market-fit leadership: Once product-market fit is reached, leaders should prioritize institutional longevity and succession by defining principles beyond the founder’s personality, cultivating trust with employees, customers, investors, and the community, and protecting that trust through structural integrity. Organizational transformation likewise requires sustained rigor, intensity, and resources comparable to financial compliance—not just a manual or one motivational speech.
- Case study—Tony’s Chocolonely: After exposing child slavery in cocoa and concluding that journalism and activism were insufficient, the founder created a chocolate company whose purpose was to eradicate child slavery. A planned 5,000-bar launch sold roughly 15,000 bars immediately; Ries says the brand became the Netherlands’ number-one chocolate brand and is expanding globally. The company operationalizes the mission through premium payments to growers, ethical production licensing that requires partners to adopt the principles across their chocolate production, and a “mission lock” governance mechanism.
Bot now supports sharing templates of Bots with others . The post highlights three reusable use cases: “Be Happier,” “Talent matchmaker,” and “Lennybot,” each with a direct template link .
- Company OS framework: Mikhail Shcheglov, CPO at OLX Uzbekistan, has operated a Company OS in production for five months. The approach combines OpenClaw as the runtime—with Slack/Telegram gateways, scheduling, and persistent identity—with Hermes for automated skill generation and self-improvement; the open-source repository is only a skeleton and must be populated with company context.
- Measure context before delegating: Track “product context coverage” across industry, business, and customers. First list five unknowns in each area as zeros; score only knowledge the system can retrieve without guessing; calculate per-area and combined coverage, then identify the three gaps per area that would raise the score fastest. The system described reads 54%, which is positioned as sufficient for backlog decisions, while 70–90% is the target range for strategy-level work; the graph can also expose knowledge silos between teams.
- Implementation and PM boundaries: Build in five stages: scaffold the runtime and interview the user to create role, company, ownership, meeting, and preference context; maintain a compact always-loaded priorities index; add three-layer memory (append-only raw transcripts with an explicit privacy opt-in, hybrid keyword/vector retrieval with supersession, then a knowledge graph); encode tested imperatives prioritizing truth, user interests, execution, and style; and hard-code sensitive permissions rather than relying only on prompts. The resulting system can automate stakeholder triage, board-model feedback, email/calendar digests, and recruiting workflows, while the PM’s defensible responsibilities remain discovery, stakeholder coordination, strategy, and accountability for outcomes.
Andrew Chen is exploring a hardware-triggered voice-transcription interaction: he asked whether a Bluetooth ring could trigger Wispr Flow, considered cheap rings used for TikTok scrolling, and then shared the remotehumans/riff GitHub link.
- The minimum viable market for software may be an individual: Hiten Shah highlights a student building software for highly specific problems that conventional startups would not pursue. The example uses Grok Bot to aggregate information across multiple sources and act on it, including tracking internship applications and student-organization event forms; users can copy and tailor bots, including a dedicated “the pm” bot. For product discovery, this suggests looking beyond startup-scale markets for narrow individual workflows that become viable when AI can combine information and execute actions.
- Hiten Shah identifies a potential AI product-distribution shift: if people casually pass bot links to one another, users themselves become the bot-discovery layer, creating a peer-to-peer acquisition loop.
- The linked scenario is problem-led and low-friction: someone sees another person struggling, shares a bot that addresses the problem, and the recipient can create it with one click. This suggests designing AI products around shareable links, fast activation, and clear utility in interpersonal contexts.
Durability as a product-strategy lens: Hiten Shah highlights Soleio’s principle that nature selects for systems able to replicate and persist against entropy, presenting it as a product-strategy insight.
Hiten Shah turned his pitch-deck review process into a Grok Bot: users submit a deck, the bot reads it in full, explains what it thinks the company is and what story it heard, then helps them work through the feedback.
- Hiten Shah’s AI-harness framing is that a model’s observed work depends on the system around it: just as a great employee can appear average inside a bad system, AI models can too. He says the surrounding system changes the work teams actually get from a model, making the model-plus-system—not the model in isolation—a relevant product-management lens.
Technology judgment: After a technology has been badly overhyped, an important product skill is recognizing when the genuine version finally arrives.
For new products and features, the MVP approach uses the most basic viable version to test a concept and gather user feedback, while balancing the capabilities required for viability against time to market and available resources.
Company OS for PM leverage: OpenClaw serves as the runtime—with Slack and Telegram gateways, scheduling, and persistent identity—while Hermes generates skills from repeated requests and drives self-improvement. Mikhail Shcheglov, CPO at OLX Uzbekistan, had this system running in production for five months. The proposed use cases include stakeholder triage, board-strategy feedback, email/calendar digests, and recruiting; the PM’s durable responsibility remains discovery, stakeholder coordination, strategy, and accountability for outcomes.
Implementation sequence: First measure “product context coverage” across industry, business, and customers: list unknowns, count only knowledge that is immediately retrievable, calculate coverage, and prioritize the gaps that would raise it fastest. Then reassemble the agent, configure only the minimum runtime credentials, interview the user to populate role/org/meeting context, and keep
MEMORY.mdas a compact index of current priorities and live issues. Add three memory layers: opt-in append-only raw transcripts, hybrid keyword/vector retrieval with supersession and stale-fact retirement, and a knowledge graph built on top. Maintain a failure-derived imperative hierarchy, hard-code security and permission gates rather than relying only on prompts, then publish the system to GitHub and test it with the team.Building AI PM experience without the title: AI PM roles rose from 2% of open PM listings in February 2024 to 46% in the source’s current comparison; AI experience was requested by 66% of ordinary “Product Manager” listings and 70% of AI PM listings in a hand-classified sample of 113 postings. The recommended five-level progression is: courses/certifications for vocabulary and a learning forcing function; a personal model-using product shipped to a live URL with evaluations; builds used by real users; freelance or consulting AI work; and ultimately shipping AI as a PM. Only one in eight jobs requires AI experience in production, so Levels 1–4 can provide evidence for many candidates who have not yet held an AI PM title.
- Product Decision League is a mobile-first game for practicing product decisions rather than only reading about them. Each challenge presents a situation discussed by a product leader; players review the context, choose a path, explain the trade-off, and compare their reasoning with what happened in the real world. The scenarios were sourced from Lenny Rachitsky’s podcast open-source data.
- The creator is seeking feedback on whether each scenario provides enough context for a meaningful decision and whether the reveal clearly explains the reasoning gap, highlighting credibility and reflection as key requirements for this type of PM-learning experience.
- An internal AI-platform PM used velocity metrics and retrospectives to identify a recurring delivery bottleneck: insufficient upfront design and anticipation left up to 70% of cycle time pending on infrastructure and network work.
- After the team introduced rituals to address the issue, the same small problems continued three months later; the PM became responsible for enforcing the rituals, analyzing metrics, and coordinating infrastructure, architecture, and delivery stakeholders despite limited technical depth and authority.
- The situation exposes a product-operating-model risk: a shared tech lead, centralized IT/security delays, and an AI architect who does not own the topic left no clearly accountable owner for day-to-day cross-functional coordination. Executives nevertheless expected the PM to coordinate without needing to understand the technical details.
- Concentrate the first market: Launch in one category within one Atlanta neighborhood, make that market feel complete before expanding, test one acquisition channel at a time for two weeks, and give each event or local group a distinct signup path. Measure completed listings and returning users—not downloads—to distinguish marketplace activity from awareness, and defer billboards and direct mail until repeat use is established.
- Align incentives with marketplace intent: Paying $1–$5 for app downloads is described as a poor validation signal; buyer discounts or seller-oriented incentives better reflect the behavior the marketplace needs.
- Seed durable supply before broad demand acquisition: Recruit established sellers or businesses rather than one-off sellers, offer free onboarding plus migration and listing help, then pursue buyers after building a healthier seller base.
- Demonstrate the product through organic content: Another recommendation is to use content that shows the app and its use cases instead of spending early budget on billboards or flyers.
- A builder is validating a market-research and competitive-intelligence tool that would accept a company URL or name and return market positioning, tech-stack data, hiring signals, and the intent behind the company’s content. The stated gap is that existing tools track keywords and backlinks but not why competitors publish.
- The proposed discovery approach is to ask PMs how they currently research companies and competitors, what is most painful, and what would make the work easier before building the product.
r/ProductManagement comment by u/audaciousmonk
How deep should a PM go at design critique?
I’m a product lead at a SaaS business. My manager has given me feedback that I need to be more in the weeds with design. He doesnt like some of the screens we shipped and has critiqued that I hadnt picked up on it. It was fair feedback.
This is coming at the back of a mandate our new CPO has handed down to PMs that we need to critique every pixel, colour choice and wording choice.
I am quite opinionated but keep my lane at the UX level and trust my designers to do what they do best.
The designer is also extremely difficult to work with and takes a ton of energy to convince him to change anything.
However I want to improve my product craft and i’m keen to hear from others.
I can’t speak to UX/UI, my products are hardware dominated
but while I do think design feedback / critique has its place and is important, you should be looking post mortem at how to build these outcomes from further upstream. Many ways to do this
- Requirements and Vision; clear breakdown of that is needed and the desired outcome. Don’t micromanage everything here, but give the team a star to reference along the way
- Building culture and design aesthetic; Team based interactions like having the team regularly discuss how products should look and act to best fit the brand/experience intended for the product. Having them share outcomes (what worked, what wasn’t well received, etc.)…. These should be team oriented, not a lecture / training and definitely not punitive in any way
- Drive feedback earlier; Prototypes or UI/UX wireframes can allow feedback before the team sinks significant effort into the project
Otherwise you run the risk of people feeling like design reviews are a coliseum fight that that’ll always leave bloodied. People will focus on survival and the negativity will kill morale / creativity
Another option is to give feedback discretely, or have safer small discussions to review the product and provide feedback. That way people don’t feel like they’re getting torn apart in front of management / department after working hard. Also creates a space for “equal voices”, yes ultimately you (product) or engineering may have the final say, but if you want open honest conversations it’s important that people feel like they can talk openly, freely, as peers
- Use an outcome-based UX lens. During UX review, map each design choice to a discovery-defined job to be done, then assess whether it improves the prompt, the user’s ability to act—including by reducing friction—or the desire to act.
- Separate craft from fit. Treat spacing, color, and wording as design craft; have the PM focus on whether the screen survives the real workflow. For deep-domain B2B products, review states such as 4,000 rows, read-only roles, half-finished records, failed syncs, and day-one empty accounts, using customer and CS data rather than taste.
- Demand rationale and evidence. Ask why Design X was chosen over Design Y, and ground feedback in customer needs, user input, success metrics, analytics, OKRs/KPIs, and design-system alignment; use A/B tests for basic UI choices that could be impactful.
- Set the PM–design boundary and improve the process. PMs remain accountable for the product and should ask questions, understand rationale, decide where appropriate, and influence where necessary; pixel-level criticism should not be based on personal taste, particularly when a senior designer’s work meets requirements. Define vision, requirements, and desired outcomes, review prototypes or wireframes before major effort is sunk, and use smaller, safer discussions to preserve open feedback and morale.