Problem Discovery, Value Proposition and Business Case

Introduction

A successful full-stack project begins before a database schema, user interface, or programming language is selected. It begins with a defensible understanding of a problem that matters. Many software projects fail not because the development team cannot implement features, but because the team solves an unimportant problem, misunderstands users, or proposes a solution whose benefits do not justify its cost and risks.

Problem discovery is the disciplined process of identifying, investigating, and validating a significant user or organisational problem. It combines design thinking, stakeholder analysis, market research, systems thinking, and feasibility analysis. The result should be more than an interesting idea. It should be a clear problem definition, a compelling value proposition, a comparison with alternatives, and a business case that supports a rational investment decision.

For full-stack developers, these activities are highly practical. They influence requirements, data structures, APIs, security controls, deployment architecture, testing priorities, and the definition of a minimum viable product (MVP). A technically elegant system with weak problem–solution fit is still a poor project.

Learning Objectives

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

• distinguish a symptom, need, opportunity, and well-formed problem statement;
• apply design-thinking methods to discover and validate user problems;
• identify and analyse stakeholders, including their influence and interests;
• conduct proportionate qualitative and quantitative market research;
• formulate a value proposition and identify a suitable target segment;
• compare solution alternatives using explicit criteria;
• assess technical, operational, economic, legal, and schedule feasibility;
• construct a basic business case using benefits, costs, risks, and assumptions; and
• translate validated findings into an MVP and a defensible project recommendation.

1. From Ideas to Problems Worth Solving

An idea is a proposed intervention; a problem is an undesirable current condition experienced by a person, organisation, or community. “Build a mobile app for local transport” is an idea. “Students cannot reliably determine whether the next campus shuttle has sufficient capacity, causing missed classes and avoidable waiting” is a problem hypothesis.

A useful problem description identifies:

1. Who experiences the difficulty;
2. What they are trying to accomplish;
3. When and where the difficulty occurs;
4. What currently happens;
5. Why it matters, including measurable consequences; and
6. What evidence supports the claim.

A symptom is an observable effect, such as long queues. A root problem may be inconsistent service information, an inefficient approval process, or insufficient capacity. Treating a symptom as the root problem can produce an ineffective solution. Root-cause analysis therefore asks “why?” repeatedly, while avoiding the assumption that every problem has one cause.

A problem statement should not prescribe a technology. A strong form is:

[User group] needs a better way to [complete a task or achieve an outcome] because [evidence-based obstacle], resulting in [important consequence].

For example: “Part-time students need a reliable way to plan academic appointments because service availability is distributed across incompatible systems, resulting in missed appointments and repeated telephone enquiries.”

Desirable problem characteristics

A project problem should be:

• meaningful: it has consequences for users or the organisation;
• observable: evidence can be collected;
• specific: the affected segment and context are identifiable;
• actionable: a digital intervention could plausibly improve it;
• bounded: it can be addressed within available time and resources; and
• open to learning: assumptions can be tested rather than merely confirmed.

The team should distinguish problem validation from solution validation. Evidence that users experience difficulty does not prove that a particular application will solve it. Both claims require testing.

2. Design Thinking as a Discovery Process

Design thinking is a human-centred approach to innovation. Its commonly used stages are empathise, define, ideate, prototype, and test. In practice, the stages are iterative rather than strictly sequential. Testing may reveal that the original problem was poorly framed, leading the team back to research.

Empathise

Empathy is systematic attention to users’ goals, behaviours, constraints, emotions, and social context. Common methods include semi-structured interviews, contextual observation, diary studies, support-ticket analysis, and usability evaluation of existing processes. The purpose is not to collect feature requests but to understand actual behaviour.

Interview questions should be open and evidence-oriented. “Tell me about the last time you booked an appointment” is more useful than “Would you use an appointment app?” The latter invites hypothetical enthusiasm and often produces unreliable results.

Define

Researchers synthesise evidence into themes, personas, journey maps, and a problem statement. A persona is a research-based representation of a user segment, not a fictional stereotype. A journey map shows stages, actions, touchpoints, emotions, pain points, and opportunities across an experience.

A “How might we...?” question can convert a problem into a design challenge without prescribing a solution. For example: “How might we help part-time students identify and secure suitable appointment times without contacting several offices?”

Ideate

Ideation generates multiple possible responses before selecting one. Techniques include brainstorming, brainwriting, storyboarding, analogous examples, and “worst possible idea” exercises. Ideas should initially be judged for relevance to the validated problem rather than implementation convenience.

Prototype and test

A prototype is a deliberately limited representation of a solution. It may be a paper sketch, clickable interface, service blueprint, API mock, or working vertical slice. Prototypes reduce the cost of learning. Testing should examine whether users understand, can use, and value the proposed experience. It should also expose accessibility, privacy, security, and operational concerns.

Design thinking is not a substitute for engineering analysis. Desirability must be considered alongside feasibility and viability. A product may be attractive to users but impossible to operate securely or affordably.

3. Stakeholder Analysis

A stakeholder is any person, group, or institution that can affect a project, is affected by it, or has a legitimate interest in it. Stakeholders include end users, customers, sponsors, administrators, developers, operations staff, regulators, suppliers, communities, and people whose data may be processed even if they never use the interface.

Stakeholder analysis prevents a narrow “user-only” view. For example, a patient portal serves patients, but clinicians, receptionists, health-data officers, insurers, and regulators also shape requirements.

Stakeholder identification and mapping

Begin with brainstorming, organisational documents, process maps, interviews, and a power–interest matrix. A typical matrix classifies stakeholders as follows:

The matrix is a communication aid, not an objective truth. Power may be formal, financial, technical, social, or informational. A group with little formal authority may possess essential operational knowledge or legitimacy.

A stakeholder register can record name or group, role, goals, influence, concerns, information needs, engagement method, and accountable owner. It should be updated as the project reveals new relationships.

Conflicting interests

Stakeholders rarely agree completely. A manager may prioritise cost reduction, users may prioritise convenience, security staff may prioritise control, and regulators may prioritise compliance. Requirements should therefore be traced to stakeholder needs and evaluated for conflicts. Negotiation should make trade-offs explicit rather than allowing the loudest participant to define the product.

4. Market and User Research

Market research investigates customers, competitors, substitutes, trends, constraints, and demand. User research focuses more specifically on people’s behaviour and experience. Both are needed for a business case.

Secondary research

Secondary research uses existing evidence: government statistics, industry reports, academic studies, public pricing, competitor documentation, app-store reviews, organisational records, and open datasets. Researchers should evaluate source authority, date, method, population, incentives, and relevance. A vendor’s market report may be useful but should not be treated as neutral proof of demand.

Primary qualitative research

Interviews and observation provide depth and context. A purposive sample selects participants because they possess relevant experience. The aim is not necessarily statistical representativeness; it is to discover patterns, language, workarounds, and unmet needs. Researchers should record consent, protect identity, and distinguish direct quotations from interpretation.

A practical interview protocol includes an introduction, consent statement, warm-up questions, behavioural questions, probes, and closing questions. Avoid leading questions, double-barrelled questions, and questions that imply a preferred answer.

Primary quantitative research

Surveys can estimate prevalence, priorities, and willingness to adopt, but their quality depends on sampling, wording, response rate, and measurement design. A convenience sample may be appropriate for early exploration but cannot support strong claims about an entire population. Percentages should be reported with the sample size and relevant limitations.

For a survey estimate of a proportion, a commonly used approximate margin of error under simple random sampling is:

Here, MOE is the margin of error, z is the standard-normal critical value for the selected confidence level, p is the estimated population proportion, and n is the sample size. The approximation assumes independent observations and a probability sample. For a 95% confidence level, z is approximately 1.96. If no prior estimate of p is available, 0.5 produces the largest variance and therefore a conservative sample-size estimate. In real projects, non-response and non-probability sampling can create errors not captured by this formula.

Research should triangulate methods. If interviews, usage records, and survey responses point in the same direction, confidence increases. Contradictions are valuable: they may indicate different user segments or a difference between reported intention and actual behaviour.

5. Value Proposition and Business Model Logic

A value proposition explains why a defined customer or user segment should choose, adopt, or support a solution. It connects a customer job, a pain or risk, and a desired gain to a specific product or service response.

A useful value-proposition structure is:

For [target segment] who [important need or job], [solution] is a [category] that [primary benefit]. Unlike [current alternative], it [distinctive evidence-based advantage].

A value proposition is not a slogan. “Fast, smart, and easy” is weak unless the claims are specific and testable. “Enables campus staff to publish verified room availability in one place, reducing duplicate enquiries” is more useful because it identifies a user, activity, and intended outcome.

The Value Proposition Canvas links customer jobs, pains, and gains with products and services, pain relievers, and gain creators. It is a hypothesis map. Teams must validate whether the proposed pains are important, whether the segment recognises them, and whether the proposed benefits exceed switching costs.

Value creation, delivery, and capture

A digital product can create value through time savings, reduced errors, improved access, better decisions, revenue generation, risk reduction, or improved experience. It delivers value through interfaces, workflows, integrations, support, and reliable operations. It captures value through subscription, transaction fees, licensing, advertising, reduced internal cost, compliance protection, or strategic benefit.

Not every valuable system has direct revenue. A public-service application may be justified by reduced administrative effort, improved equity, or safer access. The business case must state whose value is being considered and how benefits will be measured.

6. Comparing Alternatives

The relevant choice is not simply “build” versus “do nothing.” Alternatives may include improving the current process, buying a commercial product, configuring an existing platform, partnering with another organisation, building internally, or postponing the project.

A weighted decision matrix makes criteria and assumptions visible. If alternative j receives score sᵢⱼ on criterion i, and criterion weights wᵢ sum to 1, its weighted score is:

The weights are dimensionless and scores must use a consistent scale. The result is a decision aid, not proof of superiority. Scores should be supported by evidence, and sensitivity analysis should test whether changing important weights changes the decision.

For “Build MVP,” the calculation is 0.30×5 + 0.25×3 + 0.20×5 + 0.15×4 + 0.10×2 = 4.05. The equal score of the first two alternatives illustrates why teams should examine the underlying evidence rather than rely only on a ranking.

7. Feasibility Analysis

Feasibility asks whether an alternative can be implemented and sustained under real constraints. A useful framework examines:

• Technical feasibility: skills, architecture, integrations, data quality, scalability, reliability, cybersecurity, and accessibility.
• Operational feasibility: process ownership, training, support, adoption, workflow fit, and organisational readiness.
• Economic feasibility: development, infrastructure, licensing, maintenance, support, opportunity cost, and expected benefits.
• Legal and regulatory feasibility: privacy, intellectual property, contracts, records, accessibility obligations, sector regulation, and data residency.
• Schedule feasibility: dependencies, milestones, procurement, approvals, and capacity.
• Social and ethical feasibility: inclusion, power effects, surveillance, bias, safety, and the possibility of harm.

Feasibility is not binary. A high-risk area may be reduced through a prototype, a technical spike, a data-quality audit, a pilot, or a revised scope.

Economic measures

A simple return on investment measure is:

Costs and benefits must refer to the same period and use consistent monetary units. ROI can be misleading when benefits occur over several years or when risk and timing matter.

The payback period is the time required for cumulative net cash flows to recover the initial investment. With equal annual net cash inflows, a simple approximation is:

This approximation assumes constant annual inflows and ignores the time value of money. If cash flows vary, cumulative cash flows should be listed by period instead.

For multi-period investment decisions, net present value (NPV) discounts future net cash flows:

C₀ is the initial cash outflow at time 0, CFₜ is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. The rate and cash-flow periods must match, and cash flows should be incremental to the project. A positive NPV means the discounted benefits exceed discounted costs under the stated assumptions; it does not remove uncertainty.

Worked example. An MVP requires $20,000 now and is expected to produce net benefits of $12,000 in year 1 and $13,000 in year 2. Using an annual discount rate of 10%:

NPV = −20,000 + 12,000 ÷ 1.10 + 13,000 ÷ 1.10²

NPV ≈ −20,000 + 10,909.09 + 10,743.80 = $1,652.89.

Under these assumptions, the proposal has a positive NPV. The result should be tested against lower adoption, higher operating costs, and delays.

8. Building the Business Case

A business case is a structured argument for action. It should allow decision-makers to understand the problem, alternatives, expected value, cost, uncertainty, and proposed controls.

A concise business case normally contains:

1. Executive recommendation: the decision requested and rationale.
2. Problem and evidence: affected segments, scale, consequences, and research quality.
3. Objectives and success measures: outcomes rather than only features.
4. Options considered: including the baseline and reasons for rejection.
5. Proposed scope: MVP boundaries, exclusions, dependencies, and assumptions.
6. Benefits and costs: financial and non-financial, with timing.
7. Risks and mitigations: likelihood, impact, owner, trigger, and response.
8. Delivery approach: milestones, resources, architecture direction, and governance.
9. Ethical, legal, and security assessment: data, access, consent, retention, and accountability.
10. Post-launch evaluation: metrics, review dates, and criteria for continuation.

A good objective is measurable and outcome-oriented. “Launch a dashboard” is an output. “Reduce average time to locate a verified appointment from 15 minutes to 5 minutes within three months of adoption” is an outcome hypothesis. The measure must have a defined population, time period, baseline, target, and collection method.

Risk and assumption management

An assumption is something believed to be true but not yet established. A risk is an uncertain event that could affect objectives. Teams should maintain an assumption log and a risk register. High-impact, low-confidence assumptions deserve early experiments. Examples include user willingness to share data, availability of an integration API, or the claim that staff can maintain content without specialist support.

9. From Discovery to MVP Requirements

Discovery findings must be translated without prematurely freezing the design. User stories express a need from a user perspective, for example: “As a part-time student, I want to filter appointments by evening availability so that I can select a realistic option.” Acceptance criteria make the expected behaviour testable.

Prioritisation methods such as MoSCoW classify features as Must have, Should have, Could have, and Won’t have for the current release. Another approach compares user value, risk reduction, effort, and learning potential. A feature belongs in the MVP when it tests the central value proposition and provides a usable end-to-end outcome—not merely because it is easy to build.

For full-stack planning, discovery should identify:

• actors and permissions;
• sensitive data and retention needs;
• critical workflows and failure states;
• integration and data-quality dependencies;
• non-functional requirements such as performance, availability, accessibility, and security; and
• measures needed to evaluate the product after release.

A thin vertical slice—interface, API, persistence, validation, security, and deployment—often produces more useful learning than a large collection of disconnected screens.

10. Illustrative Case: Campus Appointment Access

Background

This fictional case concerns Northbridge University, which provides academic advising, financial-aid appointments, and accessibility consultations through separate offices. Students currently use email, telephone, and three booking pages.

Problem

A discovery team hypothesises that part-time and commuter students lose time because appointment information is fragmented and availability is difficult to compare. The hypothesis is investigated through 12 interviews, observation of front-desk interactions, analysis of one semester of enquiry logs, and a survey of 186 students. The sample is not claimed to represent every student; it is used to triangulate an early product decision.

Interview participants describe repeated form completion and uncertainty about whether a booking has been confirmed. Enquiry logs show that “where can I book?” is a frequent question. The survey indicates that many respondents experience difficulty, but the team notes possible self-selection bias. Staff also report that no-shows create unused appointment capacity.

Analysis

Stakeholders include students, advisers, reception staff, service managers, the university privacy officer, IT operations, and accessibility representatives. Students value a single view and clear confirmation. Advisers need accurate availability and protection against double booking. The privacy officer requires data minimisation and access control. Accessibility representatives require keyboard navigation, readable content, and compatibility with assistive technologies.

The team identifies a root issue broader than “there is no app”: service information is fragmented, ownership is unclear, and confirmation messages are inconsistent. A solution that merely aggregates links may not solve availability accuracy.

Alternatives

The team compares process improvement, procurement of a booking platform, and a focused MVP integrating two high-demand services. Criteria include user impact, privacy control, implementation time, operational ownership, and integration risk. The MVP ranks highest, but only if the pilot limits scope and confirms that both services provide reliable availability data.

Proposed approach

The MVP provides authenticated access, service selection, availability filtering, booking confirmation, cancellation, reminders, and an adviser availability interface. It excludes all university services until the integration and governance model are proven. Sensitive information is minimised: the system stores appointment metadata and necessary identity attributes, not detailed advising notes.

A technical spike tests calendar integration and conflict handling. A clickable prototype tests terminology and navigation with students, including keyboard-only users. A pilot measures task completion, booking errors, no-show rate, support enquiries, and student-reported confidence. Security review covers authentication, authorisation, audit logging, input validation, and protection against enumeration of appointments.

Outcome and decision

The business case recommends a time-limited pilot rather than full institutional deployment. Expected benefits include reduced repeated enquiries, fewer scheduling errors, and improved access for commuters. The case explicitly states that benefits depend on service-owner participation and accurate data. A go/no-go review is scheduled after the pilot using predefined measures.

Learning points

The case demonstrates that discovery changes the solution. The initial “build an app” idea becomes a bounded service-integration problem. Stakeholder analysis reveals operational and privacy requirements that students alone could not specify. Research does not eliminate uncertainty; it makes uncertainty visible and creates a basis for staged investment.

11. Ethics, Governance, and Responsible Use of AI

Problem discovery can expose personal, behavioural, or sensitive information. Researchers should collect only necessary data, obtain informed consent where required, explain purpose, protect records, and define retention and deletion practices. Participants should be able to decline without disadvantage. Special care is needed when studying children, patients, employees, or people dependent on the organisation conducting the research.

A digital solution may exclude users through inaccessible design, language assumptions, poor connectivity, algorithmic bias, or requirements for devices and identity documents. Accessibility should be treated as a quality requirement from discovery, not a late compliance task.

AI tools can assist with transcript summarisation, thematic coding, competitor comparison, prototyping, and scenario generation. They can also reproduce bias, invent evidence, expose confidential data, or obscure the reasoning behind a decision. Teams should obtain permission before submitting research data to an AI service, verify generated claims against primary evidence, preserve human accountability, and document where AI influenced analysis. Automated recommendations affecting access, eligibility, or opportunity require heightened review, explainability, monitoring, and an appeal route.

12. Common Failure Modes and Best Practices

Common failures include beginning with a favourite technology, interviewing only friends, treating stated preferences as behaviour, confusing a large market with a reachable customer segment, ignoring alternatives, hiding negative evidence, underestimating operational work, and presenting precise financial estimates unsupported by assumptions.

Best practices are to:

• state hypotheses before collecting evidence;
• use multiple research methods and record limitations;
• recruit affected users and overlooked groups;
• distinguish facts, interpretations, assumptions, and decisions;
• compare against a realistic baseline;
• test the riskiest technical and adoption assumptions early;
• make costs include maintenance, support, security, training, and decommissioning;
• define measurable outcomes and a post-launch review; and
• use staged commitment: research, prototype, pilot, then scale when evidence supports it.

Chapter Summary

Problem discovery is the evidence-based identification and framing of a meaningful need. Design thinking supports iterative movement from empathy and definition to ideation, prototyping, and testing. Stakeholder analysis reveals different interests, power relationships, operational constraints, and ethical responsibilities. Market and user research combine secondary evidence, qualitative inquiry, quantitative measurement, and triangulation; each method has limitations.

A value proposition connects a target segment and important job with a specific benefit and a defensible difference from alternatives. Alternatives should include the current state, buying, configuring, partnering, building, and postponing. Weighted decision matrices make criteria visible, while feasibility analysis considers technical, operational, economic, legal, schedule, social, and ethical dimensions.

A business case explains the problem, evidence, options, scope, benefits, costs, risks, assumptions, delivery plan, and success measures. ROI, payback, and NPV can support analysis when their assumptions and limitations are made explicit. For a full-stack project, discovery should lead to a bounded MVP, testable requirements, appropriate data governance, and a plan for learning after launch.

Key Terms

Problem discovery: Systematic investigation of an important unmet need or undesirable condition.

Problem statement: A concise description of who experiences a problem, in what context, and with what consequence.

Design thinking: A human-centred, iterative approach involving empathy, definition, ideation, prototyping, and testing.

Stakeholder: A person or group that affects, is affected by, or has a legitimate interest in a project.

Persona: A research-based representation of a user segment.

Journey map: A representation of user actions, touchpoints, needs, and difficulties across an experience.

Market research: Investigation of customers, competitors, substitutes, trends, and demand.

Triangulation: Use of multiple evidence sources or methods to examine a claim.

Value proposition: The specific value a solution promises to create for a defined segment.

Customer job: The task or outcome a customer is trying to accomplish.

Pain reliever: A feature or service mechanism intended to reduce a customer difficulty or risk.

Minimum viable product (MVP): The smallest usable product that tests a central value proposition.

Feasibility analysis: Assessment of whether an initiative can be implemented and sustained under constraints.

Business case: A structured argument for investing in a project or selecting an option.

Assumption: An unverified belief on which analysis or planning depends.

Risk register: A managed record of uncertain events, impacts, owners, and responses.

Return on investment (ROI): Benefits minus costs divided by costs, expressed as a percentage.

Net present value (NPV): Discounted value of future net cash flows minus the initial investment.

Weighted decision matrix: A comparison method using weighted criteria and alternative scores.

Stakeholder power–interest matrix: A map used to tailor stakeholder engagement.

Review Questions

Short Answer Questions

1. Distinguish a problem statement from a solution idea and provide one example of each.
2. What is the purpose of a stakeholder power–interest matrix?
3. Why should interviews focus on past behaviour rather than only hypothetical future use?
4. Define a value proposition and identify two qualities of a strong one.
5. Name four dimensions of feasibility analysis.

Long Answer Questions

1. Explain the stages of design thinking and describe how they may interact in an iterative full-stack project.
2. Discuss how qualitative and quantitative research can be combined to validate a problem while acknowledging their limitations.
3. Explain how stakeholder conflicts can influence requirements, scope, and governance.
4. Describe the principal sections of a business case and explain why assumptions should be made explicit.
5. Compare ROI, payback period, and NPV as tools for evaluating a digital project.

Analytical / Application Questions

1. A university proposes a student-services portal because “students want an app.” Construct a research plan that tests the underlying problem, identifies stakeholders, and produces evidence for an MVP decision.
2. Using the weighted decision matrix in this chapter, explain what would happen to the ranking if time to benefit were given a much higher weight. What additional evidence would you need before changing the recommendation?
3. A proposed health-support platform collects detailed user histories to personalise recommendations. Analyse the feasibility, privacy, ethical, and governance issues, and recommend a proportionate discovery and pilot approach.

Multiple Choice Questions with Answers

Question 1

Which statement is the best example of a problem statement?

A. Build a mobile application for campus transport.

B. Use artificial intelligence to optimise shuttle routes.

C. Students cannot reliably know whether the next shuttle has capacity, causing missed classes and unnecessary waiting.

D. Create a dashboard with maps and notifications.

Correct Answer: C. Students cannot reliably know whether the next shuttle has capacity, causing missed classes and unnecessary waiting.

Question 2

Which research question is most likely to elicit evidence about actual behaviour?

A. Would you use our proposed application?

B. Do you agree that the current process is inefficient?

C. What features should we build first?

D. Tell me about the last time you completed this task.

Correct Answer: D. Tell me about the last time you completed this task.

Question 3

In a power–interest matrix, a stakeholder with high power and high interest should generally be:

A. Managed closely.

B. Monitored only.

C. Kept informed but not consulted.

D. Ignored until project completion.

Correct Answer: A. Managed closely.

Question 4

Using the chapter’s weighted-score formula, what is the score for an alternative with weights 0.5 and 0.5 and scores 4 and 2?

A. 2.0

B. 3.0

C. 4.0

D. 6.0

Correct Answer: B. 3.0

Question 5

Which item is an outcome rather than an output?

A. Deploy a dashboard.

B. Write three API endpoints.

C. Reduce appointment-search time from 15 minutes to 5 minutes.

D. Create a database table.

Correct Answer: C. Reduce appointment-search time from 15 minutes to 5 minutes.

Question 6

What is the principal purpose of an MVP in discovery-led development?

A. To include every requested feature.

B. To test the central value proposition with a usable, limited product.

C. To eliminate the need for user research.

D. To guarantee commercial success.

Correct Answer: B. To test the central value proposition with a usable, limited product.

Question 7

Which statement about NPV is correct?

A. It ignores the timing of cash flows.

B. It discounts future net cash flows and subtracts the initial investment.

C. It is always equal to ROI multiplied by project duration.

D. It can be calculated without specifying a discount rate.

Correct Answer: B. It discounts future net cash flows and subtracts the initial investment.

Question 8

Which is an example of triangulation?

A. Interviewing one participant three times using the same question.

B. Using interviews, enquiry logs, and survey results to examine the same problem.

C. Replacing all research with a competitor’s advertisement.

D. Selecting only evidence that supports the preferred solution.

Correct Answer: B. Using interviews, enquiry logs, and survey results to examine the same problem.

Question 9

Which alternative should normally be included in a comparison of digital solutions?

A. Only the most technologically advanced option.

B. Only internal development.

C. The current process or do-nothing baseline.

D. Only options approved by developers.

Correct Answer: C. The current process or do-nothing baseline.

Question 10

Why should AI-generated research summaries be reviewed by humans?

A. AI outputs are automatically legally binding.

B. AI cannot process any text.

C. AI may introduce errors, bias, or unsupported claims and can expose confidential data.

D. Human review prevents all project risks.

Correct Answer: C. AI may introduce errors, bias, or unsupported claims and can expose confidential data.