Why Your MVP is Lying to You: The Hidden Difference Between Interest, Intent, and Action
Measuring behavior change, not feature engagement.
Master behavioral validation by understanding what each testing approach actually measures. Here are five principles for building ventures on behavior, not hope:
Landing pages measure interest, not commitment. Use them to validate problem awareness and gauge market size, but never confuse sign-ups with behavioral intent. Interest tells you whether customers acknowledge a problem. Action tells you whether they’ll take action. These are fundamentally different questions requiring different validation approaches.
Prototypes reveal preferences, not persistence. Clickable designs help test user flows and feature priorities, but they can’t show you whether customers will maintain behavior over time. People enthusiastically click through prototypes showcasing features they’ll never use in real life. Validate the experience, but don’t assume that clicked screens translate into adopted habits.
Concierge services expose behavioral barriers before you build. Manually deliver your service to twenty customers and observe what actually happens. Where do they get stuck? When do they abandon the process? Which steps require more effort than they’re willing to invest? These insights saved a few weeks of manual work rather than months of wasted development.
Track outcome indicators, not vanity metrics. Feature usage and session length measure engagement with your product, not customer success. Define specific behavioral outcomes that must occur for customers to achieve their goals, then measure those relentlessly. If you can’t demonstrate behavior change, you’re building the wrong thing.
Scale the validation approach to the behavioral risk. Simple utility apps might need only prototypes and quick betas. Ventures that require significant behavioral change demand concierge testing before development. Match your validation investment to how radically customers must change their habits for your venture to work. The bigger the behavioral leap, the more you need to observe real attempts before building.
When 500 Sign-Ups Mean Nothing
Marcus sat in our office holding his laptop like evidence in a trial. On the screen: a landing page for his meal planning app, complete with a waitlist that had attracted 487 sign-ups in three weeks. His pitch deck included screenshots of enthusiastic comments. “This is exactly what I need!” one person wrote. “Finally, someone gets it,” said another.
“So you’re ready to build?” we asked.
“That’s why I’m here. The validation is clear. People want this.”
We asked him a different question. “How many of those 487 people have changed their meal planning behavior?”
The silence told us everything.
Marcus’s experience highlights a common pitfall: confusing interest with action. His landing page captured desire, not behavior. Those 487 people wanted better meal planning, much like many of us want to exercise more or save money. The gap between what customers say they’ll do and what they actually do, week after week, has quietly ended more ventures than any other single factor.
Three months later, Marcus would learn this lesson the expensive way. After building a feature-rich app based on his landing page feedback, he watched as fewer than twenty of those 487 enthusiastic sign-ups used the product more than twice. The rest downloaded it, explored briefly, then returned to their old habits.
What Marcus missed, as many founders do, is that validation exists on a spectrum. Each testing approach uncovers a different aspect of customer behavior, and when we conflate one level of validation with another, we risk investing months of effort and thousands of dollars without learning what truly matters.
The Fidelity-Behavior Tradeoff
Here’s why MVP testing can be so deceptive. As you increase fidelity—how realistic and functional your test is—you also increase the strength of the behavioral signals you can observe. A landing page shows interest. A clickable prototype hints at intent. But it’s only when customers actually use a working product that we can begin to measure real behavior change.
This creates a strategic decision that is often overlooked. Do we start with quick, inexpensive tests that measure early signals, or do we invest more upfront to observe actual behavior from the outset?
The Venture Validation Progression provides a systematic way to think through this choice. Picture it as five organized stages, each one revealing something new about your customers and their likelihood of changing behavior.
Level 01: Landing Page — Testing for Interest Signals
Landing pages serve one main purpose: gauging whether enough people recognize the problem you’ve identified to justify further exploration. They’re the fastest and least expensive way to test basic market interest, but they also provide the weakest behavioral signal.
Marcus spent $200 and 2 days building his meal-planning landing page. He wrote compelling copy about the stress of deciding what to eat, the waste from unused groceries, and the health consequences of defaulting to takeout. He included a simple email sign-up form and a brief survey asking visitors about their biggest meal planning challenges.
When 487 people signed up in three weeks, Marcus felt validated. What he hadn’t yet seen was that he’d only validated problem awareness, not commitment to a solution. People acknowledged their struggles with meal planning and expressed interest in a fix. But interest signals alone don’t tell us whether those same people will actually change their behavior when given a real solution.
The limitation of landing pages becomes clear when we look at what they actually measure: an email address and maybe a few survey responses. The barrier to signing up is low—just a few seconds and no real commitment. People sign up for things they’re curious about, might use someday, or that simply catch their attention. Only a small fraction of those sign-ups reflect a genuine intent to change behavior.
Marcus’s landing page confirmed that meal planning frustration was real and widespread. That insight was worth the $200 he spent. What it couldn’t reveal—because it wasn’t designed to—was whether those frustrated people would actually use an app to change their planning habits over time.
Level 02: Mockup — Adding Intent to Interest
Mockups combine interest and intent by showing users what the product could look like. They’re visual representations that help potential customers imagine how to use your solution. Unlike landing pages, which only describe the problem and promise a solution, mockups let users see the interface, understand the workflow, and interact with specific features.
Marcus created detailed mockups of his meal-planning app, including the dashboard, recipe selection interface, shopping list generation, and calendar view. He scheduled video calls with thirty of his most engaged landing page subscribers and walked them through the designs. The feedback was overwhelmingly positive. People loved the clean interface. They praised the intuitive navigation. They suggested additional features they’d find valuable.
This stage revealed something landing pages couldn’t: which features resonated most strongly with his target customers. People consistently highlighted the automatic shopping list generation as their favorite element. They appreciated the calendar view that showed the week’s meals at a glance. Several suggested integrating with grocery delivery services.
Marcus added these feature requests to his development roadmap, confident he was building what customers wanted. But mockups share a key limitation with landing pages: they measure what people say they prefer, not what they actually do. When someone looks at a mockup and says, “I would definitely use this,” they’re picturing an ideal version of themselves with unlimited time, energy, and willpower.
Mockups can’t show us what happens when someone is exhausted from work, the kids are hungry, and ordering pizza feels easier. They can’t reveal whether the behavior you’re designing for—like planning meals days in advance—actually fits into your customers’ real lives. Mockups give a clearer picture of interest and intent, but they still don’t uncover actual behavior.
Level 03: Clickable Prototype — Understanding Expected Behaviors
Clickable prototypes take validation a step further by offering simulated interaction. Users can navigate screens, click buttons, fill out forms, and experience the product's flow. This approach helps you test whether the user experience makes sense and whether people understand how to perform the behaviors your product requires.
Marcus could have built a clickable prototype for a few thousand dollars using tools like Figma or Adobe XD. Users would open the app, browse recipe suggestions, select meals for the week, see the shopping list populate automatically, and check off items as they shopped. The prototype would feel real enough that users could imagine incorporating it into their weekly routine.
This stage reveals usability issues that mockups miss. Your recipe selection process may require too many clicks. The grocery list organization may not match how people actually shop. Users interacting with a prototype can identify friction points in the workflow before you write a single line of production code.
But notice what clickable prototypes still can’t measure: sustained behavior over time. A user might enthusiastically click through your meal-planning prototype in a 30-minute session, yet never adopt the planning behavior when it requires real effort week after week. The prototype shows us expected behaviors—how users think they would interact with your product—not what actually happens in the context of their busy, complicated lives.
Marcus skipped this stage, moving straight from mockups to development. Looking back, a clickable prototype might have shown that his multi-step meal selection process worked in a demo but created too much friction for weekly use. Even so, the most usable prototype wouldn’t have revealed the core issue: his customers struggled to maintain consistent planning behavior, no matter how smooth the interface felt.
Level 04: Concierge — Revealing Actual Behaviors
This is where validation fundamentally shifts. A concierge approach means manually delivering your service to real customers and observing what they actually do. Instead of asking what people would do or showing them what they could do, you watch what they do when implementation requires real effort, real time, and real behavior change.
For Marcus, a concierge service would have meant offering meal planning as a manual service. Each week, he would send personalized meal plans via email or text to twenty paying customers. The meals would match their dietary preferences, skill level, and time constraints. He’d include detailed shopping lists and simple recipes. Then he’d watch what happened.
This approach reveals behavioral barriers that no other validation method can expose. Some customers would follow the plans religiously the first week, pleased to have the decision-making handled for them. By week two, several would skip days when unexpected work demands arose. By week three, half would have stopped following the plans entirely, returning to their familiar patterns of last-minute decisions and default meals.
The concierge customers who abandoned the service would teach Marcus more than the ones who stuck with it. Exit interviews would reveal the real friction points. “I couldn’t get to the grocery store when you sent the list.” “The recipes required ingredients I didn’t have.” “By the time I got home, I was too tired to follow a plan.” These aren’t feature requests or interface improvements. They’re fundamental behavioral barriers that the product itself can’t overcome.
Running a concierge service takes time and limits scale. Marcus couldn’t manually serve thousands of customers. But serving twenty customers for eight weeks would have cost far less than building a full app that went unused. The behavioral data from those eight weeks could have reshaped his entire approach, had he gathered it before building.
The concierge stage addresses the critical question that earlier stages ignore: can your target customers actually sustain the behavior your product requires? Not in ideal circumstances, not when they’re motivated and energized, but week after week in their real lives with all their real constraints.
Level 05: Working Beta — Demonstrating Scaled Behavior
A working beta is a fully functional version of your product that operates in a live environment. This is the gold standard for behavioral validation, but also the most expensive and time-consuming to create. Unlike a concierge service, which shows customers can perform the behavior with manual support, a working beta shows they’ll perform it through your actual product.
Marcus eventually built his working beta. It had all the features his mockup testers requested: smart recipe suggestions, automatic shopping list generation, calendar views, meal-prep timers, and grocery-delivery integration. He launched it to his waiting list and watched the analytics obsessively.
The initial numbers looked promising. 60% of app downloads resulted in onboarding completion. Forty percent planned their first week of meals. Twenty percent generated shopping lists. But then the critical metric emerged: only 8% of users continued planning meals consistently after 2 weeks. By week four, fewer than three percent remained active.
A working beta reveals behavior at scale in real conditions. You can track not just whether people use your product, but how usage patterns evolve. Which features drive retention? Where do users drop off? What behaviors persist and which disappear when the novelty wears off?
The challenge of starting at this level is the required investment. Marcus spent six months and $50,000 building his beta before realizing his core behavioral assumption was off. If he had run a concierge service first, he could have learned the same lesson in eight weeks for the cost of his time. The beta could have come later, designed around behaviors he had already validated rather than those he had only assumed.
The Strategic Decision: Where to Start
Understanding these five levels doesn’t mean always starting at the bottom or always jumping to the top. The right entry point depends on what you need to learn and the level of behavioral risk your venture carries.
If you’re testing basic interest in a problem space, start with a landing page. It answers: Do enough people care about this problem to warrant further investigation? Marcus’s 487 sign-ups told him meal planning frustration was real and widespread. That signal justified further exploration.
If you’re testing whether a specific interface or feature approach resonates, mockups or clickable prototypes help. They answer: Does this particular solution direction feel right to customers? Do they understand how it would work? Can they imagine using it? Marcus’s mockup feedback indicated that the interface made sense and that certain features seemed especially valuable. That information shaped his initial feature set.
But if you’re testing whether customers will actually change their behavior—and every venture requires some behavior change—it’s essential to observe real behavior before building at scale. Nothing else will give you the answers you need. No amount of enthusiasm in interviews, no number of clicked buttons in prototypes, and no stack of landing page sign-ups can substitute for watching customers attempt the behavior change your venture depends on.
This is where the strategic decision becomes critical. Marcus faced a choice: spend two months running a concierge service to validate meal planning behavior, or spend six months building an app based on mockup feedback. The concierge path felt slower and less exciting, while app development felt like progress. In hindsight, the slower path would have led to better learning.
Where Marcus Went Wrong
Marcus’s misstep wasn’t building a landing page or creating mockups—those tools served their purpose. The real issue was treating interest signals as behavioral validation. He measured sign-ups rather than behavior change, feature preferences rather than sustained action, and stated intentions rather than demonstrated capability.
When his working beta launched, and users left after two weeks, Marcus first blamed the product. Maybe the interface wasn’t intuitive enough. Perhaps he needed better notifications. He considered adding gamification or social sharing features. These were all product solutions to what he believed was a product problem.
But the real challenge ran deeper. The behavior Marcus needed—planning meals days in advance and following those plans—conflicted with how his target customers actually made food decisions. They planned sporadically when they had time and energy, then defaulted to familiar, easy options when stressed or tired. The friction wasn’t in the app; it was in the behavior itself.
A concierge approach could have revealed this within weeks. Marcus would have observed 20 customers attempt to maintain meal-planning behavior with his manual support. When most of them abandoned it by week three, he would have learned that the core behavior was harder to sustain than he had assumed. That lesson could have reshaped his entire approach.
Instead of building an app that required consistent planning, he might have designed a system that removed the need for planning altogether. Pre-selected meal combinations, default shopping lists, and automatic reordering based on past choices—these solutions address the real behavioral barrier: decision fatigue when under pressure.
The difference between Marcus’s first app and this alternative approach lies in the validation sequence. Build-then-test often leads to feature-rich products that go unused. Test-then-build leads to simpler products that actually change behavior.
The Metrics That Actually Matter
Even when founders reach the higher levels of the validation progression, it’s easy to measure the wrong things. We might track feature usage instead of behavior change, count daily active users instead of outcome achievement, or celebrate vanity metrics while missing the behavioral indicators that truly predict success.
Marcus eventually built his working beta and measured everything: session length, features used, screen views, and return visits. His analytics dashboard looked impressive. But it didn’t show the one metric that mattered most: had meal planning behavior actually changed?
Behavioral metrics exist in a hierarchy that mirrors the validation progression. Understanding this hierarchy helps you track what matters at each stage.
Leading indicators sit at the bottom. These are early signals that reflect initial interest or intent—the same signals that landing pages and mockups reveal. Time to value, clicks, sign-ups, content views, funnel entry, and onboarding completion. Marcus tracked these closely. The numbers climbed steadily as he improved the onboarding flow and added features suggested by mockup testers.
These metrics are useful for optimizing user acquisition and the initial experience, but they tell us little about sustained behavior change. A customer who completes onboarding enthusiastically might never use the product again. High click-through rates on your landing page rarely correlate with behavioral persistence six weeks later.
In the middle of the hierarchy are behavioral indicators. These capture ongoing product interaction and usage depth—the actual behaviors users perform with your product. Feature usage frequency, repeat actions, session patterns, progress tracking, streak maintenance, and behavioral consistency all fit here. Marcus saw these numbers too, though they were less impressive than his leading indicators. Many users opened the app daily for a week, logged several meals, generated shopping lists, and then usage dropped off sharply.
Behavioral indicators reveal habit formation patterns. They show you whether the critical behaviors your product requires are actually happening and persisting over time. For Marcus’s meal-planning app, the critical behaviors were planning meals at least 3 days in advance, generating shopping lists, following through on the shopping, and preparing planned meals rather than defaulting to alternatives.
Tracking these specific behaviors would have shown Marcus exactly where the process broke down. Users plan meals on Sunday. They generated shopping lists. But many never made it to the grocery store on Monday. Others shopped but didn’t prepare the planned meals when exhaustion hit on Tuesday evening. The behavioral chain fractured at predictable points that the app couldn’t address with better features.
At the top of the hierarchy sit outcome indicators. These measures of customer success align with the outcomes your venture promises. The percentage of meals meeting predefined nutritional criteria, reductions in food waste, changes in grocery spending, health improvements, stress reduction around meal decisions, milestone achievement—whatever outcomes drove customers to seek a meal-planning solution in the first place.
Marcus never measured these. He didn’t know how many customers were actually eating healthier, reducing food waste, or feeling less stressed about meal decisions. He had plenty of data about app usage, but little insight into the outcomes that mattered. When users left his app, he couldn’t tell whether they left because the app didn’t work or because the behavior change was simply too hard to sustain.
The hard truth that took Marcus months to accept is this: if you can’t measure behavior change, you don’t have an MVP. You have a feature demo.
Making Strategic Choices About Validation
Six months after our first conversation, Marcus came back. This time, he wasn’t holding a laptop with sign-up numbers. He was carrying a notebook filled with observations from running a concierge service.
He’d manually created meal plans for thirty customers over eight weeks. What he discovered surprised him. The planning behavior he’d designed his app around wasn’t the issue. His customers could plan meals just fine when they had the mental energy. What they couldn’t do was maintain that planning behavior consistently week after week, especially when work stress, family demands, or unexpected events disrupted their routines.
More importantly, he discovered that successful meal planning wasn’t what his customers actually needed. The real behavior change they needed wasn’t better planning but better execution under cognitive load. When decision fatigue hit around 6 PM, all the planning in the world didn’t help if they still had to decide what to cook from their planned options.
Marcus’s new approach emerged directly from observing actual behavior in his concierge service. Instead of detailed weekly plans that require daily cooking decisions, he created systems that eliminate them. Five core meal combinations customers chose once. Automatic weekly shopping lists with those ingredients. Default delivery schedules. Minimal variation to reduce cognitive load.
The customers who succeeded in his concierge service weren’t the ones who engaged most enthusiastically with planning features. They automated their decisions and removed friction from execution. That behavioral insight shaped every aspect of his revised product.
Your Next Move
Most founders reading this are somewhere along the validation progression right now. Maybe you’re sitting on landing page data, convincing yourself you’re ready to build. You may have created mockups and heard enthusiastic feedback. You may have even launched a beta and are watching usage numbers that look promising, but don’t translate into lasting behavior change.
Before you proceed, ask yourself Marcus’s question: how many of your potential customers have actually changed their behavior?
Not “how many said they would.” Not “how many clicked through your prototype.” Not “how many engaged with your beta for a week.” How many have maintained the behavior change your venture requires for long enough to produce the outcomes you’ve promised?
If you don’t know the answer, you’re not ready for the next stage. You’re still measuring interest or intent, not action. And the gap between those three things is the difference between building something people want and building something people actually use.
The validation progression exists to help us avoid the mistakes Marcus made. Start with quick tests to gauge interest. Move to prototypes to understand expected behaviors. But before building at scale, find a way to observe actual behavior under real-world conditions. Whether through a concierge service, a manual MVP, or a limited beta that tracks behavioral outcomes instead of just feature engagement, make sure you’re measuring what matters.
Because in the end, 487 enthusiastic sign-ups mean nothing if zero customers change their behavior.
Keep reading with a 7-day free trial
Subscribe to Innovate & Thrive to keep reading this post and get 7 days of free access to the full post archives.