The best developers I have worked with were not the ones who knew the most about code. They were the ones who asked what a feature was for before they built it. That habit has a name — product thinking — and it is the single highest-leverage skill a developer can add, because it changes what you build, not just how.
The feature that works and fails
Every developer has shipped one: a feature built exactly to spec, on time, bug-free, that nobody used. Technically a success, actually a waste. The code was never the problem. The problem was that nobody asked what the user was trying to do — the spec described a solution without naming the need behind it.
Product thinking is the discipline of asking that question early, while it can still change the work. Not “how do I build this?” but “what happens for the user when this exists?”
Code answers “how”. Product thinking answers “whether”. The most expensive code is the code that shouldn’t have been written at all.
What it looks like in practice
You don’t need a title change to think like a product person. You need a handful of habits.
- Ask for the problem, not the solution. When a ticket says “add an export button”, ask what the user does with the file afterwards. Half the time the real need is smaller than the request. Sometimes it’s already solved.
- Know the numbers. How many people hit this screen? How often? A developer who knows that ten users a month see a page argues differently about spending three weeks on it.
- Watch one real user. Nothing rearranges your priorities like watching someone struggle with a flow you thought was obvious. Hundreds of hours of customer conversations taught me more than any framework.
- State the cost of options. “Version A is a day, version B is two weeks” is product input only the developer can give. Giving it early is the most valuable sentence in any planning meeting.
Why this pays off personally
Developers with product judgment get handed ambiguity instead of tickets, and ambiguity is where the interesting work is. They become the person asked “what should we do?” rather than “how long will it take?”. On small teams and client projects — where WordPress work usually lives — there often is no product manager, so the developer who can fill that gap quietly becomes the most valuable person in the room.
Where to start
On your next task, before writing code, write one sentence: “When this ships, the user will be able to ___.” If you can’t finish it, that’s not your failure — it’s a missing conversation, and having it before you build is the whole skill.
And if you want a sparring partner while you or your team build that muscle, mentoring sessions on exactly this are part of how I help.