Market and customer research that helps you decide

Useful research helps someone make a decision. It may show why buyers leave, whether a new market deserves a test or which part of a service people misunderstand. A long report is not the goal. The goal is a clearer choice, with evidence strong enough for the risk involved.

This guide explains how to turn a business question into a research plan, collect information responsibly and report what it does and does not show. Examples are planning exercises, not Lucid Growth Media client findings. The method should fit the decision; no interview count or survey size works for every project.

Write the decision before the research questions

Start with a choice and a deadline. “Should we test this service with small retailers next quarter?” is more useful than “Understand the market.” Identify who will decide, which options are open and what evidence could change the answer.

Separate the decision from the questions needed to support it. You may need to know how retailers solve the problem today, what a failed solution costs and who approves spending. Each answer should have a clear use. If nobody can explain how a question could affect the decision, reconsider whether it belongs in the study.

Work through a decision the study can change

Consider an illustrative software business deciding whether to build a booking tool for small training providers. The team thinks providers need online payments, automated reminders and a customer portal. It has heard these ideas in informal conversations but has not established which problem matters most. The decision is whether to fund a limited prototype, not whether to commit to a full product immediately.

That distinction narrows the research. The team needs to understand how providers currently accept bookings, where work is repeated, what happens when a participant cancels and who approves a new tool. It does not yet need a national estimate of every possible buyer. A market estimate may become useful later, but it would not replace understanding the work the product is supposed to support.

Write the options before collecting evidence. The business could build a small prototype, adapt an existing tool, change the offer or stop. Then describe the evidence that would make each option sensible. If the main difficulty comes from unclear cancellation rules, new software may not be the first answer. If providers repeatedly copy bookings between tools, a smaller integration may be worth exploring.

These are planning rules, not findings. The team should be willing to revise them if the research reveals an important issue it had not considered. Keep a note of the change and why it was made. Otherwise, it becomes too easy to redefine success after seeing the answers and claim that the original idea was supported all along.

The final research question might be: “Which booking task causes enough repeated work for these providers to consider changing their current process?” That question is easier to investigate than “Would people like our platform?” It invites accounts of actual work, including reasons not to change. It also gives the product team a clear use for the findings when deciding what, if anything, to prototype.

Separate facts from assumptions

List what the team already knows, the source and its date. A signed order is different from a salesperson's impression. A customer's account of a recent purchase is different from a prediction about what they might buy next year.

Keep assumptions visible. For example, “buyers need faster reporting” may really mean that three existing clients requested it. That can justify further investigation, but it does not yet describe the whole market. Recording the gap prevents an early guess from becoming a fact through repetition.

Choose a method for the uncertainty

You may need more than one method. Interviews can reveal language for a survey. A usability test can explain a form drop-off. Do not add methods just to make the project look larger. AAPOR's guidance emphasises clear goals and careful survey design, including how people are selected and contacted. [1]

Compare a focused study with a larger one

For the booking-tool example, a focused first study might combine a review of existing products with interviews about recent booking work. The public-source review shows what tools say they offer. Interviews explore how providers actually work and where existing options fall short. Neither method alone establishes how many providers would buy a new product at a given price.

A larger study might later add a survey or a prototype test. The survey could examine patterns using a suitable sample and clear questions. The prototype test could observe whether people can complete the proposed task. They answer different questions, so do not describe one as a more prestigious version of the other. A larger questionnaire is not a replacement for watching a confusing process.

Compare plans by the decisions they support. One proposal may deliver a broad industry report, while another investigates a narrow purchasing problem in detail. Either can be useful. The buyer should ask which choice the deliverables will help make and what will still be unknown. A list of research methods without that connection makes the quotation difficult to assess.

Set a stopping point for the first stage. For example, the team might pause before fieldwork if it cannot recruit people with recent booking responsibility. It might stop product planning if the available evidence concerns a different type of provider from the intended buyer. A pause is not a failure of research; it can protect the budget from a study that cannot answer the required question.

Also decide what deserves follow-up. If interviews reveal a repeated difficulty with refunds, a second stage could examine that process more closely. If feedback differs sharply between individual tutors and training companies, the team may need separate product assumptions. Do not average these groups into an imaginary typical customer simply to produce one convenient conclusion.

Keep the method explanation in everyday language. State who will take part, what they will do, what information will be collected and how it will be analysed. Explain exclusions such as markets, languages or buyer groups outside the study. A clear explanation lets the buyer judge a smaller plan fairly without mistaking it for a complete view of the market.

Define whose experience matters

Specify the people or organisations the decision concerns. For a business service, industry alone may be too broad. Buying role, company size, current process and recent need may matter more. Include people who rejected or stopped using the service when their experience is relevant.

Distinguish the intended population from the people you can reach. If all respondents come from an existing email list, the study may tell you more about current contacts than new buyers. State that limit rather than labelling the results “the market”. Do not hide hard-to-reach groups simply because recruiting them takes longer.

Build a recruitment matrix without pretending it is a census

A recruitment matrix helps the team avoid hearing only from the easiest people to reach. For the illustrative booking study, useful differences may include provider size, booking volume, current tools and responsibility for handling changes. Those factors should come from the decision being studied. Collecting age, income or other personal details without a clear purpose adds privacy risk and may not improve the research.

Define recent, relevant experience in the screening questions. Ask whether the person handled bookings within the study's chosen period, what parts they handled and which tools they used. Avoid revealing the preferred answer. “Do you waste time on manual bookings?” tells applicants which story may get them accepted. “How are bookings recorded today?” gives more room for an honest description.

This matrix is a coverage plan for learning about different experiences. It is not proof of a representative sample. If the team recruits through its own contacts, say so. If a group proves difficult to recruit, record the gap and decide whether the study can still support the decision. Do not quietly replace missing participants with people who lack the relevant experience.

Use incentives to compensate time and effort, with terms explained before participation. Do not make payment depend on praise for the idea. Keep recruitment administration separate from analysis where practical so researchers are not encouraged to value one answer because the participant was difficult to find.

At the end of recruitment, compare who took part with the intended groups. This check can reveal a skew before the report is written. If nearly everyone uses the same software or comes from one network, that context belongs beside the findings. It does not make their experiences worthless; it changes how widely those experiences can be applied.

Build a source record for desk research

For each important number or claim, record the original source, publication date, geography, definition and method. Follow a widely repeated statistic back to its origin. A report quoting another report is not independent confirmation.

Check whether two estimates measure the same thing. One may count total spending while another counts supplier revenue. One may include consumer software while your offer serves businesses only. Use ranges where definitions remain uncertain. Explain any calculation so another person can repeat it, and keep assumptions separate from source data.

Compare competitors on evidence

Review what a buyer can actually find: service scope, public prices, contract limits, onboarding, support and evidence of results. Date the review because offers change. Mark an item “not publicly stated” rather than assuming it is absent.

Do not turn competitor marketing claims into verified performance facts. If a company says its service is faster, record that as its claim unless you have a fair test. Avoid false identities, unauthorised access or collecting private information. Public availability does not remove platform terms or privacy duties.

Read search trends within their limits

Google Trends can help compare search interest over time, across locations or between terms. Its data is sampled and normalised. A score is relative interest within the selected comparison, not an absolute count of buyers or proof of market size. Low search volume also limits what can be shown. [4]

Record the terms, topic selection, country, date range and search type used. Repeat a comparison carefully when settings change. A rise after a news story may reflect curiosity rather than purchase intent. Use trends to form a question, then check it against customer behaviour, sales or other suitable evidence.

Do not treat social posts as a population survey

Public posts can reveal vocabulary, complaints and emerging topics. They over-represent people who use that platform and choose to speak publicly. Ranking systems, bots and repeated posts can further shape what you see.

Describe the collection method and what was excluded. Check platform rules before collecting, storing or sharing content. X's user-research guidance is one platform-specific reference, not permission to conduct any research or scrape any data. Protect people's identities when quoting or reporting material, and consider whether a quote can be searched back to its author. [8]

Recruit transparently and collect only what you need

Tell participants who is conducting the study, its purpose, expected time, incentive and how their information will be used. Explain whether you will record the session, who can access it and how long it will be kept. Obtain the permissions required for the actual method and audience.

Keep participation separate from sales or marketing permission. Do not pressure people to take part or to give positive answers. The ICC/ESOMAR Code sets professional standards for research, data use and participant protection. Apply relevant law as well; following a code is not a substitute for a legal assessment. [3]

Ask about real experiences in interviews

Begin with a recent event: “Tell me about the last time you chose a supplier.” Ask what happened, who was involved, what options they considered and where they hesitated. Follow the participant's account before introducing your own explanation.

Avoid selling during the interview. “Would you like a faster, simpler service?” invites agreement but gives little evidence. Ask what the current process costs in time or effort and what the person has already tried. GOV.UK's interview guidance supports open questions, careful listening and recording evidence from the session. [5]

Use an interview guide so the team covers the same core topics, while allowing useful follow-up. Keep notes that distinguish the participant's words from the researcher's interpretation. Do not turn a paraphrase into a direct quotation later.

Use a conversation guide that follows the work

An interview guide should give the researcher a route through the topic without becoming a script that must be read word for word. Begin with context, move to a recent event, explore the steps and exceptions, then ask what the person tried to improve. Leave product reactions until after the account of current work when possible. Otherwise, the proposed solution may shape the whole conversation.

For the booking example, a useful opening is: “Think about the last course you helped fill. How did the first booking arrive?” Follow the sequence. Where was it recorded? Who checked availability? What did the participant receive? What changed when someone cancelled? Ask for a demonstration using safe sample material if it is useful and permitted, rather than requesting private customer records.

Listen for the difference between a preference and a constraint. “I like email” may mean that email works well, that the person has not tried another option or that the organization requires a written record. Follow-up should explore the reason without arguing. A researcher who immediately offers a feature can miss the actual requirement.

When answers conflict, ask for another concrete example. Someone may say cancellations are rare and then describe a recent event with many changes. Both can be true in different circumstances. The useful finding may concern seasonal peaks or certain course types, rather than an overall contradiction. Keep the context instead of forcing a yes-or-no conclusion.

Close by asking whether anything important was missed. Confirm any agreed follow-up and remind the participant how the material will be used. Do not turn the closing minutes into an unannounced sales pitch. If the business later wants commercial contact, handle that through a separate, appropriate permission process rather than treating research participation as a sales lead.

Pilot the questionnaire before sending it widely

Ask one thing at a time in familiar language. Avoid leading wording, unexplained terms and answer options that overlap. Give a suitable “not applicable” or “do not know” option when people may not have the experience to answer.

Test the survey with a few people like the intended respondents. Ask how they understood each question. Check the full route on mobile, including skipped questions and completion time. Revise problems before launch. A larger sample does not repair a question that respondents interpret in different ways.

Repair questions before they create misleading numbers

Suppose a draft survey asks, “How satisfied are you with the speed and reliability of your booking system?” This asks two things at once. A respondent may find the system fast but unreliable. A single rating cannot show which issue they meant. Separate the topics when both matter, or choose the one that connects to the decision.

Another draft asks, “Would you use an affordable tool that saves time and eliminates errors?” Nearly every part encourages agreement. “Affordable” has no defined price, “saves time” is untested and “eliminates errors” is an absolute promise. A better study first asks about current work and actual spending, then presents a clearly described option with realistic limits for a specific purpose.

Answer options need equal care. A frequency question should define the period and use ranges that do not overlap. Categories such as “one to five” and “five to ten” leave a person with five unsure where to answer. Include an appropriate route for people who did not handle the task. Do not force them to invent a frequency simply to move forward.

During the pilot, ask people to explain what they thought a question meant. This is different from asking whether the survey looked good. Someone may complete every item quickly while interpreting “booking” as a confirmed payment rather than an initial request. If that distinction matters, define it in plain language before the relevant questions.

Check the order too. Showing a long list of possible problems before asking about current difficulties can supply answers the respondent might not have mentioned. There may be a good reason to use a prompted list, but the report should describe what was asked. An unprompted answer and a selected option are different forms of evidence.

Keep a version record when the pilot leads to changes. If wording changes after the main survey begins, determine whether responses can still be compared. Do not quietly combine materially different questions under one chart label. AAPOR's guidance treats questionnaire design, testing, sampling and reporting as connected parts of survey quality. A polished dashboard cannot repair an unclear question. [1]

The final questionnaire should earn the participant's time. Remove questions that nobody will use, but retain the context needed to interpret answers responsibly. A shorter survey is not automatically better if it omits essential distinctions. The useful aim is a clear, answerable set of questions that supports the agreed decision.

Explain what the sample can support

The way people are selected affects the claims you can make. An open online poll is usually a self-selected sample. Its percentages describe its respondents; they should not be presented as a precise estimate of a whole population without a defensible method.

Report recruitment, field dates, sample size, exclusions, weighting and material limitations. AAPOR's transparency standards provide a useful basis for those disclosures. Do not attach a conventional margin of sampling error to a study that does not support it. Small subgroups also need caution even when the overall sample is larger. [2]

Keep denominators and missing answers visible

Percentages are easy to misunderstand when the base changes. Consider an illustrative survey with 100 completed responses. Only 60 respondents used a booking tool, and 24 of those reported a particular problem. The relevant description is 24 of the 60 tool users who answered that question. It would be misleading to describe the figure as a share of all providers in the market.

These numbers are invented for explanation. They are not research findings or a recommended sample size. The example shows why every chart needs a clear base: who was eligible, who answered and which records were excluded. Even correct arithmetic can support the wrong conclusion if the reader assumes a different population.

Separate missing answers from “none” or “not applicable”. A skipped question may reflect confusion, lack of time or a technical issue. It does not automatically mean the respondent had no problem. Review whether missing responses cluster around a particular question, device or group before treating them as a minor formatting issue.

Small subgroup comparisons also deserve restraint. If only a few respondents fall into a category, one answer can change its percentage substantially. Report counts alongside percentages where helpful, and avoid precise-looking conclusions that the data cannot support. The appropriate statistical treatment depends on the sampling design and analysis plan, not just the charting tool.

If weights are used, explain what they adjust and what they cannot repair. Weighting does not create observations from people who were never reached, and it does not fix a leading question. The report should make the method understandable enough for readers to judge its limits. AAPOR's transparency approach is useful because it asks researchers to disclose how the results were produced. [2]

Do not erase awkward categories to make a graph look cleaner. If many people selected “other”, inspect what that may mean. Perhaps the answer options missed a common process. If many selected “do not know”, the question may concern a decision they do not control. Those patterns can be useful findings about the study or the business, rather than noise to remove.

Observe tasks in usability sessions

Give participants a realistic goal, such as finding a suitable plan or submitting a request. Ask them to show how they would do it. Watch where they hesitate, misread or take a different route. Do not explain the interface before they have had a chance to use it.

GOV.UK's moderated usability guidance explains how to plan tasks and observe use. Report what happened in the tested conditions. One participant's difficulty can reveal an issue worth fixing, but it does not tell you the percentage of all visitors affected. Retest important changes with suitable users. [6]

Check data quality before drawing conclusions

Define quality checks before inspecting results. Look for duplicates, incomplete records, impossible answers or signs that someone did not engage with the task. Keep an audit of exclusions and the reasons. Do not remove answers simply because they disagree with the preferred result.

For qualitative work, compare interpretations across researchers where practical. Look for both repeated patterns and meaningful exceptions. A strong report explains where users differ and why that may matter. It does not force every participant into one tidy story.

Turn notes into findings without losing the evidence

After interviews, create a simple evidence table. Give each participant a study identifier and separate their statement, the event described, the context and the researcher's interpretation. Keep identity details elsewhere with appropriate access controls. This lets the team compare experiences without circulating names and contact information through every working document.

For an illustrative note, a participant may say they copy booking details into a spreadsheet before sending an invoice. The observation is that this participant described two records in their process. A possible interpretation is that information is duplicated. A proposed response might be to connect the records. Those are three different statements. The interview does not by itself prove that an integration would save a particular amount of time.

Group similar observations under plain labels such as “re-entering details”, “checking payment” or “handling cancellations”. Define each label so another reviewer understands what belongs there. Avoid labels that assume the conclusion, such as “needs our automation product”. The analysis should leave room for evidence that a process works well or that the proposed product would introduce new work.

Look for exceptions before writing the summary. A provider may use the same tools without repeated entry because they follow a different process. That exception can explain a cheaper solution or reveal a condition the new product must support. It should not disappear because it makes the story less tidy.

Where more than one researcher is involved, compare a small set of notes and discuss differences in interpretation. Resolve unclear labels and record important disagreements. Agreement is useful, but forced consensus can hide uncertainty. The report can say that evidence supports more than one explanation and recommend a specific follow-up to distinguish them.

Separate association from cause

Two things changing together does not prove that one caused the other. Sales may rise after a campaign because demand is seasonal, a competitor ran out of stock or pricing changed. Note plausible alternatives before recommending more spend.

A controlled experiment compares groups or conditions designed to isolate a change. Google's conversion-lift documentation describes one advertising approach, with its own eligibility and design requirements. It is not a promise that any small campaign can measure added sales precisely. Where a controlled test is not suitable, report the evidence as observational and explain the limit. [7]

Use AI as an assistant, not as a participant

AI can help organise notes, suggest codes or draft a summary from approved material. A researcher must check quotations, counts and interpretations against the original evidence. Do not upload participant information to a tool unless the processing is authorised and its handling has been reviewed.

Generated personas and simulated interviews are ideas, not recruited people. They must not be reported as customer findings or used to inflate a sample. Label any synthetic material clearly. Keep a record of the tool's role so a reviewer can distinguish collected evidence from generated suggestions.

Turn findings into a decision record

For each main finding, state the evidence, uncertainty and business implication. Link a recommendation to the finding it depends on. Name the owner of the next action and the condition that would make the team reconsider.

For example, interviews may show that buyers cannot compare support scope. The next step could be a clearer comparison page, followed by a usability check. That is more defensible than claiming the interviews prove a market-wide demand for a new product. Keep negative and inconclusive results visible; they can prevent expensive mistakes.

Make the final meeting a decision meeting

A useful presentation begins with the decision, then the evidence needed to judge it. For the illustrative booking project, the first page could explain whether the study supports a prototype, a narrower idea, an existing-tool review or a pause. It should not open with a long catalogue of every interview question before the reader knows what the work means.

For each recommendation, show the finding it relies on and the main uncertainty. If the study suggests that copying payment details is a repeated task, explain who reported it and under what conditions. Recommend a prototype or process test that addresses that task. Do not jump from the finding to an unsupported market-size or revenue claim.

Invite the decision maker to question the interpretation, but keep evidence separate from preference. A senior person's enthusiasm does not turn weak evidence into strong evidence. Equally, a study can reveal a useful opportunity even if it differs from the original idea. Record the actual business decision and any reasons that sit outside the research, such as budget or timing.

Agree what happens to unanswered questions. Some can wait until the prototype exists. Others may need resolution before any build, such as whether the necessary system access is available. Prioritizing those questions avoids buying another broad study when a narrow technical or operational check would be enough.

At handover, include a plain explanation of the method and a source record alongside the summary. Provide only the participant material covered by the agreed permissions and data plan. The client should be able to inspect how conclusions were reached without receiving unnecessary personal information. A clear record also helps a later team understand why a decision was reasonable at the time, even if new evidence eventually changes it.

Plan data handling and handover at the start

Agree who can access recordings, notes and contact details. Separate participant identities from analysis where practical. Set retention and deletion rules, including backups and client handover. A useful report rarely needs to include a raw contact list.

At handover, provide the decision summary, method, source record, findings, limits and agreed supporting material. Explain what was not researched. The client should be able to judge the conclusions without needing every raw file or trusting an unexplained score.

Check what a research quotation includes

Compare research quotations using the same decision and deliverables. One price may include recruitment, incentives, transcription, analysis and a results meeting. Another may cover only the sessions. Ask for a clear breakdown of the work and the costs that depend on outside suppliers. A lower headline fee may describe a smaller purchase rather than a more efficient method.

Confirm what the client must provide. The researcher may need an approved participant invitation, access to a safe prototype, product information or a decision maker for planning. Delays in those inputs can change the schedule. The proposal should explain how recruitment problems, missed sessions and changes to the study are handled, without guaranteeing that every intended participant can be reached.

• Identify the research question and the decision it supports.
• Name the intended participants, sources and recruitment route.
• List fieldwork, analysis, review and reporting tasks separately.
• Confirm incentives, supplier charges and any translation or transcription costs.
• Specify the permitted data handover, retention and deletion arrangements.
• Agree which changes require a revised cost or schedule.

Ask to see the proposed report structure before commissioning the work. It should make room for methods, limits and inconclusive findings, not only recommendations. This helps prevent a later expectation that the researcher must produce a positive answer to justify the project fee.

Also agree how questions after handover will be handled. A short clarification about a chart is different from a new analysis or another round of interviews. Naming the included review time makes the deliverable easier to use and the working relationship easier to manage. The aim is a clear purchase whose evidence can be assessed, not a promise that research will remove every uncertainty from the business decision.

A practical research plan

• Name the decision, owner and deadline.
• List the assumptions that could change the decision.
• Choose the people, sources and methods that can test them.
• Set recruitment, consent, data access and retention rules.
• Pilot the questions or tasks and fix problems.
• Agree quality checks and reporting limits in advance.
• Turn the findings into actions with owners and review dates.

To scope research with Lucid Growth Media, share the decision you need to make, who it affects, the deadline and what evidence you already have. Avoid sending participant records through the enquiry form. The first step is agreeing a useful question and a responsible way to answer it.