Product Adoption Blues: Don't Build Before You Feel Pull

Solve the adoption problem before development starts. Product managers and product owners can talk about the user’s current project and the result they might provide. They can show a rough output, run the work manually, or ask the user to put some skin in the game. But do not build yet. Strong pull needs to earn the backlog item and delivery plan.

That is the sharper application of Rob Snyder’s work. A team that waits until after release to ask whether users care has already spent most of its learning budget. ADKAR can help people adopt a worthwhile change, but it cannot turn a nice-to-have feature into something people need. The product team’s first job is to find demand strong enough to pull a solution into existence. Then it can build the smallest thing that fits that demand and help the new behavior stick.

You know the scene. Someone requests a feature. The idea fits the strategy, users say it would be helpful, and the business case shows plausible value. The roadmap slot is approved, the team builds it, and the release notes go out. A few friendly users praise the demo.

Then they return to the spreadsheet, the Slack message, or the person they already know how to call. The product team responds with more communication and training, followed by nudges or manager escalation. Sometimes that closes a real capability gap. But it is an expensive way to discover that the original signal was courtesy or intellectual agreement rather than demand.

The adoption problem did not begin when usage stayed flat. It began when the team treated “I like it” or “I would use that” as enough evidence to build.

Rob Snyder describes PULL as the state of having demand. It is more specific than a painful problem, an attractive idea, or a positive return-on-investment calculation. His current framework looks for four conditions:

• Project: A person has a specific project on their real to-do list and is working on it now.
• Unavoidable: There is a reason this project must be addressed now instead of remaining in the infinite backlog.
• List of options: The person is already considering ways to make progress, including workarounds, services, hiring, other products, or doing the work manually.
• Limitations: Those options have serious shortcomings that block the result the person is trying to achieve.

Together, the four give the need a shape. The user is not waiting for a product team to create urgency or teach them that a problem exists. They are already trying to make progress and cannot get there with the options available. A solution that fits can be pulled into that situation.

This is why Snyder distinguishes people who need something from the much larger population who would merely benefit from it. Someone can agree that your feature is useful, understand its ROI, complain about the current process, and still be perfectly rational not to adopt it. If their project is not active and unavoidable, using your feature would require them to displace work they care about more.

Snyder’s ideas sit in familiar territory. The Lean Startup treats product ideas as hypotheses and uses validated learning to decide whether to persevere or pivot. Running Lean starts with risky assumptions about a customer and problem, then tests them outside the building. Both try to reduce the waste of building on untested beliefs.

Pretotyping goes after the same waste with the useful challenge to make sure you are building the right “it” before you build it right. The Mom Test teaches you to avoid compliments and hypothetical promises by asking about what people already do, then looking for commitment and advancement. All four push a product team away from internal certainty and toward observable evidence.

Snyder adds a particularly demanding definition of what you are trying to observe. A problem is not demand. Pain is not demand. A person saying they would pay or use the feature is still not the same as someone trying to complete an unavoidable project and finding that the available options cannot get them there. PULL connects the timing of the project, the user’s alternatives, and the limitations of those alternatives into one causal picture.

His practical advice follows from that picture. Sell the project before you build the product. Deliver the result manually if you can. Show the successful output, not a polished fake product. In a commercial setting, ask the customer to pay, because payment shows seriousness that a free design partnership often hides. You are trying to discover a project that already has enough pull, then learn what supply would fit it.

For a PM or PO, “do not build” does not mean “do not learn.” Talk to people who are doing the work. Walk through the last time they attempted the project. Ask what made it important now, what they tried, and where those options failed. Offer to produce the result manually with a spreadsheet, an analyst, a concierge service, or a temporary workflow. A rough mockup can help explain the idea, but the useful signal is what the user does next, not how many comments they add to the screen.

This is also where product discovery often gets distorted. Once a polished prototype exists, the conversation becomes supply-shaped. Users discuss screen details and missing fields because that is what the team put in front of them. The team leaves with a longer feature list and a warm feeling, but still does not know whether the underlying project is unavoidable or whether anyone will change behavior to get the result.

The build decision should come after the product team has seen strong pull repeat in a deliberately chosen group of users. Not necessarily hundreds of users. But enough similar cases to explain, in plain language, who is trying to accomplish what, why it has to happen now, what they use today, why that fails, and what they actually gave up to try a better way.

Snyder’s strongest commercial signal is payment. Internal products often cannot use money that cleanly, but they still need a price. The price can be scarce attention, access to live data, time from the people doing the work, agreement to run a manual pilot, or willingness to retire part of the old process. A sponsor saying “this is strategic” is weak evidence if nobody close to the work will make room for it.

Before building, I would look for signals such as these:

• A named team has a real project and deadline, not a general interest in improving someday.
• Users provide live cases and data.
• The team will try a manual or concierge version of the result before software exists.
• Someone with authority will remove a policy, incentive, or process barrier if the experiment works.
• The users agree what current option they will reduce or stop using if the new approach succeeds.

These signals are valuable because they cost something. They expose whether the request can survive contact with competing priorities. If users will not invest a few hours in a manual test, it is hard to believe they will absorb the disruption of a new production workflow later.

The Prosci ADKAR model describes five outcomes an individual needs for change: Awareness, Desire, Knowledge, Ability, and Reinforcement. It is a useful adoption map once you have identified a change worth making. The sequence helps a PM or PO see why a genuinely valuable product may still fail to become normal work.

But ADKAR cannot excuse weak demand. Awareness of your feature is not evidence that the user’s project is unavoidable. Desire is not a communication deliverable that the rollout team can manufacture with better messaging. If people understand the feature and still have no reason to displace their current priorities, you may not have a change-adoption problem yet. You may have built without pull.

Used well, PULL and ADKAR answer different questions. PULL asks whether there is already enough demand to justify creating supply. ADKAR asks what must be true for each person to adopt and sustain the new behavior. Before development, you can assess likely Knowledge and Ability barriers. Check whether permissions and data quality support the workflow. Look at incentives and manager support too. After a manual test or release, Reinforcement tells you whether the surrounding system supports the new behavior or quietly rewards the old spreadsheet and approval chain.

This ordering matters. First find people who are already trying to move. Then remove the barriers that keep them from moving with you.

A product operating model is supposed to move the organization from funding output to steering for outcomes. Without that, the promise is hollow. The product team needs explicit permission to keep learning without converting uncertainty into code.

That means a roadmap candidate should carry demand evidence, not only a problem statement and an estimated business case. What active project did we observe, and why is it unavoidable now? Which options are users trying? Where do those options block them? What did users commit before we offered production software? Which repeated cases suggest that a small amount of supply could enable meaningful behavior change?

If those answers are weak, the next step is more demand discovery, a manual service, a pretotype, a different target group, or stopping. It is not an MVP by reflex. An MVP is still a product. Even a small feature creates code and support obligations, invites security review, depends on data, and takes capacity away from other work. Cheap building can make this discipline harder because it lets us avoid the uncomfortable conversation about whether anybody is pulling.

There are exceptions. Infrastructure and hardware may require technical work before users can experience the result. So can regulated capabilities or long-horizon platform investments. Even then, separate feasibility risk from demand risk. Find the consuming team and its unavoidable project. Ask for evidence that the capability will be used if it works. “We have to build something before we can test it” should change the experiment, not erase the need for evidence.

Maybe the feature is already live. Then the honest move is not to declare the work complete or immediately increase the rollout pressure. Treat the release as an expensive pretotype and look for the few users who adopted without being chased. Study the project that pulled them in, the alternatives they abandoned, the limitations your feature overcame, and the ADKAR conditions that helped the behavior stick.

Those cases can become a repeatable adoption pattern. Find other users with the same project, urgency, failed options, and operating conditions. If you cannot find such a case, stop adding adoption theater around the feature. Narrow it, change it, reposition it around a different project, or stop investing.

This is Snyder’s founder advice, translated. Do not build a feature and then push people toward it. Find the pull, serve the project with the lightest possible approach, and let repeated evidence earn the right to build.

If your product operating model still turns polite interest into roadmap commitments, take the Product Organization Scorecard or let’s talk about making evidence of value part of how the work is managed.