Problem Discovery and Design Thinking

Introduction

Entrepreneurial ventures rarely fail because founders cannot generate ideas. They fail because the ideas address weak, misunderstood, or economically unsustainable problems. Problem discovery is therefore a central activity in entrepreneurship and startup incubation. It involves identifying situations that create meaningful difficulty for particular people or organizations, understanding the underlying causes, and determining whether a new solution could create and capture value.

Design thinking provides a structured but flexible approach to this work. It combines empathy, observation, interpretation, experimentation, and learning. Rather than beginning with a technology or product, the entrepreneur begins with people, their contexts, and the outcomes they are trying to achieve. The objective is not merely to make users satisfied with an existing concept; it is to discover an important problem and develop evidence-based responses to it.

In an incubation setting, design thinking should not be treated as a linear checklist. Teams may move repeatedly between understanding stakeholders, defining the problem, generating ideas, prototyping, and testing. The process is disciplined because it requires evidence and explicit assumptions, but it is also iterative because early understanding is inevitably incomplete.

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish between symptoms, problems, needs, and opportunities.
2. Identify and analyse stakeholders using systematic stakeholder-analysis methods.
3. Plan and conduct ethical observations and semi-structured interviews.
4. Construct and interpret journey maps and other insight tools.
5. Apply the major stages and principles of design thinking.
6. Formulate problem statements and testable opportunity hypotheses.
7. Generate and evaluate solutions using desirability, feasibility, viability, and impact criteria.
8. Recognize research bias, ethical risks, inclusion requirements, and limitations in problem discovery.
9. Translate discovery insights into prototypes, experiments, and startup decisions.

1. From Ideas to Problems

An idea is a proposed product, service, process, or business model. A problem is an undesirable condition or unmet need experienced by a person, group, or organization. A need is a requirement or desired outcome that motivates action. An opportunity is a situation in which a problem may be addressed in a way that creates value for users and a sustainable venture.

These concepts should not be confused. For example, “a mobile application for local farmers” is an idea. “Small farmers cannot reliably obtain timely information about wholesale prices” is a problem hypothesis. “Farmers need trustworthy, accessible market information before deciding where to sell” expresses a need. An opportunity might be a service that combines verified price data with localized alerts and advisory support.

Symptoms and root causes

Entrepreneurs often observe a symptom rather than the underlying problem. A hospital may report long waiting times, but the cause may be poor appointment scheduling, repeated data entry, inadequate triage, or a shortage of specialists. A university may observe low student attendance, but the underlying causes may include transportation difficulties, timetable conflicts, financial pressure, or teaching methods that do not support participation.

A useful discovery process asks:

• What is happening?
• Who experiences it?
• When and where does it occur?
• What does the person currently do about it?
• What are the consequences?
• Why might the situation exist?
• What evidence would confirm or challenge this explanation?

The “five whys” technique can help explore causes, but it should not be used mechanically. Repeatedly asking “why?” may oversimplify complex systems or imply that one individual is responsible for a structural problem. Root-cause exploration should therefore be combined with observation, stakeholder comparison, and contextual analysis.

Problem quality

A promising entrepreneurial problem usually has several characteristics:

• It affects a clearly identifiable group.
• It occurs with sufficient frequency or intensity.
• Existing alternatives are inadequate, costly, inaccessible, or frustrating.
• People have motivation or capacity to change their current behaviour.
• The problem can be addressed within legal, technical, and organizational constraints.
• Solving it could create value without producing disproportionate harm.

The presence of complaints alone does not prove that a viable opportunity exists. People may complain about a situation but be unwilling to pay, change habits, adopt a new technology, or influence the purchasing decision. Discovery must therefore examine both the problem and the surrounding behaviour and institutional context.

2. Stakeholder Analysis

A stakeholder is any person, group, organization, or institution that affects, is affected by, or can influence a problem and its potential solution. In entrepreneurship, the user is not always the customer. For example, a child may use an educational product, a parent may pay for it, a school may approve it, and a regulator may determine whether it can be used.

Stakeholder categories

Common categories include:

Stakeholder mapping

A stakeholder map makes relationships visible. The team may map stakeholders according to power and interest, influence and impact, or closeness to the user experience. A high-power stakeholder with low day-to-day involvement may require early approval, while a low-power stakeholder who experiences significant harm must not be ignored.

Stakeholder analysis should not become a justification for privileging powerful actors. A venture may be commercially attractive to a buyer while imposing surveillance, exclusion, or environmental costs on less powerful groups. Responsible discovery gives attention to voice, vulnerability, dependency, and possible distributional effects.

A practical stakeholder-analysis sequence is:

1. List all actors connected with the problem.
2. Describe each actor’s role, interests, resources, risks, and influence.
3. Identify conflicts and dependencies among stakeholders.
4. Select representative participants for research.
5. Record which assumptions are supported by evidence and which remain uncertain.
6. Revisit the map as new information emerges.

3. Observation as a Discovery Method

Observation helps entrepreneurs understand what people actually do rather than what they remember or claim to do. It is especially valuable when behaviour is routine, tacit, socially sensitive, or difficult to describe. A founder studying food-delivery work, for instance, may learn more by observing the sequence of collecting orders, navigating traffic, contacting customers, and resolving errors than by asking only general questions.

Planning observation

A good observation plan specifies:

• the setting and activity to be observed;
• the people, interactions, and artefacts of interest;
• the time period and sampling approach;
• the questions guiding attention;
• the consent and privacy arrangements;
• the method for recording notes.

Observation may be structured, using a predefined schedule, or exploratory, allowing unexpected behaviour to emerge. It may be participant observation, in which the researcher takes part in the activity, or non-participant observation, in which the researcher remains outside the activity. Each approach introduces different risks of influence and interpretation.

Notes should distinguish direct observation from interpretation. “The employee checked the same customer record three times in ten minutes” is an observation. “The software is confusing” is an interpretation that requires further investigation. Photographs, recordings, and screen captures require explicit permission and careful handling of personal information.

What to observe

Researchers should attend to:

• sequences and timing;
• workarounds and unofficial practices;
• interruptions and handoffs;
• emotional responses and moments of frustration;
• tools, documents, and physical environments;
• differences between expert and novice behaviour;
• accessibility barriers;
• errors, recovery actions, and unresolved tasks.

The purpose is not to judge participants. Workarounds often reveal creativity and system failure rather than user incompetence.

4. Interviews and Conversation-Based Inquiry

Interviews provide access to meanings, motivations, experiences, and expectations that cannot be directly observed. In early discovery, semi-structured interviews are generally useful. They combine a consistent set of themes with enough flexibility to follow important experiences.

Designing effective interviews

A useful interview guide moves from context to experience, behaviour, consequences, and reflection:

1. “Tell me about the last time you…”
2. “What happened next?”
3. “What was difficult about that situation?”
4. “How did you handle it?”
5. “What alternatives did you consider?”
6. “What did the situation cost in time, money, effort, or emotion?”
7. “What would a better outcome look like?”

Questions about actual past behaviour are usually more reliable than questions about hypothetical future behaviour. “Would you use this application?” often produces polite optimism. “How did you solve this problem the last time it occurred?” reveals current alternatives and commitment.

Leading questions should be avoided. “Would you like a faster payment system?” presupposes that speed is the priority and that a new system is desired. “How do you currently make payments, and what difficulties arise?” is more open.

Interview quality and analysis

The interviewer should build rapport, explain the purpose, seek permission, protect confidentiality, and avoid defending a proposed idea. Interviews should be recorded only with consent. Immediately after each interview, the researcher should document context, notable quotations, emerging interpretations, and unanswered questions.

Analysis can involve coding statements into categories such as goals, frustrations, workarounds, constraints, emotions, and desired outcomes. The team should compare patterns across participants rather than treating one memorable quotation as proof. Negative cases—experiences that contradict the dominant pattern—are particularly valuable because they reveal conditions and segments that may otherwise be overlooked.

5. Journey Mapping and Sense-Making

A journey map represents the stages through which a person moves while trying to accomplish a goal. It may include actions, thoughts, emotions, touchpoints, pain points, backstage processes, and opportunities. Journey mapping is useful because problems often occur between organizational departments or technologies rather than within one isolated interaction.

A basic journey map can use the following structure:

The map should identify whose journey is being represented, the goal, the time period, and the evidence used. It should not be a fictional decorative poster. A journey map based on interviews, observation, and service records is more credible than one based only on assumptions.

Journey maps can be expanded into service blueprints, which connect frontstage user experiences with backstage processes, technologies, staff roles, and support systems. This is particularly important for service startups: an apparently simple customer interface may require complex verification, logistics, payment, or regulatory work.

6. Design Thinking as an Iterative Process

Design thinking is commonly expressed through five activities: empathize, define, ideate, prototype, and test. These labels are useful, but they do not imply a strictly sequential process.

Empathize and understand context

Empathy in design is not merely feeling sympathy. It is a disciplined attempt to understand a person’s goals, constraints, practices, and lived context. The entrepreneur should seek multiple perspectives and remain aware that the researcher’s assumptions shape what is noticed.

Define the problem

A strong problem statement identifies a user, a need or desired outcome, and the context or insight that explains its importance. For example:

Commuter students who work part-time need a reliable way to coordinate changing class and work schedules because existing timetable tools do not integrate the constraints that determine whether they can attend.

This statement avoids prescribing a solution. “Students need a scheduling application” is less useful because it embeds a product before the problem has been established.

A how-might-we question converts an insight into an opportunity for exploration: “How might we help commuter students coordinate academic and work commitments without increasing planning burden?” The question should be broad enough to permit alternatives but focused enough to guide ideation.

Ideate

Ideation aims to produce a range of possible responses before selecting one. Useful methods include brainstorming, brainwriting, analogy, forced connections, worst-possible-idea exercises, and sketching. Quantity can be helpful at the beginning because early evaluation tends to favour familiar solutions.

Effective ideation rules include deferring judgment, building on others’ ideas, making ideas visible, and separating generation from evaluation. However, creativity should not be confused with novelty. A simple process change may create more value than an advanced technology.

Prototype

A prototype is a representation used to learn. It may be a paper sketch, storyboard, role-play, landing page, clickable interface, service script, mock-up, or manually delivered service. A prototype should answer a specific question. A low-fidelity prototype is often appropriate when the team is testing the problem, workflow, or value proposition. Higher fidelity is justified when visual detail, technical performance, or interaction quality is itself the subject of learning.

Test and learn

Testing should examine user behaviour, comprehension, desirability, and operational assumptions. The team should define what it expects to learn before testing and specify what evidence would cause it to continue, modify, or abandon the concept. Testing is not a sales demonstration. If the researcher explains too much or guides the participant toward approval, the result becomes unreliable.

7. Evaluating Opportunities: Desirability, Feasibility, Viability, and Impact

A solution is promising only when several conditions align.

Desirability

Desirability concerns whether people value the proposed outcome and are willing to change behaviour, adopt the solution, or recommend it. Evidence may include repeated problem behaviour, active workarounds, stated priorities, trial completion, retention, referrals, or payment. Stated interest alone is weak evidence.

Feasibility

Feasibility concerns whether the solution can be built, delivered, supported, and operated with available or attainable resources. Relevant issues include technical capability, data access, supply chains, skills, partnerships, cybersecurity, accessibility, and regulatory requirements.

Viability

Viability concerns whether the venture can sustain itself economically. It includes the customer, revenue mechanism, cost structure, acquisition process, cash requirements, and competitive response. A desirable service may not be viable if users cannot pay and no credible sponsor or alternative revenue source exists.

Impact

Impact concerns the broader consequences of the solution. These may include social inclusion, worker welfare, environmental effects, privacy, safety, and distribution of benefits and burdens. Impact should be considered from the beginning, not added as a marketing claim after product design.

A simple evaluation matrix can help teams compare concepts, but numerical scores should not create false precision. Scores are judgments based on evidence quality and assumptions. Teams should record the evidence behind each assessment and identify the riskiest uncertainty.

8. From Insights to Testable Hypotheses

Discovery becomes entrepreneurial when observations are translated into assumptions that can be tested. A useful hypothesis identifies a target group, a problem, a proposed response, and an observable outcome.

For example:

We believe that independent tutors lose prospective clients because responding to enquiries across several channels is slow. If a shared enquiry-and-booking service is offered, tutors will adopt it and complete a defined number of bookings within a pilot period.

The hypothesis should specify what would count as meaningful evidence. The team may test the problem through interviews and diary studies, the solution through a concierge service, and the business model through a paid pilot. The purpose of an experiment is not to prove the founder correct; it is to reduce uncertainty at reasonable cost.

Useful experiment types include:

• Problem interviews: test whether the problem is real and important.
• Concept tests: examine comprehension and perceived value.
• Concierge tests: deliver the proposed service manually before automating it.
• Landing-page tests: assess interest and message clarity, while recognizing that clicks do not prove sustained demand.
• Wizard-of-oz prototypes: present an apparently automated service while people perform the hidden work.
• Pilot programmes: examine use in a realistic organizational context.

9. Illustrative Case: FreshRoute Food Redistribution

Background

FreshRoute is a fictional early-stage venture exploring a service that connects supermarkets with community organizations to redistribute edible surplus food. The founding team initially proposed a smartphone platform that would automatically match surplus inventory with charities.

Problem discovery

The team conducted stakeholder mapping and identified store managers, food-safety officers, delivery drivers, community organizations, recipients, municipal authorities, and software providers. It discovered that store managers were not primarily asking for a matching platform. Their major difficulties involved unpredictable pickup times, unclear responsibility for food safety, incomplete records, and the risk that staff would spend more time preparing donations than managing them.

Observation showed that surplus food was often identified near the end of a shift. Staff used informal messaging groups and paper notes. Community organizations had limited cold-storage capacity and could not always accept the quantity offered. Interviews also revealed that recipients could experience stigma when collection systems were visibly labelled as charity services.

Analysis

The original problem statement—“charities need an app to receive surplus food”—was too narrow. A revised statement was:

Retail staff and community organizations need a predictable, safe, and low-administration process for transferring suitable surplus food because current coordination is unreliable and responsibilities are unclear.

The team created a journey map showing identification, classification, listing, acceptance, pickup, storage, distribution, and reporting. It identified several opportunities: scheduled collection windows, clear acceptance rules, temperature and safety records, capacity visibility, and discreet distribution arrangements.

Approach and solution

Instead of immediately building a full platform, FreshRoute ran a concierge pilot with two stores and three community organizations. A coordinator used a shared form and telephone calls to match donations, schedule pickups, and record acceptance. A simple dashboard was introduced only after recurring workflows became clear.

The pilot tested several assumptions: whether stores would prepare surplus consistently, whether organizations could accept scheduled quantities, whether transport arrangements were feasible, and whether records met local requirements. The team also consulted food-safety authorities before expanding.

Outcome

The pilot showed strong interest but exposed an important feasibility constraint: some organizations lacked refrigeration and could accept only specified food categories. The venture therefore narrowed its initial market to stores located near organizations with suitable facilities. It also developed standard operating procedures and made capacity information central to the service.

The most important result was not the creation of software. It was the discovery that coordination, accountability, and infrastructure—not simply information matching—were the central problems.

Learning points

1. The first idea may conceal the real system problem.
2. Users, buyers, beneficiaries, and regulators may have different requirements.
3. Observation reveals operational work that interviews may omit.
4. A manual pilot can test feasibility before costly automation.
5. Social value requires attention to dignity, safety, and unequal capacity.

10. Ethics, Inclusion, and Governance

Problem discovery involves people’s time, experiences, data, and sometimes vulnerability. Ethical practice is therefore a professional responsibility.

Researchers should obtain informed consent, explain the purpose of the research, allow withdrawal where appropriate, minimize data collection, protect identity, and store records securely. Sensitive information should not be collected merely because it might be useful later. Participants should not be pressured by employers, teachers, service providers, or researchers who hold power over them.

Inclusive discovery requires more than recruiting a demographically diverse sample. The team should consider language, disability, digital access, gender, age, income, geography, cultural norms, and the consequences of exclusion. A solution optimized for highly connected users may intensify disadvantage for people who lack devices, data, transport, or confidence.

Entrepreneurs should also distinguish participation from extraction. Participants should understand how their contributions will be used. Where feasible, teams can share findings, acknowledge contributions, and provide compensation that is fair without becoming coercive.

11. Technology and Artificial Intelligence in Discovery

Digital tools can support transcription, qualitative coding, survey analysis, journey visualization, and rapid prototyping. Artificial intelligence can help summarize large volumes of text, generate alternative interview prompts, identify recurring topics, or simulate possible service interactions. However, AI-generated summaries may omit minority perspectives, reproduce stereotypes, or present interpretations as facts.

Good practice includes obtaining permission before uploading recordings, removing identifying information, checking outputs against original evidence, retaining human responsibility for interpretation, and documenting the tool’s role. AI should assist inquiry rather than replace direct engagement with stakeholders. A generated persona is not evidence of a real user, and a synthetic interview cannot substitute for an actual participant.

12. Challenges and Limitations

Design thinking is powerful but not automatically rigorous. Common limitations include:

• Confirmation bias: founders notice evidence supporting an existing idea.
• Courtesy bias: participants provide positive responses to avoid discomfort.
• Small or unrepresentative samples: findings are generalized beyond their evidence.
• Recruitment bias: easy-to-reach participants differ from intended users.
• Researcher influence: questions or behaviour alter participant responses.
• Overemphasis on individual users: structural, institutional, or political causes are neglected.
• Prototype enthusiasm: a polished prototype creates approval that may not survive real use.
• Metric substitution: clicks or stated interest are mistaken for value, retention, or payment.
• Premature scaling: teams automate a poorly understood process.

Rigour requires triangulation: comparing interviews, observations, behavioural data, documents, and experiments. It also requires recording uncertainty. A discovery report should state not only what the team believes but why, based on which evidence, and with what limitations.

13. Best Practices for Incubated Ventures

A disciplined startup team should:

1. Begin with a problem context rather than a predetermined technology.
2. Map the full stakeholder system, including people who may bear unintended costs.
3. Recruit participants who represent important contexts and edge cases.
4. Ask about recent behaviour and existing alternatives.
5. Separate observations, quotations, interpretations, and assumptions.
6. Use journey maps to identify cross-organizational failures.
7. Formulate a concise, solution-neutral problem statement.
8. Test the riskiest assumption before building extensive features.
9. Use the smallest credible prototype or pilot.
10. Evaluate desirability, feasibility, viability, and impact together.
11. Treat negative evidence as useful learning.
12. Document decisions so that mentors, partners, and future team members can audit the reasoning.

Chapter Summary

Problem discovery is the disciplined investigation of meaningful human, organizational, and societal difficulties before committing to a solution. Entrepreneurs distinguish symptoms from underlying problems by combining stakeholder analysis, observation, interviews, journey mapping, and contextual research. Stakeholder mapping reveals different roles, interests, power relationships, and risks; observation exposes actual behaviour and workarounds; interviews reveal meanings and motivations; and journey maps make experiences and service gaps visible across time and organizational boundaries.

Design thinking integrates empathy, definition, ideation, prototyping, and testing in an iterative learning process. Strong problem statements avoid embedding a solution and identify a specific user, desired outcome, and context. Startup concepts must be assessed through desirability, feasibility, viability, and impact rather than novelty alone. Ethical research, inclusion, privacy, and responsible use of AI are essential. The most effective incubated ventures treat discovery as evidence-based learning and remain willing to narrow, redesign, or abandon an initial idea.

Key Terms

Problem discovery: Systematic investigation of important unmet needs or undesirable conditions.

Design thinking: An iterative approach combining user understanding, problem definition, ideation, prototyping, and testing.

Stakeholder: Any actor who affects, is affected by, or can influence a problem or solution.

Primary user: The person who directly uses or experiences a product or service.

Customer: The person or organization that pays for or authorizes a solution.

Need: A requirement or desired outcome that motivates behaviour.

Opportunity: A situation in which a problem can potentially be addressed to create value.

Workaround: An informal or alternative method used to overcome a limitation.

Observation: Systematic attention to behaviour, context, interactions, and artefacts.

Semi-structured interview: An interview guided by consistent themes but allowing flexible follow-up.

Journey map: A representation of stages, actions, experiences, and pain points in a user’s effort to achieve a goal.

Service blueprint: A map connecting user experience with backstage processes and support systems.

Problem statement: A concise, evidence-informed description of a user problem and desired outcome.

How-might-we question: An open opportunity question used to guide solution generation.

Prototype: A representation created to learn about a concept or assumption.

Desirability: The extent to which intended users value and adopt a solution.

Feasibility: The extent to which a solution can be built and delivered reliably.

Viability: The extent to which a venture can sustain itself economically.

Impact: The broader positive and negative consequences of a solution.

Triangulation: Comparing multiple evidence sources or methods to improve confidence in findings.

Review Questions

Short Answer Questions

1. Distinguish between an idea, a problem, a need, and an opportunity.
2. Why is the user not always the customer?
3. State two benefits of observation in entrepreneurial problem discovery.
4. What makes a problem statement solution-neutral?
5. Define desirability, feasibility, viability, and impact.

Long Answer Questions

1. Explain how stakeholder mapping can reveal risks and opportunities that a founder might otherwise miss.
2. Describe how to plan and conduct a rigorous semi-structured interview for startup discovery.
3. Explain the purpose and components of a journey map and discuss how it can support service innovation.
4. Discuss the iterative relationship among empathy, definition, ideation, prototyping, and testing.
5. Examine the ethical responsibilities of an entrepreneurial team conducting research with vulnerable participants.

Analytical / Application Questions

1. A university observes that many students miss appointments with academic advisers. Develop a stakeholder map, propose an observation plan, and formulate two alternative problem statements.
2. A startup team has received enthusiastic interview responses to a proposed delivery application. Design a low-cost experiment that tests actual desirability rather than stated interest, and identify evidence that would change the team’s decision.
3. Using the FreshRoute case, explain why a technically sophisticated matching platform was not the first appropriate solution. Evaluate the case through desirability, feasibility, viability, and impact.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a problem from an idea?

A. A problem is always technical, whereas an idea is always social.

B. A problem describes an undesirable condition or unmet need, whereas an idea proposes a possible response.

C. A problem is something customers pay for, whereas an idea is free.

D. A problem must already have a complete business model.

Correct Answer: B. A problem describes an undesirable condition or unmet need, whereas an idea proposes a possible response.

Question 2

Why should entrepreneurial interviews focus on recent behaviour?

A. Recent behaviour generally provides stronger evidence than hypothetical promises.

B. Recent behaviour eliminates the need for observation.

C. Recent behaviour guarantees that a participant will become a customer.

D. Recent behaviour makes ethical consent unnecessary.

Correct Answer: A. Recent behaviour generally provides stronger evidence than hypothetical promises.

Question 3

Which stakeholder may authorize payment without being the primary user?

A. A person who directly experiences the service only

B. A competitor with no relationship to the venture

C. A purchasing manager buying software for employees

D. A passer-by who has never encountered the problem

Correct Answer: C. A purchasing manager buying software for employees

Question 4

What is the main purpose of a journey map?

A. To calculate the venture’s annual profit

B. To represent stages, experiences, and pain points in a user’s effort to achieve a goal

C. To replace all interviews with a visual diagram

D. To determine the legal ownership of a product

Correct Answer: B. To represent stages, experiences, and pain points in a user’s effort to achieve a goal

Question 5

Which is the strongest problem statement?

A. Students need our scheduling application.

B. We should build an artificial-intelligence timetable.

C. Commuter students need a reliable way to coordinate changing class and work schedules because existing tools omit work constraints.

D. Our startup will dominate student productivity.

Correct Answer: C. Commuter students need a reliable way to coordinate changing class and work schedules because existing tools omit work constraints.

Question 6

A prototype is best understood as:

A. A final product released without testing

B. A representation created to learn about a concept or assumption

C. A legal contract with a supplier

D. A guarantee of market demand

Correct Answer: B. A representation created to learn about a concept or assumption

Question 7

Which criterion asks whether a solution can be built and delivered reliably?

A. Desirability

B. Feasibility

C. Viability

D. Impact

Correct Answer: B. Feasibility

Question 8

Which research practice best reduces confirmation bias?

A. Interviewing only people who already support the idea

B. Ignoring contradictory evidence

C. Comparing multiple evidence sources and actively examining negative cases

D. Using a more attractive prototype

Correct Answer: C. Comparing multiple evidence sources and actively examining negative cases

Question 9

Why might a concierge pilot be useful before software automation?

A. It tests workflows and value through manual delivery before substantial development investment.

B. It guarantees regulatory approval.

C. It removes the need to understand users.

D. It proves that the final technology will scale indefinitely.

Correct Answer: A. It tests workflows and value through manual delivery before substantial development investment.

Question 10

Which statement about AI in problem discovery is most accurate?

A. AI-generated personas are equivalent to evidence from real users.

B. AI can support analysis, but outputs require human checking and may reproduce bias.

C. AI eliminates the need for informed consent when processing recordings.

D. AI summaries are always more reliable than original research data.

Correct Answer: B. AI can support analysis, but outputs require human checking and may reproduce bias.