We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
Snyder's method for finding demand and keeping customers
On Lenny's Podcast, Rob Snyder said demand comes from a specific person with PULL:
- Project: something on their to-do list, like "I want to hire more employees," not "buy recruitment software."
- Unavoidable: it has to happen now.
- List: the options they've considered.
- Limitations: the reasons those options aren't good enough .
All four have to be present. A product team with an urgent, required feature that it can build itself "won't buy anything unless their existing options aren't good enough" .
Advice PMs can act on:
- Talk to customers before you build. Snyder calls building first the most "brutal" trap. AI shortens it to weeks, but you should still "face the cold wind of reality as soon as possible" .
- Skip design partners. In his experience they buy into your vision, give feedback "playing Steve Jobs," and never buy. People with a real job to get done just want it done . Offering a partnership puts off buyers who really need the product and attracts people who don't .
- Throw the Hail Mary. If a call is lukewarm, ask what they'd pay to have taken off their plate right now. One startup selling applicant tracking to governments got its first contract from a job-description problem it heard about this way .
- Design for retention. Snyder assumes every customer will churn until they reach a specific outcome, "X." Find X and build onboarding so every customer gets there. For his restaurant retention product, X was preventing an employee from quitting within the first two weeks . If churn is near-total, find out who stays. One horizontal AI-workflows startup found freight forwarders sticking with a single workflow and refocused the whole company on them as a premium product .
- Run a "case study factory." Repeat one customer win across pipeline, sales and delivery, then fix the current bottleneck first .
Will AI push PMs toward strategy or toward constant execution?
A former PM now in grad school says the job has become "all about speed and no one cares about quality." They see two possible futures: PM merging with brand and marketing, or moving into consulting and forward-deployed roles . Replies split three ways:
- Judgment matters more. One PM's biggest worry is companies "confusing the ability to build faster with knowing what to build." They expect PM to move toward strategy, positioning and trade-offs .
- Back to normal. Another hears less 2025-style "product is going away" talk. Building faster, they say, "hasn't necessarily translated into happier customers or more money" .
- Product under strategy. A PM in logistics predicts product orgs will report to CSOs rather than CTOs, with PMs prototyping and testing with users before engineering starts .
The pushback comes from the execution side. A B2B SaaS PM describes doing discovery, delivery and releases "at basically the same time" under constant pressure to ship faster. They call it temporary, driven by leaders' "ridiculous promises" about AI .
Aakash Gupta makes a related point about strategy. Decentralized decisions (even CSMs are "shipping to production") and PMs' career incentives are spreading AI across products. A strategy has to help teams say no, and AI only belongs where it advances the core value proposition .
Pay and backgrounds of PMs at AI model labs
Gupta reports that open model-PM roles posting a US salary range have a $345K median base, versus $216K for PM roles outside AI. He reviewed 316 product people at 22 model-training companies:
- 85% were PMs before joining the lab.
- 64% have a technical degree.
- 28% founded a company first.
- Median career length is 13 years .
Only 6% started in data or research . His advice: take the AI feature on your team, learn to build evals, and write the behavior spec yourself .
Turning tacit knowledge into specs
A non-technical founder with 230+ paying users built a financial-services product largely with AI. He is weighing a developer hire with a $35K recruiter fee, and says explaining the domain often feels slower than building it himself . The top advice: spend a week writing the financial rules as test cases (input, expected output, and why). That becomes "the spec, the regression suite and the onboarding doc at once" . Another builder says their real bottlenecks after AI are decisions and testing, not generating specs .
Also notable
- Hiten Shah: you learn a lot by watching someone use a product without the builder explaining anything .
- TBM 447: John Cutler argues that "our work and our workplace are not the same thing." Protecting the work can mean accepting a workplace's limits, choosing your battles, or moving on .
- Rob Snyder’s pull framework locates demand in a specific person, not a company: they have a project or workflow they must address now, their existing options—including doing it themselves—are inadequate, and the product gets them unstuck; pain or value alone is not enough without urgency and inadequate alternatives.
- For zero-to-one, form a pull hypothesis through firsthand observation of customers’ work, then reflect their project, urgency, and inadequate options and test whether they try to buy; check that the signal repeats with other prospects. Don’t delay customer conversations to build first; Snyder warns design partners can provide feedback without having an urgent job they need done. If calls are lukewarm, ask what they would pay to have taken off their plate now and use the answer to revise the hypothesis. He says this also applies to established companies: successful new-product ideas he heard about came from customer requests on sales calls, while whiteboarded ideas did not; he recommends learning through selling.
- After a sale, identify the specific outcome that makes a customer unlikely to churn and design delivery and onboarding to get them there; investigate churn for a segment or workflow with stronger pull. For scale, treat the startup as a factory for repeating one customer/problem/outcome case across pipeline, sales, and delivery, focusing on the current growth bottleneck.
- Use the PULL framework to assess demand at the individual-buyer level: a Project they are trying to complete, Unavoidable urgency, a List of options they considered, and Limitations that make those options insufficient. All four matter; pain or value alone may not displace existing priorities.
- Find and test a pull hypothesis before committing to a product: get firsthand exposure to customers’ work, describe what the person is trying to do and why current options fail, then look for concrete buying behavior—not praise or hypothetical future interest. The same approach can guide new products at established companies: the interview cites customer requests arising in sales calls as a source of successful products, unlike ideas generated on whiteboards.
- Make early outreach a short invitation to talk, not a product pitch; on calls, ask why the person took the meeting, agree on an agenda, and get permission to explore their context before pitching a simple way to help. If the conversation is lukewarm, ask what they would pay to have taken off their plate now and use the answer to revise the hypothesis. Avoid proactively turning urgent buyers into design partners: that can shift the conversation from getting a job done to helping build a product.
- Treat retention as a product-delivery problem: identify the customer outcome or behavior that makes churn unlikely, then design onboarding and hands-on delivery to get customers there. If churn is high, investigate which customer segment or workflow retains and consider focusing the product there.
- Model growth as a repeatable “case study factory”: repeatedly acquire, sell to, and deliver for customers with the same successful use case; find the current bottleneck across pipeline, sales, and delivery, and focus on resolving it.
- Commenters suggested early-stage startups may be a better fit for returning founders’ ownership experience, while larger companies may worry about founders being flight risks or unwilling to work within organizational constraints. One advised emphasizing scrappy, cross-functional work on a resume rather than leading with the CEO title.
- The transition can be difficult: one former founder said adapting to organizational politics and norms remained a struggle after returning to product; another commenter described the senior+ PM market as much more selective and recommended referrals, recognizable company names, or deep industry experience.
- A commenter also described moving from cofounder and CEO of a 25-person startup to global CPO of a 60-person business, showing a possible senior product leadership route back into an organization.
- Workplace reactions that seem self-sabotaging may be responses to genuinely harmful or dysfunctional conditions, not proof that the problem exists only in one’s head. Trying to correct every reaction through tighter self-monitoring can reproduce suppression and pressure, while workplace power and evaluation norms may reward dominance, overconfidence, and dismissiveness.
- Separate commitment to the work from attachment to a particular workplace: conflicts need not be a referendum on competence or identity; choose battles, accept the workplace’s limits, or move on. Acceptance does not require abandoning efforts to change a difficult situation or challenge injustice; act without needing to control the outcome.
- In a founder’s AI-built financial-services product with 230+ paying users and substantial domain-specific requirements, commenters recommend making tacit knowledge explicit: document key workflows and what “done” means, and turn financial rules into input/expected-output test cases that can serve as specs, a regression suite, and onboarding material. A bounded paid feature can test the handoff: ask a candidate to derive acceptance criteria from a customer scenario and carry the work through testing and release without step-by-step direction.
- One commenter proposed using an AI-based product manager to capture domain knowledge, translate requirements into specifications, and coordinate development agents; another cautioned that decision-making and testing may be the real bottlenecks, since added software can make changes harder.
- Several commenters argue that AI makes execution faster and cheaper without improving the judgment of what to build, shifting PM value toward customer understanding, opportunity selection, positioning, strategy, trade-offs, and taste rather than output volume or backlog coordination.
- One forecast is that Product will align more closely with strategy than engineering: PMs could use AI to prototype and gather user feedback before engineering takes on work, then orchestrate teams and resources—potentially making the traditional MVP less central.
- A counterpoint is that AI may consolidate responsibilities: with fewer people needed to implement changes, people who understand both system behavior and business needs may take on more cross-functional decisions and risk management. One PM also reports pressure to run discovery, delivery, and releases concurrently while pushing for faster execution, a warning that AI-era role changes may intensify delivery strain.
Andrew Chen suggests that the post-AI era may enable more solo and nontechnical founders, including domain experts without tech experience (such as a dentist building dental SaaS) and content creators whose products become apps.
An India-based B.Tech student built PM Radar to consolidate India and remote PM, APM, and product-internship listings after finding the search fragmented and listings often stale. The board links to original company postings, filters by level, experience, location, and recency, offers optional daily email updates, and lets users report listings that ask candidates to pay fees. Its AI “Check my match” feature gives a role-specific fit score, identifies gaps, and suggests resume lines; the resume is stored in the browser and sent to Google’s Gemini AI when the user runs the feature. A commenter proposed improving listing freshness and trust with a “new and checked today” view, original-posting check timestamps, and closed-role reports, and making match explanations distinguish missing experience from missing resume keywords.
Lenny Rachitsky highlighted an 86-minute product-market-fit guide with Rob Snyder, whose discussion covers the PULL framework for finding customers who are “weird not to buy,” sources of startup ideas, effective cold outreach, first sales calls (including why Snyder skips design partners), and the “Hail Mary” question and “goblin mode.”
Hiten Shah recommends learning about a product by watching someone try to use it without the builder explaining anything.
- Product strategy should help teams say no rather than endorse a long list of priorities, and AI features should advance the product’s core value proposition for users and buyers; decentralized shipping and incentives to build AI features may contribute to “AI everywhere” proliferation.
- The post reports median base pay of $345K for model-PM openings with posted US ranges, versus $216K for PM roles outside AI. In a separate review of 316 LinkedIn profiles across 22 companies that train AI models, 85% had been PMs before joining a lab, 64% had a technical degree, and 6% started in data or research; the median career length was 13 years. The suggested next step for current PMs is to take on an AI feature, learn to build evals, and write the behavior spec.
- Spotify’s team extensively iterated on wireframes before writing code, then launched in Europe after two years of product iteration, when it could provide what it considered the best possible service—a case for not skipping wireframes.
Product teams should prioritize what customers actually need over disputes about who copied whom or who thinks they were copied.
For Product Owner interview prep, candidates with operations or consulting backgrounds can draw on examples of prioritizing competing requests, managing stakeholders, and making decisions with limited data; they should also practice writing user stories, defining acceptance criteria, and deciding what enters a sprint.
A product manager with 2.5 years in Microsoft’s product organization, most recently working on Copilot, moved to a Series A startup for faster learning and greater ownership . A commenter advised speaking with current startup employees and assessing over 6–9 months whether the role brings more responsibility or stake, while noting that Microsoft experience may continue to open career doors .
The prototype lets users predict outcomes in news, sports, politics, and internet events using free points, targeting South Asian countries . A commenter suggested testing it in three cricket WhatsApp groups and checking whether 100 people return daily, treating repeat use as a stronger signal than prototype interest . Another commenter questioned whether free points alone give users enough reason to participate .
Backlog Agency says it is actively hiring for a few US-based and remote product management roles; candidates must register on its website to view current openings.
Use market-demand research and customer discovery to test a business opportunity; one commenter recommends The Mom Test and cautions against relying on advice from people who urgently need your help. For positioning, emphasize concrete business advantages—team strengths, differentiated go-to-market access, and customer pain points you can uniquely reach—rather than the idea alone.
A skincare recommendation platform is seeking pre-launch QA testers for a 30-second face-scan feature; no signup or full skin assessment is required. Testers are asked to probe edge cases—including dark lighting, glasses, hair over the face, an open mouth, multiple people, or a face photo—and submit feedback through a three-question form.
For entry-level PM applications, commenters recommend showcasing user research, feature prioritization, and completed end-to-end projects in a resume and portfolio, and networking with PMs for advice or referrals. One commenter described the path as difficult for freshers and reported being told that college background can matter; this is anecdotal advice, not evidence of a general hiring rule.
r/startups comment by u/TrainingOstrich657
Solo founder with 230+ paying users and growing. Do I spend the money to hire a developer or keep building it myself? (I will not promote)
I’m pretty torn on what to do at this point and would appreciate some advice from other founders who’ve been in a similar position.
I started a B2B software company almost two years ago. I’m currently the only employee, although I’ve been through about five different employees and contractors along the way.
I don’t have a software engineering background, but I’ve basically built the entire product myself, largely using AI. We now have over 230 users in a niche market, solving a real problem with real, paying, recurring customers. It may not sound like a lot but it’s a niche, high dollar value customer base and it’s continuing to grow.
It’s entirely possible that we could generate another $500k in revenue over the next six months. But it’s also entirely possible that we only generate $100k. There’s a lot of uncertainty, and that’s part of what’s making this decision difficult.
Here’s my dilemma.
I want to hire a software developer to take over the development side of things so I can focus on actually growing the business. The problem is that I’ve really struggled to find the right person.
In my experience with previous developers and contractors, I’ve often found that it’s easier to just use AI and build things myself rather than explain everything to someone else. But the downside is that doing it myself still takes a tremendous amount of time.
On one hand, I desperately want someone to take this work off my plate. On the other hand, if I have to explain exactly how to do everything, I feel like I might as well just do it myself.
Part of the challenge is that our software is in the financial services space and requires a significant amount of subject matter expertise. It’s not something where I can just tell a developer, “Hey, go build this feature,” and expect them to figure it out. There’s a lot of domain-specific knowledge involved.
I’ve tried just about everything to find someone. I’ve reached out to our users, posted on job boards, tried recruiting through Reddit, and ultimately ended up working with a recruiter.
We finally found someone who we think could be a really good fit. The problem is that it’s really expensive and it feels like I’m burning precious capital.
Just the recruiter’s fee alone is around $35k, on top of the developer’s salary.
I realize that potentially generating $500k in revenue over six months sounds great, but that’s far from guaranteed. If we only generate $100k, suddenly I’ve got a serious cash flow problem, especially after committing to a full-time salary and a $35k recruiting fee.
So I’m sitting here trying to figure out whether I should take the financial risk and hire this person, or just keep doing what I’ve been doing and continue building the product myself with AI.
The business is working. We have paying customers. There’s clearly demand. But I also know I can’t keep spending all my time developing the software if I want to grow the company.
For founders who’ve been in this position, what did you do? At what point did you decide it was worth taking the financial risk to bring on a developer, especially when you were already capable of building the product yourself?
Would love to hear from people who’ve actually dealt with this.
Most replies here are about how to hire. The thing I’d settle first is whether you can survive the bad case, because that’s what’s actually stopping you.
Do the math on the $100k scenario, not the $500k one. Salary + benefits + the fee, against cash on hand plus revenue at your current run rate (not projected). If that still leaves you 9-12 months of runway, hire. If it doesn’t, the answer is “not yet”, however good the candidate is.
On the $35k: recruiter fees are often more negotiable than founders assume. Ask to split it across 2-3 payments and to extend the replacement guarantee to 90+ days. If they won’t move at all, that tells you something too.
On “it’s faster to do it myself”: that usually means the domain knowledge only exists in your head, not that developers are slow. Before anyone starts, spend a week writing your financial rules down as test cases: input, expected output, and why. That becomes the spec, the regression suite and the onboarding doc at once. A good hire can work from it without you dictating every feature, and it protects you better than an NDA, because the rules live in the company rather than in one person.
Last thing: with an AI-built codebase, plan the first month around them learning it and adding tests, not shipping features. If you expect features in week 2, you’ll conclude the hire failed when it was really just onboarding.
- In a founder’s AI-built financial-services product with 230+ paying users and substantial domain-specific requirements, commenters recommend making tacit knowledge explicit: document key workflows and what “done” means, and turn financial rules into input/expected-output test cases that can serve as specs, a regression suite, and onboarding material. A bounded paid feature can test the handoff: ask a candidate to derive acceptance criteria from a customer scenario and carry the work through testing and release without step-by-step direction.
- One commenter proposed using an AI-based product manager to capture domain knowledge, translate requirements into specifications, and coordinate development agents; another cautioned that decision-making and testing may be the real bottlenecks, since added software can make changes harder.