01The shift
AI made execution cheaper. Thinking got more important.
If you don’t know how to think in systems, build in layers, stay focused on the user outcome, and use AI to sharpen your judgment, you’re not building better products. You’re building broken ones faster.
This is a PM essay, but it applies to anyone who’s been pulled into building: generalists, founders, first-time coders who’ve picked up a tool like Cursor or Claude or Codex. The mistakes are the same. There are four of them. If you fix them, you stop vibe coding like a beginner and start shipping like a product engineer.
02Mistake 1
Thinking in features instead of systems.
A lot of people start with a feature list. Login, dashboard, reminders, charts, settings. That feels productive. It’s not a product. It’s a list of parts.
A real product is a system: parts, connections, and purpose. Most people stop at parts. The way to level up is to take those parts and connect them so they produce the job the product is being hired to perform.
How do these things connect? What changes over time? What needs to persist? What causes something else to happen when this happens? What is the product actually trying to produce for the user?
Parts — what most people ship
A list of screens with a login in front.
- LoginScreen.
- DashboardScreen.
- GoalsScreen.
- RemindersScreen.
- SettingsScreen.
System — what a product is
A loop the user lives inside.
- CreateUser sets a goal.
- PersistProgress accumulates over time.
- TriggerProgress drives reminders and reflections.
- CompoundStreaks and recommendations emerge from the loop.
- OutcomeThe user actually makes progress on the goal.
An AI needs that context before it can start coding. Otherwise it generates something that looks impressive but is structurally confused.
Jim’s take
Before you ask AI to generate code, spend a few minutes writing down the system — not the screens. Figure out how they connect.
If you’re not good at systems thinking yet, use AI to learn: “how would you model this product as a system? What are the core objects? What changes over time? What should persist? What are the key relationships?” This is one of the best uses of AI — not to build faster, but to see how strong builders think.
04Mistake 2
Trying to one-shot the whole app.
You open Cursor or Claude and ask for everything at once. Front end, back end, database, auth, state, polish. For a moment it feels incredible. You have something on the screen. It sort of works. You can show it to someone.
Then the problems start. One field breaks three screens. State is handled differently in different places. The logic gets tangled. Early decisions fight each other. Now you’re not building a product — you’re untangling a mess you created.
This is where a lot of new vibe coders give up. Once the mess gets big enough, they either quit or delete everything and regenerate the same problem.
One-shotting gets you a demo. It does not get you a product.
Strong builders work in layers. One simple workflow. One simple data model. One version that basically works. Then they use it. They feel where it breaks. They show it to someone. They identify what matters next. Then they build the next layer.
Jim’s take
Don’t ask AI for the whole app. Ask for the next right layer. That one habit alone saves you from a huge amount of damage.
05Mistake 3
Falling into the feature trap.
AI makes it incredibly easy to add more. More screens, more settings, more filters, more flows. Output shows up so quickly it feels like progress. But a bigger product is not always a better product. Sometimes it’s just a more confusing one.
This is where PMs lose focus. It’s where generalists and first-time builders get into trouble because they don’t yet have the instinct to pull themselves back to the user outcome. They stop asking what the user is actually trying to get done and start adding features just because they can.
AI lowers the cost of building. It does not lower the cost of losing focus.
Jim’s take
Get back to the basics. Jobs to be done. What job is the user hiring this product to do? What is the core workflow? Does this feature actually make that workflow better?
If not, it’s probably clutter. And AI can make you a very efficient person at building clutter.
06Mistake 4
Using AI like a junior coder instead of a senior engineer.
Most people use AI like a vending machine. Write this, fix this, refactor this, patch that bug. It helps. But it’s low leverage. The better move is to use AI like a senior engineer sitting next to you — not just to generate code, but to think with you before the code gets written.
Junior posture
“Write this. Fix this. Refactor this. Patch this bug.”
Shallow execution. You get shallow architecture.
Senior posture
“How should this be structured? What belongs on the client vs. the back end? What actually needs to be stored? What’s likely to break as this grows?”
AI helps you make technical decisions, not just execute them.
The hard part isn’t writing the code anymore. The hard part is judgment. What should be simple? What should be flexible? What should be hardcoded for now? What should wait? What actually matters?
And just as important: don’t automatically trust the first answer. AI is very good at sounding right. That does not mean it is right. Push on it. “Are you sure? What’s the downside? What’s a simpler option? What would a strong engineer disagree with here?”
If you use AI for shallow execution, you get shallow architecture. If you challenge it like a senior, it starts teaching you to think like one.
07What compounds
The real advantage isn’t faster output. It’s faster learning.
Over time, when you challenge AI like a senior, you internalize the judgment. You see what good decisions look like. You release a product, you watch how customers react, you see how the architecture performs. Then you come to the next project and you’ve learned something real. You start to know which shortcuts are harmless and which ones create problems later.
Jim’s take
If you fix these four mistakes, you don’t just get better at working with AI. You become something more capable than the old version of a product manager — or the person who could never build what they wanted to build, but now has the capability.
You become someone who can think in systems, not features. Build in layers, not giant prompts. Stay grounded in the user outcome without getting lost in sprawl. Use AI not just to generate code, but to sharpen judgment.
