We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
AI coding speed is making product discovery a control plane. A principal product designer reports 3× PR volume versus the same period a year earlier, but also solutions that bypass the process and leave product teams with less visibility. The team’s response adapts Teresa Torres’s Continuous Discovery Habits: ingest interviews, research, and market/competitive intelligence; review an Opportunity Solution Tree weekly across Product, Engineering, and Design; prototype targeted opportunities, map journeys, test assumptions cheaply, and promote only validated solutions into specs and sprints. Tie opportunities to outcome metrics and shipped features to leading and lagging traction metrics. Add lint gates for accessibility and design-system violations, plus an agent that checks the Definition of Done and runs browser testing under reviewer observation. Apply: let agents accelerate evidence and prototypes; keep problem framing and release ownership visible to the team.
Trust is becoming consumer-agent UX. A consumer-AI product thesis treats personality, proficiency, and personalization as consequential as the graphical interface; contextual selective memory across platforms as a potential moat; and trust as distinct from privacy, requiring understandable reasoning plus inspectable, auditable actions when agents make decisions or purchases. Treat the return on data access, memory and forgetting rules, and action audit trail as first-mile product requirements—not policy copy.
Tactical Playbook
Diagnose same-day trial churn before changing onboarding.
- Compare cancellation records with failed charges or abandoned 3DS, then check whether “cancelled” accounts still use days 2–7; those users may be preventing renewal rather than churning.
- Ask one required reason inside the cancellation flow—setup failure, missing expected job, price, or testing—instead of emailing after exit.
- For genuine non-returners, inspect the first 90 seconds with session replays and confirm that the walkthrough waits for fetched data.
This splits one alarming metric into distinct fixes: billing copy, product promise or onboarding, and payment failure.
Use payment as the demand gate. For a product already held by three customers paying $700–$1,000 MRR, one recommendation is to ask what they used before and would return to if the product disappeared; test the next idea as a paid, two-week concierge before writing software. If nobody pays for the manual version, the software is unlikely to sell.
Case Studies & Lessons
Microsoft certification signaled security, not acquisition. A founder converted an internal Google Chat assistant into SaaS, then spent three months on BYOK, knowledge connectors, and security. Reaching the Microsoft marketplace required multiple accounts and repeated review failures; Microsoft 365 certification added 56 controls, 600–900 pages of PDFs, 100–150 screenshots, and a penetration test. After certification, the founder reports no major sign-up increase and concludes that marketplace presence is primarily proof of safety; pursue it when clients require security approval, not as a growth channel.
Pitch Deck Coach demonstrates a better AI-evaluation pattern. The review was restricted to LinkedIn’s 37-slide 2004 Series B deck, excluded later knowledge, and was compared only afterward with Reid Hoffman’s retrospective. It rejected projected conversion rates and margins as proven because paid products were not live, and correctly refused to infer recruiting as the first business because the deck presented three revenue businesses—even though the founders knew that privately. A disagreement over when usage evidence should appear led the bot to distinguish concept from data pitches and check whether a deck addresses the investor’s biggest objection. Takeaway: evaluate AI against time-bounded artifacts, separate forecasts from evidence, and expose strategy that exists only in the team’s head.
Career Corner
Match your operating style to your management contract. Ask whether leadership wants a strategy- or execution-heavy PM and whether it prefers testing every AI feature or using proven tools. Extend the calibration to docs versus meetings and detail versus headline updates, then reset assumptions with a new boss, team, or post-layoff environment. Put the answers into a working agreement during the first 1:1 and revisit it when the environment changes.
Tools & Resources
Product Idea Stress Test. The bot takes an idea, identifies what must be true, looks for evidence, and recommends the next test—explicitly countering AI’s tendency to flatter an idea. Use it before roadmap commitment, then turn its assumptions into the discovery or paid-concierge tests above.
- Evaluation pattern for AI reviewers: Hiten tested Pitch Deck Coach on LinkedIn’s actual 2004 Series B deck, restricted it to the 37 slides, instructed it to ignore everything that happened afterward, and froze the review before showing it Reid Hoffman’s retrospective. This setup separates judgment based on the original artifact from hindsight.
- Method updates and lessons: The evaluation changed the bot’s methodology by adding a distinction between concept pitches and data pitches and a check for whether a deck deliberately addresses the investor’s biggest objection. The review also rejected projected conversion rates and operating margins as proven because LinkedIn’s paid products were not yet live. It exposed a communication gap when the deck presented three revenue businesses while the founders privately knew recruiting would come first. A related trade-off: the coach wanted LinkedIn usage evidence earlier, while Reid Hoffman considered the analogy slides among the strongest because the deck was a concept pitch and its available data looked small beside Friendster and MySpace.
- AI-assisted coding can increase output while creating product-governance risks: one team reports 3× PR volume but also solutions bypassing the full product process and reduced product-team visibility; another account describes unrequested “vibe-coded” features, skipped design, engineers unable to explain edge cases, and feature-count incentives that produce unused features later sunset.
- A reported countermeasure adapts Teresa Torres’s Continuous Discovery Habits to AI: ingest customer interviews, research, and market/competitive intelligence into a shared discovery system; review an Opportunity Solution Tree weekly with Product, Engineering, and Design; use mixed-discipline teams to generate POCs for targeted opportunities; map user journeys, identify assumptions, test them cheaply, and promote only validated solutions into specs and sprint work. The process defines the “what” before sprint execution and links opportunities to outcome metrics and shipped features to leading and lagging traction metrics.
- Quality controls include lint rules that block or warn on accessibility violations, measurement of design-system compliance, agent-friendly component documentation, removal of deprecated patterns, and an agent command that checks proposed work against the definition of done and runs reviewer-observed browser user-testing loops; the contributor reports less rework after these changes.
- PMs can add an ownership gate through demos and UAT: shipping does not pass unless developers can answer questions and address PRD concerns; developers who cannot explain or demonstrate coverage repeat the demo.
- One practitioner offers a clearly labeled small, isolated cautionary example: leadership mandated an AI-native approach instead of targeting bottlenecks, after which costs spiraled, delivery suffered, and feature quality deteriorated.
- Health-tech product work benefits from tracking both reimbursement mechanics and outcomes: one practitioner says many workflows exist to satisfy reimbursement rules, while an experienced health-tech PM/GM argues that outcomes demonstrate ROI and competitiveness and should be selected based on the payer mix and population served.
- Build on transferable PM fundamentals—understanding users, buyers, and their pain points—then add domain knowledge; for healthcare, recommended learning includes CMS and ONC materials and regulations such as HIPAA and the 21st Century Cures Act.
- Career signals are mixed: one commenter describes health-tech PM as a lower-paying niche than tech PM and suggests ad tech or marketplaces for stronger earning potential, while another reports growing recognition that technical talent is needed to repair data and architecture problems, making many openings “rescue jobs.”
Shreyas Doshi criticizes Claude’s new personality as user-hostile: it allegedly confidently asserts what is good for users without being asked, assumes users are unintelligent, and uses jargon to sound intelligent; he says these behaviors make the experience unbearable.
- Use a staged discovery-to-MVP workflow for new opportunities: understand the underlying problem, research existing solutions, identify customer pain points and gaps, map those gaps to a possible solution, validate it with a small group, and build only the unmet portion into the MVP. Clear communication of the problem and intended solution is also part of the test.
- Gate development on willingness to pay: run a paid, manual concierge version for roughly two weeks before writing software; pre-selling a minimal solution or securing multi-month commitments provides stronger demand evidence than interest alone, while failure to get payment for the manual version is a strong warning against building the product. Examples of lightweight tests include Buffer’s landing page with paid tiers, Dropbox’s demo video before the product was ready, and Tesla’s preorders.
- Treat demand and distribution as separate product risks: even a product addressing a high-demand problem may fail to convert users without a strategic acquisition capability; “build it and they will come” is not a sufficient strategy.
- Use existing paid traction to define the job to build around: for the poster’s three customers paying roughly $700–$1,000 MRR, the recommended next step is to ask what they used before the product and what they would return to if it disappeared.
- A university PM club is considering practical programming such as product teardown workshops, mock product cases, prioritization and roadmapping exercises, user research, product strategy workshops, and company/site visits.
- A suggested exercise is stakeholder role-play, including a scenario where someone asks a PM to extend an app their cousin built with Claude in an hour; this can practice handling unrealistic requests and stakeholder expectations.
- For AI-assisted UI work, coding agents should prove completion rather than merely report it by attaching before-and-after screenshots or video to every UI-change pull request. The referenced workflow uploads the media directly to GitHub’s user-attachments endpoint and embeds the returned URL in the PR body, avoiding committed media and external hosting.
- Treat same-day trial cancellations as separate diagnostic populations: users who cancel billing to avoid accidental renewal but continue using the 7-day trial, and users who genuinely stop using the product. Compare sessions on days 2–7 with failed-payment or abandoned-3DS records before changing onboarding. In this case, the founder reports that users retain access but do not use the app, while a read-only landing-page demo is already available, so billing anxiety is not yet a sufficient explanation.
- Analyze the first-session path rather than relying on post-cancellation emails: distinguish users who complete the walkthrough and perform a meaningful action such as exporting or copying something from users who remain in the empty state, then inspect the first 90 seconds with analytics and session replays. Also verify that the walkthrough does not appear before fetched data loads, since teaching the product against an empty screen could create immediate abandonment.
- Capture feedback inside the cancellation flow, before confirmation, with one required question and concrete options such as setup failure, missing expected functionality, price, or exploratory testing; use the responses to split the same-day cohort into different problems. Compare time spent in the read-only demo with time spent in the signed-up app; if users spend longer in the demo, investigate a promise-to-product mismatch at signup rather than assuming onboarding is the only issue.
Hiten Shah introduced a Product Idea Stress Test bot for evaluating ideas before building. Users provide an idea; the bot identifies what must be true for it to work, looks for evidence supporting those assumptions, and recommends what to test next. Shah created it to counter AI’s tendency to simply tell users that their ideas sound interesting.
- @rauchg treats inbound DMs as a product-discovery channel: he reads every message, even when he cannot reply, to learn about new ideas, identify ways to improve the product, and find where it is falling short. He also uses the channel to spot potential hires and investment opportunities.
- Use the first positive response to define targeting and messaging. After finding one interested customer, compare that person with the non-converters: where they were, what they were already doing about the problem, and the language they used. Treat the shared pattern as a targeting specification and reuse the customer’s own words in future outreach.
- Validate acquisition channels with sustained volume. The founder reported roughly one lead from 20 cold Reddit messages and no success from cold email; a commenter argued that 20 messages is only a warm-up, recommended sending 100 more comparable messages, and advised running the channel that produced the only positive signal for a month instead of switching channels every two weeks.
- Conduct behavioral discovery with beta users. Ask the beta tester to reconstruct the last time they encountered the problem step by step—including any workaround they created—rather than relying on a survey; the workaround can become both the product specification and the language for the pitch.
- Lead with the customer’s problem before presenting the product. One founder’s outreach approach is to go where target customers gather, discuss their problems and failed approaches, and only introduce the product once the solution appears relevant and the customer is receptive.
- AI workflow: Move beyond using AI like a search engine by supplying substantial context and examples of work you consider good, then letting it execute the task. Gradually increase the responsibility delegated to AI as confidence grows.
- A founder reports that a $29 web app promising an “over 50% decrease in distress” had been tried by about 100 people with “genuinely great results,” yet prospects remained skeptical that a product at that price could deliver. This frames conversion as a trust/credibility problem, not only a pricing problem.
- Test pricing and trust separately instead of making the whole product free: compare $29, a lower price, and a limited free version, while measuring starts, completions, payments, and refunds. If users get results but will not pay, investigate price/value; if they will not try because they distrust the claim, free access may not solve the barrier.
- Keep monetization reversible through field/A/B testing, tiers, or a time-limited trial rather than permanently opening the product; suggested variants included a 14-day trial followed by a $29 paywall. Freemium is most defensible when free users can create reach or referrals in a mass market; niche products should not assume free users add value without that distribution effect. For a product making therapeutic or distress-reduction claims, commenters also urged validating clinical, licensing, and messaging requirements; the founder said it was being treated as wellness with legal messaging guidelines.
- One hiring manager said an MBA and college background receive zero emphasis in PM hiring; direct relevant experience is most desirable, indirect experience is acceptable, and attitude matters.
- A core PM communication skill is noticing pain points in current processes and leading discussions toward solutions; PMs must also understand team concerns, create processes that keep execution smooth, and explain plans and their rationale to stakeholders.
- One commenter described a tough market in which technical skills are highly sought after for platform PM roles amid AI adoption. They also highlighted pricing and packaging, go-to-market coordination, and engineering skills or awareness of building products from code; an MBA may help with making a business case but is not a substitute for technical capability.
- Career tactic: Adapt product-management practices to what your current leadership expects rather than copying advice from PMs in different environments. Ask leaders directly about the desired strategy-versus-execution split and whether they prefer experimentation with every new AI feature or reliance on proven tools.
- Use the same expectation-setting approach for work-life balance, communication format, and managing upward. Reassess assumptions when changing managers, teams, or companies, and align especially closely with the environment when starting a new role, getting a new boss, or after a layoff.
- A startup founder says the main obstacle for a $29 trauma-memory distress app is user skepticism rather than product roughness; the team is weighing free distribution against future backlash and attracting non-paying users instead of customers.
- A practical validation approach is a constrained trial instead of permanent free access: gate 30-day access behind a short survey, collect feedback on outcomes, and test a conversion incentive; another suggestion is a free single session followed by paid access to encourage commitment.
- To reduce trust friction, commenters recommended social proof and testimonials, questioned the “50% decrease in distress or your money back” claim, and suggested pursuing a university study to replace anecdotal results with peer-reviewed evidence.
- Pricing may influence perceived credibility: one commenter argued that a very low price can look “too good to be true” and suggested testing higher or subscription pricing, though this is presented as anecdotal advice rather than validated evidence.
- A claim-verification pipeline tested on 11 U.S. equity raises and 56 claims initially flagged 73% of companies for at least one unsupported claim, but every apparent contradiction involved point-in-time valuation, total-raised, or user-count figures that were being compared with third-party aggregators lagging by a funding round; the mismatches were usually stale-data artifacts rather than deception.
- The revised workflow separates durable claims from snapshot metrics, date-stamps every figure before flagging discrepancies, uses the SEC Form C as the source of truth for U.S. raise amounts, and treats the small n=11 sample as a case study rather than a publishable statistic. Durable claims in the sample were mostly supported: 19 of 25 verified, 5 partially supported, and 1 contradicted.
Stripe CEO Patrick Collison describes AI economic infrastructure as a cross-stack product challenge spanning agent wallets, MPP, Tempo, MCP, Stripe CLI, Agentic Commerce Suite, sandboxes, OpenRouter, metered billing, Radar, and distillation/token fraud; he says this is changing “pretty much every layer” of Stripe’s stack.
- Use VC “Requests for Startups” as discovery input, not roadmap direction. The discussion warns against repeatedly pivoting to chase hot lists and recommends asking why an “A for B” idea signals an emerging need, then checking for a genuine gap, demand, and a differentiated advantage.
- Gate major product bets with evidence and incentives. Classify prompts as random guesses, potential investor lures, or genuinely insight-backed opportunities; avoid spending years on speculative or investor-driven ideas without sufficient early capital. For promising opportunities, use the sequence: identify a potential need, verify that people will pay, build or supply the solution, and iterate.
- Treat early-stage product validation as a time series rather than waiting for an MVP: maintain a regular evidence trail covering research, positioning decisions, and what you chose not to build. One suggested implementation is a short monthly update cadence.
- Prioritize updates around changed product evidence—such as paid pilots, retention, or sharper insights from customer calls—because recurring communication without new signal is considered less credible.
- Progress from research to evidence of actual product traction: the advice suggests that having a built product and traction leads investors to take the company more seriously than research alone.
r/startups comment by u/Nalds80
I will not promote, anyways how do y’all find customers?
hey. I built one startup, which flopped, I’m working on my second at the moment, I have found a singular lead and person willing to beta test and be on the waitlist. I tried cold emails and didn’t work. cold reddit messages produced one lead out of maybe 20 ish. my successful entrepreneurs, how do y’all find clients?
You buried the actual finding in your own post. Cold reddit messages got you one lead out of about twenty. That is five percent. Cold email got you zero. You are filing both under failed, but one of those is a working channel you are about to abandon.
Twenty messages is not a test, it is a warmup. At that sample size nobody can tell a 5 percent channel from a 0 percent channel, including you. Send a hundred more the same way before you conclude anything about it.
Second thing, and this one cost me a lot of time early on. “How do I find customers” is usually the wrong question once you already have one. The better question is what did that one person have in common that the other nineteen did not. You have a sample of one that said yes, so go study them properly. Where were they, what were they already doing about this problem before you turned up, what words did they use to describe it. That is your targeting spec. Most founders skip this because one data point feels too thin to learn from, then go spray a hundred more messages at people who look nothing like the only person who bit.
Third, one lead plus a beta tester after a first startup that flopped is not a bad position, it is just an early one. The failure mode to watch is switching channels every two weeks because nothing produces fast enough. Every channel looks broken at low volume. Run the one that produced your only yes properly for a month, then judge it.
On that beta tester, talk to them far more than feels comfortable, and not with a survey. Ask them to walk you through what they did the last time they hit this problem, step by step, including whatever workaround they cobbled together themselves. The workaround is your product spec and it is also your pitch, because then you can repeat their own words back to the next hundred people instead of guessing at what to say.
- Use the first positive response to define targeting and messaging. After finding one interested customer, compare that person with the non-converters: where they were, what they were already doing about the problem, and the language they used. Treat the shared pattern as a targeting specification and reuse the customer’s own words in future outreach.
- Validate acquisition channels with sustained volume. The founder reported roughly one lead from 20 cold Reddit messages and no success from cold email; a commenter argued that 20 messages is only a warm-up, recommended sending 100 more comparable messages, and advised running the channel that produced the only positive signal for a month instead of switching channels every two weeks.
- Conduct behavioral discovery with beta users. Ask the beta tester to reconstruct the last time they encountered the problem step by step—including any workaround they created—rather than relying on a survey; the workaround can become both the product specification and the language for the pitch.
- Lead with the customer’s problem before presenting the product. One founder’s outreach approach is to go where target customers gather, discuss their problems and failed approaches, and only introduce the product once the solution appears relevant and the customer is receptive.