Thinking in Outcomes
What a product engineer is and is not, why the problem comes before the solution, who the users are and what they are trying to get done, and why a shipped feature is a cost until it changes something.
An engineer who owns whether the thing they built changed anything — from the question behind the ticket to the number after the launch — and can explain every decision in between.
Every ticket arrives with the solution already chosen. Decompress it into the problem, the people, the evidence, the change and the smallest test before you estimate a single line.
"Users" is not a person. Name a role doing a task at a moment, and the job they are hiring the feature to do — then build for the job, not the request.
Output is what shipped; outcome is what changed because it shipped. Being measured on the second changes what you build, how small you build it, and what you do after launch.
The sprint is the cheapest part. Support, performance, complexity and eventually removal arrive after launch, keep arriving, and are paid by people who were not in the planning meeting.
A product engineer almost never refuses. They propose the smaller, cheaper way to find out who is right — and make it easy for the person asking to say yes to that instead.