First Viable Product Iteration Loop
Launch a viable first version, then iterate it into a durable product
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 96%
The First Viable Product Iteration Loop uses AI-enabled development speed to reach genuine user feedback sooner without pretending that the first build is complete. The team creates a minimal version that performs the central job, puts it in front of actual users, studies how they respond, and feeds those observations into the next build. Each cycle should improve usefulness, reliability, and fit with user expectations. The mechanism is speed multiplied by repeated validation: faster building creates more opportunities to learn, while disciplined iteration converts those lessons into a stronger product. The framework distinguishes a viable starting point from a scalable, polished product and preserves the product judgment, user understanding, and sustained obsession that automation cannot replace.
Origin
Anton Osika described this approach while explaining how Lovable compresses initial development from months to weeks without eliminating the need for product iteration. Extracted from Marketing Against The Grain.
Core principles
- 01Treat the first release as a learning vehicle, not a finished product
- 02Use faster development to shorten the feedback cycle
- 03Let real users reveal what the product must become
- 04Expect quality to require many rounds of iteration
How to run it
- 1
Define the first viable outcome
Identify the smallest real outcome the product must deliver for a user. Scope the first build around that outcome rather than a complete feature vision.
Pro tip Choose an outcome that can be observed in real use.
Watch out Do not reduce the scope so far that the release cannot produce meaningful feedback.
- 2
Build at accelerated speed
Use AI development tools to turn the defined outcome into working software quickly. Avoid polishing assumptions that users have not validated.
Pro tip Spend saved development time on additional learning cycles.
Watch out Fast generation does not guarantee sound architecture or reliable behavior.
- 3
Release to real users
Put the viable version into the hands of people with the target problem. Observe behavior rather than relying only on stated preferences.
Pro tip Recruit users who would genuinely benefit if the product worked.
Watch out Friendly reactions from non-target users can create false confidence.
- 4
Extract the strongest signal
Identify where users gain value, become confused, abandon the flow, or request repeated improvements. Select the learning with the greatest effect on product quality.
Pro tip Prioritize repeated behavioral signals over isolated feature requests.
Watch out Do not let a loud individual substitute for a representative pattern.
- 5
Iterate toward product quality
Implement the highest-value improvement and repeat the release-and-learning cycle. Continue until the product meets users' rising expectations at the required scale.
Pro tip Track whether each iteration improves a defined user outcome.
Watch out Do not mistake a functioning prototype for a scalable product.
In the wild
A McKinsey contact had previously spent six months obtaining the first version of a business tool. Using Lovable, the team produced its initial version in three weeks, creating an opportunity to begin validation and iteration substantially earlier.
→ The organization shortened the path to a usable first version from six months to three weeks.
Kieran used Lovable and supporting tools to build a roughly 30,000-line creative writing application. The initial product provides inspirational material that users develop further, giving him a functioning foundation to test before wider release.
→ A marketer without an active software-engineering career created real software that could proceed into user validation.
Common mistakes
Calling the prototype finished
A quickly generated build may demonstrate the idea without meeting the reliability, usability, and scalability expected of a mature product.
Iterating without user evidence
More versions do not create progress when changes are driven only by internal opinions rather than observed user needs.
Is it for you?
Best for
It is best for founders and internal teams that can build quickly but still need evidence about what users value.
Not ideal for
It is not ideal for safety-critical releases that require extensive validation before any real-world use.
From the transcript
“And like the first version I referred to often as like the first viable product. But if you iterate enough, I think we're going to…”
“Um I think that building a really good product is still going to need a lot of obsession, understanding of your users, and a lot…”
“Now they did it in three weeks with Lovable.”
From the episode
The Startup Letting 99% of People Build Apps Without Code