Product-market fit: stop building what nobody needs

Picture a founder sitting in front of a potential customer.

The product works. The demo is polished. The AI features do what they promise. The customer nods along, asks a few thoughtful questions and says something every founder has heard:

"This is really interesting. Send me some information."

Another promising meeting. Another opportunity in the CRM. Three weeks later, nothing.

The founder adds another feature, improves the onboarding and rewrites the sales pitch. Perhaps the product just needs to be a little better. Or perhaps nobody needed it in the first place.

This is an illustrative scenario, but most founders will recognise it. We confuse customer interest with buying intent, product usage with product-market fit, and activity with progress. It's the same confusion that turns MQLs into lead theatre.

AI is making that confusion more expensive. Building got cheap, so we can now build a lot before anyone has made a meaningful commitment.

In a recent episode of Lenny's Podcast, Rob Snyder, author of The Power of Pull, walked through his framework for finding product-market fit. Lenny introduces him as someone who has helped more than 50 startups go from zero to 1 million dollars in ARR.

His central idea fits in two sentences. Find people who already need to make something happen and can't get there with their existing options. Then see whether they actually try to buy.

I think this reaches far beyond early-stage startups. It changes how we should approach product management, go-to-market and the AI systems connecting them.

Your biggest competitor is the customer's to-do list

Most product teams start with problems. They conduct customer interviews, identify pain points, estimate market opportunities and build solutions. Then marketing translates those solutions into value propositions, and sales tries to convince prospects to care.

The process looks logical. There's just one missing variable: priority.

A customer can have a genuine problem, recognise that your product solves it and agree that it offers excellent value. And still have no intention of buying.

They have fifteen other things to finish this quarter. Their existing workaround is acceptable. The boss has demanded something else. Or the problem is annoying but has no meaningful consequences.

In Snyder's framework, the difference between interest and genuine demand is pull. Pull happens when a particular person is already trying to accomplish something important, needs to do it now and finds their existing options insufficient.

That person is already trying to change. Nobody has to convince them that change is necessary.

The distinction flips the approach to product-market fit. The question moves from how to persuade more people to buy, to where people are already trying to buy something that doesn't quite exist yet.

The PULL framework: four conditions for real demand

Snyder breaks this down into four elements.

Element	The question
P: Project	What is this person actively trying to accomplish?
U: Unavoidable	Why must they accomplish it now?
L: List of options	What alternatives are they considering or already using?
L: Limitations	Why can't those alternatives get the job done?

All four matter. A project without urgency becomes a nice idea for next year. Urgency without limitations means the customer can probably solve it themselves. A better product without an important project is just another tool someone doesn't need.

Snyder gives an example from Jump, an AI meeting-notes product for financial advisers.

Financial advisers need to document client meetings and keep records in their CRM. Snyder explains that compliance obligations make the work unavoidable. Generic AI note-takers might produce good summaries, but they don't necessarily integrate with the required systems or meet the compliance requirements. Jump addresses that specific gap.

Now compare that with insurance agents. They also spend time meeting clients, and they might also dislike writing notes. But in the example Snyder describes, they don't face the same requirement to keep those records in the CRM. Doing nothing is an acceptable alternative.

Same broad pain. Similar workflow. Very different buying behaviour.

That's an important lesson for anyone defining an ideal customer profile.

An industry is not your customer. A company is not your customer. A person with an unavoidable project is your customer.

And that person's current priorities matter more than your carefully polished value proposition.

AI has changed the economics of getting product-market fit wrong

Here's where I would extend Snyder's argument.

For years, building software was expensive enough to force some discipline. A major feature required developers, planning, testing and months of engineering capacity.

Today, a capable founder can use AI-assisted development to produce a working prototype in days. That's real progress, and it creates a new trap: we start using speed of execution as evidence of progress.

A team builds ten features, launches three landing pages, automates outbound and creates a polished demo. The weekly review looks productive. Yet the most important question remains unanswered.

Who is trying to buy this, and why now?

Coding got fast. Getting to market didn't. More precisely, the bottleneck has moved. When building becomes cheap, deciding what deserves building becomes relatively more valuable. When I wrote about building a SaaS product in 90 days, the hard part was never the code. It was the cutting.

Product-market fit can no longer be treated as a phase that happens after product development. It needs to shape development from the beginning.

That means customer conversations are more than research inputs for product managers. They're commercial experiments that test whether the customer will act. And the strongest signal is a purchase.

Stop interviewing people about your idea. Test whether they try to buy.

Snyder recommends starting with what he calls a pull hypothesis. Before building the product, write down your assumptions about the buyer's situation.

Here's a hypothetical example from B2B software development. A VP Product is under pressure to deliver a major release this quarter. Her team uses Jira, documentation tools and AI coding assistants, but important product decisions aren't consistently reflected in implementation work. The release is at risk, and adding more developers won't necessarily solve the coordination problem.

The hypothesis becomes:

• Project: Deliver a committed release without losing critical requirements between product and engineering.
• Unavoidable: The release has an externally committed deadline.
• Options: More meetings, more product managers, better documentation, existing Jira integrations and AI coding tools.
• Limitations: These options may improve individual tasks without reliably keeping decisions, tickets and implementation aligned.

Notice what is missing. There's no feature list, no grand product vision, no pitch about AI magic. Just a specific person, an important project and a reason existing methods aren't working.

This is the kind of hypothesis worth testing for a product like Teklens, which I co-founded: a shared Product Brain, one memory for people and AI agents that connects product conversations, Jira and code.

But it's still a hypothesis. The relevant buyer may not consider the problem urgent. The team may already handle it well enough. Or the actual buyer is a CTO preparing for an audit, rather than a VP Product managing a release.

The purpose of discovery is to find out.

Snyder recommends showing potential customers a simple description of the project, urgency and limitations, followed by a conceptual explanation of how you could help. Then watch what they do.

Some ask for an implementation plan, pull in a colleague, raise procurement or ask when they can start. Others congratulate you on the vision and promise to keep in touch. Those are very different signals.

A verbal promise to buy is encouraging. A paid commitment is stronger. Actual adoption and retention are stronger again.

Five sales conversations can teach you more than five weeks of development

One of Snyder's most useful recommendations is to work in small discovery cycles. Start with a hypothesis. Find relevant people. Run around five conversations. Review what you learnt.

If nobody is trying to move forward, don't automatically book another fifty meetings. Change the hypothesis. Maybe the problem is real but not urgent. Maybe the wrong person owns it. Maybe existing tools are already sufficient. Or perhaps you've discovered a different project that matters far more.

Snyder calls one way to discover this the Hail Mary question:

"Is there anything on your to-do list that you'd pay someone to take off your plate right now?"

It's a plain question, and far more useful than asking what features someone would like to see. It moves the conversation from product opinions to actual priorities.

People are generous with feedback about products they have no intention of buying. They'll happily spend an hour designing your roadmap. They just won't finance it.

Snyder is particularly sceptical of design partnerships that generate a lot of feedback but little commercial commitment.

I wouldn't dismiss design partners entirely. In complex B2B environments, co-development can reveal integration constraints, workflow realities and organisational requirements that would otherwise stay invisible. But the commercial test still matters. A design partner should have a real project, a defined success criterion and a credible route to becoming a paying customer. Otherwise, you might have recruited a helpful product adviser rather than a buyer.

Sell the outcome before you build the platform

There's another implication that AI makes particularly interesting. You don't always need a finished software product to test demand. If a customer needs a specific job completed, you can sometimes deliver the outcome with a combination of people, existing software and automation.

Snyder describes founders starting with service-shaped offerings before developing the underlying software.

Imagine a company that needs to reduce its market research cycle from weeks to days. The first version might involve researchers using AI tools, manual quality checks and a simple reporting interface. The buyer gets the outcome. The provider learns which steps are repeatable. Then the team automates those steps. It's the order a forward deployed engineer works in: map the real process first, then automate what repeats.

This reverses the traditional sequence. The old one: build software, find customers, hope they use it. The new one: find an urgent job, sell the outcome, deliver it, learn the workflow, then automate what repeats.

That is particularly relevant to AI-native B2B companies. But there's a risk. If every customer requires a different implementation, you haven't necessarily found a scalable product. You may have built a consulting business with excellent tooling. I've written about where that line runs, and about the honest middle path of product plus services, in service agency vs software product.

The discipline is to separate the repeatable core from the bespoke work around it. Charge for the outcome early. Learn what's reusable. Productise the recurring work. Don't confuse five unrelated customer projects with product-market fit.

Product-market fit doesn't end when customers buy

A customer who urgently wants to buy can still churn. Perhaps the product doesn't work as promised. Perhaps implementation is too complicated. Perhaps the buyer's immediate project ends, and the product is no longer needed.

Snyder suggests thinking about the customer's journey in two stages. Before purchase, you need to find someone for whom buying makes obvious sense. After purchase, you need to identify the moment when leaving would no longer make sense.

That second moment is more useful than celebrating activation rates. A login proves little. A customer completing a task that used to block their business is a much better signal.

For a product connecting requirements, tickets and code, that moment might be a team catching an important mismatch before it reaches production, then resolving it with the right context. For a GTM system, it might be a seller getting an actionable buying signal that would otherwise have disappeared between the CRM, meetings and emails.

These are hypotheses to test, not universal activation metrics. The operational question is:

What must a customer experience before they would genuinely miss the product if it disappeared?

Then build onboarding backwards from that moment.

Run your company as a case study factory

Towards the end of the interview, Snyder introduces an idea I find more useful than the PULL acronym itself: think of your company as a factory producing repeatable customer success stories.

He means customer outcomes that repeat, customer after customer. Marketing case studies with polished logos and suspicious percentages are something else.

Each successful customer follows roughly the same pattern. A particular person has an urgent project. Their existing options fall short. They buy something that helps. They achieve the desired outcome. They stay because the solution remains valuable.

Your company becomes a system for repeating that pattern:

1. Find the right buyer.
2. Understand the urgent project.
3. Prove a credible solution.
4. Win a commercial commitment.
5. Deliver the promised result.
6. Reach lasting value.
7. Retain, learn and repeat.

This mental model connects product management, sales, marketing and customer success around one definition of success. It also changes how you think about growth.

If pipeline is the bottleneck, improve how you find similar buyers. If customers have urgent projects but don't buy, investigate the offer, credibility, commercial process or purchasing constraints. If they buy but don't stay, improve delivery and time to value, or reconsider whether the initial demand is repeatable.

The focus changes with the constraint. That's far more useful than telling every department to improve all its KPIs at once.

Where shared context becomes the missing infrastructure

This is where I see a connection to the systems we're building around Product, GTM and AI.

Imagine a customer tells Sales that their biggest priority is reducing release delays. The discussion produces useful evidence about urgency, existing solutions, blockers, budget and the people involved.

In many organisations, that information stays in a call recording or a CRM note. Product receives a feature request stripped of its original context. Marketing creates a generic pain-point message. Customer Success gets an onboarding checklist but not the business outcome the customer expects. Then an AI agent is asked to prepare a follow-up from whichever fragments it can retrieve.

Everyone is working. Everyone has different information.

Snyder's case study factory requires something more coherent. The same customer evidence should inform the product decision, the commercial promise, the implementation plan and the retention milestone. Nobody needs to read one enormous document for that. Each person and each agent needs the relevant evidence at the moment they decide.

This is the principle behind Get Multiplayer: humans set goals, decide and approve. Agents prepare and do the repeatable work. Shared goals and shared context keep them working together.

For example, one agent can extract a customer's active project and alternatives from a sales conversation. Another can compare those requirements with the product backlog. A third can prepare an onboarding plan based on the promised outcome.

But people must still check the evidence and decide what it means. Otherwise, you're simply automating assumptions. Faster. At scale.

Where I disagree: pull alone doesn't guarantee a great business

Snyder's framework is especially useful because it forces commercial honesty. But it isn't a complete theory of company building.

A customer can have genuine urgency and still represent a terrible market. Perhaps the project only happens once every five years. Perhaps the buyer has no authority to spend. Perhaps delivery costs more than the contract. Perhaps the problem is extremely valuable but exists in too few organisations.

Strong pull validates a particular opportunity. It doesn't automatically validate market size, attractive margins, repeatable distribution or defensibility.

In enterprise B2B, the distinction between a person who wants the solution and an organisation that can purchase it is particularly important. The champion may have pull. Security, Legal and Procurement still have requirements of their own.

That's why I see the PULL framework as a complement to a well-run enterprise sales process, rather than a replacement for one. And it's why retention matters as much as early purchase intent.

You need three layers of evidence:

• Demand: Do people urgently try to buy?
• Value: Does the solution produce a result they care about?
• Economics: Can you repeat that result profitably across enough customers?

Only when these reinforce one another does an exciting opportunity start to resemble a scalable business.

A practical product-market fit playbook

If I were starting a new B2B product next Monday, I'd organise the first cycle around seven activities.

1. Choose a person, not a market. Identify the role, responsibility and situation where the need is likely to be urgent. "Mid-market SaaS" is too vague.
2. Write a PULL hypothesis. Document the project, why now, existing options and why those options fail. Mark assumptions separately from confirmed customer evidence.
3. Get close to the work. Observe actual workflows, customer meetings, tools and handovers. Interviews help, but watching someone struggle with a real task can reveal what they forget to mention.
4. Run five commercial conversations. Ask about current projects, deadlines, attempted solutions and purchasing steps. Show only enough of a proposed solution to test whether they'd move forward.
5. Look for action, not enthusiasm. A paid diagnostic, signed order, commercial commitment or customer-driven procurement process is stronger evidence than positive feedback.
6. Deliver the outcome and find the retention moment. Work closely with the first customers. Identify the event that proves lasting value, then make that event central to onboarding.
7. Turn learning into a repeatable system. Feed validated evidence into positioning, product priorities, sales qualification and onboarding. Find the next bottleneck and improve it.

AI can help at every stage. It can analyse calls, cluster patterns, compare options, produce prototypes, prepare proposals, document learning and automate repeatable delivery work.

What it cannot do is manufacture an urgent customer priority where none exists. That's why the human role remains essential: deciding whether the evidence justifies the next investment.

Build less. Learn what deserves building.

I started with a founder who had a polished demo and a prospect who promised to get back in touch.

The typical response is to improve the product, send another follow-up and increase outreach volume. Sometimes that's exactly what's needed. Sometimes the most valuable next step is admitting that you're trying to sell something nobody is urgently trying to buy.

Rob Snyder gives us a practical way to tell the difference. AI gives us the ability to act on that learning much faster. The combination works, provided we use the technology in the right order.

Find the urgent project. Prove the customer will act. Deliver the outcome. Make it repeatable.

Find the customers worth building for first. Then let AI make you fast.

If you want one operator note a week on Product, GTM and AI, subscribe to The Science of GTM newsletter.

Based on Rob Snyder's conversation with Lenny Rachitsky on Lenny's Podcast, An 86-minute guide to finding PMF, published 25 October 2026 (listen on Snipd). Rob Snyder's book: The Power of Pull, John Murray Business, 2026. The PULL framework, the Hail Mary question and the case study factory are Snyder's. The reading for Product, GTM and AI and the practical extensions are my own.