Solving Yesterday’s Problems Will Kill You

Join us at The 7th Annual Red Queen Conference
April 22 -23 – Silicon Valley
How do Portfolio Acquisition Executives and COCOMs ensure they’re working on the right problem with the right priority before locking in a requirement? Discuss, share and prototype Innovation Targeting concepts with your peers.  Get hands-on with the companies and venture capitalists, on how to do a “technical terrain walk” to rapidly identify, validate, assist and on-board the technology.
If you are part of a PAE or CPE register here: https://www.commonmission.us/red-queen-7

The Department of War is in the midst of the most ambitious acquisition reform in 60 years. It’s just in time as drone and missile warfare lessons (autonomy, Counter UAS, etc.) from Ukraine and the War in Iran are top of mind and reshaping what the DoW is buying. Reorganizing the DoW into Portfolio Acquisition Executives is reforming how the DoW is buying. The new Warfighting Acquisition System is working to reward speed to delivery.

These are real reforms, and they implement nearly every recommendation the defense innovation community has made for the last decade.

And yet many of the weapons and systems they are about to buy will be for yesterday’s problems.

Here’s why.


Do Something! Is Not the Same as Solving the Problem
Our combatant commands and allies desperately need an immediate solution to counter drones. We’re shipping what we have and we’re rapidly scaling up more of it.  But that’s not the same as solving the Counter UAS problems.

Today, the Counter-UAS response has invested heavily in the develop, scale and deploy phases. JIATF-401 was stood up last August to proliferate counter-drone capabilities. The Army runs industry competitions. DIU scouts commercial technology. The PAE reform consolidates requirements, contracting, testing, and sustainment under a single portfolio leader. These are the middle phases of the innovation cycle, and they are getting real investment and real attention. But what’s missing is where the inputs to requirements will come from.

If this isn’t fixed, we’ll end up solving yesterday’s problems. So, how do we ensure we’re working on the right problem with the right priority before locking in a requirement?

What’s needed is a rapid Portfolio Acquisition Executive requirements process to replace the rigid and unwieldy JCDIS – one that collapses the cycle time between problems, requirements and acquisition. One that can deliver a 70% solution fielded in weeks, assessed against operational reality, with findings distributed across the force and fed back into detection of the next problem.

The Innovation Targeting Cycle
Each Portfolio Acquisition Executives needs four things the current organization reforms don’t provide:

  1. Forward-deployed Problem Discovery Teams in the Combatant Commands – embed small, cross-functional teams with operational units, sourcing and curating problems from direct observation. Not technology scouts. Problem scouts. These don’t need to be organic to the PAE.
  2. Fusion Cells – collect data from the field, industry and labs and rapidly do due diligence to ensure we are working on the right problems at the right tempo with the right expected outcomes.
  3. Rapid operational assessment is built into the cycle, not conducted as a post-mortem months after fielding. Every deployment of a capability should generate data: did it work? Did operators adopt it? Did the adversary adapt? That data feeds the next rotation.
  4. Lateral distribution at operational speed – what one unit learns must reach every other unit facing the same threat before the next engagement, not the next rotation. Our institutional schoolhouses operate at institutional

The Innovation Targeting Cycle phases – Detect, Define, Develop, Deploy, Assess, Distribute – run continuously by a fusion cell, each rotation generating the input for the next. A solution fielded in weeks, assessed against reality in the field, with rapid dissemination of findings across the force.

Detect – Persistently monitor how a threat evolves at the tactical edge with forward-deployed problem discovery teams embedded with operational units, scanning for how the adversary adapted since last week. (Today’s case would be drones.)

Define – Scope the specific problem each unit faces with enough precision to drive useful solutions. A PAE leader at headquarters, no matter how empowered by the new reforms, cannot see the distinctions that matter without ground truth from the fight. Requirements still originate from within the institutional system – headquarters staffs, Service-level assessments – not from soldiers and Marines observing the problem in context.

Tying all of this together is a PAE Fusion Cell that collects the inputs from the operational force, industry and the labs and executes the discovery required to confirm we are working on actual problems (not symptoms) and the required speed to solve them.

Assess – Systematically measure whether fielded systems actually work against an adversary who adapts after every engagement. We tend to field systems and declare victory. Without assessment, there is no feedback loop. Without a feedback loop that anticipates adaptation, you cannot out-cycle the adversary. (Today this would be counter UAS systems.)

Distribute – Ensure that what one unit learns reaches every other unit facing the same threat at operational speed much less delivers that same assessment to industry.

We Had This Problem Before. It Was Called the IED (Improvised Explosive Device)
IED’s – roadside bombs – were killing servicemen in vehicles and on foot in Iraq and Afghanistan. The parallels between the counter-IED fight and the current counter-drone fight are uncannily exact.Both the Iraq IED threat and the Ukraine/Iran drone threat have 5 characteristics that make them resistant to conventional acquisition:

  1. Cheap, dual-use components. IED parts were globally available commercial products. Drone components are identical — flight controllers, autopilot software, motors, all commercially sourced. A Shahed-pattern drone costs ~$20,000. We engage them with $400,000 Stingers.
  2. Adversarial knowledge proliferates faster than acquisition countermeasures. In Iraq IED construction techniques spread through informal networks faster than the Army could field countermeasures. Today, drone designs spread even faster — through open-source repositories, commercial supply chains, and state-sponsored proliferation from Russia to Iran to the Houthis, and Hezbollah.
  3. Adversaries Had a Faster OODA Loop. Every time we fielded a jammer, within weeks the adversary swapped trigger mechanisms. Drones are the same way. New radio/satellite links, new autonomy software. The adversary’s development cycle runs in days. Ours runs in years.
  4. Tactical variation that defeats one-size-fits-all solutions. IEDs in Helmand Province were a different problem from an IED with an explosively formed penetrator in Baghdad. The Counter-UAS threat has identical variation. A Houthi one-way attack drone flying 1,500 km is nothing like an FPV (First Person Video) kamikaze at the platoon level, which is nothing like a Chinese autonomous swarm.
  5. Our reflex is to throw technology at a systems problem. The U.S. spent over $75 billion on counter-IED. As War on the Rocks concluded last November: drones are “IEDs that fly now.” The failed counter-IED framework should not be replicated. But that is precisely what is happening.

Summary: The reforms to the Warfighter Acquisition System provide Portfolio Acquisition Executives (PAEs) with the organizational structures for Developing, Scaling and Deploying weapons.

An Innovation Targeting Cycle would provide the front end that connects the reality of the warfighter’s at the tip of the spear to the PAEs.

Several PAE organizations have already begun this journey. Others are just beginning. We need to develop and share best practices across PAEs and across the DoW.

Join us at The 7th Annual Red Queen Conference
April 22 -23 – Silicon Valley
How do Portfolio Acquisition Executives and COCOMs ensure they’re working on the right problem with the right priority before locking in a requirement? Discuss, share and prototype Innovation Targeting concepts with your peers.   Get hands-on with the companies and venture capitalists, on how to do a “technical terrain walk” to rapidly identify, validate, assist and on-board the technology.If you are part of a PAE or CPE register here Register here: https://www.commonmission.us/red-queen-7

 

Your Startup Is Probably Dead On Arrival

Your Startup Is Probably Dead On Arrival

If you started a company more than two years ago, it’s likely that many of your assumptions are no longer true.

You need to stop coding, building, recruiting, fund raising, etc., and take stock of what changed around you. Or your company will die.


I just had coffee with Chris, a startup founder I invested in six years ago. Since then he’s been heads-down focused working on 1) a complex autonomy problem, 2) in an existing market with 3) a unique business model.

Chris is now starting to raise his first large fundraising round. In looking at his investor deck I realized that while he’s been heads down, the world has changed around him – by a lot. The software moat he built with his 5-year investment in autonomy development is looking less unique every day. Autonomous drones and ground vehicles in Ukraine have spawned 10s, if not 100s, of companies with larger, better funded development teams working on the same problem. 

While Chris has been fighting for adoption for this niche market (one that is ripe for disruption, but the incumbents still control), the market for autonomy in an adjacent market – defense – has boomed. In the last five years VC Investment in defense startups has gone from zero to $20 billion/year. His product would be perfect for contested logistics and medical evacuation. But he had literally no clue these opportunities in the defense market had occurred. 

While there’s still a business to be had (Chris’s team has done amazing system integration with an existing airborne platform that makes his solution different from most), – it’s not the business he started. 

Catching up with Chris made me realize that most startups older than two years old have an obsolete business plan – and a technical stack and team that’s likely out of date.

Just as a reminder if you haven’t been paying attention.

What’s Changed
Venture capital has tilted hard toward AI. In 2025, AI deals represented two-thirds of all the dollars VCs invested. That means if you’re not building something AI-related, you’re competing for a smaller pool of dollars. Non-AI startups need to answer, “Why can’t a better-funded AI-native competitor eat your lunch?”

For software founders, AI has blown up the old math around cost, speed, and headcount. Vibe coding with tools like Claude Code or OpenAI Codex means you can build an MVP (minimal viable product) in days, sometimes hours, not months. (Which means an MVP is no longer proof of your team’s competency.)

These tools are changing the makeup of development teams (fewer engineers, and new types of engineers – outcome/business process engineers and deep technical types.) What used to require a team of developers can now be done by a handful of people – and sometimes just one. Data used to be a differentiator and a moat, but current foundation models (ChatGPT, Gemini, Claude) are commoditizing/embedding public data sources.

The notion of Agile development now needs rethinking.

The constraint used to be: Can we afford to build and ship this? Now the constraint is: Do we know what to test? And can we get in front of users fast enough to learn? Agile is no longer a serial process. AI Agents can run multiple things in parallel for the same or less cost. You can now test multiple versions of the same business at once (or simultaneously be testing different businesses). While you can be simultaneously testing five pricing models, ten messages or twenty UX flows, the “user interface” may no longer be a screen at all. Testing might be to find prompt(s) to AI Agent(s) deliver needed outcomes. The bottleneck is no longer engineering. It’s moving up the stack to judgment, customer insight for desired outcomes and distribution.

Agents
AI Agents will change every category of software – including yours. Today, software applications are built to give users information and then expect the users to do the work via a user interface of dashboards, alerts, workflow tools and reports. But customers buy software because they want to get a job done, not to look at more screens. Getting the job done is what AI Agents (orchestrated by tools like OpenClaw) will autonomously enable.

What that means is, if your current product tells a user what to do next, an AI Agent will eventually do that step for them. And if your competitor’s product does the task automatically while yours still waits for a human click, you no longer have a competitive product. The next generation of applications won’t just put information on a screen, they’ll act just like an employee.

They’ll resolve the support ticket, book the meeting, qualify the lead or reorder the inventory. And when products move from software-as-interface to software-as-outcome, pricing will move from seats to results; per resolved ticket, per booked meeting, per closed lead.

(The search for Product/Market fit will become the search for AI Agent/Customer Outcome fit. Minimum Viable Products (MVPs) will become Minimum Productive Outcomes (MPOs.) More on this in the next post.)

Hardware
For hardware founders, the shift is just as significant. Hardware is still constrained by physics, capital, supply chains, and manufacturing cycles. While you can’t fake your way past cutting metal, building prototypes or taping-out a chip, AI will let you kill bad ideas faster. Now, before you build a physical prototype, you can simulate more design variants, create digital twins, and stress-test assumptions earlier and much cheaper than before. The result is that you accelerate learning and discovery (at times getting to failure faster) and in startups, that’s a feature, not a bug.

And once AI is embedded as part of the system, the product itself changes. Adding AI as a backend of a camera means the camera can now become a surveillance system, a vibration sensor, a machine tool failure prediction system. A robot becomes a factory worker. The moat is no longer just the hardware. It’s the combination of what the hardware can sense and what the AI can do to use that data to decide and act.

The Sunk Cost Trap
Founders who started pre-2025 typically have built a technical stack optimized for a world where software development was bespoke and expensive. While Agile development and DevSecOps made us lean, they operate in a serial fashion, and startups hired a team sized for this structure. Companies that have spent years developing a “moat” of proprietary code and features are waking up to the fact that AI is commoditizing most of their tech stack. This leaves startups trying to raise money for a business model that may be partially (or wholly) obsolete.

None of this may be obvious to a founding team when you’re heads down trying to ship a product and searching for product/market fit.

Technical stack, product features, user interface, number of employees, all of these sunk costs become reasons not to pivot: How can we throw away years of work? Our VCs funded this specific idea. Customers still want a UI. The team believes in this roadmap. Our customers aren’t ready for this. (Chris is a perfect example. He built something genuinely impressive, and likely still competitive, but the business model around it needs to change.)

Some sunk costs continue to be assets; deep domain knowledge, customer relationships, proprietary data, hard-won regulatory approvals, physical integrations – those are worth keeping. In Chris’s startup – that’s his airframe integration.

The sunk costs that are liabilities are a large engineering team built for slow software cycles, a pricing model based on seats, a product roadmap built around features rather than outcomes. These are what is known as the “Dead Moose on the table” – something so obviously wrong but that no one wanted to challenge.

The founders who survive will be the ones who can look at what they’ve built and ask: if I were starting this company today, using today’s tools in today’s market, what would I actually build? 

That’s uncomfortable when you’ve raised money on a specific thesis. But it’s less uncomfortable than your investors telling you they’re not going to fund your next round, and going out of business defending an obsolete plan.

Lessons Learned

  • You don’t get to run a 2024 (or earlier) playbook in 2026Everything has changed – fund raising, tech, business models
    • Agile development is changing to parallel development
  • The search for Product/Market fit will become the search for AI Agent/Customer Outcome fit. Minimal Viable Products (MVPs) will become Minimal Productive Outcomes (MPOs.) More on this in the next post
  • The sunk cost mindset will put you out of business
  • Defensible moats may still be found in having proprietary data, deep understanding of customer outcomes, getting regulatory lock-in, or being a Program of Record
  • If you’re not losing sleep, you haven’t understood what’s happening
  • Founders who survive will get out of the building to take stock, pivot and course correct