You want to build a feature. Before you write a line of production code you are betting on a stack of assumptions about desirability, viability, feasibility, and usability. That has not changed. What changed is how fast you can test them. The old model designed a separate experiment per assumption over four to eight weeks. The new model builds one prototype that tests the riskiest ones at once, in three to five days.
Map the assumptions first
Skipping the map and jumping straight to prototyping is a common mistake. Spend 20 minutes with your team. Write down every assumption for 10 minutes, do not filter. Then spend 10 minutes finding the killers. For each one, ask: if this is false, does the whole project fail?
Red kills the project. For an AI job recommendation system, that is "freelancers want personalized recommendations" and "recommendations increase apply rate." Yellow is important but solvable, like "we can build an accurate engine." Green is nice to have. Then design the prototype to test the red assumptions, not to showcase the solution.
The prototype is the experiment
When a freelancer uses your recommendation prototype and says "I would not use this, I prefer browsing everything," you just tested desirability and it failed. When they immediately apply to three jobs, desirability and usability passed. For feasibility, use real data so obviously wrong matches expose a shaky technical approach. For viability, get a proxy: "if this existed, would it change how often you apply?"
The one-week cycle
- Monday: map assumptions in the morning, build the prototype in the afternoon using AI coding tools, two to three hours, functional not polished.
- Tuesday and Wednesday: show it to five customers using the prototype interview format. Watch them use it. If you cannot get five live calls, do three live and two async.
- Thursday: synthesize. For each red assumption, what did you learn? If ambiguous, iterate and test two or three more Friday.
- Friday: decide. Green, build it and use the prototype as the spec. Yellow, iterate and test again. Red, kill it or pivot back to the opportunity.
The kill decision is the hard part
Testing was never the hard part. Acting on the results is. When a test fails, most PMs rationalize: the sample was too small, the prototype was not polished. Do not. I killed a recommendation project at Smartcat after showing personalized jobs to eight new freelancers. Two engaged, six went back to search. They wanted to see all their options, not a curated set. We killed it, pivoted in a week to better search filters and a browse-all view, shipped in three weeks, and activation improved 28 percent. The kill saved eight weeks. In the old model we would have wasted 12.
This week, write down the top three assumptions your project sits on, build a working prototype that tests the riskiest one today, show it to three customers tomorrow, and decide by Friday.