We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI-native product teams are redesigning the artifact around shared context, not document volume. Together AI’s CPO says long AI-written documents now consume coworkers’ context rather than signal work. His team replaced 20-page PRFAQs with two pages plus a prototype, built a hierarchical shared-context repository, and keeps the PM accountable for the quality of anything AI produces. Their supporting tools synthesize support tickets and Gong calls daily so leaders can skim broadly and go deep selectively. Apply: make the prototype the primary alignment object, keep the decision brief short, and make context discoverable in layers; use AI to question and synthesize, not to own the decision.
More people can build, so product selection and coherence become the scarcer work. USV made Scott Belsky its first Product Advisory Partner to help portfolio companies with product, positioning, and experiences; the announcement argues that AI accelerates building while uncertainty about moats and consumer preferences makes resilient products harder. Hiten Shah’s parallel framing is blunt: every idea can now become a demo, so the PM must decide which ideas deserve to enter the product and make the whole experience coherent. A polished demo is therefore a weaker filter; the bar moves toward evidence, a clear product story, and disciplined inclusion.
Tactical Playbook
Map the operating system before accepting the feature request. When a business asks for a new website, first map Customer → Lead → Sales → Operations → Delivery → Reporting; classify each step as automate, integrate, custom-build, or leave alone. Prioritize the points where the business loses time, money, or information—not the visible software request.
Triangulate competitive intelligence, and separate discovery from validation. Competitor pages describe the narrative a company wants prospects to believe; reviews and communities can reveal customer language and failure modes, but may be biased and should not establish prevalence on their own. For a lean team, maintain a source registry spanning release notes, pricing, reviews, job posts, and sales-call mentions; normalize changes into a weekly digest tagged by segment and strategic impact, with confidence labels and source citations. Also watch quiet changes—removed features, softened claims, or new pricing footnotes—as possible signals.
Give AI a risk budget rather than a binary trust decision. One GTM practitioner is comfortable letting AI inspect performance data, flag falling activation, propose onboarding campaigns, and draft emails, but warns that reviewing every customer-facing change can become an approval queue. Define tiers: AI-only analysis and drafts; bounded actions under pre-approved rules; and human approval for new claims, audiences, or high-consequence sends.
Case Studies & Lessons
A deliberately strange B2B experiment converted attention into pipeline. A cloud-security startup built a fake toy store for CISOs, selling joke products such as a “CISO panic button.” The article reports that it cost almost nothing, drew 46,000 visitors in 24 hours, and produced hundreds of qualified leads. The lesson is not “be quirky”; it is to design a low-cost artifact around a recognizable customer identity, then measure qualified downstream behavior rather than reach alone.
Career Corner
B2B-to-B2C interview prep needs an evidence chain. One PM’s B2B habits—workflows, business rules, feasibility, and operational efficiency—were judged weaker on intuitive interface interactions. The practical adjustment is to start with the consumer problem and persona, then show key-flow events and KPIs, the hypothesis behind a change, and the experiment suited to the question—A/B, fake-door, Wizard-of-Oz, or another method.
Replace indiscriminate job-application volume with targeted outreach. A single current anecdote—not a market statistic—describes 6,000 applications over 12 months without a PM role. A career coach’s counterstrategy is to choose 20–30 companies where the candidate’s background is unusually relevant, contact employees with a tailored reason, and prioritize warm introductions over generic posts.
Tools & Resources
A structured growth-ideation bank. Lenny’s current collection contains 64 creative ideas organized by outcome—buzz, launches, word-of-mouth, leads, competitive moves, willingness to pay, and retention—and is explicitly designed to be fed into an agent for product-specific brainstorming. Use one target outcome to constrain the brainstorm, then test the cheapest credible idea.
- Use customer-facing teams to recruit, but keep discovery PM-led. In B2B, ask sales, account management, or support to nominate customers who match a precise persona and open the introduction; the PM should conduct the interview rather than delegate insight gathering to sales or marketing. Keep the referring salesperson informed, but avoid making them the exclusive go-between or filter for all customer communication.
- Use a tiered recruitment playbook. For existing customers, start with customer-facing teams; for a specific hypothesis, ask sales/support to identify candidates, send a 15-minute invitation, and provide a scheduling link, ideally clustering sessions on Mondays or Tuesdays. For non-customers, one practitioner suggests defining an ideal buyer persona and contacting 100 LinkedIn prospects, estimating 2–3 interviews per week in 4–5 hours and useful insights from fewer than 10 interviews; another reports LinkedIn outreach as time-consuming with about a 2% response rate, while a recruiting agency is an option when budget permits.
- Create repeatable feedback channels. A customer council can use a shared form or a CRM flag for customers willing to speak with Product; in-product or website prompts can recruit participants, with an incentive and short qualifying survey for public-facing requests.
- Improve interview signal before and during the session. Define the relevant jobs-to-be-done, user journeys, and problem before recruiting; review the customer’s account history and usage, bring only the PM plus one colleague when possible, keep the group to no more than three, and meet at the customer’s site or at a convenient time to minimize distractions and influence.
Choose discovery methods by cost of learning: Compare conversations, observation, sketches/prototypes, manual delivery, and working software based on what remains unknown and the cost of answering it. Five conversations can expose a bad assumption, observation can reveal details users omit, and manual delivery can test demand before software is built. When useful software is cheap enough, a real product may teach more through use than another week of discussion. AI has lowered the cost of researching markets, analyzing customer evidence, building, studying responses, and iterating, so the product can join customer research earlier without replacing it.
Beam case study: Beam started from an internal problem: using a window on another Mac required opening full Screen Sharing. The team built a small useful version quickly because they understood the workflow, had Mac expertise and testing machines, and could get the product into real use. Instead of asking whether people wanted “a better way” to access another Mac, Shah asked people on X to show their actual setups; more than 100 replied and 42 completed a baseline form. Twenty-nine interacted with another Mac several times a day, 28 kept the other Mac nearby, and only four usually wanted the whole computer while 18 wanted one application or a few specific ones. The evidence shifted the product understanding from generic remote access toward app-level access across nearby, specialized “personal Mac fleets.”
Validate replacement, not enthusiasm: After launch, ask, “If Beam weren't installed, what would you have done instead?” and observe whether Screen Sharing, another remote-access tool, or physically walking to the other machine disappears—and what users return to when Beam fails. Shah distinguishes compliments, signups, repeated use, replacement of an existing behavior, payment, and retention as answering different validation questions; replacement shows that the product displaced something, while retention shows whether it keeps earning a place in the user’s life. A founder can be customer zero, but must find people with the same problem, understand their current workflow, put the product into it, and watch what changes; Beam is testing this with free access for early users in a small X group.
- A fresh-grad Product Analyst in adtech reported that heavy company-specific terminology, sparse documentation, and limited manager/mentor bandwidth made the initial ramp feel overwhelming and left them unsure about performance. The suggested response is to allow time for context-building, focus first on one important end-to-end flow, and learn the product, industry, users, and problems before trying to master everything.
- Make onboarding explicit: set clear goals with the manager and document what you learn and do; choose one or two role-relevant areas, map how the product works and whom it serves, identify user problems, share findings with the manager, and agree on an effective way to exchange notes.
- Build context deliberately by whiteboarding the stack, tools, and workflows; mapping stakeholders and knowledgeable peers; and maintaining a glossary of abbreviations. AI can help explain jargon and local systems, but its answers should be verified because it can make mistakes. Taking on selected manager activities and repeatedly asking why the work and approach were chosen can accelerate learning and surface pain points.
- Use the cost of learning to choose the next discovery method. Start with the least expensive method that can answer the current uncertainty—conversation, observation, manual delivery, prototype, or software—and move the product into real use earlier when building is cheap enough to generate better evidence; AI has lowered the cost of building, researching, and iterating on customer response.
- Beam shows how an early product can become part of research. The team started from its own multi-Mac workflow problem, built a small usable version, then asked people to show their existing setups rather than asking whether they wanted a hypothetical solution. More than 100 people replied and 42 completed a baseline form; 28 kept the other Mac nearby, while only four usually wanted the entire other computer and 18 wanted one app or a few specific apps. This shifted the problem framing from generic remote access toward friction at the boundary between machines.
- Validate behavior change, not enthusiasm. Track what the product replaces—such as a Screen Sharing session, another remote-access tool, or walking to another machine—and ask, “If Beam weren't installed, what would you have done instead?” The evidence bar rises from compliments to signups, repeated use, disappearance of an existing behavior, payment, and retention. A founder can be customer zero, but must then find people with the problem, understand their current workaround, put the product into that workflow, and observe what changes.
- Use unconventional, low-cost experiments to break through crowded acquisition channels: A cloud-security startup built a fake toy store for CISOs, selling joke products such as a “CISO panic button.” The stunt generated 46,000 visitors in 24 hours and hundreds of qualified enterprise leads, despite being designed primarily to earn attention.
- Turn outbound prospecting into customer discovery: Select 8–10 ideal customers, apply the product or service to their situation, and send them a useful report, audit, or analysis instead of asking for a demo. Vanta sent Segment a custom SOC 2 gap assessment before Vanta had a product; Segment became a design partner that helped shape the company.
- Reduce activation friction with self-serve product experiences: Replace or supplement “Book a demo” with a no-signup playground that lets prospects reach an aha moment without providing an email or credit card; the examples given are Plausible’s live analytics dashboard and Linear’s demo workspace.
- Use narrow free tools as acquisition wedges: Strip one product capability down to a single free interaction with no signup requirement. Wordware’s free X-profile roasting tool reportedly attracted 8.1 million users and more than 400,000 signups for the core product.
- Treat conversion improvements as experiments: Adding a blurred product screenshot behind a signup form increased conversion by 25% in one reported A/B test, suggesting that curiosity and a sense of progress can be tested as signup motivators.
- Design referral and ambassador mechanics explicitly: An open ambassador program can recruit many small creators, pay based on impressions, and avoid follower or content-approval requirements; tl;dv’s example paid $100 per 20,000 views, capped at $700 per post, and reported more than 10 million monthly impressions.
- The PM artifact is a shared product story, not merely a specification. The story should explain who will use the product, why it matters in their lives, and how the experience should feel; it must be immediately understandable and repeatable without the PM present. AI changes the workflow from idea → spec → scope → build to quickly build a prototype, play with it, design the real product, then ship and learn. Because prototypes are cheap but production-quality products are not, PM judgment should focus on product coherence and impact rather than simply whether an idea fits the schedule or available resources.
- Use Purpose–Core actions–Cycle to define product vision and measurement. Specify why users choose the product, what they actually do with it, and how often each action should occur. Evaluate usage through direct, intentional traffic and completion of meaningful core actions—not just signups, DAU/MAU, waitlists, revenue, or brief app opens.
- Design onboarding for the curious middle of the user distribution. Introduce the product step by step with simple, discrete actions; repeat the core message, explain why nonessential information is requested, and teach each key concept through a clear user action. For AI products, replace the blank prompt with concrete capability examples and get users to a valuable use case quickly, ideally using their own data. Judge onboarding variants by next-day or next-week retention and core-action adoption, not by how many users reach the end of the flow.
- Twitter’s onboarding rebuild illustrates the approach. Millions of people signed up after hearing about Twitter but did not return because they could not explain what the product was or what to do after signup. The Learn Flow taught the product one concept at a time—following accounts produced tweets in a timeline—and improved retention more than anything else Twitter shipped that year.
- For AI products, treat user transcripts as product research. Read the user’s exact prompts, rephrasing, and abandonment moments to identify unmet expectations; use AI to surface patterns, but retain human judgment about what the product story actually is.
- For launches and growth campaigns, consider an “anti-professional” tactic: deliberately break a professional norm in public—for example, discuss what roles actually pay or admit that a big launch failed to meet internal expectations—to stand out from polished professional content.
- The rationale is that unexpected executions can be shared organically, remain memorable longer, and usually cost less than a week of ad spend than conventional channels such as high-production launch videos, paid influencers, social, and events.
TokenCompass is building a measurement layer for AI at work to help leadership teams understand AI spend and usage and budget tokens across human employees and agents; the product is currently in private beta. Its stated product rationale is that companies need tools to plan and make informed financial decisions about token spend, pointing to token-cost visibility and allocation as emerging requirements for enterprise AI products.
- Separate attention from adoption: The discussion cites 90% U.S. awareness versus 11% use for GLP-1s, and 95% crypto awareness versus 14% ownership. In a sample of about 960 TikTok videos about peptides, posts fell into promotional, personal-exploration, educational, and skeptical-warning categories; skeptical warnings represented about 19%, while promotional content increasingly converged with personal-experience content as adoption grew. PMs can use awareness-versus-use data and social-content composition to avoid treating virality as product demand.
- Watch for productized demand as a maturity signal: Protein quantities had not changed, but brands began prominently featuring protein on yogurt packaging because consumers were actively looking for it. A trend may be reaching the mainstream when it changes product positioning or merchandising, not merely when it generates online discussion.
- Map origin communities and adoption lag: The speakers argue that peptide culture began in American Heartland and bodybuilding communities before being professionalized or accelerated in Silicon Valley. Wearables similarly took a long adoption path—Fitbit launched in 2007, Apple Watch in 2015, and broader uptake followed through product development and slow adoption. PMs evaluating emerging categories should distinguish the originating user community from the later high-visibility scaling channel.
- Lenny’s growth thesis: when competitors rely on the same high-production launch videos, paid influencers, AEO, social, and events, unexpected tactics are more likely to be shared organically, remembered for months, and usually cost less than a week of ad spend.
- Tom Orbach’s collection of 64 growth ideas is organized around seven outcomes: generating buzz without paid ads or influencers, making launches stand out, encouraging word of mouth, increasing leads and conversions, outsmarting competitors, increasing what customers will pay while keeping them happy, and improving retention.
- A practical ideation workflow is to feed the collection’s Markdown version into an AI agent to brainstorm growth ideas tailored to a specific product and its goals.
- AI makes building an individual feature cheaper, but production-quality delivery remains costly: treating coding agents as “free” can produce spaghetti code, Frankenstein data models, duplicated code, feature bloat, performance problems, and downstream maintenance work. Skilled engineers must still observe and steer AI-generated output, and architecture decisions cannot be outsourced to coding agents.
- Separate build to learn from build to earn: use cheap, throwaway prototypes for discovery, but actually discard them instead of treating them as production-ready foundations.
- AI products require substantial product and engineering work beyond the demo, including error analysis, evaluations, LLM-as-judge processes, and repeated prompt/orchestration iteration. Reaching a good-looking prototype may be fast, while closing the final 30% to a trustworthy product can take months or years; delivery became cheaper, not free, so discovery and delivery both remain essential.
- Lenny Rachitsky argues that teams relying on high-production launch videos, paid influencers, AEO, social, and poorly attended events are competing for the same channels and attention. His counterstrategy is to pursue unexpected growth tactics that earn organic sharing, remain memorable, and can cost less than a week of ad spend.
- Tom Orbach’s collection contains 64 creative growth ideas organized around seven objectives: generating buzz without paid ads or influencers, making launches stand out, prompting word-of-mouth, increasing leads and conversions, outsmarting competitors, increasing customers’ willingness to pay, and improving retention.
- A company without a formal PM/PO function is falling behind on release notes, user and stakeholder updates, roadmap editing and prioritization, user-feedback management, UAT, launch communications, and knowledge-base updates; budget constraints are driving consideration of fractional or part-time help.
- The discussion distinguishes strategic fractional PM work from execution-heavy part-time support: one recommendation is to retain roadmap prioritization and potentially user-feedback ownership internally while automating or redistributing routine updates, knowledge-base maintenance, UAT coordination, and release communications.
- A proposed staffing split assigns a motivated junior/full-time hire to release notes, stakeholder and user communications, launch messaging, and knowledge-base updates, while a fractional senior PM handles roadmap prioritization, user feedback, UAT, competitive analysis, and coaching the junior hire.
- Suggested implementation practices include defining explicit goals and deliverables like an outsourced QA engagement, separating research/analysis/recommendation work, standardizing communication templates and processes, tapering an initial full-time engagement to three then two days per week, and embedding workflows so the team can continue after the specialist leaves.
- For a first-time PM managing multiple products in a niche industry with outsourced development, establish a lightweight operating system: maintain a living glossary and stakeholder map; keep a one-page snapshot for each product covering its goal, commitments, risks, and next decision; and create a delivery rhythm with written acceptance criteria, regular demos, and a decision log. These practices help the PM learn, prioritize, and make uncertainty visible.
- Core habits recommended for reducing ambiguity are to start from first principles, define measurable success criteria before beginning an initiative, focus on customer/user/business problems rather than presumed solutions, ask questions, and understand end-user pain points.
- Community responses offer a career reality check: PM overwhelm may change form rather than disappear, with respondents reporting continued overwhelm after 10 or 20+ years and, in one account, greater stress at senior levels than as a junior.
- “Customer zero” is a starting point, not validation. If a founder has lived with a problem deeply and can build a useful version without a large bet, they can start with their own workflow—but must then find people who already have the problem, understand their current behavior and workarounds, put the product into that workflow, and observe what changes to earn “customer one.”
- Choose discovery methods by learning cost, not habit. Conversations, observation, manual delivery, prototypes, and working software answer different questions; five conversations may expose a bad premise, while a cheap product can reveal more through real use. AI has lowered the cost of building and iterating, making the product itself viable as an earlier research instrument, while customer research remains necessary.
- Beam illustrates behavior-led discovery. Shah’s team began with its own need to access apps running on another Mac, then collected 100+ X replies and 42 baseline responses. Of those respondents, 29 interacted with another Mac several times daily, 28 kept the other Mac nearby, and 18 usually wanted one application or a few specific apps rather than the whole computer—evidence that reframed the opportunity from generic remote access toward lightweight, app-level access.
- Prioritize evidence of replacement over expressed interest. The strongest validation is seeing an existing workaround disappear—such as fewer Screen Sharing sessions, less use of another tool, or no longer walking to another computer—followed later by payment and retention. After adoption, ask, “If the product weren’t installed, what would you have done instead?” to identify what it actually replaced.
- B2B PMs moving into B2C should start with the consumer problem and persona, then demonstrate empathy for users who are less tolerant of interface friction; B2C interviews place greater weight on intuitive experiences, outcomes, and experimentation than on workflows, business rules, backend feasibility, and operational efficiency.
- Build interview examples around a clear evidence chain: instrument key user flows with events and KPIs, identify the data or customer feedback that prompted a change, state the hypothesis, choose an appropriate experiment, and explain how the result validated or disproved it. Useful practice areas include root-cause analysis and growth cases.
- Treat experiments as learning rather than proof: select the lightest method suited to the question—such as fake-door, Wizard-of-Oz, multivariate, or qualitative comparisons—and minimize engineering effort while testing. A/B testing can also mean comparing versions qualitatively across users or iterating from version A to version B when automated telemetry is unavailable.
- A QA Team Lead at Accenture with approximately six years of testing experience is considering a transition into Product Management. They report transferable experience in product requirements, user impact, Product/Engineering collaboration, sprint planning and estimation, feature decomposition, release support, cross-team coordination, and mentoring; they are more motivated by understanding problems, user needs, trade-offs, and what to build than by testing the finished product.
- The stated preparation gap is a lack of formal product ownership experience, including roadmap and product-metrics responsibility. The poster is weighing paid structured training against self-study, case studies, and projects.
- A PM four months into a new Indian fintech role reported that personal issues had reduced availability and performance; although they had identified high-impact problems and aligned leadership, execution was slower than expected, raising concerns about internal perception and job security.
- Recovery expectations vary by company: four months may still be onboarding in some organizations but may be considered a long time in others. If the setback was isolated, the recommended response is to focus on execution and deliver value over the next 6–8 months.
- Once performance shows an upward trend, have a candid conversation with the manager and potentially a skip-level leader about what happened. The advice also warns that termination remains possible in highly cutthroat companies, making rapid improvement in the performance trajectory the immediate priority before repairing the internal narrative.
- An internal platform team at a multi-billion-dollar company reports that nearly every stakeholder initiative is now an AI agent or LLM-based solution. The team has no clear customer demand for next year, expects to spend the next six months in keep-the-lights-on mode, and worries that agent-heavy product work could reduce teams to human-in-the-loop support, minor tuning, and configuration. This is an anecdotal signal that generative AI may compress the scope and staffing of some product organizations.
- Community counter-signals highlight risks to validate before treating this as a settled operating model: AI adoption may create technology debt and depend on venture-subsidized token costs, while agents may be “solutions looking for problems.” Another commenter argues that simply reacting to inbound requests was never a full product function, implying PM value should shift toward problem selection and product direction rather than disappear.
- Use discovery questions before accepting stakeholder requests: clarify the intended outcome, KPIs, operator, formal plans, leadership sponsorship, deadline flexibility, and what existing work should be deprioritized before moving into solution mode. This can reveal that a request is less important or insufficiently thought through, while framing pushback as partnership rather than gatekeeping.
- Make scope transfers explicit: when work falls outside the team’s responsibility, ask which existing commitment should move, who owns the trade-off, and where the scope decision is documented. A short weekly alignment with the managing engineer can establish boundaries in advance; visible prioritization decisions are preferable to quiet scope transfer.
r/ProductManagement comment by u/signalbound
CTO at a franchise organization. Not a traditional tech company so historically not much attention was put into internal product.
Thanks for the clarification.
Some things don’t need a PM, here is how I have seen other companies solve it
- Knowledge base updating (technical writer or within the team)
- UAT Planning and Implementation (QA or a Dev)
- Roadmap Editing and Prioritization (10 mins), requirements in roadmap and refining that is where the work is
- Release notes published (AI can do this with minor human intervention
The hardest part CAN be user and stakeholder updates, but if you let the roadmap so the talking you can save lots of time here.
I’m not sure you need a PM. As this seems so delivery and execution oriented. I’d look to solve it in other ways and spread the burden over others.
Unless you want a PM who will do more than that, but this seems quite boring and you definitely don’t need a senior.
I’d be bored out of my mind doing those menial things.
If you would offload talking users, strategy and planning, at least to some extent then a PM will add a lot more value.
- A company without a formal PM/PO function is falling behind on release notes, user and stakeholder updates, roadmap editing and prioritization, user-feedback management, UAT, launch communications, and knowledge-base updates; budget constraints are driving consideration of fractional or part-time help.
- The discussion distinguishes strategic fractional PM work from execution-heavy part-time support: one recommendation is to retain roadmap prioritization and potentially user-feedback ownership internally while automating or redistributing routine updates, knowledge-base maintenance, UAT coordination, and release communications.
- A proposed staffing split assigns a motivated junior/full-time hire to release notes, stakeholder and user communications, launch messaging, and knowledge-base updates, while a fractional senior PM handles roadmap prioritization, user feedback, UAT, competitive analysis, and coaching the junior hire.
- Suggested implementation practices include defining explicit goals and deliverables like an outsourced QA engagement, separating research/analysis/recommendation work, standardizing communication templates and processes, tapering an initial full-time engagement to three then two days per week, and embedding workflows so the team can continue after the specialist leaves.