The build is the easy part.
Picking it is the job.

Most GTM projects begin with a tool. The good ones begin with a sentence about what is actually stopping the company from growing.

Ask someone what they are working on and you usually get a product name. We are rolling out Clay. We are rebuilding lead routing. We are adding an AI SDR. None of those are answers. They are the middle of a story whose beginning nobody said out loud.

The beginning is the constraint: the one thing that, if you removed it, would let the company grow faster or cheaper than it does today. Every system worth building removes one of those. Everything else is work that looks like work.

Two of mine

Kizen. I was the first GTM engineering hire, and the CRM was visibly a mess, so the obvious move was to go fix the CRM. The real constraint was smaller and meaner: inbound arrived in a VP's inbox and sat there. First touch averaged about 72 hours, and by then the moment had passed. So the build was not “fix the CRM.” It was routing. Resolve the company from the email domain, enrich it, assign it, put a clean contact in front of a rep in about ten seconds. The data model got built too, but it got built because routing needed it, not because messy data offended me.

AlphaForge. I had a construction market and a mandate to run outbound at it. The obvious constraint is “not enough contacts.” It was not. The real one was that a raw construction list is not a market. Equipment dealers, design-only firms, and trade press look exactly like real buyers in a spreadsheet, so every name I added made the list worse rather than better. The build was a gate, not a bigger list. 631 contractors survived it, and one of them wrote back to explain how his team actually decides whether to rent or own.

The three checks I run before I start

1. Say it in one sentence, with no tool in it. “Inbound dies in an inbox for three days.” If the sentence needs a product name to make sense, you are describing a purchase, not a problem.
2. Name who feels it. Point at a person and a moment in their week. A constraint nobody can find on their own calendar is a preference.
3. Say what changes when it is gone, as a number. If nothing measurable moves, it was not the constraint. It was an annoyance with a budget attached.

Starting here changes what I build. It also changes what I refuse to build, and that second part is worth more than it sounds. A good chunk of the value in a first ninety days is the list of things you did not do. When a request lands that does not trace back to a named constraint, I can say so out loud with a reason, instead of just having a bad feeling about it in a meeting.

It also protects against the most expensive failure in this job: building something excellent that nobody needed. That build still costs a quarter. It just costs it quietly.

In 2026 nearly every company calls itself “AI-native”. Most are not. The test is structural, not a matter of taste, and you can run it from the outside.

I learned this the expensive way, by once evaluating a company on its marketing rather than its architecture. It is a mistake you only need to make once.

“AI-native” is doing fundraising work now. That is not an accusation, it is just what the phrase has become. Underneath it sit two genuinely different things. One is architecture, where AI is built into the data model and the workflow engine, so builders and users get it continuously without configuring anything. The other is features, where model calls are layered onto ordinary plumbing. Both can be good products. They are not the same product, and mixing them up costs you a job, a vendor budget, or a year of roadmap.

Attio passes most of it. Clay passes most of it. Cursor passes it for code. A large share of the software that says “AI-native” in 2026 passes none of the three, and you can usually tell inside twenty minutes of reading the developer docs rather than the homepage.

What this is not

It is not snobbery. Layering model calls onto a CRM is a legitimate product and real engineering, and I have shipped plenty of it. I built an agent that resolves company identity from an email domain and chains straight into enrichment, and I would describe it in exactly those words. The discipline is naming what you built accurately, whether you are buying it or putting it on your own resume.

Which is the other half of why I keep this test around. It works on me. “Used model APIs in production” and “built autonomous AI agents” are different claims, and I would rather be the person who makes the smaller true one. Sophisticated interviewers read that as knowing where the line is. The ones who miss it tell me something too.

Where I run it

• On a company before I join, using their developer docs, not their landing page
• On a vendor before anyone signs
• On myself, so that when someone asks about my AI experience the answer is precise instead of impressive