ai · lean-startup · mvp
By Shayan Ghasemnezhad3min read
Build-Measure-Learn was designed for web products. AI changes the feedback loop, the MVP definition, and the cost of experimentation.
The Lean Startup methodology—Build-Measure-Learn, minimum viable products, validated learning—shaped a generation of software companies. Its core insight remains sound: reduce the cycle time between hypothesis and evidence. But AI-native products break several of the framework’s assumptions, and teams that apply Lean Startup without adaptation end up optimising for the wrong things.
The fundamental principle—validate demand before scaling supply—is timeless. Before building an AI feature, confirm that users have the problem you are solving and that they value a solution enough to change behaviour. This can be tested with mockups, Wizard of Oz prototypes (human behind the curtain), or simple rule-based systems before investing in model development.
Customer development interviews, concierge MVPs, and landing page tests are as relevant for AI products as for traditional software. The question “Would you use this?” still precedes “Can we build this?”
The MVP concept breaks when the minimum viable version of an AI feature is indistinguishable from a bad product. A recommendation engine that gives mediocre suggestions does not validate the hypothesis that users want recommendations—it validates that users abandon features that do not work well. AI quality has a threshold below which the feature is worse than not having it.
The feedback loop also changes. Traditional MVPs get fast, clear signal: users click or they do not, they convert or they bounce. AI features produce ambiguous signal. Did the user accept the AI’s suggestion because it was good, or because they did not know enough to evaluate it? Did they reject it because it was wrong, or because the presentation was confusing? Measuring AI feature success requires intentional instrumentation, not just funnel analytics.
Redefine the MVP for AI products as the Minimum Trustworthy Product. The bar is not “does it work?” but “does it work well enough that users trust it to inform decisions?” This means the first version may need higher quality than a traditional MVP, but can have a narrower scope. Constrain the domain rather than the quality.
An AI that summarises meeting notes with 95% accuracy for 15-minute standups is more valuable than one that handles all meeting types at 70% accuracy. Narrow the scope, raise the quality bar, and expand the domain as confidence grows.
Build: Prototype with off-the-shelf models and prompt engineering before training custom models. The fastest path to learning is the one that requires the least infrastructure. If a GPT-4 prompt can approximate the feature, ship that and learn from usage before investing in fine-tuning.
Measure: Define quality metrics before launch, not after. Set up A/B testing infrastructure that compares AI-assisted workflows against non-AI baselines. Measure task completion time, error rate, and user confidence—not just engagement.
agentic-ai · ai
AI agents degrade silently. The observability stack and eval framework that catches drift before users do.
Learn: Instrument for failure analysis. When the AI produces a wrong answer, you need to know why: was the input ambiguous, the context insufficient, or the model inadequate? Feedback loops that only capture “right or wrong” do not generate actionable learning.
The most common failure: building the model before validating the workflow. Teams invest months in training a custom model for a feature that users do not adopt—not because the model was wrong, but because the feature did not fit into the user’s existing workflow. Validate the workflow first.
The second failure: measuring AI engagement instead of AI impact. High usage of an AI feature is not evidence of value if the feature creates work rather than removing it. Measure whether the AI feature makes the user’s job faster, more accurate, or less stressful—not just whether they click on it.
Lean Startup is not dead—it needs a firmware update. Keep the scientific method. Adjust the definition of viable, the measurement strategy, and the learning infrastructure for systems that are probabilistic by design.
