The requirements-list trap.
A buyer hands a young product a long list of requirements, and the team starts building to it. That feels like demand. It is usually the opposite: a buyer who never decided what they want, and a vendor who just stopped being one.
The list that feels like a win
I have been on the receiving end of the list. A big customer takes interest, then sends one: twenty, forty, sometimes a hundred requirements, neatly numbered, and the message underneath is that when it does all of these, we will talk. It feels like the deal getting real. It is where a young product quietly loses, and I lost it too.
Because I read the list as demand, and I started building. One sprint became three. The roadmap bent around one customer. And somewhere in there I stopped being a vendor with a price and became an unpaid engineering team working off someone else’s backlog, calling it traction the whole way down.
What the list actually is
A long requirements list usually isn’t a spec. It is a symptom. The buyer often hasn’t locked their own use case, so they cannot tell you the one outcome they need. “Send us everything” is what a buyer asks for when they have not yet decided what they want. It shifts the risk onto you: now you have to guess which of the hundred items is the real one, and build all of them to be safe.
You are not behind on features. The buyer is behind on a decision, and the list is how that shows up on your desk.
Build to the list, become internal IT
Build to the list and the price goes with it. A vendor sells one outcome for a price. An internal IT team delivers against a backlog, forever, and gets measured on completeness, not outcome. The minute you accept the list as the brief, you have agreed to the second job. The deal stops being “is this worth the money” and becomes “is item 47 done yet.” And the economics follow the role. A vendor holds a price because it sells an outcome. An internal team is a cost to be trimmed, measured on whether the backlog shrank, never bought again for something bigger. You win the deal and lose the margin.
Internal IT is just the version of this you hit with a requirements list. The same move, the buyer’s frame deciding what you are, can make you a service layer, a pilot that never ends, a feature in someone else’s product, or a line in procurement. Anything but a vendor with a price. What decides which one is a single question: who owns the outcome.
What to do instead
Treat the list as the start of a conversation, not the terms of one. Name the one job your product does now, in the buyer’s own words, and tie the price to that. The list does not vanish; it gets sorted into “this is the job” and “this is everything else, later.” You sell the job. You scope the rest. You stay a vendor.
The honest version is uncomfortable: it means telling a keen buyer that you will not build forty things, and trusting that the one that matters is enough to win. It usually is. The buyer was never going to fall in love with item 47.
Where this is too clean
Sometimes the list is real. A regulated buyer in pharma or finance has genuine must-haves, and “we only do one job” will lose you the room. The move there is not to ignore the list; it is to separate the few items that are truly gating from the many that are wishful, and to sit the gating ones on top of one named job, not in place of it. The trap is not having requirements. The trap is letting the list decide what you are.
The quieter signal, in your inbox.
Notes and pieces on what actually moves ventures, from the work. No noise, no schedule for its own sake. Leave any time.