J.R. MullisGovernment business development is the work of finding the offices that already have your problem and the money to solve it, learning how their requirement is written and funded, and being known to those people before anything is competed. It is research and relationships, done on a multi-year calendar. The proposal is the receipt.
- Not outbound email volume, and not conference badges.
- Not proposal writing. Writing executes a decision that BD and capture already made.
- Measured by named offices, funded requirements, and cycle time, not by meetings held.
I spent more than twenty years inside government acquisition, a good stretch of it as an Air Force Contracting Officer. In that time a lot of companies did business development at me. Most of it was not business development. It was a capability brief, delivered at a person who could not buy anything, six weeks before a solicitation that had already been shaped by somebody else.
The companies that were actually good at this were doing something different, and it did not look like selling. It looked like homework.
What the job actually consists of
Strip away the vocabulary and federal business development is four activities, run continuously and in this order of importance.
1. Finding where the money and the problem already sit together
The government publishes an enormous amount about what it intends to buy and when. Budget justification documents describe programs line by line. Program offices post industry days, requests for information, and sources sought notices. Unfunded priority lists say out loud what a service wanted and did not get. SBIR and STTR topics are written by people with a specific problem. Award histories show who has been buying what, from whom, on which vehicle.
Good BD reads all of that and produces a short list: the handful of offices where your technology maps to a problem someone is already funded, or nearly funded, to solve. A long list is a symptom, not an achievement.
2. Translating what you built into what they wrote down
Your commercial pitch does not survive contact with a program office. Not because it is bad, but because it answers a question nobody in the room asked. A government requirement is written in the language of a capability gap, a mission thread, and a performance parameter. If your one-pager talks about a platform, a stack, and a total addressable market, the person reading it has to do the translation themselves. Most of them will not.
The company that gets the meeting is usually not the one with the best technology. It is the one whose description of itself matched the words already in the requirement.
3. Being known before the competition starts
By the time an opportunity is publicly competed, the shape of the answer is generally set. That is not corruption; it is how requirements development works. Someone had a problem, talked to industry to understand what was possible, wrote a requirement reflecting what they learned, and got it funded. Every one of those steps is an opportunity for you to be in the room, lawfully, as one of the companies helping the government understand the art of the possible.
Miss all of them and you are bidding against a requirement written around somebody else’s architecture. You can still win. You are just paying a tax you did not have to pay.
4. Keeping the relationship alive across the calendar
Federal timelines are long, and the length is the part companies underestimate. A requirement can take a year or more to mature into money, and the people involved rotate. Program managers move. Military members change station. A champion who was excited about you in March may be somewhere else in October, and the person replacing them has never heard of you.
Real BD builds a relationship with the office, not just with a person, and it survives the turnover.
The companies I remembered were the ones who followed up after a meeting with something useful and asked for nothing. A two-page technical note answering a question we raised. A pointer to another company’s work that was relevant. They were building an account with us, and it worked, because when the requirement finally got written I already knew what they could do.
What government business development is not
It is worth being blunt about the three things that get sold as BD and are not.
It is not outreach volume. Cold email into a government inbox has a poor return, and high volume actively hurts you, because the federal community is small and word travels. One good conversation with the office that owns the requirement is worth several hundred sends.
It is not proposal writing. Proposals are execution. By the time you are writing, the decisions that determine the outcome have already been made: whether to bid, what to emphasize, who to team with, and how to price. A firm whose only product is writing is selling you the last four weeks of a twelve-month job.
It is not access. Be careful with anyone selling relationships as the product. Access without a mapped requirement and a funding line is a coffee meeting. The useful version of a relationship is knowing which office has the problem, what stage their requirement is at, and what they need from you next. That is knowledge, and it is checkable.
How to tell whether yours is working
Most companies measure federal BD with commercial instruments and get a distorted reading. Meetings held is not a metric; the government takes a lot of meetings. Proposals submitted is not a metric either, and a high number can be a warning sign.
Here is what we watch instead.
| Signal | What it tells you | Warning sign |
|---|---|---|
| Named funded offices in the pipeline | You are working real demand, not a list | Pipeline full of solicitations nobody has a relationship behind |
| Requirement stage per opportunity | You know how early you got there | Everything enters the pipeline at the solicitation stage |
| Repeat contact with the same office | You are building an account | New logos every month, no second meetings |
| Bid decisions declined | Somebody is qualifying | You bid everything you find |
| Time from first contact to first award | Your real cycle time, for planning | Nobody has measured it |
The last one matters more than it looks. A company that knows its own federal cycle time can plan runway, brief a board honestly, and decide whether to keep going. A company that does not is guessing, and usually guessing optimistically.
The uncomfortable version
If you have no federal past performance, no office that has told you they have the problem, and no funding line you can name, then a proposal is not your bottleneck and buying one will not help. That is a BD problem, and the fix takes two to four quarters of unglamorous work: reading budget documents, getting to the right offices, and giving them a reason to remember you.
We say that to companies fairly often, including when saying it costs us the engagement. It is the same advice I would have given from the other side of the table, and it was true then too.