How to Think Like a Product Engineer
Early in my career, I was proud of how fast I could close tickets. I genuinely thought velocity was the metric. Get the ticket, build the thing, move it to done. Repeat. I was good at it.
Then I shipped a feature that nobody used.
I had built it exactly to spec. Every acceptance criterion met. The code was clean, the PR was reviewed, the QA was thorough. It was correct. It was completely useless. Nobody had thought hard enough about whether anyone actually wanted it, and I had not thought about it at all. I was too busy building.
That was the first time I seriously questioned what "doing my job well" actually meant.
The spec is a starting point, not a contract
Most engineers are spec-followers by default. Not because they are lazy or incurious, but because the system rewards it. Tickets get closed, velocity goes up, sprints get completed. It feels like progress.
The problem is that a spec is someone's best guess at a solution, written before any code exists. It is based on assumptions. Some of those assumptions are wrong. Some of them were reasonable when the ticket was written but have since changed. And occasionally, the spec is solving the wrong problem entirely.
The engineers I have learned the most from treat the spec as a starting point. They read it, they understand what it is trying to achieve, and then they ask whether this is actually the right way to get there. Sometimes it is. Sometimes there is a simpler version that gets 90% of the outcome for 20% of the work. Sometimes the spec is pointing at a symptom when the actual problem is somewhere else.
You cannot see any of that if you just start building.
Ask why before you open your editor
I have a habit now that I picked up out of frustration with my past self. Before I start any new feature, I spend about 15 minutes writing down what success looks like. Not the technical spec. The outcome. What does the world look like if this works? What metric moves? What does a user do differently because this thing exists?
It sounds simple. It is embarrassingly clarifying.
A feature built to reduce churn is a different feature from one built to acquire new users, even if the UI looks identical. The edge cases you prioritize, the error states you invest in, the copy you push back on because it confuses new users versus the copy that is fine for existing ones, all of that changes depending on why you are building the thing. If you do not know why, you are making those calls arbitrarily.
The questions I try to answer before writing a line of code:
- Why is this being built now?
- What does failure look like, and how would we know?
- Who is the actual user and what are they trying to do?
- What is the one thing this feature has to get right?
Not as bureaucratic process. Just because the answers change how I build.
Proactive opinions, not passive execution
The first time I pushed back on a spec and suggested a different approach, I was genuinely nervous. I had the thought that maybe this was not my place. I was an engineer, not a PM. My job was to build the thing, not redesign it.
The PM's reaction: "I've been waiting for someone to say that."
That was a turning point. PMs are not withholding context or trying to hand you bad specs. They are doing a hard job under real constraints and they often do not know what is easy versus hard to build. I did not know what actually mattered to the business. The conversation between us was where the good decision was going to get made, and I had been opting out of that conversation entirely.
Now when I see a better path, I bring it up with the tradeoffs spelled out. Not "I don't want to build this." More like: "I can build what's in the spec, which is probably three weeks of work. There's also a version that takes three days and I think it moves the same metric. Worth five minutes to talk about it?"
That is not overstepping. That is the job.
Get curious about how your product actually gets used
I started sitting in on customer calls when I could get myself invited. I started reading support tickets. Not because anyone asked me to, just because I kept making decisions in the dark and I was tired of it.
The first time I watched a user get confused by something I had built, I felt it in a specific way that no bug report ever produced. The mental model I had built the feature around was just not the mental model the user had. I had been totally confident in my implementation. It was the wrong implementation.
That kind of feedback rewires how you think about your work. You start asking different questions during implementation. You think about the person who is going to land on this screen without any of your context. You get less precious about your own ideas when you have seen enough of them fail in the real world.
The curiosity extends to the business too. How does the company make money? What is the north star metric? How does the thing I am building connect to that? I used to think this was not my concern. Now I think it is some of the most useful context I can have.
Edge cases are product decisions
Most engineers treat edge cases as technical problems. You either fix them or you do not. If you do not, you feel a little guilty about it and move on.
Product engineers treat edge cases as product decisions, and that is a meaningful difference.
"One in a thousand users hits this error state. The fix takes two days. If we skip it for now, support can handle it manually and we address it next sprint." That is a valid decision. It is not a corner being cut. It is a conscious tradeoff made with the right information.
The problem is you cannot make that tradeoff well without product context. Without it, you either spend two days fixing something that affects three users a month, or you ship something genuinely broken for a segment of users that actually matters. Both happen all the time. Both are the result of treating edge cases as purely technical problems.
Knowing which edge cases matter requires understanding the user and the business. There is no shortcut.
Shipping is not done
Done is when you know whether it worked.
This is the habit I think most engineers skip, and I skipped it for years. You ship the feature, the ticket goes to done, you move to the next thing. The feedback loop never closes.
The most underrated thing you can do after a feature ships is check whether it solved the problem. Not to find bugs. To see if the assumption was right. Did the metric move? Are users engaging with it the way we expected? If it underperformed, was the assumption wrong, or was it built correctly but the wrong thing? Those are different problems with different implications for what you do next.
I have shipped features that were technically correct and solved the wrong problem. I have shipped features that underperformed not because the idea was wrong but because the implementation missed something important. You can only tell the difference if you look.
The engineers who close the feedback loop consistently develop product judgment faster than everyone else. The ones who skip it stay at the same level of product intuition indefinitely, because intuition is just pattern recognition and you cannot build patterns from incomplete data.
Build real relationships outside engineering
The PM relationships that have been most useful in my career were not professional-cordial. They were genuine. I was actually curious about how they thought, what pressures they were under, what they were trying to figure out.
When a PM trusts your product judgment, they bring you in earlier. They share context before the spec is written. They take your alternatives seriously. That trust is not given because you have a good attitude. It is earned by consistently showing up with well-reasoned opinions and following through on what you say you are going to do.
The same is true with designers, data people, support. Every one of those disciplines has context that makes me better at my job. Support knows which problems users are actually experiencing. Data knows what the numbers actually mean versus what people assume they mean. Designers know things about user behavior that engineers rarely think to ask about.
Being curious about how other people think is not soft skills fluff. It is how you get the information you need to build the right things.
The shift
I am not going to pretend this mindset is easy to adopt or that I have it fully figured out. There are still times I catch myself building exactly what the spec says without asking enough questions. Old habits are sticky.
But the difference between the work I was doing before and the work I do now is real. Not just in quality. In how it feels. Building something and knowing why you built it, following up to see if it worked, having an opinion about whether the next thing on the roadmap is actually the right next thing, that is a more interesting way to spend your time.
The ticket-closing version of the job is fine. The product engineering version of the job is better.
Start with why. Then build.