Scoping a v1 from build-along videos instead of a feature list
The recordings show you the whole job, including the steps nobody documents and the ones no competitor bothered to solve.
The short answer: scope your first release from the steps that appear in every recording of the job, and cut everything that appears in fewer than half of them. Ten to fifteen build-along or workflow videos is normally enough for the step sequence to stabilise and for the boundary to draw itself.
Most v1 scopes are assembled by looking at an incumbent, listing what it does, and deciding which subset to copy. That produces a smaller version of somebody else’s product rather than a complete answer to a job, and it inherits every questionable decision the incumbent made without ever surfacing why they made it.
Scope from the job, not from the product
A feature list is a compressed artefact: it is what survived one team’s roadmap, budget and internal politics. The recordings are uncompressed. Someone sits down, does the work start to finish, and narrates every step, including the ones they perform outside any product at all.
Those out-of-product steps are the interesting part. When a workflow pauses so the person can open a spreadsheet, check a reference table, or message a colleague, the software they are demonstrating has stopped being sufficient. That gap is either your v1 or a deliberate exclusion, and either way it should be a decision rather than an oversight.
| Observed pattern | Reading | v1 decision |
|---|---|---|
| Step appears in every source | Load-bearing | In scope |
| Step appears in half, skippers get worse results | Load-bearing but not obvious | In scope, with a default |
| Step appears in half, skippers are fine | Preference, not requirement | Defer |
| Step performed outside any tool | Unsolved middle | Strongest v1 candidate |
| Step only at large scale | Future problem | Out of scope, note it |
The fourth row is where new products come from. It is also where extracting SaaS ideas from YouTube content and scoping meet: the same unsolved middle that justified the idea is usually the thing the first release must do exceptionally well, and everything around it can be thin.
Order carries information too
Watch for sequence, not just presence. If every source performs step C before step B despite the tooling suggesting otherwise, there is a reason — usually that B is expensive to redo, so people front-load the thing that might invalidate it. Copying that ordering into your product is close to free and reads as competence.
Sequence also exposes irreversibility, which is the property that determines how much confirmation an interface needs. Steps people visibly hesitate before, or repeat carefully, are the ones that are hard to undo. Those deserve a preview or a dry run; the rest do not, and spraying confirmations across everything is how software gets tedious.
- ✗Copy the incumbent's menu, minus a few items
- ✗Every step gets equal engineering weight
- ✗Scale features built before there is scale
- ✗The manual workaround never gets noticed
- ✓Steps ranked by how often they recur
- ✓Depth on the unsolved middle, thin elsewhere
- ✓Deferred list written down, with the reason
- ✓Ordering and irreversibility copied from reality
Vendor demos and sponsored walkthroughs show a happy path assembled to finish inside ten minutes. They are useful for interface conventions and almost worthless for scoping, because the messy inputs, the retries, and the awkward hand-offs have all been removed in advance. Weight independent build-alongs far above them.
Finding the hard part early
Every job has one step that carries most of the technical risk, and it is usually visible as the moment the recording slows down or the narrator starts explaining rather than doing. Identifying it before the estimate happens is the single highest-value output of this pass.
It changes the shape of the plan. A scope with a known hard part gets sequenced so the risk is tested in week one rather than discovered in week six, and it lets you ask the right question when picking tooling — which is where scoping hands off to choosing a tech stack from practitioner videos. The stack decision is much easier when you already know which single capability it has to be good at.
Turning the map into something buildable
A scope map is not a spec. It becomes one when each in-scope step gets an input, an output, and a note about what “done” looks like — all of which the recordings supply if you were watching for them. Written that way, the map is directly usable as the context file for a coding agent, which is the workflow in turning research notes into a coding-agent spec.
Keep the deferred list in the same document as the in-scope list, with the evidence for each deferral. Scope arguments recur every few weeks once building starts, and a line that says “two of fifteen sources did this, both at enterprise scale” ends the conversation faster than an opinion does. That is the same evidence habit as prioritising features with research evidence.
When two scopes both look reasonable
Sometimes the corpus supports two coherent boundaries — a narrow tool that nails the unsolved middle, and a broader one that owns the whole sequence. Both can be defensible, and the recordings will not choose for you.
What they will do is tell you the cost of each: how many steps the broader version has to get right, and how many other tools the narrow version has to sit politely beside. That is enough to run the comparison properly rather than by instinct, in the way described in choosing between two SaaS ideas.
Scope the inputs, not just the steps
A step map describes what happens; it does not describe what the job starts with. That second question is where scopes quietly double in size, because real inputs are messier than the ones a team imagines while planning: files exported from three different systems, spreadsheets with merged header rows, data that is nearly but not quite consistent.
Build-alongs show this plainly, because the presenter has to open the real file on camera. Watch for the moment before the work starts — the cleaning, the renaming, the deleting of a stray column — and decide deliberately whether your v1 accepts that mess or requires it to be tidied first.
Both answers are defensible and they are very different products. Requiring clean input keeps the build small and pushes work back onto the user; absorbing the mess is expensive engineering that often turns out to be the actual value. What is not defensible is discovering the question during your first customer trial.
Deciding what “good enough” means
Every in-scope step needs a quality bar, and the corpus sets it more honestly than the team will. Watch how carefully people check the output of each step: the ones they scrutinise are the ones where errors are expensive, and those need to be right rather than fast.
The steps nobody checks are equally informative. Where practitioners glance at a result and move on, approximate is acceptable, and building precision there is effort spent on something no user will ever notice. Recording that judgement next to each step turns the scope map into something an engineer can price, because “done” stops being a matter of taste.
What the pass costs
Ten to fifteen build-alongs, watched for steps rather than for opinions, is a day of focused work and produces a boundary you can defend in a planning meeting. As of August 2026 that fits the $19 a month plan with 25 videos and 2 projects; $59 covers 80 videos and 8 projects, and $199 covers 250 videos, 20 projects and 3 seats. Full detail is on the pricing page.
Turn a dozen build-alongs into a step map that separates load-bearing work from optional extras, with the source moment attached to every call. 7-day free trial.
Closing thought
The most expensive thing in a first release is not the feature you got wrong. It is the feature you built carefully because a competitor had it, for a step that half your market performs in a spreadsheet and does not mind.
Frequently asked
How can videos help me scope a v1?
Build-along and workflow videos show the whole job end to end, including the parts nobody writes down. Watching several of them tells you which steps are genuinely load-bearing and which are optional extras you can leave out of a first release without breaking the outcome.
What is a load-bearing step?
One that appears in every recording of the job and that the outcome fails without. If eight of ten sources perform a step and the two that skip it end up with a worse result, that step is in your v1. Anything performed by one person once is not.
Does this give me an engineering estimate?
No. It gives you a scope boundary, which is the input an estimate needs. It tells you what has to exist for the job to complete, in what order, and where the hard parts sit — but hours still come from the people who will write the code.
How do I avoid copying a competitor's feature list?
Scope from the job, not from a product. A feature list is one team's answer to the job; the recordings show the job itself, including the parts that team chose not to solve. Those gaps are usually more interesting than the overlap.
What should I deliberately leave out of a first release?
Anything that appears in fewer than half the sources, anything only needed at a scale you will not reach for a year, and anything the workflow currently handles acceptably outside software — a spreadsheet that nobody complains about is not a v1 problem.
How many build-alongs do I need to watch?
Ten to fifteen for an unfamiliar job. You are looking for the step sequence to stabilise; once three consecutive sources add nothing new to the map, the scope boundary is as sharp as the corpus will make it.
What does this research pass cost?
As of August 2026 plans run $19 a month for 25 videos and 2 projects, $59 for 80 videos and 8 projects, and $199 for 250 videos, 20 projects and 3 seats. Scoping one v1 usually takes ten to fifteen sources and fits the entry tier.