The engineers winning with AI right now aren't the ones who understand how transformers work. They're the ones who understand users.
Building used to take weeks, so being a fast and reliable engineer was enough on its own. You could be the person who shipped clean code on time and that was enough to look good, even if the feature was confusing or hard to use, that was someone else's problem.
AI collapses building to hours. Any engineer can ship a feature fast now. What separates engineers is whether they thought about the person using it.
Why AI changes the equation
Building used to be the expensive part. A feature took weeks, and once it was out, fixing what you got wrong was its own project that had to fight for roadmap space. AI changes that. Building is cheap now. The hard part is the dozen small decisions that aren't in the spec but determine whether the feature actually works for the person using it.
You might push back here. Isn't AI also getting better at product judgment? Claude can suggest edge cases, draft empty states, flag missing flows. True, and you should use it for that. But AI doesn't know your user. It doesn't know that the person logging in for the first time is a new employee, anxious about whether their account is set up right and their salary will arrive on time. It doesn't know that "No payslips found" reads as broken to someone who's never used the product before. AI can give you ten plausible empty states. You still have to figure out which one is right for the person on the other end.
What product-focused actually means
Product thinking matters at every stage. What it looks like changes with the company.
It's most obvious at an early stage startup. The ticket is a couple of sentences in Linear and a Slack thread with the founder. It covers the happy path: there's a button, it runs payroll, the employer sees a confirmation. It doesn't cover what happens when an employee hasn't added their bank account yet, or when one of them was terminated last week, or when the payment hasn't gone out yet but the payslip is already showing. Nobody specced these cases because nobody had thought of them yet. You're seeing them because you're the one writing the code, which means you're the one deciding how the product should behave when reality doesn't match the happy path.
It doesn't stop mattering when the company gets bigger and the specs get longer. It just gets harder to notice. A PM at a larger company can spec out the payslip download feature in detail, with a Figma file, acceptance criteria, and a flow diagram. Build it and ship it. Except the file lands in the user's downloads folder as payslip.pdf, payslip(1).pdf, payslip(2).pdf, because the spec said "let users download their payslip" and didn't say anything about the filename. An employee applying for a visa now has to rename three files before they can submit anything. The engineer who thought about where this file ends up names it Payslip_April_2026_Sahil_Yadav.pdf from the start. Nobody specced that. It takes two minutes and saves every employee downloading their payslips from doing that work themselves.
That's what product-focused means. Not sitting in roadmap meetings. The judgment calls that land on you because nobody else is going to make them, no matter the company size or how good the spec is.
How to build this muscle
The good news is that product judgment isn't a personality trait. It's a habit, and the engineers who have it built it the same way anyone builds a habit: deliberately, on purpose, over a lot of features.
Walls cost the same to build and to remove. A first-time employer logs in to run payroll. They hit a wall: no bank account on file. They figure out where to add one, add it, come back. They hit another wall: no pay schedule. Off they go again. By the time they actually run payroll, they've context-switched four times and the product feels broken. An engineer who thought about the flow puts an "Add bank account" button right there in the payroll run UI, so the employer can do it without leaving the screen. Same five minutes of work either way, completely different experience for the person on the other end. The spec gets you a feature. Thinking about the user gets you a product.
Use Claude to find your blind spots. The user you picture at the start of a feature is usually the only user the feature actually works for. So list out every situation a real user could be in when they hit this flow (onboarding incomplete, compliance pending, data half-filled) and every state the feature itself could be in (empty, loading, error, partial data). Hand Claude both lists and the feature description, and ask what you missed. Claude isn't smarter about your product. It just doesn't share your blind spots.
Your view of the product isn't the user's. You built the thing with admin access and the whole flow loaded in your head. They're seeing it for the first time, on mobile, at the end of a long day. Sign up fresh with a new email and run through the full setup with no shortcuts. Or hand the laptop to a teammate who hasn't seen the feature and watch them use it without saying a word. You'll notice everything that's broken in twenty minutes.
Shipping is when the work starts. A while back I shipped a major feature. I watched a few users go through it and saw stuff I hadn't thought of, some places they hesitated, some things they expected that weren't there. I patched them that week. If I hadn't watched, those users would still be struggling, and I'd be staring at the support queue trying to figure out what went wrong. So next time you ship something, open session replays and watch a few users go through it. Every place they hesitate or backtrack is a wall you didn't see.
What this means for you
AI will build whatever you decide. It just won't decide what.
So try this with the next feature you're about to build. Before you write a line of code, write down who's using it, what they're trying to do, and what's standing between them. List the situations they could be in and the UI states the feature could be in, hand both lists to Claude, and ask what you missed.
Before you ship, run through it yourself with a fresh email or hand it to a teammate.
And after you ship, watch five people use it. They'll see the obvious problems you stopped noticing weeks ago. Jakob Nielsen's research found that five users is enough to catch around 85% of a flow's usability problems. The number isn't the point. Users hit problems you'd never run into, because they're trying to get something done and you're just trying to verify the code works.
That's the work. AI doesn't do it for you, it just builds whatever you decide on, faster than you ever could yourself. The decision is still the part that matters.