There’s a version of software engineering where the work arrives neatly packaged. A ticket describes the requirement, an engineer implements it, tests pass, the ticket moves to Done.
Real product work is rarely that tidy.
A ticket is a starting point
The most useful question I’ve learned to ask is often the simplest: what problem are we actually trying to solve?
That question changes the conversation. A requirement that sounds like a button might really be about giving somebody confidence that a process has completed. A request for another status might actually expose that the underlying workflow is unclear. A seemingly small UI change can reveal assumptions in the API or data model that nobody noticed when the ticket was written.
I don’t think challenging that means being difficult. Done well, it is part of the job. Product brings context, users bring needs, engineering brings knowledge of the system, and the useful answer normally appears somewhere between them.
Understanding the outcome changes the implementation
When I understand why something matters, I make better technical decisions. I can spot where a simpler solution might be enough, where a failure state needs more thought, or where the proposed approach creates complexity the user will never benefit from.
It also makes trade-offs easier to discuss. “This will take longer” is not particularly useful on its own. “This version gives us the outcome now, while this extra complexity only matters if we later need X” is a product conversation people can actually make a decision with.
The code is part of the product
I like working close to product because it stops engineering becoming an implementation service. The technical shape of a feature affects what is possible, how quickly it can change and what happens when the happy path breaks.
Equally, understanding the user stops technical elegance becoming the goal in itself. Sometimes the cleverest solution is not the most useful one.
The ticket matters. But the ticket isn’t the problem. The problem is the thing somebody needs to do, understand or achieve — and that is where I want the engineering conversation to start.