Stop asking “what should we add next?” and start asking “what for?”, because every new feature brings new support… and sometimes it doesn't even bring real usage.
There's an idea that has been following me for a while, building software keeps getting easier, and yet we keep falling into the same trap. Not bugs, not frameworks, not architecture. Something more basic: confusing "making" with "improving."
I'm increasingly convinced the bottleneck isn't just implementation anymore. With AI, the cost of writing code goes down, speed goes up, and with that comes a dangerous temptation: if we can build almost anything, we build more. And when we build more without a clear compass, the product fills up with things that don't match real usage.
What worries me most isn't "bad" functionality, but irrelevant functionality—the kind of feature that arrives urgently, gets delivered, gets celebrated… and then quietly disappears in practice. Not because it's removed, but because nobody really incorporates it into their day-to-day. Sometimes there wasn't even a hypothesis. It was born from "we want to add X" rather than "people are trying to do Y and can't right now."
And even if it isn't used, that feature never fully goes away. It lives on as complexity, more states to handle, more edge cases to test, more permissions to reason about, more documentation that rots, more "weird" behavior that comes back the moment someone touches that area. Every new thing you put into a product opens a door to confusion, friction, and doubt. That debt hits the user—but the team pays it too, for months or years, maintaining and explaining something that wasn't essential in the first place.
"Everything is technically possible." With the right team and enough time, you can build almost anything. But we can isn't a reason. It's a temptation. A product isn't built to prove technical capability; it's built to be used. And that changes the criteria: not everything that can be built deserves to exist inside the product.
Building product is, by definition, keeping in mind how it will be used. Not as a finishing detail, but as the starting point. The difference between "developing software" and "building product" lives right there. The goal isn't to ship something; it's to improve a real experience.
That's why it's a red flag for me when development starts from the wrong question. When the conversation revolves around "what do we add next?" instead of "what for?" or "what are people trying to achieve, and where are they getting stuck?" It sounds like a small difference, but it changes everything. If you start from real usage, constraints appear: who uses it, when, what alternatives they have, what hurts, what "better" actually means. If you start from "adding something," you optimize for getting it into production. Even if it doesn't fit, even if it isn't validated, even if it won't hold up over time.
At that point, two signals matter more than we like to admit: (real) adoption, and support as a sensor. Tickets, friction, recurring questions. Of course, not everything is measured through direct usage; compliance or enterprise features can be rarely used yet critical. That's exactly why it matters that a feature exists with a hypothesis and a metric, even if it's indirect. The problem isn't "low usage." The problem is "no meaning, no hypothesis, no measurement, no owner".
You can't fix this with good intentions alone. You need structure, a real place for this way of building in how teams are organized, how impact is evaluated, and how responsibilities are designed. That's why I find it useful to talk about a role like Product Software Engineer.
When I say "role," I mean it: something formal, with a clear growth path. Not to create an elite category, not to make it trendy, but to avoid the usual outcome, product thinking becoming invisible labor, without authority, recognition, or boundaries. The value here isn't "knowing more about product." It's judgment and perspective, and that tends to come with experience.
A Product Software Engineer isn't a disguised technical PM. They don't have to do management, talk to customers, sell a vision, or run stakeholder coordination. It's a different way of understanding development: participating in the full cycle of building a solution, with permission (and expectation) to discuss priorities, challenge the need for functionality, propose alternatives, and ask the uncomfortable question before complexity becomes a permanent resident in the product.
The key isn't replacing other roles. The biggest risk is misusing this role, turning it into an excuse to cut PMs or design, or loading one person with responsibilities that don't belong to them. If you formalize a role like this to "save" other roles, you're not creating a Product Software Engineer; you're creating an overloaded engineer with no focus. The role works when collaboration is real and boundaries are clear. Collaboration not as a nice word, but as system design: who decides what, how priorities are debated, how ideas become hypotheses and metrics, and how disagreements get resolved without becoming theatre.
And this is where I come back to AI, because it's the accelerator that turns all of this from "interesting" into necessary. AI makes it easier to produce code, yes, but it doesn't automatically reduce the real cost of building high-quality software. Sometimes it increases it, more surface area for bugs, more accidental debt, more risk if there isn't judgment. What it definitely does is shift the center of gravity. Before, the question was "can we build it?" Now it should be "should we build it?" and "how will we know quickly if this actually helps?". When building becomes cheap, choosing the wrong thing becomes expensive. Expensive in focus, complexity, maintenance, support, and user trust.
If I had to reduce all of this to one idea, it would be simple: we build a product to be used. Before opening the IDE, before estimating, before designing a solution, it's worth pausing and asking what this exists for, who will use it, what they're trying to achieve, how we'll know it worked, what support it will generate, what it will cost in six months, what simpler alternative exists. That pause isn't bureaucracy. It's responsibility.
I don't know if the right name is Product Software Engineer. Honestly, I don't really care about the name. What I do believe is that this responsibility needs to exist explicitly. Without it, products fill up with things that get shipped but don't get used, and teams fill up with work that doesn't improve anything. If everything is possible, what will differentiate us isn't our ability to build it, it's our ability to choose what deserves to exist inside the product. And that choice shouldn't be accidental. It should be part of the job.