A thread I read recently about development paradigms for new LLM application features sparked some thinking. Here's my take, informed by building my own projects.
1. The Core Problem
The question isn't how to build the feature — it's how to front-load the risk.
- Not understanding user needs well enough to segment the audience or judge what "PMF" looks like.
- Not knowing how to reach users, or knowing the path but not being able to market at an acceptable cost.
- Lacking clarity on where the model's capability boundaries are in specific scenarios.
- Iteration on product development and marketing is overall too slow.
2. The Paradigm
When we hit a problem, should we wait for the model's future capabilities to solve it, or do we have to solve it now through product and engineering? This isn't a binary 0/1 choice — it's a continuous spectrum with enormous gray area.
2.1 Front-load the Risk
The definition of MVP should expand to Minimum Marketable Product: validate that a feature is feasible while simultaneously validating that it can be marketed.
2.2 The Core Validation Pod (CVP)
The CVP should close the loop on R&D, user insight, and marketing capabilities, and deliver a minimal PMF product prototype at an acceptable marketing cost.
2.3 CVP-Driven Development Process
- Product design, prototype scoping.
- CVP pod builds and iterates on product v0.5.
- Once validated, decide whether to continue polishing before full release.
- Other engineering resources join, rebuild according to production requirements.
3. Real-World Organizational Challenges
Staffing
The capabilities a CVP needs are different from the specialized roles most organizations have. It needs breadth — the ability to close the loop independently. A core 2–3 people over a tight time cycle.
Disrupting Existing Development Processes
The CVP essentially consolidates and front-loads risks that were previously scattered across development and marketing. But a CVP team is hard to put on a shared roadmap or performance review cycle with other teams.
Consistency Between Prototype and Production
You need a higher-abstraction platform or DSL that lets both the prototype and production system use exactly the same technical framework, enabling relatively easy migration between the CVP phase and production.