Search⌘ K
AI Features
Home
Courses
Forward Deployed Engineer for AI Systems

Scoping the MVP

Define the smallest end-to-end workflow that meets all explicit requirements within the available time. Plan backward from the handoff deadline, build a walking skeleton that validates the end-to-end workflow, and reduce optional scope when implementation takes longer than planned while preserving time for testing, documentation, and handoff.

We'll cover the following...

Supplier API integration has exceeded its estimated time by 30 minutes. Completing the required report functionality will take an estimated 15 more minutes. You also allocated 30 minutes to building a chart. Should you keep the optional chart and reduce the time allocated to recording and final verification, or remove the chart from scope?

First, review the fictional assignment to identify the requirements that must be completed within the time limit:

  • Build a local reorder report for a stock coordinator using inventory.csv and the supplied live supplier API.

  • The report should list every item whose stock is strictly below its reorder point, along with its supplier contact. Missing contacts and unusable input must look clearly different from successful results.

  • Submit focused checks, a documented way to run the tool with one command, a README, and a recorded walkthrough of no more than three minutes.

  • You have a maximum of 240 minutes of active work. API credentials and documentation are provided. Hosting, login, and charts are not required.

Defining the MVP

The minimum viable product (MVP) is the smallest usable workflow that satisfies the required acceptance criteria within the constraints. Calling a submission an MVP does not authorize removing explicit obligations.

Protect the connected customer workflow and the evidence needed to inspect and run it; spend optional scope when implementation overruns.

For this assignment, completion means CSV input through live enrichment to an inspectable reorder report, followed by the requested verification and handoff. Use these supplied records:

  • P10: Stock 2, reorder point 5, supplier S1

  • P11: Stock 5, reorder point 5, supplier S2

  • P12: Stock 0, reorder point 3, supplier S3

The supplied API test account contains S1 with contact purchasing@example.test and no contact for S3. Its paginated responses must be traversed to establish the lookup results.

The expected completed report includes P10 with its contact and P12 with an explicit unresolved-contact status. P11 is excluded because 5 < 5 is false. An unreadable CSV produces a clear failure rather than a success report. These are planned expected results, not executed software or live-call results.

Building a walking skeleton

A local command is enough: Read the CSV, select qualifying rows, enrich their supplier IDs through the live API, and write a readable report. Nothing in the brief requires a browser interface.

A walking skeleton is a thin, executable path from input to visible ...