R&D, Product and Service Development

Introduction and Context

Research and development (R&D), product development, and service development are the mechanisms through which entrepreneurial ideas become offerings that create value for customers and capture value for the venture. An idea is not automatically an innovation. It becomes an innovation when knowledge, technology, design, and organizational capability are combined to produce a solution that is adopted and generates meaningful value.

For entrepreneurs, development is both a creative and a disciplined activity. Creativity is needed to identify opportunities and generate alternatives; discipline is needed to test assumptions, control risk, manage resources, comply with standards, and deliver a reliable offering. Development decisions are made under uncertainty. Customers may not yet understand their own needs, technologies may not perform as expected, and competitors or regulations may change during the project.

This chapter presents an integrated approach to managing development from concept to launch. It combines stage-gate governance, agile and lean startup practices, prototyping, minimum viable products (MVPs), systems engineering, testing, quality management, and cross-functional teamwork. These approaches are complementary rather than mutually exclusive. A medical-device venture, for example, may use agile design iterations within a formal stage-gate process because regulatory approval requires documented evidence and controlled changes.

Learning Objectives

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

1. Explain the purpose and scope of R&D, product development, and service development.
2. Distinguish discovery, development, validation, launch, and post-launch learning.
3. Apply stage-gate, agile, lean startup, and design-thinking practices appropriately.
4. Design useful prototypes and MVPs that test explicit assumptions.
5. Translate customer needs into technical and service requirements.
6. Explain systems engineering, verification, validation, quality, and risk management.
7. Evaluate development performance using suitable measures.
8. Organize effective cross-functional development teams.
9. Analyze ethical, regulatory, sustainability, and intellectual-property implications.

1. The Development System

1.1 R&D, product development, and service development

R&D consists of systematic work intended to create or improve knowledge, technologies, materials, processes, products, or services. It commonly includes:

• Basic research, which seeks understanding without an immediate commercial application.
• Applied research, which investigates knowledge for a defined practical purpose.
• Experimental development, which uses existing knowledge to create or substantially improve products, services, processes, or systems.

Product development converts an opportunity and a set of requirements into a physical or digital product that can be manufactured, distributed, used, supported, and eventually retired. Service development creates a customer experience and an operating system involving people, processes, information, facilities, and technology. A software platform, for example, is technically a product but may be experienced as a continuing service.

A development project therefore includes more than design. It may involve market research, intellectual-property analysis, engineering, user experience, sourcing, operations, cybersecurity, finance, legal review, training, distribution, and after-sales support.

1.2 The development funnel

The development funnel narrows a broad set of possibilities into a small number of validated opportunities. Typical activities are:

1. Opportunity discovery: identify a customer problem, unmet need, technological possibility, or regulatory change.
2. Concept generation: create alternative solutions rather than committing prematurely to one idea.
3. Concept screening: assess strategic fit, customer value, feasibility, risk, and commercial potential.
4. Concept definition: specify the target customer, use case, value proposition, business model, and initial requirements.
5. Feasibility and validation: test critical technical, behavioral, operational, and economic assumptions.
6. Development: build the offering and the system required to deliver it.
7. Launch preparation: establish production or service operations, distribution, support, training, compliance, and communication.
8. Launch and learning: release the offering, monitor evidence, correct defects, and decide whether to scale, modify, or stop.

The funnel is not purely linear. Evidence may cause a team to return to an earlier stage, redefine the customer, or abandon the concept. A disciplined project treats stopping as a rational outcome when expected value no longer justifies further investment.

1.3 Uncertainty and risk

Development contains several types of uncertainty:

• Desirability uncertainty: whether customers experience the problem and value the proposed solution.
• Feasibility uncertainty: whether the technology can meet required performance, cost, safety, and reliability.
• Viability uncertainty: whether the venture can earn sufficient revenue or strategic benefit.
• Usability uncertainty: whether users can understand and use the offering effectively.
• Operational uncertainty: whether the organization can produce, deliver, maintain, and scale it.
• Regulatory and social uncertainty: whether the offering meets legal, ethical, environmental, and social expectations.

An assumption should be expressed in a testable form. For example: “At least 40% of target users will complete the onboarding process without assistance” is more useful than “Users will like the interface.” The first statement identifies a population, behavior, and threshold.

A simple expected-value model can help prioritize experiments:

Here, EV is the expected value of conducting an experiment, P(S) is the estimated probability that the experiment produces a useful result, V(S) is the value of that result, and C is the cost of the experiment. The model assumes that value and cost can be expressed in comparable units and is a decision aid rather than a precise forecast. It is especially useful when comparing a cheap, informative test with an expensive commitment.

2. Governance Through Stage-Gate

Stage-gate is a governance model in which development work is divided into stages separated by decision points called gates. Each stage produces evidence; each gate determines whether the project should continue, be redirected, delayed, or stopped.

A typical structure is:

A gate is not merely a presentation. It is a decision with explicit criteria, a responsible decision authority, and documented assumptions. Common gate decisions are go, conditional go, hold, redirect, and kill.

2.1 Benefits and limitations

Stage-gate provides portfolio visibility, resource discipline, accountability, and early risk reduction. It is particularly valuable when projects require substantial capital, involve safety or regulatory obligations, or depend on coordinated supply and operations.

However, a rigid stage-gate process can create bureaucracy, delay learning, and encourage teams to defend a predetermined plan. It may also reward polished documents rather than truthful evidence. The remedy is not to eliminate governance but to make gates evidence-based and proportional to risk. Early gates should emphasize learning and inexpensive experiments; later gates should require stronger technical, financial, and compliance evidence.

2.2 Gate criteria

Useful criteria include:

• Customer problem importance and evidence of willingness to adopt or pay.
• Strategic fit and differentiation.
• Technical feasibility and maturity.
• Total cost and expected contribution.
• Resource requirements and organizational capability.
• Intellectual-property position.
• Safety, privacy, cybersecurity, environmental, and regulatory risk.
• Scalability of production, delivery, and support.
• Quality and reliability evidence.

Criteria should be defined before the evidence is reviewed. Otherwise, teams may change standards to justify a favored project.

3. Agile, Lean Startup, and Design Thinking

3.1 Agile development

Agile approaches manage uncertainty through short iterations, frequent feedback, visible work, and adaptive planning. A cross-functional team selects a limited amount of work for an iteration, produces a usable increment, reviews evidence, and reprioritizes the backlog.

Agile is not synonymous with “no planning.” Effective agile development includes a product vision, architecture or service blueprint, prioritized outcomes, quality standards, risk controls, and a clear definition of done. Agile is most effective when the team can obtain rapid feedback and when requirements are expected to evolve.

3.2 Lean startup

Lean startup practice emphasizes validated learning. The venture identifies a risky assumption, builds the smallest test capable of examining it, measures actual behavior, and decides whether to persevere, pivot, or stop. The build–measure–learn cycle is valuable because it reduces investment before evidence of desirability and viability exists.

An MVP is not simply a cheap or incomplete version of a product. It is the minimum credible offering or experiment that tests a central business hypothesis with real or representative users. An MVP may be a manual service behind a simple interface, a landing page measuring qualified interest, a prototype used in interviews, or a restricted pilot. It must be ethical: users should not be misled about safety, capability, privacy, or the experimental nature of the offering.

3.3 Design thinking

Design thinking commonly combines empathic inquiry, problem framing, idea generation, prototyping, and testing. Its contribution is to prevent teams from defining a solution before understanding the user’s context. Observation and interviews reveal latent needs, workarounds, emotional factors, and constraints that may not appear in conventional surveys.

The methods differ in emphasis:

A capable entrepreneur combines these approaches according to uncertainty, risk, and reversibility.

4. From Customer Need to Requirements

A customer statement such as “the device should be easy to use” is meaningful but insufficient for engineering or service operations. Requirements translate needs into observable outcomes.

A good requirement is specific, necessary, feasible, verifiable, unambiguous, and traceable to a stakeholder need. For example, “A first-time user shall complete account creation in no more than three minutes using a mobile connection of at least 10 Mb/s” is testable, although its target and conditions must be justified.

Requirements may be classified as:

• Functional: what the system must do.
• Performance: how well it must do it, such as speed, accuracy, capacity, or range.
• Interface: how components, users, or external systems interact.
• Reliability and maintainability: expected availability, failure behavior, repair time, and serviceability.
• Safety and security: hazards, access controls, data protection, and resilience.
• Regulatory and environmental: mandatory standards, emissions, accessibility, or disposal requirements.
• Business and service: cost, delivery time, staffing, training, and support requirements.

Requirements should be prioritized. The MoSCoW method classifies them as must have, should have, could have, and will not have for this release. Prioritization prevents the scope from expanding without an explicit trade-off.

5. Systems Engineering and Architecture

Systems engineering manages the relationships among components, users, processes, and external environments. It is essential when a product or service has interacting hardware, software, people, data, and operating processes.

A systems approach generally includes:

1. Define stakeholders, context, mission, and lifecycle.
2. Elicit and prioritize requirements.
3. Decompose the system into subsystems and interfaces.
4. Allocate requirements to components.
5. Design the architecture and identify trade-offs.
6. Integrate components progressively.
7. Verify and validate the complete system.
8. Manage configuration, changes, risks, and lifecycle support.

Architecture decisions should consider performance, cost, modularity, interoperability, cybersecurity, maintainability, manufacturability, and future change. A modular architecture can allow one component to be upgraded without redesigning the entire system, but interfaces must be clearly specified and tested.

A traceability matrix links stakeholder needs to requirements, design elements, tests, and evidence. It reduces the risk that a requirement is forgotten or that an unneeded feature consumes resources. Traceability is particularly important in regulated industries.

6. Prototyping and Experimentation

A prototype is a representation of a proposed product, service, interface, process, or system used to learn. Prototypes vary in fidelity:

• Low-fidelity: sketches, storyboards, paper interfaces, role play, or cardboard models.
• Medium-fidelity: clickable mock-ups, 3D-printed parts, simulated dashboards, or pilot service scripts.
• High-fidelity: functional engineering prototypes, production-representative units, or live software builds.

The appropriate prototype is the cheapest one that can answer the current question credibly. A high-fidelity prototype is unnecessary when the uncertainty concerns the basic desirability of a concept. Conversely, a visual mock-up cannot establish the thermal safety of a battery system.

Each experiment should specify:

• The assumption or question.
• The target users or test conditions.
• The prototype and procedure.
• The evidence to collect.
• The decision rule.
• The owner, time limit, and cost.

For example, a team testing a delivery service might recruit 20 target users, provide a manually coordinated service for two weeks, and measure repeat use, completion time, complaints, and willingness to pay. The experiment should distinguish genuine demand from interest created by incentives or novelty.

6.1 Quantitative measures

Useful development measures include conversion rate, task completion, defect rate, cycle time, retention, reliability, and cost. A basic conversion rate is:

The numerator and denominator must refer to the same period, population, and definition of an opportunity. If 80 of 400 qualified visitors complete registration, the conversion rate is 20%.

For a service, first-contact resolution may be calculated as:

These measures describe observed performance; they do not by themselves establish causation. A higher conversion rate may result from a seasonal campaign rather than a better product.

7. Testing, Verification, and Validation

Verification asks, “Did we build the product or service according to its specified requirements?” Validation asks, “Did we build the right product or service for the intended users and context?” A system can pass verification and still fail validation if its requirements were wrong.

Testing may include:

• Unit or component testing.
• Integration testing.
• System testing.
• Performance and load testing.
• Usability and accessibility testing.
• Safety and environmental testing.
• Security and privacy testing.
• Pilot or beta testing.
• Acceptance testing with customers or operators.
• Regression testing after changes.

A test specification should identify the requirement, method, equipment or environment, sample or test article, acceptance criterion, responsible person, and record of results. Test conditions must be representative enough to support the decision. A software product tested only on a developer’s device has not been adequately validated for a diverse customer base.

Reliability is the probability that an item performs its required function for a specified time under stated conditions. It is not identical to quality: quality concerns conformance and fitness at a point or period, while reliability concerns continued performance over time.

If failures are assumed to occur at a constant rate, a simple exponential reliability model is:

Here, R(t) is reliability over time t, λ is a constant failure rate per unit of time, and e is the base of natural logarithms. The assumption of a constant failure rate is often unrealistic during early-life and wear-out periods, so this model should not be used without checking its applicability. If λ = 0.001 failures per hour and t = 100 hours, then R(t) = e^(−0.1) ≈ 0.905, or about 90.5%.

8. Quality Management and Risk Control

Quality management is the coordinated system through which an organization directs and controls quality. It includes customer requirements, process control, supplier quality, inspection, corrective action, and continual improvement.

Important practices include:

• Define quality characteristics and acceptance criteria early.
• Prevent defects through robust design rather than relying only on final inspection.
• Use controlled specifications, versions, and change records.
• Analyze root causes rather than treating symptoms.
• Monitor suppliers and outsourced development.
• Capture customer complaints and feed them into improvement.
• Establish escalation and corrective-action procedures.

Failure mode and effects analysis (FMEA) is a structured method for identifying potential failures, their effects, causes, controls, and recommended actions. Traditional scoring often considers severity, occurrence, and detectability. Scores should support discussion, not create false precision; a low numerical score does not make a catastrophic hazard acceptable.

Risk controls should follow a hierarchy: eliminate the hazard where possible, reduce it through design, add protective measures, provide warnings and training, and monitor residual risk. Safety-critical decisions require competent review and applicable standards or regulatory approval.

9. Cross-Functional Teams and Development Leadership

Development is most effective when people with different expertise collaborate from the beginning. A typical team may include entrepreneurship or product management, customer research, engineering, design, operations, finance, marketing, sales, legal, quality, cybersecurity, and customer support.

Cross-functional teams reduce handoff delays and reveal conflicts early. They also create coordination challenges. Team members may use different terminology, have competing objectives, or protect functional interests. Effective leadership establishes a shared outcome, decision rights, communication routines, and evidence-based conflict resolution.

Useful team practices include:

• A clear product vision and measurable outcome.
• A single, prioritized backlog or requirements baseline.
• Named owners for decisions and risks.
• Short review cycles and visible evidence.
• Psychological safety for reporting bad news.
• Design reviews at appropriate points.
• Retrospectives that improve the development process.
• Explicit escalation for safety, legal, or ethical concerns.

The product manager or venture leader integrates customer value, technology, economics, and organizational capacity. This role should not suppress specialist judgment. A quality engineer must be able to stop a release when evidence indicates unacceptable risk, regardless of commercial pressure.

10. Economics and Portfolio Decisions

R&D portfolios balance exploratory projects, incremental improvements, and major innovations. A project may be strategically important even if near-term financial returns are uncertain, but the organization should make the uncertainty visible.

A basic net present value model is:

Here, CF_t is the net cash flow at time t, r is the discount rate per period, and n is the final period. The model assumes cash flows and the discount rate are estimated consistently and that timing is defined. NPV is useful for comparable investment decisions but can undervalue strategic learning, option value, social benefits, or highly uncertain projects.

Development cost should not be confused with sunk cost. Money already spent cannot be recovered and should not justify continuing a weak project. Future costs and future benefits are relevant to the decision. Portfolio reviews should consider strategic fit, risk-adjusted potential, resource constraints, dependencies, and learning value.

11. Launch and Post-Launch Management

A technically complete product is not launch-ready unless the organization can deliver the promised experience. Launch readiness may require:

• Stable production or service capacity.
• Qualified suppliers and documented processes.
• Pricing, contracts, billing, and distribution.
• Customer support, training, and knowledge bases.
• Security, privacy, accessibility, and regulatory controls.
• Monitoring, incident response, and rollback procedures.
• Communication that accurately represents capabilities and limitations.

A launch should be treated as a controlled learning event. Early-release metrics may include activation, adoption, retention, defects, support contacts, refund rate, service-level performance, customer satisfaction, contribution margin, and safety incidents. Teams should define thresholds that trigger correction, withdrawal, or escalation.

For digital services, release management may use feature flags, staged rollouts, automated monitoring, and rollback. For physical products, it may use pilot production, controlled distribution, field-service feedback, and corrective-action notices. In both cases, post-launch learning should update requirements and future portfolio choices.

12. Ethics, Regulation, Sustainability, and Intellectual Property

Development decisions can affect people who are not direct customers. Ethical analysis should consider safety, fairness, accessibility, privacy, labor conditions, environmental impact, and the possibility of misuse. AI-enabled products require additional attention to data provenance, bias, explainability appropriate to the context, human oversight, security, and responsibility when automated recommendations cause harm.

Regulatory requirements differ by sector and jurisdiction. Entrepreneurs should identify applicable obligations early rather than treating compliance as a final document exercise. Examples include product safety, consumer protection, medical or financial regulation, data protection, accessibility, employment law, environmental rules, and cybersecurity requirements.

Intellectual-property strategy may include patents, trademarks, copyright, trade secrets, design rights, contracts, and freedom-to-operate analysis. A patent may protect a qualifying invention but can disclose technical information and requires time and cost. A trade secret may be valuable only while confidentiality is maintained. Entrepreneurs should document ownership and confidentiality when working with employees, universities, contractors, and partners.

Sustainability requires lifecycle thinking. Decisions about materials, energy, repairability, packaging, logistics, software infrastructure, and end-of-life treatment may create impacts beyond the point of sale. A low-cost design that is difficult to repair or creates avoidable waste may generate hidden social and economic costs.

13. Illustrative Case: Developing a Smart Cold-Chain Service

Background

This illustrative case concerns FreshRoute, a fictional venture proposing a monitoring service for small food distributors. The service combines low-cost temperature sensors, a mobile application, and an alert-support service. The target customers lose revenue when food becomes unsafe or unsellable, but they have limited technical staff.

Problem and initial assumptions

The founding team assumed that distributors would purchase sensors immediately because temperature loss was costly. Interviews revealed a more complex problem: owners wanted prevention, but drivers and warehouse staff feared that alerts would be used to punish them. Customers also required simple installation, reliable connectivity, and evidence suitable for insurance or regulatory discussions.

The team documented four critical assumptions:

1. Managers would pay for a service that reduced spoilage.
2. Staff could install and maintain the sensor without specialist support.
3. Alerts would be accurate enough to avoid excessive false alarms.
4. The venture could provide support at a sustainable cost.

Analysis and approach

The team first built a low-fidelity service blueprint showing sensor placement, data transmission, alert review, staff response, and customer reporting. It then conducted a manual pilot with eight distributors. Sensors were installed by the venture team, and alerts were reviewed by a human operator before being sent to customers. This MVP tested willingness to use the service and the operational workflow without prematurely building a complete automated platform.

A cross-functional team defined requirements. Examples included a maximum installation time, battery-life target, alert escalation procedure, data-retention policy, and a requirement that users could acknowledge an alert with one tap. Engineering created a functional prototype, while operations tested installation and replacement procedures.

The project used stage-gate governance. At the first gate, interview evidence supported the problem but not the original assumption about immediate sensor purchases. The concept was redirected toward a managed monitoring subscription. At the development gate, the team required evidence from a pilot under representative temperatures and connectivity conditions. At the launch gate, it required customer-support capacity, documented calibration procedures, privacy terms, and a process for investigating missed alerts.

Outcome

The pilot showed strong interest among distributors but identified two unacceptable issues: connectivity failures in certain storage areas and alert fatigue caused by poorly calibrated thresholds. The team added offline data storage, redesigned escalation rules, and introduced a short onboarding program. It delayed a larger launch until missed-alert performance and support costs met predefined thresholds.

Learning points

The case illustrates that an MVP is a learning instrument, not merely a small product. It also shows why technical performance, user behavior, service operations, and economics must be tested together. The strongest opportunity was not the sensor alone but the integrated service of monitoring, interpretation, response, and evidence. Finally, governance improved the project when gates enabled redirection rather than simply approving predetermined plans.

Challenges and Limitations

No development method eliminates uncertainty. Customer interviews can produce polite but unreliable statements; observed behavior can be distorted by incentives; prototypes may not represent production performance; and early metrics may favor short-term engagement over long-term value. Agile iterations can accumulate technical debt, while stage-gate reviews can become ceremonial. Lean experiments can overlook safety and inclusion if teams focus only on speed. Systems engineering can become document-heavy when traceability is applied without judgment.

Managers should therefore match method intensity to risk and reversibility. A low-risk digital feature may be released experimentally, whereas a safety-critical product requires formal evidence, independent review, configuration control, and regulatory compliance. Quantitative metrics should be interpreted with qualitative evidence and professional judgment. Most importantly, teams should reward truthful learning, including evidence that a concept should be changed or stopped.

Best-Practice Checklist

Before committing substantial resources, a venture should be able to answer:

• What important customer problem is being addressed?
• Which assumptions are most uncertain and consequential?
• What is the cheapest credible test for each assumption?
• What requirements define success, and how will they be verified?
• Who owns each decision, risk, and interface?
• How will safety, privacy, security, accessibility, and sustainability be addressed?
• What evidence is required at each gate?
• How will production, delivery, support, and compliance work at scale?
• What conditions would cause the team to pivot, pause, or stop?
• How will post-launch evidence improve the next decision?

Chapter Summary

R&D and development convert knowledge and opportunities into products, services, and systems that customers can use and organizations can deliver. Effective development balances creativity with disciplined learning, engineering, economics, quality, and governance. The development funnel moves from opportunity discovery through concept definition, validation, development, launch, and post-launch improvement.

Stage-gate provides decision discipline, while agile supports iterative delivery, lean startup tests critical assumptions, and design thinking improves understanding of user problems. Prototypes and MVPs should be designed around explicit learning objectives. Requirements translate needs into verifiable outcomes; systems engineering manages architecture, interfaces, traceability, and lifecycle concerns. Verification confirms conformance to specifications, whereas validation confirms fitness for user needs.

Quality management, risk analysis, testing, and cross-functional collaboration are essential to dependable outcomes. Development decisions must also address financial viability, intellectual property, regulation, ethics, sustainability, privacy, cybersecurity, and responsible use of AI. The most capable entrepreneurial teams do not follow one method mechanically. They combine methods in proportion to uncertainty, risk, and the speed at which credible evidence can be obtained.

Key Terms

R&D: Systematic work to create or improve knowledge, technologies, products, services, or processes.

Applied research: Research directed toward a practical purpose.

Experimental development: Use of existing knowledge to create or improve an offering or process.

Development funnel: A process that narrows many opportunities into validated offerings.

Stage-gate: A governance process dividing development into stages separated by evidence-based decisions.

Agile development: Iterative development using short cycles, feedback, adaptation, and incremental delivery.

Lean startup: An approach based on testing assumptions through build–measure–learn cycles.

Minimum viable product (MVP): The smallest credible offering or experiment that tests a central hypothesis.

Prototype: A representation used to learn about a product, service, process, or system.

Requirement: A necessary and verifiable statement of what a system or offering must achieve.

Systems engineering: An interdisciplinary approach to managing system requirements, architecture, integration, and lifecycle performance.

Verification: Demonstration that specified requirements have been met.

Validation: Demonstration that the offering satisfies intended user and contextual needs.

Reliability: The probability that an item performs its required function for a specified time and condition.

Quality management: Coordinated activities for directing and controlling quality.

FMEA: A structured method for analyzing potential failure modes, effects, causes, and controls.

Cross-functional team: A team combining expertise from multiple organizational functions.

Traceability: The ability to link needs, requirements, designs, tests, and evidence.

Technical debt: Future cost or risk created by expedient technical decisions.

Product–market fit: The condition in which a defined market repeatedly adopts and values an offering.

Review Questions

Short Answer Questions

1. What is the difference between verification and validation?
2. Why is an MVP an experiment rather than simply an incomplete product?
3. Identify three types of uncertainty in development.
4. What is the purpose of a stage-gate review?
5. Why are cross-functional teams important in product and service development?

Long Answer Questions

1. Explain how stage-gate, agile, lean startup, and design thinking can be combined in one development project.
2. Discuss the process of translating customer needs into requirements and explain why traceability matters.
3. Explain the role of systems engineering in a product containing hardware, software, people, and operational processes.
4. Discuss the relationship between quality management, testing, reliability, and risk control.
5. Evaluate the ethical, regulatory, sustainability, and intellectual-property issues that an entrepreneur should consider before launch.

Analytical / Application Questions

1. A startup has strong evidence of customer interest but has not demonstrated technical reliability or scalable delivery. Design a sequence of experiments and stage-gate criteria for the next six months.
2. Develop an MVP for a digital service used by small retailers. State the key assumptions, prototype, measures, decision rules, and ethical safeguards.
3. A project team wants to launch despite repeated usability failures because a competitor is entering the market. Analyze the decision using customer value, quality, risk, governance, and long-term strategic considerations.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a stage-gate process?

A. A process that eliminates the need for customer research

B. A governance process using evidence-based decisions between development stages

C. A method that requires every feature to be completed before testing

D. A financial model used only after product launch

Correct Answer: B. A governance process using evidence-based decisions between development stages

Question 2

What is the primary purpose of a minimum viable product?

A. To maximize the number of features at launch

B. To produce the cheapest possible version regardless of quality

C. To test a central hypothesis with the smallest credible offering or experiment

D. To replace all regulatory and safety testing

Correct Answer: C. To test a central hypothesis with the smallest credible offering or experiment

Question 3

Which question is primarily addressed by validation?

A. Did the product meet its documented specifications?

B. Was the project completed within the approved budget?

C. Did the team use an agile framework?

D. Did the offering solve the intended user problem in its context?

Correct Answer: D. Did the offering solve the intended user problem in its context?

Question 4

If 80 of 400 eligible visitors complete registration, what is the conversion rate?

A. 5%

B. 20%

C. 40%

D. 80%

Correct Answer: B. 20%

Question 5

Which requirement is most directly verifiable?

A. The application shall feel modern

B. The service shall be highly attractive

C. A first-time user shall complete onboarding within three minutes under specified conditions

D. The product shall delight every customer

Correct Answer: C. A first-time user shall complete onboarding within three minutes under specified conditions

Question 6

What is the main purpose of systems engineering?

A. To manage relationships among requirements, components, interfaces, and lifecycle performance

B. To ensure that marketing operates independently from engineering

C. To replace all prototypes with documentation

D. To focus only on the appearance of a product

Correct Answer: A. To manage relationships among requirements, components, interfaces, and lifecycle performance

Question 7

In the reliability expression R(t) = e^(−λt), what does λ represent under the stated model?

A. The operating time

B. The probability of customer adoption

C. The constant failure rate per unit of time

D. The number of tested components

Correct Answer: C. The constant failure rate per unit of time

Question 8

Which practice is most consistent with lean startup?

A. Building the complete product before contacting users

B. Testing a critical assumption, measuring behavior, and deciding whether to persevere or pivot

C. Treating all original requirements as permanent

D. Using only employee opinions as evidence

Correct Answer: B. Testing a critical assumption, measuring behavior, and deciding whether to persevere or pivot

Question 9

Why is a cross-functional development team valuable?

A. It prevents specialists from reviewing one another’s work

B. It combines perspectives needed to address customer, technical, operational, financial, and compliance issues

C. It guarantees that a project cannot fail

D. It removes the need for decision rights

Correct Answer: B. It combines perspectives needed to address customer, technical, operational, financial, and compliance issues

Question 10

Which statement about an MVP is correct?

A. It may be a manually delivered service if that credibly tests the business hypothesis

B. It must always be a fully automated software product

C. It should conceal important limitations from users

D. It is useful only after regulatory approval

Correct Answer: A. It may be a manually delivered service if that credibly tests the business hypothesis