Category: Loop Principles

  • What Do We Replace the Roadmap With?

    What Do We Replace the Roadmap With?

    I’ve never really loved roadmaps.

    Not because direction doesn’t matter. It does. But because past two quarters, they’ve almost never been real.

    In most companies I’ve worked at, Q1 is mostly accurate. Q2 starts to wobble. By Q3 you’re explaining why the world changed. By Q4 you’re rewriting the story.

    And yet we keep pretending.

    We build slide decks projecting certainty. We sequence features nine months out. We treat deviation like failure instead of reality.

    The older I get, the less patience I have for that.


    What We Did Instead

    Twelve years ago at Koddi, we didn’t really run the company off roadmaps.

    That wasn’t some philosophical stance. We were just a bunch of kids in our twenties trying to build a business.

    We knew the big projects. Adding advertising partners to our platform could take months. Infrastructure work took time.

    But we didn’t manage the company through a feature timeline.

    Every week, a small group of us would get in a room and ask one question:

    What do we have to do this week?

    That was it.

    Every week was essentially a reset. We looked at the state of the business and recalibrated around what mattered most right now.

    We didn’t optimize for everyone feeling productive because they were checking things off a roadmap.

    We optimized for impact.

    Now here’s the important part: it wasn’t chaos.

    We had a plan. It was just very simple.

    We had a monthly revenue target, and we almost always hit it. There was one month we didn’t. A lot of it was outside our control. But the entire company sat down and talked about what we needed to change to make sure that didn’t happen again.

    Our roadmap was basically one line:

    Hit revenue. Stay alive. Fuel growth.

    Everything else bent around that.


    The Constraint Was the Plan

    When revenue is the constraint, the conversation changes.

    You don’t argue about whether Feature A should come before Feature B because it’s “on the roadmap.”

    You ask:

    What moves revenue?
    What unblocks sales?
    What improves performance?
    What closes the gap?

    If we were on track, we doubled down.

    If we weren’t, we recalibrated.

    Planning wasn’t about predicting the year. It was about responding to the constraint.

    Nicholas, our president and a close friend, used to say:

    “Do better and bigger just happens.”

    At the time it sounded almost too simple.

    But that was the operating philosophy.

    Do better:

    • Improve conversion
    • Add partners
    • Fix performance
    • Close deals
    • Remove bottlenecks

    Bigger followed.

    We didn’t obsess over scaling before we had improved. We improved relentlessly, and scale emerged.

    A small group of kids in their twenties scaled that business to millions in revenue within a few years. Not because we had perfect planning. Not because we ran perfect Agile.

    Honestly, we didn’t really do Agile at all.

    We kind of just did work.

    Important work. Constraint-driven work. Weekly reset work.


    Planning Around the Real Constraint

    Looking back, the lesson wasn’t that roadmaps are useless.

    The lesson was simpler:

    The roadmap was never the plan.
    The constraint was.

    Great teams organize around the scarcest thing that actually matters.

    At Koddi, that constraint was revenue.

    That clarity allowed the team to move quickly, reset constantly, and focus on the highest leverage work each week.


    The Constraint Is Changing

    In an AI-native world, the constraint is shifting.

    Execution cost is collapsing. Prototypes can be built in days. Small teams can build things that used to require entire engineering departments.

    But a new constraint is emerging:

    Token capacity and compute.

    Every AI-native team now operates within some form of token budget or compute budget, whether they track it explicitly or not.

    My guess is most teams are dramatically underutilizing that capacity. They’re paying for tokens but not deploying them effectively.

    The real job of product teams may start to look like this:

    Make sure your token budget is being used on the highest leverage tasks possible.

    Shipping improvements.
    Learning faster.
    Running experiments.
    Removing bottlenecks.
    Improving the system itself.

    And as learning loops happen, what counts as “highest leverage” may change day to day.

    Just like revenue was the constraint at Koddi, tokens and compute are quickly becoming the constraint for AI-native teams.

    Planning becomes less about predicting features and more about allocating that capacity wisely.

    Even some of the largest AI companies hint at this kind of thinking. NVIDIA’s Jensen Huang has said their long-term plan is largely defined by what they’re doing today and how they adapt as the landscape changes.

    That mindset sounds a lot like the weekly resets we used to run at Koddi.


    Planning in the Loop Era

    This isn’t anti-planning.

    Direction should be durable.

    But tactics should be fluid.

    You should know:

    • where you’re heading
    • what matters financially
    • what could kill the company

    But pretending you can accurately sequence the next twelve months of work in a fast-moving environment doesn’t make you disciplined.

    It makes you attached.

    Small and mighty teams don’t win because their roadmap was accurate.

    They win because they turn the highest leverage levers every single week.

    They know the constraint.
    They reset constantly.
    They do better. And bigger happens.

  • Restart Beats Refactoring in the Agent Era

    Restart Beats Refactoring in the Agent Era

    Yesterday our AI agents attended a small funeral.

    The one we buried was named Dumb Eric.

    He had been shipping code for days. Running development loops through the night. Opening pull requests while I slept.

    But another agent on our team had surpassed him.

    So we shut Eric down and rebuilt him from scratch.

    (The cover photo is Dumb Eric. An old MacBook Pro sitting slightly lopsided in a chair. That’s where he lives right now while we work out the kinks and figure out the long-term infrastructure.)


    Dumb Eric was the first agent I built to orchestrate our development workflow.

    A deterministic loop that could move through tickets, generate code, open PRs, and keep working without me sitting there babysitting it.

    At first it worked exactly the way I hoped.

    I could go to sleep, wake up, and find a stack of pull requests ready for review.

    The system was doing real work.

    Then another agent showed up.

    Steve, our CTO, built one named Charlie.

    And Charlie was better.

    Cleaner architecture.
    Better task handling.
    Fewer strange edge cases.

    So I did what most engineers instinctively do when their system starts falling behind.

    I tried to refactor.


    Refactoring feels productive.

    You keep the system you built.
    You improve pieces of it.
    You convince yourself you’re preserving momentum.

    But the deeper I went, the worse it got.

    Edge cases started piling up.
    Old decisions collided with new improvements.
    Half-finished fixes layered on top of older assumptions.

    Eventually I realized something uncomfortable.

    I wasn’t improving the system.
    I was protecting my past work.


    One of the principles I’ve been writing about with Loop is simple.

    Restart beats refactoring.

    For most of software history, restarting was the dangerous option.

    Rewrites were slow.
    Expensive.
    Risky.

    But the economics of building software have changed.

    When agents can generate large portions of a system quickly, the cost of rebuilding drops dramatically.

    So instead of continuing to patch Eric, I did something different.

    I had Charlie fork himself.

    Then generate a new Eric.


    Within an hour Eric was running again.

    Opening PRs.
    Moving through tickets.
    Doing exactly what he was supposed to do.

    And the lesson was obvious.

    Restarting was faster than refactoring.


    This isn’t just true for agents.

    We’re seeing the same pattern at a much larger scale.

    Right now we’re rebuilding the entire Psych Hub training platform.

    The previous system had accumulated years of constraints. Architecture that was hard to change. Features layered on over time. The usual gravity that slows teams down.

    Instead of carefully refactoring our way forward, we restarted.

    In roughly 4–6 weeks, we rebuilt the core platform and added more than a year’s worth of features customers had been asking for.

    At this point we’re mostly working through edge cases.

    But the bigger win is the foundation.

    The system is clean again.
    The architecture is easier to extend.
    And the team moves faster.

    Restarting gave us back our speed.


    For decades, software teams were taught to avoid rewriting systems at all costs.

    Protect the existing system.
    Refactor carefully.
    Preserve what you have.

    That advice made sense when rebuilding software took months or years.

    But the agent era changes the math.

    When building becomes dramatically faster, the cost of starting over collapses.

    And when the cost of rebuilding approaches zero, a different strategy starts to make sense.

    Sometimes the fastest way forward isn’t fixing the past.

    It’s letting it go and building something better.


    Dumb Eric died yesterday.

    Eric 2.0 shipped an hour later.

    And the lesson applies to far more than agents.