I Spent 20 Years Learning How to Build for People. Then I Had to Unlearn It.

How First Principles Thinking turned a career pivot into something I didn't expect: a mirror.

There's a specific kind of silence that follows a layoff.

Not the dramatic kind from the movies. Just a Tuesday afternoon where the calendar suddenly has nothing in it, and the habits of two decades, the standups, the sprint reviews, the Jira tickets are still running in your head like a train that doesn't know the tracks have ended.

I'd spent 20 years moving through the industry's layers. Traditional design. Then UI/UX. Then Product Management. I knew how to take a mess of a problem, map a user journey, write a story, run a sprint, and ship something people actually used. I was good at it.

And then, for the first time in a long time, I had no idea what I was doing.

The Reflex That Almost Held Me Back

The natural instinct, when you're a product person who's been laid off, is to look for the same kind of work. You refine the CV, you update the LinkedIn, you reach out to your network. You reason by analogy: this is what job searching looks like, so this is what I'll do.

I did that for a while. And then, almost by accident, I stumbled into a conversation about something called First Principles Thinking.

The idea isn't new; Aristotle had a version of it, physicists have used it for centuries, and Elon Musk built his empire on it. But the framing that hit me was simple: instead of reasoning from what already exists, you strip everything back to the most basic truths and rebuild from there.

I started applying it to my situation. And the first thing I noticed was uncomfortable.

I'd been asking the wrong question.

I wasn't looking for a job. I was looking for a way to make an income from the skills I had. Those are not the same thing. One requires an employer. The other doesn't.

What Happens When You Apply It to AI

Around the same time, I started seriously exploring AI agents. Not as a user, but as someone trying to understand what they actually are at a fundamental level.

Strip away the hype and the jargon, and an AI agent is three things:

• A brain: it can reason through a problem

• Tools: it can take action in the world (send an email, update a spreadsheet, post to LinkedIn and a whole lot than that…)

• Memory: it knows what's happened and what the goal is

That's it. Once I saw it that way, something clicked. Because I realised I didn't need a "Social Media Manager," a "Research Assistant," or a "VA." I needed those three components, assembled in the right order, pointed at a specific task.

The job title was the veneer. The logic was the reality.

The Part Nobody Warned Me About

Here's what I didn't expect: building with AI agents is one of the most effective ways to audit your own thinking.

Every time the agent failed and it failed a lot at first, it was pointing at a specific gap in my instructions. Not a bug in the software. A gap in my logic.

When the agent produced something random and off-base, it was because my input was vague. I'd said "write a summary" without defining what a summary meant to me, how long it should be, or what it was for.

When the agent got stuck in a loop, it was because my decision logic was circular. I'd written instructions that assumed knowledge the agent didn't have.

Every failure was legible. And that made it genuinely different from almost any other kind of learning I'd done. In a normal team, a developer would fill the gaps with assumptions. A designer would interpret the brief. The messiness of human collaboration papers over the cracks in your thinking.

The agent doesn't do that. It just stops and waits, or it does something wrong, and you have to go back and find the exact sentence where your logic broke down.

After a few weeks of this, I realised: I was documenting my own expertise in real time. Every agent I built was a kind of externalised map of how I actually think.

Where My UX Background Turned Out to Matter

I used to feel slightly embarrassed about being a visual learner. In meetings, I'd be the one sketching while everyone else talked. I'd see the shape of an argument before I could articulate it.

Turns out that's not a quirk. In the context of AI agents, it's the closest thing to a superpower I've got.

A user journey and an agent workflow are the same animal. Both ask: what does the person (or the data) need? What decision happens here? Where does it go next? I'd spent years thinking in flows. All I had to do was redirect that thinking inward onto my own processes instead of someone else's product.

The first time I sketched an agent workflow on paper and then fed that sketch to an LMM and said "build me the logic for this," something shifted. I wasn't coding. I wasn't prompting. I was architecting. And that felt like familiar ground.

What I'm Actually Building

I'm in the early stages of building a company around AI agents. I don't have all the answers. Most days I feel like a junior developer which, if you've spent 20 years being the person with the roadmap, is both humbling and strangely energizing.

What I do know is this: the bottleneck in AI-agent work is not technical. It's clarity. The people who will build the most useful things with this technology are not necessarily the ones who can write Python. They're the ones who can look at a messy, human, intuition-driven process and describe it precisely enough for a machine to follow.

That's a Product skill. That's a UX skill. That's a 20-year skill.

I spent two decades learning how to strip complexity down to something a user could navigate without thinking. Now I'm learning to strip it down to something a machine can execute without guessing.

Same first principle. Different surface.