We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Agent products are being judged by continuity, not capability alone. In one agent builder’s account, a product shipped after six days of work in a Slack thread exceeding 1,000 messages because context and decisions survived across sessions; the same system timed out, lost context, and sent one alert 34 times. Capability and dependability proved to be separate achievements.
The surrounding harness—state, tool connections, permissions, recovery, routines, and verification—creates “continuity of execution”: retaining what changed, which decisions survived, what remains unresolved, and where to resume. Evaluate an agent on a consequential task and count context restores, cross-system handoffs, restarts, repeated instructions, completion checks, and interventions to stop runaway work; whatever falls back to the operator is a product gap. Keep repeatable operator work in the product, but reserve priorities, boundaries, approvals, and “good enough” for human judgment.
The implication extends beyond agents: company-specific operating knowledge is “specialized intelligence” mostly trapped in people’s heads, so the edge goes to companies that capture it as work happens rather than relying only on generalized model output.
Tactical Playbook
Match automation architecture to task risk. A four-part taxonomy distinguishes a scheduled task (fixed time, no memory), loop (memory and gates), goal (an explicit finish line), and workflow (locked order for auditable output). Examples are a morning brief, weekly business review, 14 interview notes completed when each has a summary/theme/quote, and launch-readiness or meeting-notes-to-tickets workflows. Use the five-second test before building: fixed time, need last time, “done when X,” or repetitive auditability.
Make strategic recommendations leave receipts. Anchor analysis to the organization’s goal; for churn, inspect cancellation data and exit surveys, segment the cohort, use win/loss interviews, then propose an intervention and show the work. Bring evidence on customer segments, pricing/packaging, or messaging—not generic “strategy.”
Case Studies & Lessons
Turn launch into a research loop. Enigma AI says its live robot deployment let online users ask robots to do tasks they were never taught, with zero task-specific data or fine-tuning. Scott Belsky’s product read is that the launch simultaneously engages curious users, yields interaction data, shortens deployment cycles, and creates storytelling from day one. For novel products, design launch to produce learning and repeatable release loops, not just awareness.
Gate growth on independent use. A free social app reportedly spent 4–5 years reaching roughly 20 monthly active users, mostly friends, with no revenue or obvious differentiation; its founder also paid for bar coasters before confirming bars would use them. A sharper practical gate: wait for at least one stranger to discover and keep using the product before scaling marketing; otherwise pivot or shut down.
Career Corner
The headline is better; the market is not easy. PM listings rose 2.3% to 25,905 (+19% year over year), but every region except EEA and LATAM declined. Hybrid grew 3.5% while remote fell 3.4%, with the longer view showing work consolidating around hybrid. One recruiter-data commenter estimates more than 30 open-to-work PMs per opening globally; a hiring manager reports roughly 300 applications and says finalists stood out through curiosity, learning drive, intelligence, and communication rather than checkbox backgrounds. Target geography and work format, and show differentiated work rather than applying at volume.
Tools & Resources
Shared AI pods are a practical team pattern. One PM organization reports shared memory for vision, strategic bets, product context, knowledge bases, and Jira; PM, design, and architecture personas; a council agent; and live connections to Jira, Confluence, support, and funnel tools. Its reported payoff was consistency across five PMs, standardized artifacts, and architect stress-testing before engineering. Another team built an internal search in four hours versus an estimated three-plus months for developers, while pausing before granting write access. Start with read-only sources, shared context, and review personas; add write permissions only after evaluating failure modes.
- PM job listings worldwide rose 2.3% in August 2026 (second straight month of growth, matching July's 2.3%), reaching 25,905 open listings, +19% year over year but 0.2% below the six-month average .
- Regionally, only EEA (+1.7%) and LATAM (+0.4%) grew; Canada fell 9.1%, the US fell 2.7%, the Middle East fell 2.5%, APAC fell 1.2%, and the UK was essentially flat at -0.2%, so the global gain masks broad regional declines .
- By level, associate PM listings jumped 20% (largest move) though still down 3.4% over two months; PM roles grew 3.5% (+17% YoY); senior PM fell 3.1% but is up 25% YoY; leadership roles rose 15% (+6.4% over six months) .
- Work environment: on-site listings grew 4.6%, hybrid 3.5%, remote fell 3.4%; over six months hybrid is up 8.2% and 36% YoY, while remote is down 7.7% despite +32% YoY - flexible work is consolidating around hybrid .
- A commenter notes 35% of PM roles are in the Bay Area, making almost every other market trickier .
- The report author shared LinkedIn recruiter data showing over 30:1 open-to-work PMs globally, most competitive in APAC, with spam/automated applications worsening the pile .
- A hiring manager on the thread received ~300 applications for a PM req, ~80% with similar India-engineering-to-US-MBA backgrounds; they shortlist atypical candidates showing natural curiosity, drive to learn, intelligence, and communication, not checkbox matches .
- An Indian PM aspirant with mechanical-engineering, Amazon HR, MBA, and wealth-management background who built a trading bot, fleet-management SaaS, and web-development agent is targeting AI PM roles ; the report author advised focusing on finance/product roles first, since AI PM is very competitive for that background .
- Commenters urge PMs in declining regional markets to adapt rather than stay complacent, calling flexibility survival .
Guest author Kristen Lowe, narrative strategist and incoming Director of Founder & Editorial Communications at Scribe, argues founder-led communication is a low-cost, high-leverage way for startups to cut through AI-generated noise; the only thing most founders need is an answer to "Why did I start this company?", and that founding story is the most narratively powerful idea to share .
Her framework sorts founders into three archetypes that map to how audiences connect: Problem (started to solve their own problem → "I identify with you"), Insight (saw a problem only they saw → "I trust you"), and Vision (imagined a better world → "I'd follow you"). The archetype determines the comms goal, voice, messaging pillars, and success conditions — not posting cadence or channel details .
- Problem founders (e.g., Sara Blakely/Spanx, Tobi Lütke/Shopify): goal is a loyal following who feel deeply understood; voice is personal, honest, detailed, (appropriately) urgent/frustrated; primary pillar is high-repetition, scene-based vignette storytelling about their experience with the problem ("I was crying in my car during lunch," not "existing options weren't working for me"), plus pillars on product design (every feature has a personal origin story) and community experiences. Common mistakes: overgeneralizing, slipping into CEO persona, oversharing beyond the story .
- Insight founders (e.g., Stewart Butterfield/Slack, Reed Hastings/Netflix): goal is an audience that trusts their opinions and analysis; voice is clear, analytical but accessible, curious, opinionated, generous; primary pillar is regular, incisive thought leadership with explicit reasoning (being helpful, not just right), plus predictions (especially in high-ambiguity moments like the AI boom) and engagement with other thinkers. Common mistakes: making people feel stupid, publishing takes without reasoning, never admitting uncertainty; favor long-form content over LinkedIn's conclusion-forward format .
- Vision founders (e.g., Steve Jobs/Apple, Elon Musk/Tesla): the rarest type; goal is followers deeply invested in the future; voice is expansive, certain, hopeful, plainspoken; primary pillar is "x doesn't have to be true" — breaking down status-quo assumptions with fair, generous explanation — plus the vision in concrete detail and milestones/progress as proof the vision is achievable. Common mistakes: contempt for the status quo, making yourself the protagonist, talking scale instead of shape; best on video/audio/keynote stages .
Success signals per archetype: Problem founders see customers sharing their own related experiences in comments/replies; Insight founders see their language and reasoning recycled by others and get invited to new formats; Vision founders hear people describe the imagined world back in their own words .
Grok Bot, an AI-agent product in early beta, is announced as AI teammates that do real work for you — they sign in to your tools, use them as you do, and come back with finished work .
Lenny Rachitsky, a prominent PM community voice, got early access and says he hasn't been this excited about a new AI product in a while; he calls it "like OpenClaw, but super easy, reliable, and less scary to use" and predicts it will be a huge new product line for Cursor/Grok/SpaceX, disclosing that he is not an investor and has no ties to the product .
His live use cases: matching job seekers with hiring companies, auto-replying to support emails (saving him hours), scanning credit card statements to find subscriptions to cancel, and sending briefs for upcoming podcast guests .
- The author, writing a week after stepping down from an executive role at Ancestry, describes how identity becomes wrapped up in the title, company, or role under one's name; when that disappears, even by choice, identity feels thinner, and the instinct to fill the blank space with the next title can lead you into the next chapter without ever deciding what it should be about .
- Her three-step process for discovering the "post-name-tag" self: Reset (stop moving; the pause is where the work happens), Reflect (tell yourself the true version of what happened, then set it down; minds prefer a preventable story over a random one, but carrying a self-blame story into your next role is fighting a war that already ended), and Reimagine (then ask what you liked, didn't like, and want the next chapter to be about, now that nobody is assigning you a title) .
- Her "permission slip": rewrite your story to make it more accurate, not to look better, because most people carry a version that blames them for things never theirs to control, shaping how they walk into the next room and what they type under their name .
- Example: Brad Smith, CEO of Intuit for over a decade, after stepping down became president of Marshall University and wrote openly about the in-between .
- Hiten Shah, after months building AI agents the hard way, concludes capability and dependability are separate achievements: longer-running work gives failures more time to compound, more state must survive, and context can disappear while the system keeps going .
- He became the 'infrastructure': restarting processes, restoring context, checking outputs, handling permissions/routing, and deciding when work was finished — small interventions that added up .
- He frames the surrounding system as the 'harness': the model supplies capability, while the harness preserves state, connects tools, manages permissions, supports recovery, and provides routines plus verification. 'Continuity of execution' requires remembering the work itself — what changed, which decisions survived, what's unresolved, where to resume — not just facts .
- Product boundary principle: repeatable operator work belongs inside the product; human judgment belongs in consequential work (priorities, boundaries, approvals, defining 'good enough'). Human attention should enter because judgment is needed, not because the system lost the thread .
- Evaluation heuristic for agent products: ask an agent to do something consequential and watch how often you restore context, move output between systems, restart failed work, repeat instructions, check completion, or stop a runaway loop — that work falling back to you is the product gap .
- Grok Bot shows the target state: files, apps, ongoing work, coordination, and human takeover feel like one coherent interaction — 'making a complicated system feel obvious is difficult product work' .
- In a companion post he contrasts the builder's desire for open source with the user's desire for zero-maintenance software: one wants freedom through control, the other freedom from thinking about software at all .
Lenny Rachitsky published a newsletter post, "How to make people care about your startup" (https://www.lennysnewsletter.com/p/how-to-make-people-care-about-your) , and a related post asking "Which founder archetype are you?" that covers the three founder archetypes (https://www.lennysnewsletter.com/i/210403546/the-three-founder-archetypes) . The archetypes post links back to the startup-caring post .
- A new approach called "VIP coding" (explaining what you want in plain English and iterating with AI, rather than reading/writing code) lets an idea become an application in hours instead of roughly 6 months, and the speaker says 100,000+ new projects are created daily; it shifts software creation from the <1% who previously had access to the 99%, who can now build, and is called a complete transformation of the software economy .
- Career guidance for knowledge workers in the AI transition: decompose your job into tasks — some AI/robots will perform, some you'll do with them (requiring AI fluency and awareness of the latest tools), and a third bucket of human-unique, entrepreneurial work you bring to any role. "If you are not changing your job, your job is changing on you"; leaning into curiosity and defining yourself around your unique lived experience gives more agency, "no one beats you at being you" .
- As customer interactions shift to AI conversations, companies will need new roles such as "conversation designers" and "AI architects" to make those experiences exceptional, with conversation design predicted to be as important as UI design .
- Product principle for the AI age: trust cannot be outsourced to machines; keep human agency as the source of trust and prioritize it from the start in any product or business, especially as machines gain computing, reasoning, and action capabilities .
Lenny Rachitsky shared a newsletter article, "How to make people care about your startup" (https://www.lennysnewsletter.com/p/how-to-make-people-care-about-your), relevant to startup/product storytelling and growth . In a reply, he tagged @lulumeservey, suggesting she'd like it .
- If someone has to ask whether what they built is a product, it probably isn't one yet; start by clarifying the problem being addressed, since fuzzy problems make everything else fuzzy .
- The honest answer is "I don't know": quantify it with evidence — does it solve a need, is the market accessible, how many people want it, was it built with industry requirements (cybersecurity, design, scale) in mind. Validate via soft launch or a hobby project before giving a definitive answer; comfort with uncertainty is part of the PM job .
- "It’s only a product if enough people find it valuable enough to pay. Until then, it’s just a project."
- An organizational blocker: stakeholders often can't agree on definitions of product vs feature vs subscription (even at Series B). Writing these definitions down and making them canonical aligns other teams. Start from: what is the business → what are we selling and to whom (value proposition) → then requirements for being a product, a feature, and how to price/package .
- Product vs feature test: a product solves a customer problem; a feature is an attribute that alone can't solve it. Example: disposable plates — the plate is the product; size, material, color are features; pricing/packaging (e.g., pack of 100 for $5) is a separate decision .
- Avoid getting stuck in ontology debates (project vs product); focus on getting the idea and its value articulated into documentation .
- A contract PM/PO on a 6-person team was fired after ~10 weeks despite turning around a food-bank platform project: he took over from the tech lead and senior dev who had delivered little in the first 6 weeks, got the timeline under control, won key wins, and secured a contract extension; the firing feedback acknowledged strong project/client management but cited the team's dissatisfaction with his soft skills.
- He attributes the outcome to having responsibility without clear authority: no decision-making hierarchy was defined, and the tech lead and senior dev expected to drive the project, creating a 2v1 dynamic.
- The lead dev likely issued an ultimatum, and the company chose to keep the lead dev (who writes 90% of the code) over the PM who had saved the engagement.
- A specific relationship mistake: he called out the QA in the group chat in front of the team, which he now sees as damaging the relationship.
- His takeaways: start 1:1s earlier; clarify roles, responsibilities, and decision-making authority on day one; and improve how he gives/receives feedback, as he can get hot-headed under criticism.
- He asks the community how to protect against such projects, what questions to ask before joining about decision-making authority, and how to align responsibility with authority.
In response to OpenClaw founder Peter Steinberger prompting PMs to move beyond "Loops" to "the next thing," this Product Growth post asks whether PMs now need to learn graphs . After weeks of testing, the author's verdict: yes, PMs do need to learn graphs — "perhaps unfortunately" — but they are "extremely easy to learn and prompt" .
CircleBack founder Ali (YC W24) shares operational tactics for AI-native product teams:
- Customer feedback loop: CircleBack runs a weekly run rotation where an engineer handles inbound support and talks to customers; feedback from customer visits is captured automatically, and the founder asks the recording for a customer's wish list and follows up to confirm shipped items .
- AI output quality: the team maintains evals for action-item detection (e.g., an action completed during the meeting should not appear as a to-do) and writing style — notes are opinionated and never use the word 'discussed' as it adds no signal; every model/prompt change is checked against these evals to avoid regressions .
- AI guardrails: agents are never allowed to send emails unattended (drafts are OK) or publish product copy without human final pass; engineers own architecture while agents build, and AI performs review passes on code, architecture, product, and copy for consistency .
- Recording thesis: as LLMs and AI agents do more company work, shared context becomes essential, so companies will default to recording every conversation; products must let customers trust that one-on-one remarks won't be shared widely .
- Product philosophy: as software cost falls, what matters more than shipping speed is what you decide to build and how systems interoperate .
One PM team's shared AI pod (built on Cursor/Claude): shared memory with team vision, strategic bets, product context, KBs and Jira; multiple personas (PM, designer, architect) with baked-in context and constraints; a PM council agent distributing tasks across personas and synthesizing outputs; live MCP connections to Jira, Confluence, support tickets, and funnel tooling; quarterly updates to shared memory . Reported benefits: consistency (five PMs don't produce five interpretations of the same strategic bet), standardized artifacts (PRDs, Jira templates, prioritization) through shared personas, outcome-focused planning, and an architect persona that stress-tests PRDs before engineering, surfacing gaps early .
Another PM org using Cursor for a year: AI tools for research and discovery, pulling from ADO work items, wiki, legacy technical docs, SQL artifacts, meeting transcripts, and local exports; PMs have built read-only internal apps (search pages, data dashboards, workflow dashboards) and are pausing before giving PM-built apps write access to the database . A PM built a complex search that had been on the backlog 8 months in 4 hours — deployed to users, when it would have taken devs 3+ months — and backburner items are now being tackled by non-devs .
Hiten Shah describes an emerging layer of bespoke internal software that AI has made economically buildable, citing his own AI marketing systems as an example . His approach: four marketing systems built around jobs his team already does — two Hermes agents in Slack, one media system that saves hours and may become a product, and one kept-secret system with multiple sub-agents and a real-time interface . The systems are useful because they start from existing work and are shaped by the team's context and decisions; he frames the technical foundation as "a model becomes an agent when its harness gives it a way to see, do, remember, and check" .
PM with 12+ years left his job to build an AI marketing-analytics SaaS with a co-founder. Despite a Product Hunt launch at #6 and strong organic push, the product was too thin: 1,000 signups produced zero paid users, investors passed, and by month 9 he was burning savings after the co-founder checked out . Post-mortem: the first wedge (AI agent for Google Analytics only) demoed well but drew free-tool users who structurally would never pay; meanwhile users repeatedly asked for more integrations — 'them literally describing the full vision back to us' — but milestone-driven roadmap discipline kept them monetizing the wrong slice. Lessons: validate that the wedge monetizes, not just that the vision is right; when users repeatedly ask for the same thing, listen over your milestone; momentum decays .
Rebuilding solo, Claude Code removed the need for a tech co-founder; he launched last December, went 1.5 months with no paid users, and got his first Stripe payment on 11 Feb from a customer in 'Chili', then six more within a month; SaaS crossed $1,000 MRR 'last month'. A side agency (SEO/AEO services) landed its first client — a mid-size clinic that found him through ChatGPT — and grew to a $30k retainer base with 8 clients, leading him to quit his full-time PM job. He credits his PM training for the turnaround, automating with agents wherever possible .
Community takeaways: wanting is confirmed only when someone pays, not through interviews, waitlist forms, or signups ; prioritize real validation over arbitrary milestones because users were 'telling you what they wanted all along' . The author adds that speed and CTO-dependence were the real blockers; now paying users reach him on WhatsApp, the feedback loop is fast, and features sometimes ship within hours . One commenter sees a big usage gap in marketing data and credits the product with opening that analysis to mid-sized firms .
Hiten Shah shares product lessons from months of building AI agents. A product shipped in six days with nearly all work in one 1,000+ message Slack thread; context accumulated and decisions survived across sessions . Core distinction: capability and dependability are separate achievements — longer-running work gives failures more time to compound, e.g. disappearing context, restarts, and a loop that sent the same alert 34 times . Introduces the 'harness': the surrounding system that keeps agent capability usable over time by preserving state, connecting tools, managing permissions, and supporting recovery . This is 'continuity of execution' — the system must remember the work itself (what changed, which decisions survived, what's unresolved, where the next step starts), not just facts . Design guidance: repeatable operator work belongs inside the product; human judgment belongs in consequential work (priorities, boundaries, approvals, defining 'good enough') . Evaluation heuristic for agent products: assign a consequential task, then count how often you restore context, move output, restart failed work, repeat instructions, verify completion, or intervene because the system kept going — 'That work falling back to you is the product gap' . The best agent products absorb that accidental operator work, letting humans focus on judgment and taste .
An X post critiques a "new launch meta for labs": create an inferior product, give influencers early access (or pay them), they all post praise, but no one actually uses the product — adding that Grok Bot is no different and that better, cheaper alternatives have existed for months . Hiten Shah replies that he understands the take given users burned by larger labs and later-stage startups, but @bot is not that kind of launch — "It is a damn good product" .
A PM at a large public company reports a pod of four PMs with no attached engineering teams, a backlog of disconnected tasks, persistent engineering pushback ('needs more research,' 'check with another team,' 'dependencies'), low morale, and a manager who says they're doing great despite nothing shipped — leaving the PM unsure whether to push for shipping or focus on visibility for the performance review .
Top advice from the thread:
- Treat your boss as your #1 customer: find out what they care about and what helps/hurts them, then define success in your role from that; send follow-up emails after 1:1s with a 90-day plan and 6-month tentative goals; and assess your product's P&L health (profitable vs. dying) to decide whether to push or leave .
- Find one engineering partner who shares your frustration and ship one small thing fast; a visible fast-ship example lends weight when you claim other teams are too slow, and once one team ships rapidly, management starts questioning the rest .
- Build a baseline metric (e.g., average new-product development time or new-product revenue), then implement a strategy that shows improvement — usable as a performance-review KPI and resume builder .
- Treat checked-out behavior as a symptom: diagnose the root cause (here, no clear ownership around project boundaries) and fix it as a PM would; at junior level a PM identifies org-level impediments, at senior level overcomes them — present problems with factual anecdotes and proposed solutions to management .
- Beware the blame shift: if engineering produces little, leadership may later blame product for not giving good enough/final requirements — ship something you can tell a good story about within a quarter or two, and don't let your review hinge on strategy docs while the product stagnates .
- Realistic caveats: coasting while hunting another job is common (pay and resume-name reasons), but it risks frustration, eventual team axing, and layoffs; and incentives matter — PMs with little equity and mediocre pay at non-big-tech companies won't be highly motivated .
Hiten Shah observes that the hardest part of building AI for a team is finding the judgment nobody realized one person was supplying — pointing to the challenge of surfacing tacit knowledge that AI products for teams must capture .
- Reframe the PM role on complex products: focus on the business problem, customer pain points, and value; you don't need to know every technical detail, only enough to make or facilitate decisions and dive deeper when needed .
- Lean on engineering and mentors: schedule meetings with developers to understand what they're doing and why, ask them to explain technical choices in plain language, and get an outside mentor for an unbiased perspective .
- Ask for help as a risk management move: one PM got scope reduction and a new hire after telling their manager they were overwhelmed; another built dashboards, prototypes, and proof-of-concepts to successfully request UX and analytics support .
- Treat difficulty as normal growth, not failure: imposter syndrome is common and confidence comes from progress, not technical prowess; break learning into weekly pieces, ask questions, use the product, and track commercial data to show impact .
r/ProductManagement comment by u/71f1
Feeling out of my depth as a PM…
Hey guys! I desperately need the community today.
I’m currently leading a product with a pretty huge and technically heavy scope, working with complex data and building something that hasn’t really been done before in our space. And if I’m being completely honest, I feel very out of my depth…
There are days when I genuinely wonder whether I’m experienced or technical enough to be the person leading this, and unfortunately, I feel like my team is feeling the same. I do believe I’m good at leading; it just feels overwhelming in a way I can’t really explain - and there are so many things I actually don’t technically understand.
I’ve worked on smaller innovative products before, but this is truly next level in terms of scope and challenge, and in a way, it feels like it would require a much more experienced PM than I am. I’m also lacking a lot of support from my leader (and we don’t have UX), so I’m kind of figuring this out by myself. I DO want to say that I love the learning it’s giving me, and it’s making me grow a lot as a PM and person, and I always love that; however, at times, it genuinely feels like a humiliation ritual to lead this product - and that I HATE. 👀
My reason for posting is basically to ask: For PMs who have been in a similar situation, how did you handle the point where the product felt too complex or technical for you? What did you do that helped you the most? And how did you find your confidence?
Shoot me your best advice or insight!
Kind regards,
Struggling (but aspiring) pm
I think it’s easy when we feel out of our depth to invent a somewhat false PM persona that would be way better suited to the challenge.
The reality is, we’re all just trying to do our best, often figuring things out as we go. Even when I’ve worked on products I have lots of expertise in, I’ve been thrown something that has caused me to have to learn something new.
Experience and skills buy you confidence more than anything, but there’s no reason why you can’t feel that earlier on in your career.
Some great advice I was once given is to stop feeling uncomfortable when things aren’t easy. It’s not meant to be. It’s a hard job! Something being hard doesn’t mean you’re doing anything wrong, it just means it’s hard. Learn what you can, make decisions with the best information you have, and be gentle on yourself when you inevitably get a few things wrong.
Good luck!
- Reframe the PM role on complex products: focus on the business problem, customer pain points, and value; you don't need to know every technical detail, only enough to make or facilitate decisions and dive deeper when needed .
- Lean on engineering and mentors: schedule meetings with developers to understand what they're doing and why, ask them to explain technical choices in plain language, and get an outside mentor for an unbiased perspective .
- Ask for help as a risk management move: one PM got scope reduction and a new hire after telling their manager they were overwhelmed; another built dashboards, prototypes, and proof-of-concepts to successfully request UX and analytics support .
- Treat difficulty as normal growth, not failure: imposter syndrome is common and confidence comes from progress, not technical prowess; break learning into weekly pieces, ask questions, use the product, and track commercial data to show impact .