Minimum Viable Product and Project Execution

Introduction

Entrepreneurial ideas acquire economic and social value only when they are translated into products, services, and experiences that customers can use. The minimum viable product (MVP) is a disciplined way of making that translation under conditions of uncertainty. Rather than attempting to build a complete product immediately, an entrepreneurial team develops the smallest credible version that enables meaningful learning from real users.

MVP development is not simply a cost-cutting exercise. It is a method for testing assumptions about a problem, a customer segment, a proposed solution, and a business model. Project execution provides the operational discipline needed to convert those assumptions into deliverables. It includes defining requirements, prioritizing features, allocating resources, coordinating work, managing risks, collecting evidence, and documenting results.

Agile methods, especially Scrum and Kanban, are particularly useful in internship and startup-incubation settings because requirements change as evidence is collected. However, agile does not mean unplanned or undocumented work. Effective agility combines a clear purpose with short feedback cycles, transparent priorities, responsible decision-making, and continuous improvement.

Learning Objectives

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

1. Explain the purpose, characteristics, and limitations of an MVP.
2. Convert customer problems into testable product requirements.
3. Apply agile principles and distinguish Scrum from Kanban.
4. Prioritize features using customer value, risk, effort, and learning potential.
5. Prepare a practical MVP execution plan and allocate limited resources.
6. Identify, assess, and respond to project risks.
7. Define useful measures of progress, product performance, and learning.
8. Document internship or incubation deliverables professionally and ethically.

1. From Entrepreneurial Idea to Testable Product

An entrepreneurial opportunity usually begins with a set of assumptions. For example, a team may believe that university students need affordable healthy meals, that they will order through a mobile application, and that local food providers can fulfil orders profitably. Each statement is uncertain until tested.

A useful distinction is between a problem hypothesis and a solution hypothesis. A problem hypothesis describes who experiences a difficulty, in what context, and with what consequences. A solution hypothesis proposes how a product or service will address that difficulty. Confusing the two can cause teams to become attached to a technology before establishing that the problem matters.

A product development process can therefore be represented as a learning cycle:

assumptions → experiment or MVP → user evidence → interpretation → revised assumptions or product

The cycle is related to the lean-startup principle of validated learning. It does not imply that every decision must be reduced to a numerical experiment. Interviews, observations, prototypes, transaction data, usability tests, and service trials can all provide evidence, provided that the team defines what it is trying to learn and how the evidence will affect a decision.

What Is an MVP?

An MVP is the smallest version of a product or service that can deliver a coherent user benefit while generating reliable learning about a significant business or product assumption. Three elements are essential:

• Minimum: The scope is deliberately limited.
• Viable: The product is sufficiently functional, usable, safe, and reliable for its intended test.
• Product: It is an actual user-facing offering or realistic service experience, not merely an internal idea.

An MVP is not necessarily a rough or low-quality product. A narrow product can be professionally designed and dependable. Conversely, a product with many features may still fail to be viable if users cannot understand it, access it, or obtain the promised benefit.

The appropriate MVP depends on the uncertainty being investigated. Examples include:

A landing page that collects expressions of interest may test demand, but it is not equivalent to a functioning product. The team should describe accurately what was tested and avoid presenting interest as evidence of actual adoption or revenue.

2. Requirements: From User Need to Workable Scope

Requirements specify what a product must accomplish and the conditions under which it must operate. In an early-stage venture, requirements are provisional because learning may change them. They should therefore be clear enough to guide work but flexible enough to be revised.

User Stories and Acceptance Criteria

A common agile format is the user story:

As a [type of user], I want [capability], so that [benefit].

For example:

As a student ordering lunch, I want to see delivery times before payment, so that I can choose an option that fits my schedule.

A user story describes value from the user’s perspective; it is not a complete technical specification. The team should add acceptance criteria, which state the conditions that must be satisfied for the story to be accepted. For the example above, criteria might include:

• Delivery estimates are displayed for every available meal.
• Estimates are shown before the payment step.
• The displayed time uses the user’s local time convention.
• If an estimate is unavailable, the system explains what the user should do next.

Acceptance criteria reduce ambiguity and support objective review. They may be expressed as examples, scenarios, test cases, or observable outcomes.

Functional and Non-functional Requirements

Functional requirements describe actions or capabilities, such as creating an account, searching products, placing an order, or generating a report. Non-functional requirements describe qualities or constraints, such as security, accessibility, response time, privacy, reliability, compatibility, or legal compliance.

An MVP should not ignore non-functional requirements. A payment feature that stores sensitive information insecurely is not acceptable merely because it is small. The team must identify minimum standards for safety, privacy, accessibility, and regulatory compliance before development begins.

Definition of Ready and Definition of Done

Teams benefit from shared completion standards. A Definition of Ready identifies the minimum information needed before work begins. It may require a clear user, purpose, acceptance criteria, dependencies, and a feasible estimate. A Definition of Done identifies the conditions for considering work complete. It may require implementation, testing, documentation, review, deployment, and stakeholder acceptance.

These definitions prevent a common failure: reporting activity as progress. Writing code, conducting meetings, or designing screens does not necessarily mean that a usable product increment exists.

3. Agile Project Execution

Agile approaches developed partly in response to rigid development methods that assumed requirements could be specified completely at the beginning. The Agile Manifesto emphasizes individuals and interactions, working software, customer collaboration, and responding to change, while retaining value in processes, documentation, contracts, and plans. Agile is therefore a matter of prioritization rather than a rejection of discipline.

In an incubation project, agile execution generally involves:

1. Establishing a product goal and target user.
2. Maintaining a prioritized backlog of work.
3. Selecting a small amount of work for a short cycle.
4. Building and integrating a usable increment.
5. Reviewing the result with relevant stakeholders or users.
6. Reflecting on the process and adjusting the next cycle.

A cycle should produce evidence, not merely busyness. If no user can use, inspect, or learn from the result, the team should question whether the cycle is generating meaningful value.

Scrum

Scrum is a framework for complex product work based on defined accountabilities, events, and artifacts. The central artifacts are:

• Product Backlog: An ordered list of product work and improvements.
• Sprint Backlog: The selected work and plan for a particular Sprint.
• Increment: A usable, integrated step toward the product goal.

The Product Owner is accountable for maximizing product value and ordering the backlog. Developers create the increment and determine how the work is performed. The Scrum Master helps establish Scrum, remove impediments, and support effective practice. In a student venture, one person may perform more than one practical function, but the responsibilities should remain clear and conflicts should be managed.

A Sprint is a fixed-length period, commonly one to four weeks. Its events include Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Scrum works well when a team can protect a short cycle and regularly inspect a usable increment.

Kanban

Kanban is a flow-based approach. Work is visualized on a board, such as:

Ideas → Ready → In Progress → Review/Test → Done

The team establishes explicit policies, limits work in progress (WIP), monitors flow, and improves the system continuously. A WIP limit of two in the “In Progress” column, for example, encourages the team to finish existing work before starting more work.

Kanban is useful when priorities change frequently, work arrives continuously, or the team cannot commit to fixed Sprints. Scrum and Kanban are not identical, although a team may combine selected practices. Scrum emphasizes timeboxed events and accountabilities; Kanban emphasizes flow, policies, and WIP control.

Neither method guarantees success. Poorly defined value, weak customer contact, and inadequate technical quality can undermine either approach.

4. Feature Prioritization and MVP Scope

Because resources are scarce, an MVP cannot include every desirable feature. Prioritization should make trade-offs visible rather than allowing the loudest stakeholder to determine scope.

A practical prioritization discussion considers four questions:

1. How much customer or business value could this feature create?
2. How much uncertainty or risk does it help resolve?
3. What effort, cost, and dependency does it require?
4. Is it necessary for the product to be safe, legal, usable, or testable?

The MoSCoW method classifies work as Must have, Should have, Could have, and Won’t have for now. “Won’t have” is not a permanent rejection; it protects current scope. A feature should be a Must have only when its absence prevents the MVP from delivering its core promise or from testing the central hypothesis.

A weighted scoring model can support, but not replace, judgment. Suppose a team scores each feature from 1 to 5 for value, learning, urgency, and effort. If effort is treated as a cost, a simple priority index is:

Here, P is the priority index; V, L, and U are scores for value, learning, and urgency; E is the effort score; and wᵥ, wₗ, and wᵤ are non-negative weights. The scores must use the same defined scale, and E must be positive. The index is useful for comparison within the same project, not as an objective measure of economic value.

For example, with equal weights, a feature scoring value 5, learning 4, urgency 3, and effort 4 has:

P = (5 + 4 + 3) ÷ 4 = 3

A feature scoring value 4, learning 5, urgency 4, and effort 2 has:

P = (4 + 5 + 4) ÷ 2 = 6.5

The second feature ranks higher under this model, but a legal or security requirement may still take precedence even if its calculated index is lower. Quantitative scoring is a conversation aid, not a substitute for responsibility.

Estimating Capacity

A simple capacity estimate helps prevent overcommitment. If a team has four members, each with 20 available hours in a two-week cycle, and only 70% of time is realistically available for planned project work, planned capacity is:

C is planned capacity in person-hours, n is the number of people, h is available hours per person, and a is the availability proportion. Thus:

C = 4 × 20 × 0.70 = 56 person-hours.

The 30% allowance recognizes meetings, support, learning, interruptions, and unforeseen work. Capacity is not a promise of output; unfamiliar tasks and dependencies make estimates uncertain.

5. Planning the MVP Execution

A practical MVP plan should connect strategy, product decisions, work, and evidence. It commonly includes the following components:

Product Goal and Hypothesis

State the target user, problem, proposed benefit, and critical assumption. A strong hypothesis is specific enough to test. For example: “Among final-year students living within three kilometres of campus, at least 20% of invited users will place a paid order for a scheduled healthy lunch during a two-week pilot.” The threshold and population should be justified rather than chosen merely to produce a favourable result.

Scope and Backlog

Break the product goal into outcomes, user stories, technical tasks, research tasks, and operational tasks. Include dependencies and acceptance criteria. Separate essential work from experiments that can be postponed.

Schedule and Milestones

An MVP schedule should contain decision points, not only dates. A milestone might be “complete usability test with ten eligible users and decide whether to revise the onboarding flow.” This is more informative than “finish design.”

Resource Allocation

Resources include people, time, money, equipment, data, specialist knowledge, software, and access to users. Allocation should reflect bottlenecks. If user recruitment is the limiting factor, assigning more developers may not accelerate learning. A responsibility matrix can clarify who is responsible, accountable, consulted, and informed for each deliverable.

Quality and Release Criteria

Define what must be tested before exposing users to the MVP. Criteria may include successful completion of the core journey, basic accessibility checks, data protection controls, error handling, backup procedures, and an escalation process for incidents.

6. Risk Management

Startup projects face technical, market, operational, financial, legal, ethical, and team risks. Risk management is not the prediction of every failure. It is the systematic identification and treatment of uncertainties that could affect objectives.

A simple qualitative risk score is:

R is the risk rating, L is likelihood, and I is impact. Both may be scored from 1 to 5 using documented definitions. The product is ordinal, not a probability of loss, unless likelihood has been defined quantitatively. A score of 20 is not automatically “twice as risky” as a score of 10.

A risk register should include:

Risk responses include avoiding the activity, reducing likelihood or impact, transferring responsibility where appropriate, accepting the risk with monitoring, or preparing a contingency. An assumption log should accompany the risk register because assumptions may become risks when they remain untested.

7. Measuring Progress and Learning

A venture needs more than output metrics. Output metrics measure what the team produces, such as completed stories or deployed features. Outcome metrics measure user or business effects, such as successful task completion, repeat use, conversion, retention, cost per transaction, or customer satisfaction. An MVP should also track learning metrics, such as the proportion of tested users who understand the value proposition or the number of critical assumptions supported by evidence.

A metric is useful when its definition, data source, collection frequency, owner, and decision rule are clear. “Improve engagement” is vague. “At least 60% of eligible pilot users complete the core booking flow without assistance” is more actionable, provided that the team defines eligibility, completion, and the test period.

Teams should distinguish vanity metrics from decision metrics. Total page views may look impressive but may not indicate purchase intent. A small number of paid transactions may be more informative than thousands of unqualified visits.

For a conversion rate, the general relationship is:

The denominator must be defined carefully. If 30 of 120 eligible visitors register, the registration conversion rate is (30 ÷ 120) × 100% = 25%. This does not establish causation or guarantee future performance; channel, audience, timing, and sample size matter.

8. Documentation of Internship and Incubation Deliverables

Documentation is part of project execution, not an administrative afterthought. It creates continuity, supports assessment, protects institutional knowledge, and makes claims auditable.

A professional project portfolio may contain:

• project charter and product goal;
• problem and customer research summary;
• prioritized backlog and scope decisions;
• sprint plans, Kanban policies, or work logs;
• prototypes, screenshots, design decisions, and version history;
• test plans, test results, and defect records;
• risk register and issue log;
• budget, resource, and procurement records;
• user feedback and consent documentation;
• KPI definitions and evidence dashboard;
• retrospective findings and change decisions;
• final demonstration, reflection, and recommendations.

Internship documentation should distinguish personal contribution from team output. Students should state what they did, what evidence they produced, what changed as a result, and what limitations affected the work. A weekly report that merely lists meetings is weak; a report linking activities to deliverables and learning is stronger.

Version control and file naming should be consistent. Sensitive customer data should not be placed in uncontrolled personal storage. Access should be limited according to role, and records should be retained only as long as justified by institutional, legal, or business requirements.

9. Ethics, Governance, and Responsible Use of Technology

An MVP does not exempt a venture from ethical or legal duties. Teams should consider informed consent, privacy, accessibility, truthful marketing, intellectual property, consumer protection, cybersecurity, and the possibility of harm to vulnerable users.

Data minimization is a sound principle: collect only data necessary for a defined purpose. Consent should be understandable and voluntary, and users should know whether their data will be used for product research, marketing, or service delivery. Where personal data is processed, applicable data-protection law and institutional policy must be followed.

Artificial intelligence can assist with ideation, coding support, test generation, transcription, analytics, and customer-service prototypes. However, AI-generated material requires human review. Teams must check for fabricated information, biased outputs, insecure code, copyright concerns, disclosure obligations, and unintended exposure of confidential data. An AI tool should not be given private customer records merely for convenience.

Technology choices should be proportionate to the hypothesis. A no-code prototype, manual spreadsheet, or existing platform may be better than building a complex proprietary system before demand and workflow are understood. Conversely, a highly regulated or safety-critical context may require professional engineering, formal testing, and external review even at pilot stage.

10. Illustrative Case: CampusFresh Pilot

Background

CampusFresh is an illustrative student venture proposing scheduled delivery of affordable, healthy meals to university students. The team initially planned a full mobile application with menus, personalized nutrition, digital payments, delivery tracking, ratings, loyalty points, and restaurant integration.

Problem

The team had limited funds and six weeks before the incubation demonstration. Its central uncertainty was not whether a sophisticated application could be built, but whether students would pay for a scheduled meal service and whether local providers could fulfil orders reliably.

Analysis

The team separated assumptions into three categories:

• Customer assumption: Students value predictable, affordable healthy meals.
• Commercial assumption: Some students will pay in advance for a meal slot.
• Operational assumption: A small set of food providers can prepare and deliver orders within the promised time.

The team interviewed students about current meal practices, but it did not treat positive opinions as proof of demand. It then designed a paid pilot in which students selected from a limited menu using a simple web form. Orders were recorded in a shared operations system, and delivery coordination was initially manual.

Approach and Solution

The MVP included only:

1. A clear menu and price list.
2. A web-based order form.
3. Payment through an established provider.
4. Confirmation messages.
5. A defined delivery window.
6. A feedback survey after delivery.

The team excluded personalization, loyalty points, restaurant self-service, and live tracking. It used Kanban with a WIP limit of three items in development. The acceptance criterion for an order was that a customer could select a meal, pay, receive confirmation, and receive the meal within the advertised window.

The pilot’s decision rule was agreed in advance: continue to a second pilot only if at least 25 paid orders were completed, at least 80% arrived within the promised window, and no unresolved safety or payment incident occurred. These thresholds were operational targets, not universal standards.

Outcome

The pilot achieved sufficient paid orders but missed the delivery reliability target because one supplier regularly delivered late. The team therefore learned that demand was plausible but the supplier process was not yet reliable. It did not build the full application. Instead, it revised the operating model, reduced the delivery area, and introduced supplier preparation deadlines before considering further automation.

Learning Points

The case illustrates several principles:

• The MVP tested the most consequential assumptions rather than displaying the largest feature set.
• Manual work can be appropriate when the purpose is operational learning.
• A payment and delivery commitment generated stronger evidence than expressions of interest.
• A pre-agreed decision rule reduced the temptation to reinterpret disappointing results.
• Excluding features was a strategic decision, not evidence of incomplete professionalism.
• Operational reliability and customer value must be evaluated together.

11. Challenges and Limitations

MVP practice has limitations. First, a small or artificial pilot may not represent the broader market. Second, early users may tolerate defects that later customers will not. Third, a short experiment may measure novelty rather than sustainable value. Fourth, teams may over-focus on speed and underinvest in architecture, accessibility, security, or documentation.

There is also a danger of “MVP theatre”: presenting a prototype as a validated business when the underlying evidence is weak. A manual service may demonstrate that a team can perform a task, but it does not automatically demonstrate that the task can be delivered profitably at scale. Similarly, user enthusiasm in interviews may not translate into payment or repeat use.

Agile methods also require judgment. Excessive ceremonies can consume scarce time; inadequate ceremonies can create confusion. A backlog may become a storage place for unexamined ideas. Velocity, task counts, and hours worked should not be used as simple proxies for entrepreneurial value. The most important question remains whether the team is reducing meaningful uncertainty and delivering a responsible user benefit.

Best-Practice Checklist

Before releasing an MVP, the team should be able to answer “yes” to most of the following questions:

• Is the target user and core problem clearly defined?
• Is the central hypothesis explicit and testable?
• Does the MVP provide a coherent user benefit?
• Are essential functional and non-functional requirements documented?
• Are acceptance criteria and a Definition of Done agreed?
• Is the backlog prioritized by value, learning, risk, and effort?
• Are time, skills, budget, and dependencies realistic?
• Are safety, privacy, accessibility, and legal obligations addressed?
• Are risk owners, triggers, and contingencies identified?
• Are success measures and decision rules defined before testing?
• Is user evidence collected ethically and recorded accurately?
• Can another person understand the work from the project documentation?

Chapter Summary

An MVP is the smallest credible product or service that delivers a meaningful user benefit while testing important assumptions. Its purpose is validated learning, not merely low cost or rapid release. Effective MVP execution begins with a clear problem and solution hypothesis, then translates those hypotheses into user stories, acceptance criteria, functional and non-functional requirements, and a prioritized backlog.

Agile execution uses short feedback cycles and transparent work. Scrum organizes work through Sprints, accountabilities, events, and increments, whereas Kanban emphasizes continuous flow, visualization, explicit policies, and WIP limits. Feature prioritization should consider value, learning, urgency, effort, dependencies, and non-negotiable safety or legal requirements. Capacity estimates, milestones, risk registers, metrics, and decision rules help teams use scarce resources responsibly.

Internship and incubation deliverables should document both activities and evidence: what was done, what was learned, what changed, and what remains uncertain. Ethical conduct, privacy, accessibility, security, truthful communication, and appropriate technology choices are essential even in an early MVP. The professional entrepreneur does not merely build quickly; they build deliberately, learn honestly, and execute in a way that creates a defensible foundation for the next decision.

Key Terms

MVP: The smallest credible product or service that delivers user value and enables learning about important assumptions.

Validated learning: Evidence-based learning about whether a product, problem, or business assumption is supported.

Problem hypothesis: A testable belief about a customer, difficulty, context, and consequence.

Solution hypothesis: A testable belief about how a proposed offering will address a problem.

User story: A concise description of a desired capability from a user’s perspective.

Acceptance criteria: Conditions that must be satisfied for a requirement or story to be accepted.

Functional requirement: A required product action or capability.

Non-functional requirement: A required quality or constraint, such as security or accessibility.

Product backlog: An ordered list of product work and improvements.

Sprint: A fixed-length Scrum cycle that produces a usable increment.

Kanban: A flow-based method using visualization, explicit policies, and work-in-progress limits.

Work in progress (WIP): Work that has started but is not yet complete.

Definition of Done: Shared criteria for considering work complete and usable.

Prioritization: The structured ordering of work according to value, risk, effort, or learning.

Risk register: A record of risks, their assessment, responses, owners, and triggers.

Output metric: A measure of activity or produced work.

Outcome metric: A measure of user, operational, or business effect.

Decision rule: A pre-agreed condition that determines a subsequent action.

Technical debt: Future cost created when expedient technical choices require later correction or improvement.

Retrospective: A structured review of how work was performed and how the process can improve.

Review Questions

Short Answer Questions

1. What distinguishes an MVP from a full-featured product?
2. State two differences between Scrum and Kanban.
3. What is the purpose of acceptance criteria?
4. Why should an MVP include non-functional requirements?
5. What information should be recorded in a risk register?

Long Answer Questions

1. Explain how a team can move from a problem hypothesis to a testable MVP. Use an example.
2. Compare Scrum and Kanban and recommend a context in which each would be appropriate.
3. Discuss how value, learning, effort, and risk should influence feature prioritization.
4. Explain why documentation is an important deliverable in an internship or incubation project.
5. Evaluate the ethical and governance issues that should be considered before releasing an MVP.

Analytical / Application Questions

1. A team plans ten features for a six-week MVP but has capacity for only five. Develop a prioritization approach and justify which features should be included or deferred.
2. An online service receives many page visits but very few completed purchases. Identify possible explanations, propose two ethical experiments, and specify the evidence that would guide the next decision.
3. Design a risk register and decision rule for a student venture that intends to pilot a paid delivery service with limited staff and an external payment provider.

Multiple Choice Questions with Answers

Question 1

Which statement best defines a minimum viable product?

A. The product with the greatest number of features at launch

B. The smallest credible offering that delivers user value and generates meaningful learning

C. A prototype used only by the internal development team

D. A product released without testing to save time

Correct Answer: B. The smallest credible offering that delivers user value and generates meaningful learning

Question 2

Which item is an acceptance criterion?

A. The team will hold a meeting on Friday

B. The developer will use a particular programming language

C. The customer can complete payment and receive confirmation

D. The product owner prefers a blue interface

Correct Answer: C. The customer can complete payment and receive confirmation

Question 3

Which practice is most strongly associated with Kanban?

A. Fixed-length Sprints

B. Mandatory four-week releases

C. Work-in-progress limits

D. A requirement that all work be estimated in story points

Correct Answer: C. Work-in-progress limits

Question 4

A team has four members, 20 available hours per member, and 70% availability for planned work. What is the estimated planned capacity?

A. 28 person-hours

B. 40 person-hours

C. 56 person-hours

D. 80 person-hours

Correct Answer: C. 56 person-hours

Question 5

What is the primary purpose of a product backlog?

A. To record employee attendance

B. To provide an ordered list of product work and improvements

C. To replace all customer research

D. To guarantee that every proposed feature will be built

Correct Answer: B. To provide an ordered list of product work and improvements

Question 6

Which is an outcome metric rather than an output metric?

A. Number of meetings held

B. Number of user stories written

C. Number of screens designed

D. Percentage of users completing the core task

Correct Answer: D. Percentage of users completing the core task

Question 7

If 30 of 120 eligible visitors register, what is the registration conversion rate?

A. 4%

B. 20%

C. 25%

D. 40%

Correct Answer: C. 25%

Question 8

Which response is most appropriate when a team identifies that collecting unnecessary personal data could create privacy risk?

A. Collect more data to improve future analysis

B. Minimize collection and restrict access to necessary data

C. Ignore the risk because the product is only an MVP

D. Publish the data so users can verify it

Correct Answer: B. Minimize collection and restrict access to necessary data

Question 9

What is the main value of a pre-agreed decision rule in an MVP pilot?

A. It guarantees positive results

B. It prevents any changes to the product

C. It links observed evidence to a planned next action

D. It eliminates the need for user feedback

Correct Answer: C. It links observed evidence to a planned next action

Question 10

Which statement about prioritization scores is most accurate?

A. They replace managerial and ethical judgment completely

B. They are useful comparison aids when their scales and assumptions are defined

C. They prove that a feature will be profitable

D. They should give legal requirements the lowest priority

Correct Answer: B. They are useful comparison aids when their scales and assumptions are defined