Sometimes It's About Surviving the Chaos

The pattern I keep seeing in early product teams is the same one I used to fall into. The work feels disorderly, the calendar feels disorderly, the roadmap is half-fiction, and the first instinct is to reach for structure. A cleaner Jira workflow. A new template for PRDs. Another integration that promises to make the next week more predictable. None of it is a bad idea. None of it is the thing the team actually needs.

What it needs first is to survive the week.

I've come to think of early product work — building something genuinely new, from scratch, before there's a known shape to it — as fundamentally different from the work that comes after. The phase looks like execution. It feels like execution. But the underlying physics are closer to navigation in fog. You're not optimising a known path; you're feeling for one. And the discipline that compounds isn't process — it's principles.

The Wrong Reflex Is Always the Same

When a team is uncomfortable, it reaches for process. Process is legible. You can put it in a doc, share it in Slack, defend it in a meeting. A new principle, by contrast, is hard to point at. It doesn't have a Jira project.

So teams in genuinely chaotic environments end up over-investing in the visible thing — tickets, dashboards, integrations, frameworks — while under-investing in the thing that actually carries them through the week. Dave Snowden and Mary Boone made this concrete in their 2007 HBR paper on the Cynefin framework: different operating environments demand different leadership moves, and applying "best practices" to a chaotic context is a category error. In their words: "in a chaotic context, searching for right answers would be pointless… no manageable patterns exist — only turbulence."

Process is something you build after surviving. Surviving is what you do when the process you'd hoped to follow doesn't exist yet.

This isn't an argument against process. It's an argument about order of operations. The team that wins early isn't the one with the cleanest Linear board. It's the one whose people can act sensibly when the board is wrong.

Principles Travel Further Than Workflows

Workflows are brittle in a way principles aren't. A workflow encodes the situation it was designed for; a principle encodes the reasoning behind a class of decisions. When the situation shifts, the workflow breaks and the principle adapts.

Netflix wrote one version of this into their culture page: "We expect managers to practice context not control — giving their teams the context and clarity needed to make good decisions instead of trying to control everything themselves." That's not a soft people-ops line. It's an architectural choice. In an environment that changes faster than any process can be revised, the only sustainable scaling lever is giving people the principles to decide locally, in real time, without a meeting.

Steve Blank's framing of customer development sits in the same family. His blunt version: "no business plan survives first contact with the customer." The plan was never the asset. The principle behind the plan — contact, learn, re-plan — is.

A principle I keep coming back to in the work I do: optimise for reversibility, not certainty. In a chaotic phase, the cost of being wrong is small if you can change course this week. The cost of being slow is enormous regardless. That single principle has saved more time than every process I've put on top of it.

The Survivors Are the Ones Who Can Act Without the Map

I've been re-reading Paul Graham's "Relentlessly Resourceful" recently. It's a short essay, and the part that lands every time is his attempt to name the single most predictive trait Y Combinator looks for in a founder. Not strategic. Not technical. Not visionary. Just: relentlessly resourceful. "What would someone who was the opposite of hapless be like? They'd be relentlessly resourceful."

Resourcefulness, in this sense, isn't a personality trait. It's a behavioural posture you can choose. It's what's left when the process is silent and the data hasn't landed yet. Ben Horowitz made the same observation through a different lens in his "Peacetime CEO / Wartime CEO" essay — different modes, different rules, different people: "in peacetime, it's all about growth. In wartime, it's just about surviving."

Most early product environments are wartime dressed up in peacetime clothes. The team has the calendar of a stable company and the underlying volatility of a startup, and the gap between the two is where bad decisions live. The people who keep moving through that gap aren't the ones with the best Notion. They're the ones who internalised a few principles deeply enough that they can make a sensible call before anyone has built a process for the situation.

Process Comes After. Not Before.

Here's the part that surprised me. Once you let the principles lead, the processes that emerge are dramatically better — because they're shaped by the actual work, not by a template borrowed from a company twenty times your size.

The 2011 Startup Genome Report, a 3,200-startup study co-authored with researchers at Berkeley and Stanford, found that "startups that pivot once or twice raise 2.5x more money, have 3.6x better user growth, and are 52% less likely to scale prematurely." The teams that adapted — neither rigid nor thrashing — outperformed everyone. Adaptation isn't the opposite of process. It's the precondition for any process that's going to hold up.

I've watched this play out repeatedly in the projects I've worked on. The teams that started by drawing the perfect workflow on a whiteboard burned the first three months refining the diagram. The teams that started by surviving the first three months — making sharp local calls against a small set of principles — ended up with workflows that fit the work. Same calendar. Different ending.

What Actually Compounds

I don't want to write the version of this argument that romanticises chaos. Chaos isn't a strategy. It's the environment. The strategy is the small, durable set of principles you carry through it — the ones that tell you what to do when the playbook hasn't been written yet, and let you write the playbook from real evidence once it has.

The Jira board, the integrations, the dashboards — they all earn their place eventually. They just don't deserve to lead. In a fast-moving environment, the team that survives isn't the one with the most process. It's the one whose people can find order in the noise long enough to build process worth keeping.

Process is a result. Principles are the work.