The five principles behind everything I’ve built with AI as a GTM operator. The first one sounds obvious. It’s also the one I have to relearn every time I get too excited about the tool.
(Second in a series called Built, Not Coded: a field guide for GTM operators who have real problems, imperfect systems, and no interest in learning to code just to get unstuck.)
After I shared the story of building my first dashboard, I got some version of the same question more than once:
“Okay, now how do I actually start?”
The question made sense; I asked it after every webinar I joined. Ultimately, though, it was the wrong place to start.
The reason is that the way a lot of people start with AI is also the reason they get frustrated with it. The default path goes something like this: You hear AI can do something impressive. You open a chat window. You type in a request. You get back something that’s fine, but not quite right. You tweak the wording. It gets a little better. Maybe you use it. Maybe you start a new chat, and it gets lost in the ether.
Helpful? Maybe. Transformational? Definitely not.
That’s how AI becomes a slightly better search engine, a faster writing assistant, or a place to dump things when you’re stuck. Useful, but not the end goal I’m talking about.
The gap between “this helped me draft an email” and “I built the thing I’d been asking for” is not really about prompt technique. It’s about what you bring to the conversation before you ever open the tool.
Why the default approach stalls
A lot of operators start with what they’ve heard AI can do.
They’ve heard it can improve your writing, so they bring writing tasks.
They’ve heard it can summarize, so they bring long documents.
They’ve heard it can analyze, so they attach a spreadsheet and ask for insights (this is still my favorite task).
None of these things is wrong by any means. Like I said, I love feeding Claude a ton of data and having it work its magic. If that’s the only mode you use, though, you mostly get a little faster at work you already knew how to do. The really interesting shift happens when you stop starting with the tool and start with the problem you’ve been carrying around.
The dashboard that never gets prioritized and takes too long to manually run every time.
The handoff that still depends on someone remembering the right context.
The customer view that should already exist, but somehow all those expensive CRMs miss.
That’s where operators are closer to the truth than anyone else. We know where the process breaks, what the customer actually needs, and the workarounds the team uses to keep things moving. The problem isn’t awareness of the issue; it’s turning that awareness into something usable.
My issue was that I’d let myself believe that knowing the problem is not enough. Someone else has to build the thing, or create the report, or wire the systems together. To be fair, sometimes that’s true, but we’re living in a moment where that’s not always the case anymore.
The people who get the most out of AI are not the people who know the most about AI or have a coding background. They’re the people who know their own problems most clearly.
Stop asking, “What can AI do?”
Start asking, “What do I actually need?”
The five principles
Everything I’ve built so far has come back to a handful of operating principles.
I’d love to say I started with these, but I learned them the annoying way: by building things, breaking things, getting something back that was technically correct but too hard to use, and realizing the problem was usually me not being clear enough about what my real need was.
1. Start with the problem, not the tool
This sounds obvious, but it’s also the thing I see people skip consistently.
My dashboard didn’t start because I wanted to build a dashboard. It started because I was tired of manually rebuilding the same picture every time I needed to understand capacity, customer effort, and delivery risk. The dashboard was just the shape the solution eventually took.
The distinction matters because if you start with “I want to build a dashboard,” you’ll probably end up with a dashboard. If you start with “I need to understand where my team is spending time, whether that effort is aligned to customer value, and where risk is starting to show up earlier,” you’re much more likely to build something useful.
The problem comes first.
The tool comes later.
2. Treat problem clarity as the real bottleneck
This is the one that had the biggest impact on how I work with AI.
The limiting factor in nearly everything I’ve built hasn’t been AI capability. It’s been the quality of my own problem description. Everyone’s probably heard the phrase, garbage in, garbage out. It’s the same idea.
Specific in, useful out.
Vague in, vague out.
Now I start by asking myself: can I explain what I need, why it matters, what I already have, and what good looks like in one clear paragraph?
If I can’t, I’m not ready to build yet. Sometimes that means waiting a few days to rethink the problem, sometimes it’s just me taking 10 minutes to sit down and refocus on the real problem.
That used to feel like a delay, but now I realize that’s the real work.
A useful trick is to describe the problem like you’re talking to a new hire in their first week. Assume they’re capable, but also assume they know nothing about your systems, your history, your shortcuts, or those ten annoying things everyone on the team just “knows.” What would you need to tell them so they could understand the problem and not accidentally solve the wrong one?
That can be your starting prompt right there!
3. The first version is a learning artifact, not a deliverable
The first version of almost anything I’ve built has been valuable mostly because it showed me what was missing from what I actually needed.
The first dashboard showed me I needed different filters.
The first automated email exposed data problems I didn’t know I had.
The first version of a workflow usually made me realize I had been too vague about who it was for, what decision it was supposed to support, or what “good” was supposed to look like.
What’s important to remember though is that that’s not failure, that’s the process. If you expect the first version to be right, you’ll end up annoyed every time. Now, if you expect it to teach you what version two needs to be, well then, you start moving a whole lot faster.
Build the smallest useful “thing”. Learn what you got wrong or realize what is missing and then adjust. Iteration isn’t what happens when the work goes sideways. Iteration is the method.
4. Know the difference between a prototype and something you can rely on
A prototype proves the idea can work. If you’re using something like Claude, it’ll often try to build that prototype as an artifact in your chat.
The difference between a prototype and a reliable tool is when it comes into contact with the real world.
A prototype works on clean data, expected inputs, and basically the ideal state. Something reliable has to deal with messy data, weird formatting, missing fields, inconsistent names, and all the little ways reality refuses to match the clean version in your head.
If you think about building in two very broad buckets, there’s phase one, where you get it “working”. Phase two is making it trustworthy, and that gap is not insignificant. Phase 2 is where the data gremlins live.
It’s also where a lot of these projects end up back on the shelf. Someone proves the concept, gets excited, shares it too broadly, and then the first edge case breaks trust in the whole thing. Do not confuse “it worked once” with “people can rely on it.”
5. AI accelerates the build. Your judgment runs the project.
This is the one I care about most. Everything I’ve built required decisions AI couldn’t make for me. AI can’t tell you what should trigger an alert, what belongs in an executive summary versus a practitioner update, or which signals actually mattered, versus which ones would just create noise.
Those answers could only come from knowing the team, the customers, the work, the business model, and the difference between something interesting and something worth acting on. This is where your deep knowledge of the business and the pain you’re trying to solve really comes into play.
AI can help you implement a decision.
It can help you pressure-test it.
It can even give you options you would not have thought of yourself!
But it CANNOT replace the judgment and context required to choose the right direction. That call is still yours.
Try this yourself this week
Make a list of three problems you’ve accepted as unsolvable without more resources. And please, not “we need five more people.”
For each one, write a few sentences:
What do you have now?
What’s missing?
What decision are you trying to make?
What would good look like?
Then pick the one where the paragraph is clearest. Don’t be fooled by the biggest one necessarily, hone in on the clearest one. That is your starting point. Start where you already understand the problem and build the habit of finishing something. Then bring that habit to the harder stuff.
This has been the sequence behind everything I’ve built so far.
Next in the series: how I turned a CS platform that gave me data but not insight into something I could actually lead from, without replacing the platform or hiring a RevOps team.
I’m Andrew Pabon. I write about onboarding, professional services, and building leverage as a GTM operator. If this resonated, follow along for the rest of the series.