A Specific Customer Can Still Be Imaginary
You can describe your customer in detail. Role, situation, the exact pressure they are under, the moment they finally act. It sounds specific because it is specific. There is one question it does not answer.
Can you name a real person who fits it, and did you learn any of this from them?
Specificity and reality are different things, and founders collapse them constantly. A detailed customer feels like a validated one, so a description that is precise gets treated as a description that is true. It is possible to build a customer who is sharp in every particular and exists nowhere, assembled entirely from your own inference about who ought to have this problem. That customer passes every test for specificity and fails the only test that matters.
A precise description of someone you invented is still an invention.
TL;DR: The Opposite of a Vague Customer Is Not a Specific One. It Is an Observed One.
Getting specific is necessary and it is not the finish line. A specific customer built from inference is still imagined, and it produces a product aimed at a person who does not exist. The work is to trace every part of the description to something you actually saw or heard, and to name one real person you could contact today. Here is the move, in order:
Audit each component for its source: for role, context, constraint, and moment, mark whether it came from observation or from inference
Flag the inferences, because an inferred component is a guess wearing the clothes of a fact
Name one real person who fits the description and whom you could contact today, not a persona or a type
Check what you learned from them, as opposed to what you assumed on their behalf
Replace inferences with conversations until the description is grounded rather than guessed
Four signals your customer is specific but imagined:
You can describe them in vivid detail and cannot name one real person who matches
Every part of the description traces back to your own reasoning, not to something a customer said
You have never been surprised by a customer, because you have never been corrected by one
The description has not changed since the day you first wrote it
If any of those describe you, this article shows you how to tell a grounded customer from a well-drawn one.
If You Found This Article by Searching for Something Else
Most founders who need this are not searching for "imagined customer." They are searching for something more immediate.
How to define my target customer.
Why isn't my product resonating.
How to validate my customer.
Why do people say my product is nice but do not buy.
How to know if my customer is real.
All of those point at the same underlying question. Is your customer someone you observed, or someone you constructed? This article shows you how to tell the difference before the product is built around the wrong one.
Specific Is Not the Same as Real
Getting specific is the standard advice, and it is correct as far as it goes. A customer described as "small business owners" cannot be found, reached, or learned from. Narrowing that to a role, a context, a constraint, and a triggering moment is real progress, and it is where most customer-definition work aims.
It also has a blind spot. Specificity can be manufactured. You can invent a role, invent the context around it, invent the constraint, and invent the moment, and the result is a description that reads as sharp because every field is filled in with a confident answer. Nothing about it being detailed makes it true. The precision came from your imagination, and imagination is happy to be precise.
This is the trap the standard advice walks founders into. Told to get specific, they get specific, and they mistake the specificity for validation. A vague customer at least announces itself as unfinished. An imagined customer hides, because it looks exactly like the finished product the advice asked for.
The question that separates them is not how detailed the description is. It is where each detail came from.
The Editor Who Did Not Exist
Take a founder building a tool for freelance video editors. Ask him who the customer is, and the answer is impressively specific.
A senior editor, mid-thirties, working freelance for boutique creative agencies, juggling four or five clients at once, losing hours every week to disorganized revision requests scattered across email and Slack, and ready to look for a tool the moment a client disputes a final round of changes and holds up payment.
That is specific. It has a role, a context, a constraint, and a moment. By every standard test, it is a well-defined customer. And when you ask him where each piece came from, the description quietly falls apart.
The role, freelance video editor, he knows. He was one for six years. Observed.
The context, boutique creative agencies, is a guess. He worked mostly with in-house teams, and he assumes agencies are similar. Inferred.
The constraint, revision chaos across email and Slack, is drawn from his own memory of a workflow he used years ago, before the tools most editors use now existed. Inferred, and possibly out of date.
The moment, a payment dispute over a final round, is something he imagines would drive action. He has never watched it happen to anyone. Invented.
One component observed. Three assembled from inference and memory. The customer is specific and roughly three-quarters imagined, and he would have kept building against it for months, because it never occurred to him that a description this detailed could be this ungrounded.
The Evidence Audit
The fix is not more detail. Adding a sixth trait to an invented customer produces a more elaborate invention. The fix is to interrogate the source of each detail you already have.
Take the description apart and, for every component, ask one question: did this come from something I observed, or something I reasoned? A customer said it, or you did. You watched it happen, or you assumed it would. There is no shame in an inferred component early on. Every description starts mostly inferred. The failure is not having inferences. The failure is not knowing which parts are inferences, so that guesses and facts sit in the same sentence wearing the same confidence.
Mark them. The observed parts are your foundation. The inferred parts are your research agenda, the specific things to go confirm before you let them shape the product. In the editor's case, the audit turns a vague sense of "I know my customer" into a precise list: one thing known, three things to check. That list is more useful than the polished description was, because it points at exactly what to do next.
The audit also protects you from your own fluency. A founder who knows a domain can generate plausible detail endlessly, and plausibility is the problem. The more convincingly you can describe a customer from the inside, the easier it is to fill the whole picture with inference and never notice. Domain knowledge makes the imagined customer more vivid, not more real.
This inverts who is most at risk. The founder with no domain knowledge invents a shallow customer that is easy to doubt, so they go looking for real ones early. The founder with deep domain knowledge invents a convincing customer that is hard to doubt, so they build against it for months. Both are inventing. Expertise does not exempt you from the audit. It is the reason you need it most.
The One-Real-Person Test
There is a single test that collapses the whole question, and it is unforgiving.
Name one real person who matches your customer description and whom you could contact today.
Not a type. Not a composite. Not "someone like." A specific human with a name, reachable this week. Then say what you have actually heard from them about the problem, in their words, not yours.
If you can do this, your customer has at least one real anchor, and the description can be checked against a person instead of against your own reasoning. If you cannot, the description is imagined, however specific it reads, and the specificity was hiding that fact rather than fixing it.
The editor founder, run through this test, stalls for a moment and then names a former colleague. Good. He calls her. Twenty minutes in, two of his three inferences are wrong. She does not work with agencies, she works with a single long-term client. Her revision chaos is not email and Slack, it is a tool she already pays for and half-hates. The payment-dispute moment has never happened to her, but a different one has: the client asked her to onboard a second editor and she had no way to hand off project state. One conversation, and the invented customer starts turning into an observed one.
That is the exercise working. It does not confirm the description. It corrects it, and correction is the thing an imagined customer can never give you.
One extension for anyone selling into a company rather than to a single person. In enterprise sales the customer is not one role, it is a buying committee: the user who feels the problem, the economic buyer who approves the spend, the security or procurement gatekeeper who can veto. Run the one-real-person test on each of them separately. Founders who come from the user's world routinely have a vividly observed user and a completely imaginary economic buyer, invented from an assumption about who signs and why. An observed user does not vouch for an observed buyer. If you cannot name a real person in each seat and say what you heard from them, the parts of the committee you have not observed are the parts that will surprise you at the close.
One Person Anchors. Repetition Makes a Segment.
One real person is where grounding starts. It is not where it ends, and it would be a mistake to read the test as finished the moment you can name someone. One person proves the customer exists. It does not prove the customer repeats, and a startup needs the second thing.
There is a progression here worth naming, because most founders skip the middle of it. A persona is a description that matches no one in particular, assembled from reasoning. A customer is one real person you have observed. A segment is the same pattern showing up across several real people, consistently enough that you can predict it. Persona to customer is the jump from invention to observation, which is what this whole article has been about. Customer to segment is the jump from a single anchor to a repeating one, and it is the jump that turns a real person into a real market.
So one is the floor, not the goal. Name the person, then ask the harder question: does what you heard from them recur? The editor founder's real colleague handed him a genuine problem, the handoff when a client asks for a second editor. The next question is not whether that problem is real. He watched it be real. The question is whether it is one editor's situation or a pattern across ten of them. If five more editors describe the same handoff moment in their own words, he has a segment. If only she does, he has one true story and no market yet, which is still worth knowing, because it tells him exactly what to go check next.
This is the same repetition that runs under the rest of Market Clarity. A trigger is a moment that recurs across customers. Proximity is access that recurs through a stable path. A segment is a customer who recurs. The grounding you do here, one real person at a time, is the raw material the repetition is measured on. You cannot find a pattern across people you never observed.
Why the Imagined Customer Survives So Long
An imagined customer is comfortable in a way a real one is not, and the comfort is the reason founders keep it.
A real customer disagrees with you. They fail to feel the constraint you were sure they felt, they act on a moment you did not predict, they want something other than what you built. An imagined customer does none of that. It agrees with the product, because you designed it to. It confirms the plan, because it came from the same head that made the plan. Building against it feels frictionless, and the frictionlessness is the warning sign. Real customers create friction. The absence of it usually means no real customer has entered the process yet.
The cost stays hidden until it is expensive. Every decision made against the imagined customer, the feature, the message, the pitch, compounds on the last one, and they all fit together perfectly because they were all built from the same fiction. The gap only becomes visible when the finished product meets the actual market and the actual market does not respond. By then the fiction is load-bearing.
An imagined customer is cheaper to keep today and far more expensive to keep than to correct. The correction is one conversation. The alternative is a product built for a person who was never there.
The One Sentence That Tells You Where You Stand
A founder who has grounded the customer can complete this statement without a gap:
My target customer is [role, context, constraint, moment], most of which I have confirmed by observing or hearing it directly.
The one real person who matches is [name], I have spoken to them about the problem, and what they told me [changed / confirmed] the description in this specific way: [what you learned].
A founder with an imagined customer can complete the first line in vivid detail and stalls at the name, or names someone they have never actually asked. Wherever the sentence breaks is the exact place the customer is still living in your head instead of the world.
If you can name the person and point to what they taught you, your customer has a foothold in reality and you can build on it. If the description is rich and the person does not exist, that is not a reason to describe them better. It is the signal to go find one, have the conversation, and let the real person overwrite the invented one. The description you come back with will be less tidy and far more true. Either outcome moves you forward.
Grounding and Your Market Clarity
In the Startup Readiness Framework, Market Clarity distinguishes a customer you can describe from a customer you have observed, and treats the second as the only one that supports a decision. An imagined customer is among the most serious market flags, because it weakens all three market dimensions at once: the person is hard to find, the places they gather are unclear, and the evidence underneath is thin. A specific description hides that, which is exactly why it is dangerous.
Getting the definition sharp is upstream work, covered in defining your target customer. This piece is the layer beneath it: whether the sharp definition is grounded or guessed.
Market Clarity is one of the six pillars in the framework. The Startup Readiness Assessment gives you a full-system diagnostic across all six in under twenty minutes.
Take your Startup Readiness Score free today at startupready.ai →
Published
By Dr. Shaun P. Digan
Originally published on the Startup.Ready. Blog at https://startupready.ai/startup-readiness/validate-target-customer
Original Publication Date: August 3, 2026
Last Updated: August 3, 2026
About the Author
Dr. Shaun P. Digan is the founder of Startup.Ready and the creator of the Startup Readiness Framework, a research-based system for evaluating and validating early-stage startups before launch and early growth. He holds a PhD in Entrepreneurship from the University of Louisville and has spent over 15 years teaching, advising, and consulting with founders on startup strategy, validation, and growth.
In his writing, including the Startup Readiness Blog and The Foundations of Innovation Essay Series, he focuses on how founders can make better decisions by improving clarity, alignment, and readiness before scaling.