“What exactly makes us different?” Once this question keeps resurfacing, engineers easily fall into two extremes: either deciding it’s entirely someone else’s problem and simply waiting for requirements to land, or conversely promising that “building a new tech feature” will solve the positioning. I’ve been in both extremes — the former turned me into someone who waits for requirements, the latter made me mistake technical novelty for value.
Both approaches are too easy. Technology certainly can’t replace user value, but engineers also shouldn’t shrink themselves into people who merely implement interfaces.
First, distinguish: no answer, or a problem that hasn’t been clearly stated
An internal tool redesign was once criticized for being “no different from before.” Someone immediately suggested adding more sophisticated automation capabilities. But the first question to ask isn’t “what more can we add,” but: where do users actually spend their time? Are they unable to find information, forced to fill things in repeatedly, or unable to judge what to do next?
If even this has no answer, what the team lacks isn’t a feature but a problem definition. Engineers can help shift the discussion from “make something cool” to “let a certain group of people complete a certain task in fewer steps.” This isn’t overstepping into product decisions; it’s giving decisions a verifiable object.
Three genuine contributions engineers can make
First, surface the constraints. An idea may be appealing, yet require three months, pull in multiple dependency chains, or reduce reliability. Stating these costs early helps the team avoid treating wishes as promises.
Second, lower the cost of validation. There’s no need to build the full system in one go. You can start with a small-scope entry point, a throwaway prototype, or use existing data to validate the most critical assumption. Engineering’s value is often not “doing more,” but letting errors surface earlier and more cheaply.
Third, uncover overlooked friction. Engineers sit close to logs, exceptions, operation paths, and dependencies, and often see earlier than anyone else: a step that keeps retrying, a flow that can only be saved by manual intervention, a promise that doesn’t hold under edge conditions. These details are precisely the evidence for understanding the user experience.
Don’t treat technology as a stand-in for distinctiveness
Technical solutions can improve speed, cost, stability, and accessibility; any of these can become part of the value. But “using a new technology” is not itself value. The real questions remain: who finds it easier to accomplish what as a result? Can the improvement be seen? Is the cost worth it?
When the team can’t yet articulate its unique value, the most useful engineering work is to help narrow the problem, surface constraints, and design validation — no need to rush out a grand answer. The answer can come later; a more reliable path of discovery is already an important contribution.
A practice path from requirements to judgment
Engineers don’t have to take on full planning from the start. You can first understand the requirement, then the user task it serves; then observe outcome and process signals to understand the original trade-offs; and finally attempt to point out new problems and opportunities. When asked to “add a filter option,” first ask whom it helps narrow choices and in what scenario; after release, check whether it actually reduces searching and repeated operations. Only this way does technical work gradually enter the value chain.
Before proposing a technical suggestion, write down three things: what task the user cannot complete; what mechanism we are changing, rather than just what feature we’re adding; and what the minimal validation, success signal, and exit condition are. When you want to build “smart recommendation templates,” first show a small group of users suggestions based on their historical choices and observe whether searching and editing decrease; if people don’t trust the recommendations at all, optimizing the algorithm is not the next step.
A common pitfall is treating technical novelty as value, or only backfilling data after the conclusion is reached. Pick one requirement from this week and use six sentences to write down the user task, obstacle, assumed mechanism, minimal implementation, success signal, and side effects. Wherever you can’t write it out is the context you still need to fill in.