We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Big Ideas
Cheap building moves the PM bottleneck upstream. Agents can already build prototypes, instrument products, test implementations, review code, and fix issues; the harder question is shifting from “can we build this?” to “should we build it?” The practical response is to study behavior-changing mechanics rather than clone feature surfaces: identify the behavior your product depends on—such as trust to delegate, evidence becoming a decision, or context surviving a handoff—then find a proven mechanic from another category and build the smallest test. As implementation gets cheaper, judgment, taste, and ruthless prioritization matter more because teams can become very good at building bad ideas quickly; the differentiator is a repeatable loop of hypothesis, smallest test, measurement, and retained learning.
Agent UX still needs fast first-mile proof. Scott Belsky’s note argues that consumer products win partly on how users feel about themselves using them and how quickly they reach value. For agent experiences, he specifically calls for quick ROI on the time and data users provide, onboarding that balances general value with personalized problem-solving, and fresh onboarding validation for new cohorts rather than assuming beta behavior will scale.
Tactical Playbook
Turn discovery into a compounding log. Use one real potential customer per day as a baseline—without pitching—and ask what they are trying to solve, how they handle it now, and what they have already tried. After roughly 30 conversations, recurring language and objections should clarify positioning and acquisition; the value comes from writing down the patterns. For a higher-intensity version, run five conversations daily, ask about a recent event, workaround, owner, cost, and urgency, end with a dated next step, and review weekly which segment replies, reaches value, and pays. Build funnels and automation only after the log shows something repeatable.
Audit “not enough time” before adding another process. Nir Eyal frames motivation as behavior + benefit + belief: knowing the action and wanting the result is insufficient if someone does not believe in the outcome or their ability to act. His interview’s belief audit is usable for PM prioritization: write the belief, test whether it is absolutely true, examine how it changes behavior, ask who you would be without it, then try an opposing perspective for a week.
Case Studies & Lessons
AI lawyer: validate trust before buying reach. A founder says an early Reddit/news spike faded because the product was not ready; now it is usable, but the hype is gone, with SEO and waves of previous-user outreach supplying the remaining traction. Community advice identifies the product’s original credibility story—not “AI” itself—as the trust mechanism, and recommends a real lawyer using the product on real files and willing to vouch before paid acquisition. Search ads should follow evidence about the terms that successful users already searched, not precede it. The PM lesson is to treat distribution problems as product-proof problems until the target workflow and trust signal are explicit.
An org chart does not create a product culture. An internal-product proposal assigns PMs business needs, buy-versus-build, pilots, roadmaps, and outcomes; Data Science/AI owns models and agents, IT owns infrastructure, and business teams supply domain expertise and KPIs. The response is that this separation alone will not end project-pipeline behavior: teams need to validate before building, deploy and learn quickly, and treat every “sure thing” as unvalidated until evidence arrives.
Career Corner
Customer access is part of the PM job, not a perk. A platform-security PM reports an engineering-led environment where architects design features, the internal CISO is the stated customer, and large customers speak only with leadership; the PM still prioritizes but lacks direct discovery. The practical career move is to name the customer explicitly and ask for access rather than quietly accepting second-hand requirements. That gap may be structural—executive customer history or sales-controlled relationships can push PM value toward business operations—so document how you turn indirect input into decisions while seeking roles with real customer exposure.
Tools & Resources
Sharpn.ai is a new community-built PM mock-interviewer: its author describes a free simulator covering product sense, metrics, strategy, behavioral, execution, technical, and estimation interviews, with job-description tailoring, scoring, feedback, and study articles. The author says probing uses contextual clues to decide when to dig deeper. Use it for repetition and feedback; the reported Microsoft outcome is the builder’s own claim, not independent validation.
Most actionable material: a belief-audit method for "I don't have enough time" — the most common time-anxiety limiting belief — plus a behavior-benefit-belief model of motivation. The author (Nir Eyal) presents the method; the host (Jeff) provides the live case study, so attribution matters.
Time anxiety is a belief problem, not a supply problem. Eyal says "I don't have enough time" is the most common limiting belief he hears, and the coaching demo treats it as a testable belief rather than a fact . The goal is not truth but "a portfolio of perspectives" that decrease suffering and preserve motivation .
The audit steps (demoed live): write the belief; ask "Is it true?" and "Is it absolutely true (100%, no exceptions)?"; ask "Who are you with that belief?" (emotions and behavior); ask "Who would you be without it?"; then generate the diametric opposite (e.g., "I have plenty of time for the things that matter") and try one on for a week .
Host's case shows the operational cost of the belief: 40 unfinished to-dos a day, constant anxiety, frustration, and being dismissive/not present with people . His proposed alternative: do less but better — phone on airplane mode, journal, and think hard about high-leverage relationships and opportunities rather than reacting . The host also identifies self-imposed deadlines as the source of urgency . This is host framing/example, not the author's prescription.
Motivation model: behavior + benefit + belief; persistence is the decisive factor in success, and a missing belief (e.g., not believing in one's ability) extinguishes motivation .
Product-building stance: Eyal writes "not what I know but what I want to know," rooted in first-principles habit work (Hooked) and a tech-positive treatment of distraction — a curiosity-led practice applicable to product discovery, though the interview doesn't apply it to PM process directly .
Practical follow-up: free 5-minute belief-change plan at nearandfar.com/belief-change .
Uncertainty: transcript lines contain no explicit speaker labels; turn boundaries occasionally occur inside a single line, so attribution above follows content cues (e.g., "I hear" indicating the author).
Hiten Shah argues that as software gets cheaper to build, the limiting question shifts from "can we build this?" to "should we build it?" — agents already prototype, instrument, test, review, and fix code, eroding engineering scarcity as a prioritization mechanism.
Meta's model of treating the consumer internet as an external product lab — studying proven behaviors like Stories, Reels, and Threads instead of doing expensive discovery — becomes a required capability for every software company.
Don't clone features; extract the "mechanic" underneath. A pull request's mechanic (proposed work, visible to others, attached async feedback, approval changes state, persistent history) transfers beyond dev; Stories' mechanic lowered creation pressure, showed the creator who watched, and fed another sharing loop.
Cross-category learning works: games→enterprise, GitHub→AI, TikTok→research, marketplaces→agent trust. Framework: identify the single behavior your product depends on (trust to delegate, trust between transactions, evidence→decision, context for handoff), then hunt for mechanics proven to drive it.
Companies will build libraries/graphs of mechanics annotated by effect (raises contribution without big rewards, lowers anxiety of sharing unfinished work, makes verification more likely, builds reputation as byproduct, multiplayer workflows, network-density-dependent) and by where they fail. AI agents can watch launches, changelogs, reviews, OSS, and app stores to find patterns, break mechanics apart, connect them to behaviors, and suggest translations — then another agent builds the prototype.
As build costs drop, human judgment, taste, knowing which behavior matters, understanding why something worked, and knowing when to leave the product alone become the differentiators. Engineering scarcity used to block mediocre ideas; without it, ruthless prioritization is essential to avoid a new class of bloated products built by teams confusing ability with reason.
The winning capability is a learning loop: see something interesting, understand what's underneath, hypothesize why it matters for users, build the smallest test, measure, and keep the learning — the whole software industry becomes an external R&D lab.
Core practice: run at least one discovery conversation per day with a potential customer — no pitching; ask what problem they're trying to solve, how they handle it today, and what they've already tried (one commenter does five/day) . Log each conversation verbatim; after 30–100 conversations, recurring objections and language reveal your positioning, objections, and acquisition channels — this log becomes the repeatable system, not content calendars or outreach volume . Avoid habits that only produce visible counters (daily posts, DMs, feature shipping): they make you look active but don't tell you what's true; the goal is eliminating wrong guesses, and funnels/automation are premature until patterns emerge . For structured conversations, ask about a recent event, current workaround, owner, cost, and urgency; end with a dated next step; then review weekly which segments reply, reach value, and pay . The Mom Test is recommended for running effective customer conversations , and even two-minute talks reveal objections no dashboard shows .
A PM at a non-tech, data-heavy company proposed an org structure to avoid project-based execution: Product Managers own product strategy, outcomes, and delivery, run buy-vs-build and pilots/MVPs, then hand mature products to IT for maintenance; Data Science/AI owns data needs, ontologies, model/agent selection and performance; IT owns infrastructure, maintenance, and project management; Business teams act as domain experts, support discovery/roll-out, and own KPIs for their area . The team's context is using AI and PM to improve internal business efficiency, with data platforms and AWS build vs SaaS buy partnerships .
A commenter argued this structure alone won't shift the org from project-pipeline work: business teams are often biased in discovery and can't meaningfully own KPIs if they don't decide what's built. The real lever is culture: validate before building, deploy fast and learn quicker, treat learning as the top priority after revenue/profit, and treat every idea as unvalidated until proven. Since a PM alone can't change everyone's mindset, start with yourself and your closest team, push for bite-sized initiatives with quick learning, and be data-driven .
Career resilience tip for large org-change efforts: expect endless resistance and guard against burnout .
- For early idea validation, a founder recommends starting with one buyer and one painful job, interviewing ~10 people about the last time the problem occurred, what they tried, and what it cost, then offering a small paid manual solution before building anything — a payment or strong refusal teaches more than months of planning . Another distills the sequence to: get an idea, try to get people to buy it, and only if enough want to buy, build and sell it .
- Payment is the only signal that counts in validation: "the only validation that counts is someone reaching for their wallet"; surveys, likes, and "I'd totally buy this" are noise. A hardware founder validated his product with a waitlist and small paid batches .
- To judge an idea's worth: if a company or product already exists, the problem exists — the question becomes whether you can do it better — and you should ask why anyone would buy or use your product . A first business is better as an existing model "with a twist" because the market is already proven: you only have to be better for a specific someone, not new for everyone .
- Entering a field without background is doable (one founder self-taught electronics as an adult), but expect the learning to take about a year and design the plan around that; alternatively partner with someone who has the background .
- Biggest mistake flagged: building in private too long while waiting to "feel legit" — shipping something embarrassing to ten real people beats polishing for an imaginary thousand .
Startups do source short-term senior expertise, most commonly via the fractional executive model — e.g., one series B company had most of its CxO team start as fractional consultants and convert to full-time once workload scaled to five days a week .
- Startups typically prefer advisors with startup-to-scale-up experience over general 20–30-year big-company tenure, and often source them through their investors; today's startups lack the 2010s-level cash to pay many advisors. Retired veterans are most often tapped for one-off product feedback, investor-advisor roles, or help selling to the veteran's peers .
- The need is real but not something to build a product around: startups satisfy it via investors, fractional services, or advisory boards — mostly for rolodex access — and much knowledge sharing happens free through founder networks .
- A matchmaking market exists: companies offer hourly consulting by matching clients with experts (often via LinkedIn), and agencies find the right experts. These matches are usually subject-matter experts for questions like market saturation or price points; generic functions (sales strategy, finance, HR, operations) are more likely covered by a part-time business developer .
A candidate preparing for a Salesforce PM interview is seeking paid coaching and specifically wants help with product sense, product strategy, execution, case studies, and Salesforce-specific interview expectations . A community reply recommends interviewing.io and StellarPeers as cheaper, decent PM interview prep alternatives .
Gergely Orosz: Grok Bot is a massive success — a 'Claude Code' moment for 'normie' knowledge work, 'OpenClaw without needing to know anything about OpenClaw' — and every day OpenAI, Anthropic, Google wait to release something similar, giving up future market share on a market likely bigger than coding AI agents . Hiten Shah predicts Grok Bot will become a Slack/Teams alternative, noting 'Macrohard needs an interface' . He sees the missing piece as multiple humans in the same chats: multiple agents already interact with users and each other in @bot's group chats, so 'Add team member' is all that's needed .
- Multi-channel selling quickly breaks single-store inventory assumptions: Amazon, Shopify, eBay, and in-person each track their own counts, and a spreadsheet falls behind; overselling is the scarier failure because the customer waits for a product that doesn't exist .
- A pragmatic starting point is a safety threshold — automatically mark stock out-of-stock when it drops below a set number; the hard part is tuning it high enough to prevent overselling without making too much inventory look unavailable .
- Manual inventory edits do not scale across multiple storefronts — missed updates become likely as volume grows; purpose-built inventory software can manage syncing, though the challenge is keeping channels in sync without adding another complicated process .
PM hiring has shifted: Meta, Oracle, and Amazon layoffs have flooded the candidate pool with ex-Big Tech PMs who shipped at scale, so resumes with brand names no longer differentiate . Companies now screen for AI tool fluency, evidence of shipped AI features, and are replacing case interviews with case-study homework assignments . Candidates who get callbacks aren't necessarily stronger — they've 'portrayed the right version of themselves' by assembling a complete profile (GitHub, resume, content) so jobs come to them . Across 155 students in three cohorts, the pattern held that job search strategy beats pedigree; reported outcomes include a Head of Product Led Growth role at FormAssembly in 6 weeks, a VP of Product role at homebot.ai, and a Head of Product role at Times of India after closing 5 offers in 2 months .
In a r/startups thread where a solo technical founder asked for advice on cold-emailing to validate an idea , a practitioner advised separating the ideal customer profile (ICP) from the buyer persona — "playbooks get catered to the persona but the ICP represents a client category" — and validating before building "as to not build things no one wants or will buy," recommending the book Value Proposition Design. He described validating his own GTM offering by manually producing a prototype report sold at $650 (the finished build should be over $20,000) to live clients found through direct outreach; one client never paid but expanded to five states using the prototype . Other commenters suggested defining the ICP first, then joining communities where target users already hang out — Reddit, Discord, and role-specific meetups/conferences — and engaging with value rather than spam to gauge interest .
In an r/startups thread on automating B2B SaaS lead generation, a commenter recommends choosing the outbound motion by ACV: for ACV <$10k use PLG + PQL outreach (free tier → usage signals → automated upgrade nudge + one human call), since cold email is too expensive per acquisition; $10k–$50k: intent-based multi-channel (website visitors, G2 comparers → email + LinkedIn + call); $50k–$200k: 1:few ABM (50 accounts, 5-8 stakeholders each); >$200k: partner/channel and executive networking . Decision rule: if ACV <$15k, kill cold email and build a PLG funnel + PQL automation instead .
Sharpn.ai (http://sharpn.ai) is a free PM mock interviewer built by a Senior PM with nearly a decade of experience; it provides simulated interviews with instant feedback and scores based on industry standards . It covers product sense, metrics, strategy, behavioral, execution, technical, and estimations . Practice flow: pick a topic, optionally paste a job description, complete the interview to receive a score and full feedback, and request a tailored study article on how to approach the question and improve weaknesses . The tool uses context clues to decide when to probe deeper, mimicking real interviewers . Author claims a colleague landed a job at Microsoft using the tool exclusively as interview prep .
- The Central European AI lawyer platform's early traction came from a local Reddit launch post ("young local founder made AI law startup") plus a local news article, but traffic died once the novelty faded because the SaaS was too basic to be usable by real lawyers; all leads now come from Google SEO for local-language "lawyer AI" searches, and the founder is emailing previous users in waves before trying paid outreach .
- A commenter argues the original post worked because it carried a credibility story local journalists and Redditors could vouch for — the story, not the AI, was the trust mechanism — and that the founders' shift to a "more corporate" positioning removed that story, so paid traffic would arrive at a site with no equivalent trust signal .
- For skeptical, professionally cautious buyers like lawyers, paid ads just amplify whatever signal already exists; the recommendation is to build a referral or case-study layer before spending on reach: one working lawyer using the product on real files and willing to say so, ideally backed by other lawyers, a bar association, or a legal publication .
- Channel guidance: LinkedIn is where lawyers extend trust to unfamiliar tools (through people they follow professionally); Facebook is the wrong register for this buyer; Google Ads can work only once the founder knows the specific search terms best users actually typed — asking whether keywords must be selected indicates that data doesn't exist yet, so paid spend would be guessing .
- The thread's core question: with AI making building so cheap that "everyone can ship something in a weekend," the market fills with things that "look like a product but aren't solving anything," and teams doing hard, valuable work get lost in the noise or get assumed to be API wrappers — though an alternative view is that AI removed the boring parts so good teams move faster .
- Practitioner view on the net effect: AI makes it easier to get a good product to market that might not otherwise have survived development, but it has to fight much harder for attention — "development has gotten easier, but it makes distribution and getting attention from investors harder" .
- Durability argument: because AI made supply cheaper, generic products are easier to copy and harder to trust; durable advantages have moved toward proprietary distribution, workflow integration, customer evidence, data rights, and reliable operations. A startup "has to prove an outcome rather than merely demonstrate that something can be generated" .
- One concrete case: a bootstrapped enterprise software company run by a handful of people expects to close above 80% EBIT margin this year, which the operator says would be impossible without Codex/Claude — i.e., AI-enabled small teams can run highly profitable enterprise products .
- Counterpoint on market quality: before AI, the same percentage of new startups were "hopeless noise"; AI has increased the quantity of startups more than it changed the overall quality .
- Reminder on where startup value actually lies: not in building the service itself but on everything either side of it — research, validation, MVP testing, and scaling .
A Reddit user starting as data product owner at a small retail company will own data platforms on BigQuery and BI; their prior product ownership experience was on data science and NLP, not data warehousing or data platforms. They ask whether to start learning data engineering to work better with engineers and whether this role is the right career track .
A platform security PM describes an engineering-led environment where architects/engineers design features, the internal CISO is the stated customer, and requirements from large customers trickle down via manager/LT; the PM retains prioritization using business impact and market research but lacks discovery/requirements-gathering responsibility, raising the question of whether the role is product or program management .
Advice to PMs in this situation: explicitly identify all customers (including internal ones), ask leadership directly about customer access, and recognize that unstated expectations may exist; in the commenter's experience, such gaps often need to be actively surfaced rather than handed over .
Two observed reasons for PMs having minimal customer contact: (1) a GM with deep customer history (e.g., ex-CTO of a major customer) makes product decisions that the team executes; (2) sales teams guard customer relationships and product definitions follow industry standard specs, shifting the PM's value to business operations .
Advising a hardware founder on validation, a commenter recommends approaching the question from the application side: identify who has an interest in a system hardened against connection losses, imagine a plausible scenario, and build a demo solving that problem for them . When choosing a market, pick the one with the greatest yearly revenue; if consumer, consider the next best B2B market, where margins are higher and adoption can be quicker with fewer requirements, especially for hardware . Before building, contact potential users to ask what they would like in the prototype . The commenter notes the technical side seems set but the business needs improvement .
On r/ProductManagementJobs, a user who had completed a product marketing case study asked for suggestions on product sense and innovation case studies . A commenter recommended sharpn.ai (simulated mock interviews with instant feedback) and TryExponent (practice mocks with other real aspiring PMs) as good places to run mock case studies and get quick feedback . The original poster said they would try it .
Founder of a Central European AI lawyer platform, whose leads came from SEO and a viral local news article, seeks outreach channels as article traffic fades and the product becomes usable . Advisors suggest: rather than jumping to ads, first identify which returning users get the most value and what they use the product for, then test Google Search ads around that specific use case — otherwise paid traffic enters a leaky funnel; the founder plans to check power users and run Google ads around that usage . SEO works eventually but is competitive; ads give quicker ROI if laser-targeted to the right market . For a legal AI product specifically, narrow outreach to one practice area and one recurring workflow, lead with the operational trigger and evidence you can safely show rather than a broad AI promise, and surface confidentiality, accuracy, supervision, and procurement requirements early in founder-led conversations . Since organic is already converting, mine analytics for the specific pages and search terms pulling in lawyers, build deeper content around those topics, and interlink it internally before spending on ads .