Why Asking Friends and Family Produces Nothing Usable
Every founder starts by describing the idea to people they know and hearing that it sounds great. That feedback is worthless, and it is worth understanding exactly why, because the same failure modes recur in badly run formal research.
People close to you are answering a social question, not a product question. Saying "that will not work" to someone excited about their idea is unpleasant, so they do not. Beyond politeness, three biases compound: they are not the target user and are guessing at someone else's needs; they respond to how you framed the problem rather than the problem itself; and they predict their own future behavior badly. Stated purchase intent overstates actual purchase by a large factor across every category.
The fix is not more people, it is different questions asked of the right people. Research should be about what someone did last week, not what they think they would do next year. "Tell me about the last time you had to do this" produces information. "Would you buy this?" produces noise.
Define Who You Are Studying Before You Start
Write the user down in one specific sentence before recruiting anyone: not "homeowners" but "homeowners who maintain their own irrigation system and have replaced at least one valve themselves." That specificity makes recruiting possible, and it forces you to admit whether the group is large enough to be a market.
Distinguish three roles that are frequently different people: the user who operates the product, the buyer who pays, and the influencer who specifies or recommends it. In consumer products these often collapse into one person; in B2B they rarely do, and designing only for the user produces a product nobody buys. That mapping also drives a competitor analysis, because your real competition is whatever the buyer spends that budget on today.
Three Methods a Founder Can Run Without a Research Budget
Contextual observation. Watch people do the task in the place they normally do it, and say as little as possible. This is the highest-yield method by a wide margin, because the gap between how people describe a task and how they perform it is enormous. You are looking for workarounds: the tool used for the wrong purpose, the improvised jig, the step done twice, the thing set down and picked up again. Users almost never mention these because they have stopped noticing them. Six to eight observation sessions typically surface most of what matters.
Structured interviews about past behavior. Thirty to forty-five minutes, one person at a time, anchored in specific past events. Ask what they did last time, what they used, what it cost in time or money, and what would have to be true for them to change. Never describe your solution until the end, and when you do, watch whether they ask about price and availability, a far stronger signal than enthusiasm. Ten to fifteen interviews in a well-defined segment usually reach saturation. The techniques for getting past politeness are in getting honest feedback on a product idea.
Analysis of existing artifacts. Reviews of competing products, forum threads, warranty complaints, and support requests are user research someone else already paid for. Read the two-star and three-star reviews rather than the extremes: one-star and five-star reviews are usually about shipping or fanaticism, while the middle is where people describe functional shortfalls in detail. It is free, fast, covers a sample no founder could interview, and pairs well with the tactics in market research on no budget.
Sample sizes for qualitative work are smaller than people expect. You are looking for patterns and mechanisms, not statistics. If you need a number, such as what fraction of users would pay a given price, that is a separate quantitative exercise like the demand test in validating a product idea, and it needs hundreds of responses, not twelve.
Turning Findings Into Design Decisions
Research that ends in a document nobody uses was a waste of time. The conversion has to be explicit.
Start by separating three types of finding. Observations are what you saw: "four of six users held the unit against their chest to free a hand." Insights are the interpretation: "the task requires one hand for the workpiece, so the product must be operable one-handed or stowable." Requirements are the testable statement that goes into the specification: "all primary controls operable with one hand while the product is held in the same hand; unit mass under 1.5 lb (680 g)."
Only the third form belongs in the design brief. Observations without conversion get forgotten and insights without numbers get argued about. Give every requirement a source, so that six months later when someone proposes adding 4 oz, there is a documented reason it matters.
Physical dimensions deserve special care. If a finding concerns grip, reach, or force, translate it into percentile-based dimensions using real population data rather than measuring your own hand, which is the discipline of anthropometry in product design. Designing to the 50th percentile excludes half your users at one end or the other; the usual target is accommodating the 5th to 95th percentile of the relevant population.
Prioritize ruthlessly. Research produces more findings than any first product can address. Sort them into requirements that make the product work, requirements that make it better than alternatives, and requirements that are nice to have, and be honest that the third group is a later version. The finished set becomes the input to a product requirements document and to the design brief handed to whoever does the industrial design.
Research Does Not Stop When Design Starts
Treating research as a phase that closes is the most common structural mistake. The value compounds when it continues, because each design decision creates new questions that the original research could not have anticipated.
Once there is geometry, test it. Foam blocks and printed shells answer grip and reach questions in an afternoon for almost nothing. Once there is a working mechanism, put it in front of users and watch them fail at things you assumed were obvious, using the session structure in user testing with a prototype. Test the packaging and the setup experience too, since first-use failure drives returns more often than product failure does.
A few rules keep these sessions honest. Do not explain the product first; hand it over and watch. Do not defend a design when a user struggles; write down what happened. Test with people who have never seen it, since second exposure teaches nothing about first impressions. And run at least one session outside your ideal profile, where accessibility and edge-case problems surface. Five to fifteen research hours per major design decision is a small fraction of what a tooling change costs after the fact.
Get the Research Done Before the Geometry Is Fixed
Projects House runs user research as the front end of industrial design projects: recruiting and defining the segment, contextual observation and interviews, translating findings into a measurable requirements set, and carrying that set through concept and prototype testing. Send your product concept and target user through our contact form.