We had a working curve-reading model, three signed letters of intent behind it, and a build team of exactly six. The letters told us plenty about what buyers wanted (that story lives in our companion account of how the three signatures moved the tool to pilot-ready). This piece is about the harder problem that opened the moment the demand was clear: six engineers cannot build everything four different kinds of buyer would pay for, so which features do you build first, and which do you cut. That question, not the model and not the letters, is what this engagement actually turned on.
The constraint was the headcount, not the ideas
Good product ideas were never the scarce resource. The scarce resource was engineer-weeks. The accelerated track behind the model ran six people, and the accelerated track had a window; every capability we bolted onto the product wrapper was a person not spent on the curve extraction that was the whole point. So we could not treat the roadmap as a wish list to be worked through in order of enthusiasm. We had to treat it as a knapsack: a fixed amount of capacity, a pile of candidate features each with a cost and a payoff, and the job of packing the highest total payoff into the space we had.
That reframing changes what a good decision looks like. It is no longer "is this feature worth building," because in isolation almost every feature is. It becomes "is this feature worth building before that one," which is a question you can only answer if every candidate carries a comparable score. Without a score you fall back on whichever feature the loudest person in the room argued for last, and on a six-person team the loudest person is usually right about the feature and wrong about the sequence.
A price gives you a scoring unit
The score we needed had to be denominated in something the business cared about, and we had a natural unit sitting in the plan: the product was priced at 1,200 USD per seat per year. A per-seat price is a gift to a prioritiser, because it converts "how valuable is this feature" into "how much of a seat does this feature unlock," and seats are countable. A feature that a buyer needs before they will let anyone log in is worth close to a full seat. A feature that merely delights an existing seat-holder is worth a fraction of one. Koroteev and Tekic, surveying AI across the upstream, make the point that a tool's value is gated less by its sophistication than by whether it reaches the workflow it is meant to serve.1 For a per-seat product that is almost a definition of seat-value: a feature is worth the seats it makes usable.
Seat-value alone was not enough, because a feature can be valuable to one buyer and irrelevant to the rest, and building for one buyer with a team of six is how a young product quietly becomes bespoke software. So we multiplied seat-value by a second term, the strength of the demand signal: how many of the three independent letters named the feature at all. A feature that all three buyers reached for on their own carries a full-strength signal. One that a single letter demanded, however forcefully, carries a third of it. Seat-value times signal-strength gave every candidate a single priority number, comparable across the whole list, and that number is the spine of the whole exercise.
Reading the ranked list against a hard ceiling
Scoring the features was the easy half. The half that hurt was drawing the ranked list against the capacity we actually had and accepting that a line falls somewhere on it, with real features below the line.
The instrument is that ranked list made honest. Each candidate feature is a row; the teal bar is its priority, seat-value times how many of the three letters signalled for it; the dots show how many letters named it, and the readout at the bar's end is the serviceable seat-value it unlocks. The features sort themselves from most to least worth building. Then the capacity lever imposes the ceiling. Set it to six engineers, the accelerated track's real headcount, and the build window fills from the top down until it is full, and everything past that point is cut. The dashed line is where the money runs out. The first feature beneath it, marked in orange, is the highest-priority thing we did not get to build, which is the single most useful number the exhibit produces, because it names the exact cost of the constraint.
At six engineers the line falls in a place that was not intuitive before we drew it. Curve-to-LAS export, batch runs across an archive, confidence-and-QC review, and per-seat self-serve access sit comfortably above it: each unlocks real seat-value and each was named by two or three of the letters, so each scores high enough to earn its engineer-weeks. Below the line sit the features that were either narrow or expensive or both: an audit-and-lineage trail one buyer needed, on-prem deployment for another, a white-label theme for a third. Drag the lever left toward a leaner team and the build line climbs, and even a genuinely good feature like the API into a buyer's own stack falls below it. Drag it right and the cut features come back one at a time, in priority order, which is exactly the order in which more capacity should buy them.
Before
Build in order of enthusiasm
Every feature looks worth building on its own, so the roadmap gets sequenced by whoever argued last. On-prem and white-label, demanded loudly by the largest buyer, jump the queue and consume the six-engineer window while the shared core waits.
After
Build in order of seat-value x signal
Each feature carries one comparable score. Capacity fills top-down against a six-engineer ceiling; the line falls where it falls. The four features above it capture most of the serviceable seat-value; the rest are cut on purpose, not by accident.
The scoring, not the argument, sets the sequence
What the cut list bought us
The point of the exercise was never the features above the line. Those were going to get built under almost any sane process. The point was the discipline about the features below it. Once a feature is a cut with a named priority score rather than a vague "later," two useful things happen. The team stops half-building it in the margins, and the sales side stops promising it as though it were on the roadmap. On-prem deployment and the white-label theme did not vanish; they were reclassified from roadmap to deal scope, the kind of thing you build for a specific buyer, on that buyer's timeline, staffed and priced as a project rather than smuggled into the product because the buyer who wanted it had the most impressive logo.
There is a market reason the scoring rewards breadth over loudness. The serviceable slice of the software market the plan addressed was about 6.7B USD, a thin fraction of the headline oil-and-gas transactions number.2 A feature only one buyer wants is, almost by construction, scoped to a sliver of an already-thin market, so its seat-value is low no matter how strategically the buyer frames it. Weighting by how broadly the letters shared a demand is just the feature-level expression of building toward the serviceable market rather than the addressable fantasy. The knapsack and the pricing model were telling us the same thing from two directions.
What the method left behind
The lasting artifact of this engagement was not the four features we shipped first. It was the habit of never sequencing a roadmap by argument again. A six-person team has no slack to spend on features it built out of order, and "out of order" is a failure you cannot see without a score, because every feature you build feels like progress even when a higher-priority one was starved to pay for it. Giving every candidate a seat-value-times-signal number, ranking it, and drawing the honest line where six engineers ran out of weeks turned a series of heated meetings into a single legible picture that a founder, a head of sales, and an engineer could all read the same way. The features changed nothing that a competent team would not have reached eventually. The method changed how fast we reached it, and how few features we wasted getting there.
How the six-engineer team sequenced the build
- The binding constraint was engineer-weeks, not ideas. With six engineers on the accelerated track and four kinds of buyer to serve, the roadmap was a knapsack problem: pack the highest total payoff into fixed capacity, which means the real decision was what to build first and what to cut, not what was worth building at all.
- Every candidate feature got one comparable score: seat-value (the share of the 1,200 USD per-seat price it unlocks) times LOI-signal-strength (how many of the three independent letters named it). Ranking by that score and filling capacity top-down put curve-to-LAS export, batch runs, confidence QC and per-seat self-serve above the line, and left audit lineage, on-prem and white-label below it.
- Drawing the capacity line honestly is what the method buys. A cut with a named priority score stops getting half-built in the margins and stops being sold as roadmap; the single-buyer features became deal scope, staffed and priced as projects. The scoring rewards breadth because a one-buyer feature is scoped to a sliver of the 6.7B USD serviceable market, so it scores low however loudly it is argued.
References
Footnotes
-
Koroteev, D. and Tekic, Z. Artificial intelligence in oil and gas upstream: Trends, challenges, and scenarios for the future. Energy and AI, 2021. The framing that a tool's value is gated by whether it reaches the workflow it serves, which for a per-seat product translates into scoring a feature by the seats it unlocks, draws on this survey. https://www.sciencedirect.com/journal/energy-and-ai ↩
-
The three letters of intent, the four buyer types, the 1,200 USD per-seat annual price, the six-engineer accelerated headcount, and the serviceable market framing (about 6.7B USD) are the engagement's own pitch and planning records. The per-feature seat-value weights, the engineer-week cost estimates, and the priority scores in the exhibit are a schematic reconstruction of how the team ranked the work, consistent with the constraints but not a line-item ledger. The buyer identities, the client, and personnel are anonymised under operator confidentiality. The underlying digitisation corpus drew on the public Texas Railroad Commission (Texas RRC) well-log dataset. https://www.rrc.texas.gov/ ↩
