From Zero to Program of Record in the New Acquisition System

Photo by Markus Kammermann on Unsplash

Over the 20 to 30 meetings I had with early-stage companies and founders, I repeatedly received the same question: “How do we actually get to a program of record, and how fast can we do it?”

Honestly, that answer has changed over the last year and a half, and much of the advice floating around still assumes the old, antiquated system. JCIDS is gone; SBIRs just returned after a six-month lapse with new rules. OTAs and Commercial Solutions Openings (CSOs) are now the Department’s default path, and for good reason. Here’s my take; feel free to argue, but this is what worked for us, and how we brought in over 246 startups in under 18 months in the department and fielded.

TLDR: Over the last 18 months, the DoW transformed to create a faster path to a Program of record and lower the barrier to entry for new entrants in the market. As a result, money and decision-making moved from program to portfolios, and requirements now tend to follow the demo instead of the other way around. As a founder, your job is to find the person who owns a portfolio and the person who owns the operational requirements, solve a real problem for them in front of real operators, and let the paperwork catch up to what you’ve already proved. In this article, I will cover how to do that, who to spend your time with, and where I see founders burn the most months.

What Actually Changed (and What Didn’t)

I have noticed that when Founders hear “acquisition reform,” they assume everything changes overnight, and sure, some of it does. But the biggest piece is requirements. In August 2025, the Department announced it was terminating JCIDS. In the past, we used the JCIDS process to validate a requirement before funding could begin. Now, a new senior board has been formed to tie requirements more directly to funding. Alongside that, the Secretary reorganized program executive officers into Portfolio Acquisition Executives, or PAEs, who are the single accountable official for a portfolio’s outcomes and can act without months of approval chains. Said another way, one person can now say yes to a whole class of capability instead of a requirements document doing the work.

We also moved on the contracting side. In the FY26 NDAA, we revised 10 U.S.C. § 3458 so the government can award a production OTA directly from a CSO. This let us skip the prototype step and no longer limited CSOs to only “innovative” solutions. If the CSO was openly competed, the government can also award a sole-source follow-on production contract. After that, we also decided to reset the SBIR program, allowing it to lapse on September 30, 2025, then brought it back and reauthorized it on April 13, 2026, through 2031, with a new Strategic Breakthrough award of up to $30 million. The department collectively has now provided for more foreign-risk screening and per-firm proposal caps starting in FY2027.

The money did not change, and the PPBE is still alive. For FY27, we still have a request that follows the traditional PPBE process: justification books, congressional markup, and appropriations. That said, reform is underway, but a program of record still needs a funded line. If you take one thing from this post, take that. Additionally, you will still need to test, cyber, and sustainment, and treat that as a gate, too. The policy direction is to streamline T&E and allow component substitutions without full requalification, but you still need an authority to operate and a plan for who maintains it.

The pitfall is hearing “JCIDS is gone and OTAs are the default” and concluding the old rules about funding and fielding went away with them, they did not. I meet founders who think a good demo plus an OTA award ends the story, and they find out at the budget line that is not the case. Much of this is still being implemented and varies by service, so treat this post as a map and confirm the specifics with the office you are actually selling to.

SBIR: A Way In, Not a Business Model

I have gone back and forth on this, but I believe SBIR is still one of the best ways to get your first government relationship, and I tell founders to take advantage of it. The money is non-dilutive, the process is familiar, and a Phase I or II gives a program office a low-risk way to try you out. The question is what you are buying with it. I think of SBIR as a way to purchase access and evidence. Meaning getting access to a technical sponsor and evidence that your technology works on their problem.

That changes how you pick topics. Topics are often written with a customer in mind, so talk to the topic author or technical point of contact before you write a word. If you cannot name the person who wants the outcome, skip the topic. It also changes how you plan a Phase II. Plan it to end with a customer ready to co-fund or sponsor what comes next, and when you have earned it, look at the new Strategic Breakthrough award, which targets companies with a real transition story. Ask your contracting officer early how Phase III would work for you, because SBIR-derived work can be eligible for sole-source follow-on awards, and most founders never ask.

There are two additional housekeeping points I want to touch on. First, SBIR eligibility still depends on ownership, control, and affiliation, and the new law adds more foreign-risk screening, so do that diligence on your cap table now rather than in the middle of an award. Second, DoW’s BAA has moved to a monthly rolling cycle, which means you can build a pipeline instead of racing one annual deadline. With proposal caps coming in FY2027, a pipeline of well-aimed bids beats a pile of scattershot ones. The latter was created to make it very industry-friendly and shorten the sales cycles for venture backed/commerical companies who are used to building a pipeline and not spraying, praying and hoping.

The pitfall is building the whole go-to-market around SBIR awards. I still see companies stack Phase I and IIs with no customer, no budget line, and no path to production, until they get really good at writing proposals and not much else. My rule of thumb is that if an SBIR does not get you closer to a specific buyer within 12 months, it is a distraction, however nice the check is. Don’t fall into the SBIR Mil trap! There is a whole article I will write about the balance between SBIRs, OTAs and production contracts don’t worry.

Requirements: Find the Problem Owner, Not the Document

For years, the standard advice was to find the requirement. Find the ICD, find the CDD, find the document that says the government has to buy something like you. That advice is getting old, and with JCIDS gone, the better move is to find the problem owner, the person in a portfolio on the hook for an outcome who doesn’t yet have a good way to get there.

Start with the PAE or the equivalent portfolio lead for your mission area. Their scorecard focuses on speed from validated need to fielding, so showing up with something that already works does them a favor. Your first conversation should be a diagnosis, not a pitch. Get a specific operational problem with a number attached (detect this at this range within this time), then hand it back to them as a one-page problem statement in their words. If they edit and adopt it, you have helped write your own requirement.

Once that happens, ask the money question out loud (i.e., “which budget line would pay for this, and when is that line decided?”). Remember, a requirement without a funded line is still a wish. For the love of god, don’t skip the unglamorous work. This includes Cyber authorization, safety, and test approvals, which can quietly add a year, so start them while the prototype is still a prototype. Solving simple, boring problems first will save you a headache later.

The pitfall is waiting. Some founders sit around waiting for the new version of the requirements document to show up, and it may not arrive as they expect. Even when it does, someone will probably write it after watching a capability work. Don’t wait for the paperwork. Make it easy for someone to write it.

OTAs and CSOs: Faster Doesn’t Mean Easier

The DoW has decided to use the OTA process much more often than before. OTAs are the hot path right now, and for good reason. They move faster than a traditional contract, and they carry fewer of the usual obligations. Additionally, since the NDAA changed, a CSO can lead straight to a production OTA. But speed only helps if the agreement ends with someone who has money, so most of the work is choosing which agreements to pursue. If you. can’t find a production home (i.e., a service or program office) for your contract, you are not headed down the right path. Always find the production partner when going down this route.

Read the solicitation like a lawyer before you bid. A prototype can move to follow-on production without further competition if the prototype was competitively awarded and the solicitation said follow-on was possible. A Navy industry-day briefing is direct about this. If the call does not say it, think hard about whether the prototype is worth your engineering time. Also confirm whether you qualify as a nontraditional defense contractor, since that status often means no cost-share and more flexibility, and do it with counsel before you build your pricing around it. Prototype OT terms vary, and what you agree to on data rights can follow you into production, so have a government contracts attorney read the whole thing. I am not one, and you should not take contract advice from a blog post, including this one.

Consortia are the other piece of the OTA method. An OTA consortium connects startups and dual-use companies to prototype opportunities, and a successful prototype can transition directly into a production OT. Use them for access, not for demand. Join the ones that match a portfolio you are already working on, and keep at least two ways into your target customer, because one reorg or one lapsed agreement can close the only door you have.

The pitfall is treating “OTA” like a magic word. I see founders respond to whatever call shows up, win a prototype, and then discover nobody planned for production. Or they pay to join a consortium and wait for work to arrive. Neither works because the vehicle isn’t the customer.

Who You Talk To: GCCs, Services, and OSW

These three groups do very different jobs, and mixing them up is how founders waste time and effort. The Geographic Combatant Commands (GCCs) and their components tell operators what they need. They do this in various ways: integrated priority lists, urgent needs statements, and lessons learned from exercises. The services own the programs, budget lines, and contracting authority, and a PAE or portfolio lead sits with the labs and warfare centers behind them. The Office of the Secretary of War (OSW) sets policy and runs the cross-cutting offices and vehicles (DIU, R&E, A&S, CAPE, the Comptroller), and it can break a logjam when a need crosses services.

So my rule is that the GCC tells you what matters, the service pays for it, and OSW removes obstacles. For a rough split of your time once you are past the first few months, I would spend about half of it with the service side (the PAE, the program office, the lab or warfare center), about 30 percent with the GCCs and their components, and 15 to 20 percent with OSW. Adjust that for your technology. GCC time buys you a real problem statement, access to operators, and a seat at the table in exercises, but not a budget line. The OSW time buys policy cover, cross-service vehicles, and sometimes bridge funding, but not day-to-day program ownership. If you are meeting all three about the same problem and they know you are talking to each other, you are in a strong spot.

The pitfall is spending most of your relationship time with whoever is most enthusiastic, which is usually a combatant command or a component staff. They love the demo. They write a nice letter. Then nothing gets bought because the GCCs generate demand but don’t hold the money.

From a GCC Need to a Funded Program

Here is the sequence I coach founders through. It is not the only way, but it is what I see work most often:

Start with the GCC problem, in writing. Sit with the Directors of the command (i.e., for Joint it’s J1-J8), or component staff and get the operational problem stated with a metric. Not “we need better ISR,” but something like “detect this target at this range within this time, in this environment.” That sentence becomes your future requirement. Then take it to the service owner. Find the PAE or portfolio lead for that mission area and bring them the GCC’s problem and a plan, so you give them something to act on instead of asking them to find a need. Bring in OSW only where it speeds things up. If the problem crosses services, or one service is slow to move, a DIU-style CSO, an R&E effort, or a joint task force can help. If one service already wants it, you may not need OSW at all.

Next, get the capability into an exercise. Ask the GCC’s exercise planners to include it as an experiment or participating capability, and agree on the success metrics before the event. A demo without agreed metrics gives you anecdotes, and a demo with them gives you evidence. With JCIDS gone, the practical way a need gets validated is a measured operational result a portfolio owner can point to in a budget argument, so write the assessment up with the GCC and the service. Then convert to production. Use the follow-on language you negotiated at the start and tie it to a line in the next program objective memorandum (POM). Miss the POM window, and you wait another year.

Exercises build operator credibility, and a combatant commander saying “this worked in my exercise” carries real weight with a service buyer. But an exercise is only worth the effort if it produces a result someone can use. Ask who will write the assessment, what data will be collected, and which portfolio owner will read it. If nobody can answer, you are doing a demo for the sake of a demo.

A Realistic Map: Nothing to Program of Record

A realistic roadmap has many dependencies, and much of it depends on services. Timelines vary widely by service and technology, so treat these windows as a planning default, not a promise. But these are more or less the same guidelines for every company (software, hardware, or telecommunications).

Months 0 to 6: get eligible and findable. Finish your SAM, CAGE, and SBIR.gov registrations first, not when you need them. Confirm your nontraditional status and clean up your cap table and foreign affiliations. Then pick one narrow problem tied to a specific portfolio, because “we do autonomy” loses to “we cut latency on this mission thread by this much.” Join the one or two consortia that match that portfolio and start the problem-owner conversations.

Months 6 to 18: get a funded prototype. Run SBIR and CSO/OTA in parallel. SBIR buys you a sponsor relationship and non-dilutive R&D, and a CSO or consortium OTA gives you speed and a more direct path to production. Only bid on things with a champion and follow-on language. Get into an exercise with agreed success metrics, and start the cyber authorization and test paperwork now.

Months 18 to 36: become a budget line. Get your prototype into the PAE’s portfolio plan and the service POM. This step decides whether it becomes a program or a very nice memory. Show a sustainment and integration plan (who maintains it, what it plugs into, what it replaces), because PAEs fund things that lower their portfolio risk. Document the production OTA or sole-source follow-on; don’t just imply it, and don’t expect a continuing resolution to delay new starts. So plan your runway around that.

If this feels long, it is. But a startup that does the first six months well can reach a funded prototype much faster than one that comes in cold, and that is where the speed comes from now.

Questions I Get Every Week

“Should we do SBIR or go straight to a CSO?” If you have a sponsor and a narrow problem, do both. If you don’t have a sponsor, SBIR is a cheaper way to find one. If an operator is already asking for you, a CSO or consortium OTA is usually faster.

“Do we need a prime?” Not always. A prime can help with integration and contracting, but make sure you keep a direct relationship with the government customer and your data rights stay intact.

“How do we know which portfolio is ours?” Ask your best operator contact who pays for what you replace or plug into. That office is usually your portfolio.

“How early should we talk to the GCC?” Early, but for a purpose: a problem statement and a seat in an exercise. Don’t expect them to fund you.

“What if the requirement doesn’t exist yet?” That is common now. Write the problem statement yourself, validate it with the operators, and give it to the portfolio owner. Evidence from an exercise carries more weight than a document anyway.

“How long should we plan our runway for?” If you are starting cold, plan for more than two years to a funded line, and treat anything faster as upside. If your plan only works if everything goes right, it is not a plan.

“What about the continuing resolution?” It delays new starts. Ask your sponsor early whether your effort is a new start, and what the fallback is.

Where This Leaves You

The system is moving toward the way good startups already want to work: find a real problem, build something that works, prove it with operators, and get a decision-maker with money to say yes. That is better news than the old process. It is also less forgiving, because much of the old cover (a requirements document, a program office that had to buy it) is gone. You have to do the work of finding the buyer.

If you are one of the founders I meet with, bring me your problem statement, your named sponsor, and your funding line. If you are missing one of those three, we work on that first. If you disagree with any of this, good. Send me the argument and the example. I would rather be corrected than be wrong in a post that 30 teams read.