1. The dusty document
For a long time the way organisations understood their customers was a ceremony. People gathered in a room, covered the wall with coloured stickies, distilled it into a polished diagram, and called it a customer journey map. The map went on a shelf. The customers kept moving. The map did not.
Enterprises run this ritual every year and tell themselves they understand. They are, in effect, navigating a 21st-century economy with a clay tablet — the Babylonian Imago Mundi, a fixed picture of a world that has already changed.
Solo founders are not immune to the same mistake. We do it with persona docs, Notion pages, a single-line "our user is X" sentence we wrote at the start of the year. By month three it describes someone who no longer exists.
The map has to stop being a document. It has to become a loop.
2. From snapshot to loop
The traditional map is retrospective. It looks at what already happened, often weeks ago. In a world where the next product launch is six hours away on a Tuesday and a search result moves you up or down a sentiment graph by lunchtime, retrospective is the same as wrong.
The replacement is a living loop. Not a diagram you draw once; a stream you read continuously. Streams of signal — sign-ups, returns, support tickets, support silences — feed a layer that notices what is changing in time to do something about it.
Cole Armstrong, who has spent more time than anyone we know thinking about digital journeys, puts it like this:
"When you map a digital journey, start with the destination. Where do you want them to end up? Then focus on two things: keep them motivated to continue, and remove the barriers that slow them down. Know where they're going. Keep them moving."
For a tiny team the version is even smaller: can you tell, right now, which moment in your product loses someone? If the answer takes longer than a day, you are running a museum, not a company.
3. The queryable company
For the loop to work, the company has to be readable by software. Most are not. Decisions live in someone's head, in a private chat, in a draft email no one will ever search. The intelligence layer never sees them, because they were never made into anything an intelligence layer could see.
A queryable company is one where every meaningful act leaves an artifact: a ticket, a journal entry, a public message, a commit. Not because everyone enjoys documenting things — they don't — but because the artifact is what the AI uses to help you the next week.
Inside our own one-person operation the rules are deliberately simple:
- Capture, don't remember. Every voice note becomes a journal entry. Every decision lands in a ticket the iSpirit can read.
- Public over private. Even when there is no one else to read it, write the note in the place a future agent will look — not in a DM to yourself.
- One pane of glass. A single view that shows the week's commits, journal entries, completed goals, and unfinished decisions. Without it, no AI you bolt on later can route anything useful.
The point is not surveillance of yourself. The point is that the future version of you — and the AI helping that future you — can read the past version. A company you cannot search is one no software can help.
4. The role shift: fewer coordinators, more makers
The classic management hierarchy was designed to move information through layers of people. Each layer added context and slowed everything down. That trade-off made sense when communication was expensive. It does not anymore.
Inside a high-velocity company the layers between idea and result are collapsing. Three roles survive:
- The maker. Brings working prototypes to meetings, not slide decks. Comfortable shipping something rough on Tuesday and replacing it Thursday.
- The owner. One name on each outcome. Not a committee, not a working group — a single person whose job is to make a specific result happen and who is allowed to say no to anything that doesn't move it.
- The founder who builds. Stays close enough to the tools to know what is actually possible. Doesn't delegate "AI strategy" to a department, because there is no department.
For a solo founder the rearrangement is not abstract. You are all three at once, and the question is which hat costs you the most time. Most of us discover, when we look honestly, that the coordinator hat is the one we should have taken off years ago. The maker and the owner are the work. The coordinator is the friction.
Spending money on AI capacity — yes, more than feels comfortable — to remove the coordinator hat is one of the rare expenses that compounds. It is the version of hiring that does not require a hire.
5. Marrying outside-in and inside-out
Most companies separate two views and pay for it. The outside-in view is about the customer — their emotions, their friction, their joy. The inside-out view is about the company — workflows, handoffs, tasks, who-does-what. Each view on its own lies. Together they tell the truth.
| Outside-in (journey) | Inside-out (process) | |
|---|---|---|
| Perspective | The customer's experience | The company's execution |
| Focus | Emotions, needs, pain | Workflows, handoffs, tasks |
| Altitude | The whole arc of a relationship | The specific step that runs at 2pm |
| Question it answers | What hurts and why | How the hurt got made |
For a solo founder the merger is almost free, because you are both the outside-in observer and the inside-out operator. The hard part is keeping both lenses honest at the same time. The shortcut: when you feel friction as a user, write it down before you fix it as a builder. The note from the outside-in moment is the only thing that stops you from optimising the wrong step.
6. From writing code to writing intent
The most uncomfortable shift, for those of us who grew up writing code, is that the act of coding is no longer where the leverage lives. The leverage is in stating the intent clearly enough that a system of agents can implement it — and writing the tests that tell you whether they did.
That shift is real. Inside our own repositories there are corners where we no longer write the implementation — we write the spec, write the tests, and let agents iterate until both pass. It is not magic. It is a discipline of describing what "done" means precisely enough that something other than you can verify it.
It will not feel like progress for the first month. The honest sentence is that it feels like translating, slowly, a thing you used to do in your head into a thing you have to write down. By month three, the calculus inverts. You spend your morning describing four things you want by Friday. You spend your afternoon judging four things that came back overnight. A week of work happens in a day.
The "thousand-fold engineer" framing is a Silicon Valley exaggeration. The honest framing is quieter: a single person with discipline and good agents can finish what used to need three.
Information flow is the only speed limit.
What this actually changes
Most articles about AI-native operating models end with vendor benchmarks. Conversion up X%, churn down Y%, satisfaction up Z%. Those numbers are real for enterprises with the volume to measure them. For a solo founder, the change shows up smaller and sooner:
- The Sunday retrospective writes itself, instead of being the thing you skip.
- The "what should I work on first this morning" question has an answer before you finish your coffee.
- The half-formed research you would never get to gets done by Tuesday, with a citation trail you can defend.
- The pile of small digital tasks does not become a Friday-afternoon panic.
That is the shift. Not a 10× anything. A 1× life with the friction removed.
The forward-looking loop
The companies that get stuck are not the ones using old maps. They are the ones still pretending the map is the territory. The map was always a fiction we agreed to use because the territory moved too fast to draw.
It still does. The new tool is not a better map. It is a loop that watches the territory in time to act on what it sees.
Two questions, then, for anyone running a small company at the close of this decade. Is your work observable by the software you are paying for? And when something changes in the world your product lives in, does anything inside your company notice in time to do something about it?
That is the open-loop / closed-loop question. The answer is the company you are about to become.