The Product Building Treadmill
It was 2 AM on a Tuesday, and I was reviewing my team's latest feature spec. Again.
Draft #7. Still missing edge cases. Still rebuilding patterns we'd solved before. Still starting from scratch.
The worst part? We had AI tools. We had Claude, GPT-4, the whole suite. But we were still grinding out features one by one like it was 2015.
That's when it hit me: We weren't building products. We were just collecting features.
The Car That Taught Me Everything
A week later, I was explaining to my 8-year-old daughter why her toy car's wheel fell off.
"See, cars have these standard parts," I said, spinning the wheel. "Wheels, engine, seats, steering wheel. You can mix and match them, but the parts themselves? They're always the same."
She nodded, already bored, and went back to her game.
But I wasn't bored. I was having an epiphany.
What if products worked the same way?
Not as a collection of random features, but as a system of reusable primitives that you build once and compose forever?
The Search for Product Building Blocks
I started obsessing. I analyzed every successful product I could find:
- Notion: Pages, databases, blocks
- Stripe: Customers, charges, subscriptions
- Figma: Frames, components, variants
- Linear: Issues, projects, cycles
The pattern was obvious. Great products aren't built feature by feature. They're built on a foundation of primitives - fundamental building blocks that can be combined infinitely.
But here's what nobody talks about:
How do you discover YOUR product's primitives?
The Framework That Changes Everything
I spent 3 months testing different approaches with my team. We tried workshops, whiteboards, architecture reviews. Some worked. Most didn't.
Then I cracked it with a simple prompt.
This single question unlocks your product's true building blocks - the ones that make AI development actually work:
The Product Primitives Prompt
I'm working on <PRODUCT_NAME>.
<PRODUCT_DESCRIPTION>.
<PRODUCT_FEATURES>.
Thinking from a product perspective, what are the primitives within <PRODUCT_NAME> that we can build out once to let users (i.e. customers of the product) really customize the product how they like it? To do things the way they want to.
Just a reminder:
- We are built on the <PRODUCT_TECH_STACK>
- We are using <PRODUCT_INTEGRATIONS>
What are the primitives we should be building to let people customize and truly make great use of <PRODUCT_NAME>?
Clarification: I'm not talking about low-level SDK integration or anything like that; I'm trying to think high-level from a product perspective.
Building a mental model of <PRODUCT_NAME>.
The goal is to create a unique leverage points for a product <PRODUCT_NAME> such that I can build them once, but then everything else can be built on top of them. Eevery other functionality will be just extending the primitives to do additional things?
For example, if you're talking about application architecture, a primitive could be a queue, a database, a webpage, or a web app.
If you're talking about a car, a primitive would be a wheel, a steering wheel, a seat, an engine, a body of the car like that - high-level primitives over product that people use.
So, what would that be for <PRODUCT_NAME>? Hopefully, that is clear; if not, feel free to ask me any questions.
Do an example based on a <PRODUCT_JOURNEY>.Why This Works (When Everything Else Failed)
Most teams approach product development backwards. They think:
- "What feature should we build next?"
- "How do we implement it?"
- "Can AI help us code faster?"
This is why AI tools feel like faster copy-paste instead of force multipliers.
The primitives framework flips this completely:
- "What are the fundamental building blocks of our product?"
- "How do these blocks compose together?"
- "Now let AI generate every possible combination"
Suddenly, you're not building features anymore. You're building a system that generates features.
Real Example: Building an AI Project Manager
Let me show you how this actually works in practice.
Before Primitives (The Old Way)
PM: "We need a task assignment feature."
Engineer: "Okay, I'll build:
- A task assignment modal
- Assignment notifications
- Assignment history
- Bulk assignment
- Smart suggestions..."
3 days later, feature ships. Next week, rinse and repeat for a different feature.
After Primitives (The New Way)
Step 1: Run the prompt for "AI Project Manager" with product journey: "User creates project → AI suggests tasks → Team executes → Tracks progress"
Step 2: Claude identifies the primitives:
- Project (container for work)
- Task (unit of work)
- Agent (AI actor)
- Action (what agents/users can do)
- Timeline (when things happen)
- Context (information that informs decisions)
Step 3: Build these 6 primitives once. Make them composable.
Step 4: Now watch what happens:
Want task assignment? → Task + Action + Agent
Want notifications? → Task + Action + Timeline
Want smart suggestions? → Task + Context + Agent
Want project templates? → Project + Task + Timeline
Want automated delegation? → Agent + Action + Context + Timeline
We went from building 12 separate features to composing 6 primitives in infinite ways.
The 3 Changes This Made to Our Development
1. AI Actually Understands What to Build
Before primitives, AI would give us code that technically worked but felt wrong. It didn't understand the product.
After primitives, we can say: "Add a feature where agents automatically reschedule tasks based on context and timeline"
Claude knows exactly what Agent, Task, Context, and Timeline mean. It generates perfectly aligned code.
2. Features Build Themselves
We have a Slack channel called #ai-built-this where the team shares features that Claude generated without human coding.
All from primitive composition.
3. New Engineers Onboard in Hours, Not Weeks
New hire yesterday: "Wait, so everything is just these 8 primitives in different combinations?"
Me: "Yep."
New hire: "That's... actually simple."
Shipped their first feature 4 hours later.
How to Use This in Your Product
Today (15 minutes):
- Open Claude
- Replace
[PRODUCT_NAME]with your product - Replace
[PRODUCT_JOURNEY]with your core user journey - Run the prompt
- Save the primitives it identifies
This Week (2 hours):
- Review the primitives with your team
- Debate and refine (this is important - your first pass won't be perfect)
- Document them in your product spec
- Share with everyone who builds features
This Month:
- Refactor one existing feature using your primitives
- Build one new feature by composing primitives
- Measure how much faster it was
- Watch your team stop saying "we need to build X" and start saying "we need to compose Y and Z"
The Uncomfortable Truth
Most products fail not because they lack features.
They fail because they accumulate features without a coherent system.
Primitives don't just make AI development faster. They make your product comprehensible.
To users. To engineers. To AI.
And that's when everything clicks.
What Happens Next
You have two choices:
Option 1: Keep building features one at a time. Hope AI makes you 10-20% faster. Watch your product become an unmaintainable mess of edge cases.
Option 2: Spend 2 hours identifying your primitives. Build them once. Let AI compose them infinitely. Ship features while you sleep.
The primitives prompt is your starting point. Use it. Refine it. Build your system.
Then come back and tell me how many features your AI shipped this month.
P.S. - If your primitives don't feel "right" after the first pass, that's normal. The best primitive systems emerge through iteration. Start with the prompt, debate with your team, refine until it clicks.
Questions? Want to workshop your product's primitives? alex@brilliantconsulting.dev
Working with Team Brilliant? We do this in week one. Learn more →