Steve BlankModify

2026-04-28 21:00:48

This article previously appeared in The Cipher Brief.

For a decade the cybersecurity community was predicting a cyber apocalypse tied to a single event –  the day a Cryptographically Relevant Quantum Computer could run Shor’s algorithm and break the public-key cryptography systems most of the internet runs on.

We braced for a one-time shock we would absorb and adapt to. NIST (the National Institute for Standards and Technology) has already published standards for the first set of post-quantum cryptography codes.

It’s possible that the first cybersecurity apocalypse may have come early. Anthropic Mythos now tilts the odds in the cybersecurity arms race in favor of attackers – and the math of why it tilts, and how long it stays tilted, is different from anything our institutions were built to handle.

In 2013, Edward Snowden changed what people knew
In 2013 Edward Snowden changed what people understood about nation-state cyber capabilities. In the decade that followed disclosures and leaks of nation state cyber tools reduced uncertainty and accelerated the diffusion of cyber tradecraft.

The defensive playbook that followed – compartmentalization, need-to-know, leak-surface reduction, clearance reform, “worked” because the Snowden leaks and those that followed were one-time disclosures, absorbed over a decade, with the system returning to something like equilibrium.

We got good at responding to the shocks of disclosures. It became doctrine.

It was the right doctrine for the wrong future.

Pandora’s Box
In 2026 Anthropic Mythos (and similar AI systems) changes what people can do. Mythos found Zero-day vulnerabilities and thousands of “bugs” that were not publicly known to exist (a must read article here.) Many of these were not just run-of-the-mill stack-smashing exploits but sophisticated attacks that required exploiting subtle race conditions, KASLR (Kernel Address Space Layout Randomization) bypasses, memory corruption vulnerabilities and logic flaws in cryptographic libraries in cryptography libraries, and bugs in TLS, AES-GCM, and SSH.

The reality is a number of these were not “bugs.” There were nation-state exploits built over decades.

What this means is that Anthropic Mythos, and the tools that will certainly follow, has exposed hacking tools previously only available to nation-states and transformed into tools that Script Kiddies will have within a few months (and certainly within a year.) No expertise will be required to apply that tradecraft, compressing both the learning curve and the execution barrier.

All Government’s Will Scramble
When Mythos-class systems are used to analyze the code in critical infrastructure and systems, the hidden sophisticated zero-day exploits that are already in use, (including ones nation-states have been sitting on for years) will be found and patched. That means the sources intelligence agencies used to collect information will go dark as companies and governments patch these vulnerabilities.

Every intelligence service will scramble, likely with their own AI, to find new exploits and accesses to replace the ones that have been burned. This will build a cyber arms race with a new generation of AI-driven cyber exploits to replace the ones that have been discovered.

Whichever side sustains faster AI adoption – not just “procures” it, but ships it into operational systems, holds a widening advantage measured in powers of two every four months.

The constraint for intelligence agencies (and companies) wont be their budgets, or authorities or access to models. It will be their institutional capacity for change – the rate at which a defender organization can actually change what it deploys.

The Long Tail Will Not Be Patched
Anthropic has given companies early access to secure the world’s most critical software,.

That will help Fortune 100 companies. But the Fortune 100 is not just a small part of the software attack surface.

The attack surface includes the unpatched county water utility, the regional hospital, the third-tier defense supplier, the school district, the state Department of Motor Vehicles, the municipal 911 system, and the small-town electric co-op. It includes the tens of thousands of systems running software nobody has time to patch, maintained by teams that have never heard of KASLR.

Every one of those systems is now exposed to nation-state-grade tradecraft, wielded by attackers with no expertise required. Mythos-class hardening at the top of the pyramid does not trickle down. The long tail will stay unpatched for years.

Attackers Advantage – For Now
Under continuous exponential growth of AI designed cyber attacks, a cyber defender using traditional tools can’t just respond just once and stabilize their systems. They’ll need to keep investing at a rate that matches the offense’s growth rate. A one-time defensive shock like compartmentalization might work against a sudden attack, but it will fail against sustained exponential pressure of these AI attack tools because there’s no stable equilibrium to return to. A defender’s investment rate now has to track the offense’s exponential growth rate.

Ultimately/hopefully, the next generation of AI driven cyber-defense tools will create a new equilibrium.

What We Need to Do
Mythos and its follow-ons will change how we think about cyber-defense. We can’t just build a set of features to catch every exploit x or y. We need to build cyber systems that can maintain or exceed the capability rate of the attackers.

Here are the three tools governments and cyber defense companies need to build now:

1. Measure the Gap Between Attackers and Defenders.  We need to know the gap between what the attackers can do and what we can defend against. We need to develop instrumented red/blue exercises (a simulation of a cyberattack, where two teams – the red team and the blue team – are pitted against each other) to estimate the number of new vulnerabilities vs cyber defense mitigation.
2. Measure the Defender Response Time. For each corporate or government mission system, measure how long it takes to implement a change from identification to production deployment. Then treat each organizational obstacle as equivalent to technical debt that needs to be fixed and obstacle to be removed..
3. Specify Speed, Not Features. Any new Cyber Defense tools and architecture – including the next-generation cloud-native systems sitting in review right now – should have explicit ‘rate’ requirements. Claims of “our product delivers X capability is now the wrong specification. “Closes detection gap at rate greater than or equal to the offense growth rate” is the right one.

Summary

Buckle up. It’s going to be a wild ride – for companies, for defense and for government agencies.

Mythos is a sea change. It requires a different response than what the current cyber security ecosystem was built for, and one the current system is not built to produce.

We are not behind yet. The gap between Mythos and what we can build to defend is small enough today that a serious response can still match it. A year from now, the same response will be eight times too slow. Two years, sixty-four.

By the way, the only thing left in Pandora’s Box was hope.

2026-04-22 23:34:09

This article previously appeared in the Entrepreneur & Innovation Exchange (EIX)

This is the 16th year we’ve been teaching the Stanford Lean LaunchPad class. This year, from the first hour of the first class, we realized we were seeing something extraordinary happen. It was both the end and beginning of a new era. 

Teams showed up to the first day of class with MVPs (Minimal Viable Products) looking like finished products that previous classes had taken weeks or months to build. After the class, as the instructors sat processing what just happened, we realized there’s no going back. 

I’ve been writing about how AI is going to change startups, but the shock of seeing 8 teams actually implementing it was mind blowing. And not a single team thought they were doing anything extraordinary.  

Class Observations: Product Development Velocity is Off the Scale
The old sequence for our class was simple – we had teams replicate what they would do in a startup. Have an idea. Build a team. Get out of the building to talk to customers to understand their problems, do Agile development and DevSecOps to build Minimal Viable Products (MVPs) over 10 weeks to test the solutions. And if they were going to build a company, discover and  develop a “moat” of proprietary code and features.

This year, in the first week of the class our students used multiple AI tools to replace what previously would have taken a large development team. They used Perplexity and ChatGPT for research, Claude Code and Replit to build apps, Vercel/v0 for prototyping, Granola to auto-transcribe and summarize customer interviews. The whole flow was compressed.

Because it was so easy to have an idea and then build something in minutes/hours, our students showed up on the first day of the class with products. They no longer had to wait weeks or months before testing whether anyone cares.

What we realized we were watching was a massive acceleration of the Customer Discovery / Customer Validation timeline. 

Learning 1. Impedance Mismatch Between Product Development and Learning
By the third week of the class we observed that the velocity of product development meant that teams could now generate more products than they could validate. The amount of product did not equal the amount of learning. Teams were so overwhelmed with so much information from the AI tools that they lost sight of the goal of customer development. They started to believe that the product itself was the truth.

Consequence 1. AI has made Customer Validation Harder
The abundance and ease of creating MVPs has become an accidental denial of service attack on the search for a repeatable and scalable business model. While this is an artifact of today, it means we need a different model for Customer Development as rapid coding isn’t going away.

Learning 2. Student Dependence On ChatGPT Decreased the Quality of Insights After week two of the class, it was clear teams were delegating communication to an AI. This dumbed down communication turned into AI slop. ChatGPT and Claude are no substitute for thoughtful communication – whether it’s email, PowerPoint or weekly summaries of Lessons Learned. Luckily you can spot this quickly.

Learning 3. Customers are Feeling Disrupted
As the student teams got out of the building, they discovered that potential customers were already feeling disrupted by AI. Many of the companies the teams demo’d to realized that they were seeing not just incremental improvements, but in fact were being shown a “going out of business” scenario.

Learning 4. Customers realize their proprietary data might be their only moat
In some cases, potential customers who would have previously shared their data with students are now asking for NDAs to share information with the team. Customers are realizing that closely held and hard-won information might be one of the few barriers to AI.

Potential 1: Customer Co-Design
As AI tools are allowing our teams to build higher fidelity MVPs, a few are beginning to consider using the MVPs as digital twins (as a simulation of the final product.) When put in the cloud and shared with potential earlyvangelists, startups can now start co-designing the product with potential prospects.

Teams can monitor if the digital twin is being used, how it’s used, and the feedback of what features are needed can be shared instantly. Teams can update the digital twin as they add features.

Potential 2: Agent/Customer Outcome Fit
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 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. For some teams, future class sections may see the search for Product/Market fit become the search for AI Agent/Customer Outcome fit. Minimum Viable Products (MVPs) will become Minimum Productive Outcomes (MPOs.)

Lessons Learned

• MVPs are No Longer an Indication of Technical Competence
  • Vibe coding has transformed MVPs to the equivalent of PowerPoint slides
• Speed to MVPs Hasn’t Yet Meant Faster Learning About Building a Company
  • While we’re still early in the class, the blinding speed of the first week’s onslaught of MVPs hasn’t yet translated into faster learning about customer validation.
• Business Process and Business Models Still Matter
  • The bottleneck for our student teams has moved from needing the resources to build high-quality MVPs to judgment: how to choose the right problem, how to read user signals correctly, and deciding what to build next.
• Product/Market Fit and Agent/Outcome Fit Will Co-Exist (for a while.)
  • While some customers are ready to move to an Agentic workflow, for others delivering Product/Market Fit is still what users want to see.
• Startup Teams Will Be Smaller
  • Our class teams are 4-5. In the past, if they decided to pursue their idea and start a company they would need to hire a larger team to build the product, manage the product, find out whether they had product/market fit, create demand, etc. That’s mostly no longer true.
  • Most teams won’t need to raise money to find out if the problem is real or before they know if users care.
• Enterprise Pricing Models Will Change
  • Some teams are already testing pricing that will shift from per/seat to workflows, outcomes, results, resolutions, successful task
• Customer Development Will Change
  • Because the Customer Development cycle is faster and multiple MVPs now can be run simultaneously…
  • Effort shifts to the extra time needed on hypotheses testing because the velocity and volume of product development can overwhelm signals from potential customers
  • As MVPs rapidly change, they need to be instrumented to monitor customer usage/interactions

More Learning In the Weeks Ahead

2026-04-09 21:00:25

Drones in Ukraine and in the War with Iran have made the surface of the earth a contested space. The U.S. has discovered that 1) air superiority and missile defense systems (THAAD, Patriot batteries) designed to counter tens or hundreds of aircraft and missiles is insufficient against asymmetric attacks of thousands of drones. And that 2) undefended high value fixed civilian infrastructure – oil tankers, data centers, desalination plants, oil refineries, energy nodes, factories, et al -are all at risk. 

When the targets are no longer just military assets but anything valuable on the surface, the long term math no longer favors the defender. To solve this problem the U.S. is spending $10s of billions of dollars on low-cost Counter-UAS systems – detection systems, inexpensive missiles, kamikaze drones, microwave and laser weapons.

But what we’re not spending $10s of billions on is learning how to cheaply and quickly put our high-value, hard-to-replace, and time-critical assets (munitions, fuel distribution, Command and Control continuity nodes, spares), etc., out of harm’s way – sheltered, underground (or in space). 

The lessons from Gaza reinforce that underground systems can also preserve forces and enable maneuver. The lessons from Ukraine are that survivability while under constant drone observation/attack requires using underground facilities to provide overhead cover (while masking RF, infrared and other signatures). And the lessons from Iran’s attacks on infrastructure in the Gulf Cooperation Council countries is that anything on the surface is going to be a target.

We need to rethink the nature of force protection as well as military and civilian infrastructure protection.

Protecting Ground Forces
The problem of protecting troops with foxholes against artillery is hundreds of years old. In WWI, trenches connected foxholes into systems. Bunkers were hardened against direct hits. Each step was a response to increased lethality from above. Today, drones are the new artillery; a persistent, cheap and precise overhead threat but with the ability to maneuver laterally, enter openings, and loiter. And mass drone attacks put every high value military and civilian target on the surface at risk. Fielding more hardened shelters for soldiers like the Army’s Modular Protective System Overhead Cover shelters is a first step for FPV kamikaze drones defense, but drones can get inside buildings through any sufficiently sized openings. 

Drone Protection
Ukraine has installed ~500 miles of anti-drone net tunnels with a goal of 2,500 miles by the end of 2026. These are metal poles and fishing nets stretched over roads but they represent the same instinct: the surface is a kill zone, so cover it. Russia has done the same.

The logical response is to go underground (or out to space) but the technology to do it quickly, cheaply, and at scale is genuinely new. The gap in current thinking is between “put up nets” (cheap, fast, limited) and “build a Cold War concrete bunker” (expensive, slow, permanent). What’s missing is the middle layer – rapidly bored shallow tunnels that provide genuine overhead cover for movement corridors, equipment parking, and personnel protection. 

What tunnels solve that nets and shelters don’t
A net stops an FPV drone’s propellers. A shelter stops shrapnel. But a tunnel 15-30 feet underground is invisible to ISR, immune most to top-attack munitions, can’t be entered by a drone through a door or window, and survives anything short of a bunker-buster. Gaza proved that even with total air superiority and ground control, Israel has destroyed only about 40 percent of Gaza’s tunnels after two and a half years of war.

That’s an asymmetric defender’s advantage the U.S. military should be thinking about for its own use, not just as a threat to overcome.

What’s changed to make this feasible is that we may not need boring tunnels per se, but instead modular, pre-fabricated tunnel segments that can be installed with cut-and-cover methods at expeditionary bases. Or autonomous boring machines sized for military logistics (smaller versions of the Boring Company TBMs) corridors rather than highway traffic.

The problem is a lack of urgency and imagination
The problem is real, the incumbents (Army Corps of Engineers) are slow, and the existing commercial tunneling industry isn’t thinking about expeditionary military applications.

The doctrinal gap is between “dig a foxhole with an entrenching tool” (individual soldier, hours) or deploy a few Army’s Modular Protective System Overhead Cover shelters or “build a Cold War hardened aircraft shelter” (major construction project, years, billions). There’s no doctrine for rapidly boring hardened underground movement corridors, dispersed equipment shelters, or protected command post positions using modern tunneling technology.

Army doctrine treats excavation as something done with organic engineer equipment — backhoes, bulldozers, troops with shovels — to create individual fighting positions and cut-and-cover bunkers. The Air Force doctrine barely addresses physical hardening at all, having spent 30 years assuming air superiority would substitute for it.

Nobody in the doctrinal community is asking: what if the Army could cut and cover 100 meters of precast tunnel segments in a day or if we could bore a 12-foot diameter tunnel 30 feet underground at a rate of a hundred of meters per week and use it as a protected logistics corridor, command post, or aircraft revetment?

Summary
Oceans on both sides and friendly nations on our borders have lulled America into a false sense of security. After all, the U.S. has not fought a foreign force on American soil since 1812.

Protection and survivability is no longer a problem for a single service nor is it a problem of a single solution or an incremental solution. Something fundamentally disruptive has changed in the nature of asymmetric warfare and there’s no going back. While we’re actively chasing immediate solutions (Golden Dome, JTAF-401, et al), we need to rethink the nature of force protection, and military and civilian infrastructure protection. Protection and survivability solutions are not as sexy as buying aircraft or weapons systems but they may be the key to winning a war.

The U.S. needs a coherent protection and survivability strategy across the DoW and all sectors of our economy. This conversation needs to be not only about how we do it, but how we organize to do it, how we budget and pay for it and how we rapidly deploy it.

Lessons Learned

• There is no coherent protection and survivability strategy that addresses drones across the DoW and the whole of nation
  • Just point solutions
• For troops near the front, tunnels could reduce visual, thermal, and RF signature while providing fragment protection with a network of small, concealed, overhead- covered positions, short connectors, buried command posts, protected aid stations, and revetted vehicle hides.  
• We need to underground assets that cannot be quickly replaced 
  • Command posts, comms nodes, ammunition, fuel distribution points, repair facilities, key power systems, maintenance spares, and high-value aircraft or drones.  
  • Think protected taxiways, blast walls, covered trenches, buried cabling, alternate exits, redundant portals, and rapid runway repair. Sortie generation under attack depends on a whole system, not one bunker.  
• We need to work with commercial companies to harden/defend their sites
  • Provide active defenses and incentives for under-grounding critical facilities
• The Army and Air Force need to rethink their doctrines and techniques for Protection and Survivability
  • Army Techniques Publications (ATP) 3-37.34 – Survivability Operations treat excavation as something done with backhoes, bulldozers, troops with shovels to create individual fighting positions and cut-and-cover bunkers. Update it.
  • The Air Force needs to do the same with AFDP 3-10, AFDP 3-0.1 (Force Protection and AFTTP 3-32.34v3, AFH 10-222, Volume 14 and UFC 3-340-02
• We need to think of force and infrastructure protection not piecemeal but holistically
• • Part of any weapons systems requirement and budget should now include protection and survivability 
  • Protection and survivability should be deployed concurrently with weapons systems
• We need a Whole of Nation approach to protection and survivability for both the force and critical infrastructure

2026-03-31 21:00:48

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.

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

2026-03-17 21:00:30

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

2026-02-24 22:00:57

What Lies Ahead I have no Way of Knowing, But It’s Now Time to Get Going
Tom Petty

This post previously appeared in Philanthropy.org

A while ago I wrote about what happens in a startup when a new event creates a wake-up call that makes founding engineers reevaluate their jobs. (It’s worth a read here.)  Recently my wife and I had something happen that made us reevaluate a 25-year-old relationship.

These two bookends made me realize something larger: reevaluating all types of relationships – romantic, friendship, founders, business partnerships/ventures, and even countries – is a healthy and normal part of growing, getting older and, at times, wiser.

First World Problem
We had a close relationship with a local nonprofit for over a quarter of a century. By close I mean their first executive director lived rent free in a property we owned, we provided resources when they most needed it, I had sat on their board, and when I was a public official I listened carefully to their input and suggestions, and helped them where I could. When I couldn’t do something they requested I called them and let them know why. They did the same for me. When their next executive director took over (he had been the number 2 to the previous director), the relationship continued, but in hindsight was a bit more distant. About a year ago they hired their third executive director. He had none of the history with us. And here comes the wake-up call.

I called to ask for his support on an issue very important to us. The conversation ended with what I thought was “I’ll consider it.” I never heard back. So I was surprised (but shouldn’t have been) to discover a public letter from the nonprofit taking the opposite point of view. In the past when we disagreed I got a phone call or email that said, “We heard you, but here’s why we’re going to do X and Y.” This time, and the first time in 25 years, crickets – I heard nothing.

This wasn’t the end of the world and truly is a first world problem – but it was a wake-up call.

It took my wife and I about a week to take stock. We realized that the executive director didn’t do anything “wrong.” We weren’t “owed” a call. The new director was looking forward unencumbered by the past, while we were looking backwards at the 25-year relationship. Anything we did prior to his arrival obviously wasn’t on his radar. But it was a jarring change from how we interacted in the past.

We realized that our relationship had been on automatic pilot. Until then there was no reason to rethink it. Our original support was for work this nonprofit had been doing at the turn of this century. Now that was no longer their core mission. And as we thought deeper we applied the same lens to reevaluate other organizations we were supporting. And no surprise, many of their missions had also changed, or in many cases our own interests were now elsewhere. 

Wake-up calls happen when you realize the contract you believed in isn’t shared anymore.

In the end, we are now supporting a new generation of non-profits.

But it reminded me about the bigger picture and the nature of relationships.

Most Relationships Aren’t Forever
Almost every one of us will go through breakups, either initiating them or being on the receiving end. Rather than thinking that equals failure, consider it a type of a life pivot.

Most of us grow up with a belief that “real” relationships are permanent. That if something mattered once, it should always matter in the same way. That longevity of a relationship alone equals success. It doesn’t. Permanence is comforting, but it isn’t how humans, markets, or institutions actually work. People travel with us for a while then the convoy reconfigures as life roles and needs change.

People change. Leadership changes (in business and countries). Priorities change. Incentives change. Organizations change. Sometimes you change and the other side doesn’t. Sometimes it’s the opposite. Sometimes both change, just not in the same direction. None of that automatically means anyone failed. It usually means growth happened.

Why people move on
Moving on is often framed as disloyal or selfish. In practice, it’s usually neither. It’s reality finally catching up with a story you’ve been telling yourself. Common reasons:

1. The relationship was built for an earlier version of you. At different stages of life we value different things: exploration, stability, achievement, meaning, time. A relationship can be good and still no longer fit.
2. The relationship was built for an earlier version of them. This happens often to co-founders in startups. Skills needed in the early stages are no longer the ones needed to scale. One of you learns new skills while the other is heads down doing what they’ve always done.
3. The shared mission expires. Some relationships may be temporal or transactional. They exist to accomplish something specific: raise kids, start a company, survive a hard period, launch a project. When the mission ends, you discover what remains. (For founders it’s often done-and-gone and off to the next one.)
4. The implicit contract changes. Every relationship has unwritten rules: honesty, reciprocity, respect, no surprises, or, often fatal, a breach of trust. When those rules shift without discussion, friction appears. (Trust takes years to earn, but can be lost in a minute.)
5. Misalignment becomes chronic. Often there isn’t a single disagreement. It’s a pattern. You keep explaining away discomfort and keep lowering expectations. Eventually you realize you’re managing a declining relationship. You start calculating the lost opportunity cost of not moving on.
6. The cost of staying rises. As you get older, you become more aware that time is finite. You grow less willing to spend it on relationships that consistently drain more than they return.
7. People and institutions drift from your goals. Individuals move toward comfort, status, and security. Organizations move toward new goals, new donors, different metrics, and survival at all costs. Sometimes that drift still matches you. Sometimes it doesn’t.

Lessons Learned

• A wake-up call is an event that shatters your current view of a relationship and forces you to reevaluate 
• You never know what will trigger a wake-up call
• As we get older, we perceive time as more limited. We invest more in meaningful relationships and prune the rest.  
  • That doesn’t make us cynical, just more calibrated
• Time to reevaluate relationships when:
  • Values no longer align
  • You’re doing all the work
  • There’s a breakdown of trust
  • You would not be partnering with them if you met them today