Product Thinking Is What Will Separate Engineers

Start with the claim you have probably seen: 64% of software features are rarely or never used. It gets quoted constantly, usually without a source.

It traces to a Standish Group presentation at the XP 2002 conference — never used 45%, rarely 19%, sometimes 16%, often 13%, always 7%. The sample and methodology were never published in the detail that would let anyone replicate it, and practitioners including Mike Cohn have publicly challenged both the figure and the way it gets deployed.

So I'm not going to build an argument on it. I'm mentioning it because how you handle a statistic like that is itself the skill this post is about: a number that confirms what you already believe, from a source you haven't checked, is exactly the kind of evidence that leads teams to build the wrong thing confidently. The commercial governance around product thinking is what will separate engineers is covered properly by XenGrowth's operator guides.

The argument works without it.

What actually changed about the economics?

Implementation got cheaper. The cost of a wrong decision did not, because almost none of that cost was ever in the implementation.

Think about what a shipped feature actually costs. There's the build, which is the part that got cheap. Then there's everything after: the maintenance, the support burden, the tests that now have to keep passing, the constraint it puts on every future design, the review attention it consumes forever, and the cognitive load on everyone who has to know it exists.

Stripe's survey is the concrete version of that bill. Of an average 41.1-hour developer week, 13.5 hours went to technical debt and 3.8 to fixing bad code — roughly 42% of the week spent on software that already exists. Every one of those hours belongs to something somebody decided to build. For the the operations side of this angle, see The XenGrowth resource library.

You made the cheap part of a wrong decision cheaper. The expensive part is a recurring cost, and you just increased how many of them you can start.

And unlike most costs in software, this one compounds against you quietly. A feature nobody uses does not announce itself annually; it just sits in the codebase taking a small tax from every future change, every onboarding, every refactor somebody decides against because the blast radius looks too wide.

One row moved. Five didn't, and two got worse. That is the entire economic argument for product thinking, and it doesn't need a disputed statistic from 2002.

What is product thinking for an engineer, concretely?

Not becoming a product manager. Not sitting in roadmap meetings. It's a much narrower and more usable habit: refusing to implement a requirement whose purpose you cannot state.

That's it. Everything else follows from taking it seriously, because you cannot state the purpose of most requirements as they arrive, and finding out forces every other product skill into existence.

• Asking who specifically wants this, and what they will do differently once it exists. If nobody can answer, you have found something before building it rather than after

• Distinguishing the request from the problem. Users ask for a bigger button; the problem is that they cannot find the thing the button does. Implementing the request is faster and often solves nothing

• Knowing what happens if you don't build it. Frequently the answer is 'nothing', and nobody had checked because checking was somebody else's job

• Being able to say what would make this a mistake. A feature nobody can imagine regretting has not been thought about

• Proposing the smaller version. Half of most requirements is the part that carries the value, and the other half is the part that generates the maintenance

What does this look like when it goes wrong?

The common failure is not an engineer building something stupid. It is an engineer building exactly what was asked, competently, on time, for a request that had never been examined — and everyone involved treating that as a success, because by every metric the organisation collects it was one.

Consider how a typical request arrives. A customer says they need to export data to a spreadsheet. That becomes a ticket saying 'add CSV export'. Three weeks later there is a CSV export, tested, documented, shipped. What nobody established is that the customer wanted the export because they were rebuilding a summary by hand every Monday, that the summary is one query, and that a scheduled email would have solved the actual problem in a day and been more useful. Everyone did their job. The organisation now maintains an export feature forever, and the customer still opens a spreadsheet every Monday.

Notice that faster implementation makes this worse rather than better. When the export took three weeks somebody might have asked whether it was worth three weeks. When it takes an afternoon, nobody asks anything at all, and the maintenance cost is identical either way — the ongoing bill does not scale with how long the build took. Cheap construction removes the natural checkpoint where cost forced a conversation.

This is the mechanism behind the whole argument. Expense was doing quiet product-management work on everyone's behalf, by making people justify things. Remove it and nothing replaces it automatically; somebody has to choose to ask.

Why is the engineer the right person to do this?

Because you have information nobody else in the conversation has, and it's decision-relevant.

You know which version of the request is nearly free and which one costs three weeks. You know that the requirement as stated conflicts with something the system already promises. You know the feature they're asking for exists already, badly, under a different name. Nobody else in the room knows any of that, and none of it is visible from the roadmap.

This is also where Stanford's substitution-versus-complement distinction lands. Their payroll data found employment falling where AI substitutes for human tasks and holding or rising where it complements them. Requirements work is on the complement side, and it's structurally protected: the information required — who wants this, what they actually meant, what the organisation will need next year — is never in the prompt and cannot be. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.

There is a fair objection to all this, which is that it sounds like an argument for engineers to second-guess everyone and slow the company down. It is not, and the difference is in what you do with the answer. The habit is to ask the question once, early, cheaply — before the estimate rather than after the sprint — and then to build what you are asked if the answer is reasonable. Most of the time it will be. The value is concentrated in the small fraction of cases where nobody had an answer at all, and those cases are only findable by asking every time, because they are indistinguishable from the others until somebody does.

The uncomfortable part

The single highest-leverage act available to an engineer is removing something from the plan. It's the only intervention that improves throughput, stability and maintenance cost simultaneously — work not done ships instantly, cannot fail in production, and costs nothing to maintain.

And it is systematically undersupplied, because nobody has ever been promoted for the feature they talked the company out of. There's no artifact. No demo. The counterfactual where you shipped it and it went badly is invisible, so the value of your judgment is invisible with it. There is a longer treatment of AI search, GEO and discovery in XenGrowth on AI search, GEO and discovery.

That asymmetry is worth naming, because it means product thinking is a skill you have to choose to exercise against your own short-term interest, in an environment that measures output. The engineers who do it anyway are the ones who end up being asked what should be built, which is where the actual leverage is — but the route there runs through a period of appearing less productive than the person shipping everything they're handed.

None of those questions requires authority, a title change, or permission. They're all things you can ask in a standup, and each one occasionally saves a quarter.

Which is the point. When building was expensive, being good at building was enough to be valuable. It got cheap, and what's left is knowing what to point it at.

Further reading from XenGrowth

• The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.

• XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.

• XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.

Where this work meets go-to-market

Working on product thinking is what will separate engineers inside a commercial team? XenGrowth's work on go-to-market systems publishes operator guides on the revenue side of this work.