Contract Archaeology: Finding the Product in Your Services

Read one contract you have delivered three times before you try to see the pattern.

The first pass is for scope: what you promised, what you left out, where the option years sat. The second is for money: the CLINs, the rate table, the travel line you always underprice. The third is for the question a delivery lead asked you that you could not answer. Why does almost every engagement start with the same two weeks of data collection?

You did not have a good answer. You had a habit.

The product was in the repetition. You had been reading the contract for scope.

Starting with an idea fails at the sale

In my own work, the attempts that failed started with an idea and went looking for evidence afterward.

You name the thing. You build a demo. You show it to a friendly program office and come back with a feature list. That list feels like traction. It is not. It was generated by a demo, not by a buyer.

In this market the failure happens in a specific place. The demo is easy. The sale is not. Three questions go unanswered, and each gets more expensive the later you answer it: who signs, what the product refuses to do, and what it needs before it can touch real data.

So the service absorbs the product. The first interested customer asks for a change. The change is billable. Later you have a project with a login screen and a roadmap you cannot keep.

The reverse direction is less flattering and much cheaper. You read what you already delivered. The customer's own paperwork tells you what repeats. An idea is a hypothesis. A contract is evidence.

Four shapes to dig for in your own contracts

Pull the last three contracts you delivered. Cover the customer names. Read for what is identical.

You are not looking for scope. You are looking for the thing you did three times without noticing.

A repeated deliverable

Start with the CDRL list in the attachments, the contract's own inventory of what you owe. If the same artifact shows up in three contracts under three names, you have a candidate. The monthly status report that becomes a program health summary that becomes a performance dashboard is one deliverable wearing three covers. The names change. The work does not.

A repeated data assembly

Before anyone analyzes anything, someone collects. Three systems, the same fields, the same crosswalk. The analysis changes every engagement. The assembly does not. It is where the hours go, and the most codifiable part of the work. If you have rebuilt the same spreadsheet from the same three exports, you have already done the archaeology. You did it again instead of writing it down.

A repeated workflow

Same steps, same order, same decision points. Intake, gap check, evidence request, review, sign-off. If two delivery leads run it the same way without comparing notes, the workflow is real. Write down the steps and the two or three decision points. Those are the spine of a product, because they are where a buyer's trust either holds or breaks.

A repeated decision

The hardest to see and the most valuable. A judgment you make the same way every time. Is this control satisfied? Is this document in scope? Is this risk material? If you can write the rules down, you have logic, and logic can be encoded. If you cannot, you have a service, and the service is you. That is a fine business. It is not a product, and no amount of software will make it one.

The four shapes are not equal. A repeated decision is worth more than a repeated deliverable, because a deliverable can be copied and a decision has to be trusted. Start where the evidence is strongest.

Score it before you build it

A shortlist is not a decision. Score two or three candidates on five criteria, 1 to 5, for a maximum of 25.

The score is not a forecast. It ranks the candidates you already have, before any of them costs you a build.

Criterion	A 5 looks like	A 1 looks like
Repeatability	A new hire could deliver it from the documentation without calling you.	Every engagement is custom.
Buyer	You can name the person, the budget line, and the paper that reaches them.	The buyer is "the government," which is not a person.
Boundary	One sentence, no "and," and three refusals written before the first request.	The scope is whatever the last customer asked for.
Codifiable	The rules are written and a junior person can apply them.	The output depends on taste you cannot explain.
Compliance surface	No system of record, no authorization path of its own, and a scope that can avoid controlled data.	The product needs its own authorization before the first sale.

Two columns are closer to pass/fail than the others. A 1 or a 2 on boundary or compliance surface will not be rescued by a 5 on repeatability. The first product has to survive its own scope.

Here is an illustrative row: a solicitation compliance matrix scored 21 out of 25 against an agency buyer — repeatability 5, buyer 2, boundary 4, codifiable 5, compliance surface 5. The 2 is the decision. Scored against a capture manager at another services firm, the same candidate is nameable, reachable, and needs no vehicle. Same product. Different buyer. Different score. Name the buyer before you score.

The five criteria above are the short version I run first, because you can answer them from your own delivery record. The book uses six dimensions: repeatability, cross-agency demand, compliance leverage, vehicle access, ATO feasibility, and economic viability. The full score is in Part 2 of Shrink-Wrap It.

The boundary test

A boundary is real only when you have said no inside it and kept the customer.

You can score a 4 on boundary and still lose, because the boundary lives in your head and not in the document the customer signs. Three tests.

One sentence, no "and." Say what the product is. If the sentence needs a second clause, you have not decided.

Three refusals, written before the first request. Name the adjacent work you will not do. If you cannot name three, the product is still a category.

The re-entry test. Can someone else deliver it without you in the room? If not, the boundary is fiction and the product is a job with your name on it.

The refusals matter most in the first option year, when the adjacent request arrives. If the boundary cannot appear in a CLIN, a task order scope, or the order form the customer signs, it will not survive a friendly customer. A boundary on a slide is a preference.

None of this tells you whether anyone wants the product. The boundary test tells you whether the thing can hold its shape. Demand is a different test, and this exercise does not run it.

What to do with the winner

Do not start with code. Start with four pages.

The boundary sentence and the three refusals.
The repeat list: what stays identical across customers.
The evidence list: what the product has to show for a buyer to trust an output. Source, date, who approved it.
The first-sale path: who signs, on what paper, and what has to be true before they can. That is a vehicle and authorization question before it is a product question; what an IDIQ actually gives you is the place to start.

Then deliver it by hand once. Not a demo. The real artifact, for one buyer, with you doing the work behind the curtain. You are testing whether the boundary holds when a real person asks for the adjacent thing. If it holds, automate it. If it does not, you saved yourself the build.

That is Architect, the second of HARBOR's six stages. It is a writing exercise before it is a building one. The framework is at harborgovcon.com/framework.

This exercise chooses the candidate. The book decides whether it can be sold: vehicle, ATO path, unit economics. The full score is in Part 2 of Shrink-Wrap It: /book.

The Bottom Line

The product is not in your head. It is in the contracts you already delivered: the deliverable you produced three times, the assembly you rebuild every engagement, the sequence your leads run without comparing notes, the judgment you make the same way every time.

Read the paperwork for repetition, score what repeats, and do not build until the boundary holds in one sentence.

What I cannot tell you is that this produces a product that sells. The book sets a validation rule for the method, and no product of mine has met it yet. I am not going to dress that up. Treat the score as a way to choose, not a promise. The choosing is still the cheapest part.

Read one contract you have delivered three times before you try to see the pattern.

You did not have a good answer. You had a habit.

The product was in the repetition. You had been reading the contract for scope.

Starting with an idea fails at the sale

In my own work, the attempts that failed started with an idea and went looking for evidence afterward.

You name the thing. You build a demo. You show it to a friendly program office and come back with a feature list. That list feels like traction. It is not. It was generated by a demo, not by a buyer.

So the service absorbs the product. The first interested customer asks for a change. The change is billable. Later you have a project with a login screen and a roadmap you cannot keep.

The reverse direction is less flattering and much cheaper. You read what you already delivered. The customer's own paperwork tells you what repeats. An idea is a hypothesis. A contract is evidence.

Four shapes to dig for in your own contracts

Pull the last three contracts you delivered. Cover the customer names. Read for what is identical.

You are not looking for scope. You are looking for the thing you did three times without noticing.

A repeated deliverable

A repeated data assembly

A repeated workflow

A repeated decision

Score it before you build it

A shortlist is not a decision. Score two or three candidates on five criteria, 1 to 5, for a maximum of 25.

The score is not a forecast. It ranks the candidates you already have, before any of them costs you a build.

Criterion	A 5 looks like	A 1 looks like
Repeatability	A new hire could deliver it from the documentation without calling you.	Every engagement is custom.
Buyer	You can name the person, the budget line, and the paper that reaches them.	The buyer is "the government," which is not a person.
Boundary	One sentence, no "and," and three refusals written before the first request.	The scope is whatever the last customer asked for.
Codifiable	The rules are written and a junior person can apply them.	The output depends on taste you cannot explain.
Compliance surface	No system of record, no authorization path of its own, and a scope that can avoid controlled data.	The product needs its own authorization before the first sale.

Two columns are closer to pass/fail than the others. A 1 or a 2 on boundary or compliance surface will not be rescued by a 5 on repeatability. The first product has to survive its own scope.

The boundary test

A boundary is real only when you have said no inside it and kept the customer.

You can score a 4 on boundary and still lose, because the boundary lives in your head and not in the document the customer signs. Three tests.

One sentence, no "and." Say what the product is. If the sentence needs a second clause, you have not decided.

Three refusals, written before the first request. Name the adjacent work you will not do. If you cannot name three, the product is still a category.

The re-entry test. Can someone else deliver it without you in the room? If not, the boundary is fiction and the product is a job with your name on it.

None of this tells you whether anyone wants the product. The boundary test tells you whether the thing can hold its shape. Demand is a different test, and this exercise does not run it.

What to do with the winner

Do not start with code. Start with four pages.

The boundary sentence and the three refusals.
The repeat list: what stays identical across customers.
The evidence list: what the product has to show for a buyer to trust an output. Source, date, who approved it.
The first-sale path: who signs, on what paper, and what has to be true before they can. That is a vehicle and authorization question before it is a product question; what an IDIQ actually gives you is the place to start.

That is Architect, the second of HARBOR's six stages. It is a writing exercise before it is a building one. The framework is at harborgovcon.com/framework.

This exercise chooses the candidate. The book decides whether it can be sold: vehicle, ATO path, unit economics. The full score is in Part 2 of Shrink-Wrap It: /book.

The Bottom Line

Read the paperwork for repetition, score what repeats, and do not build until the boundary holds in one sentence.