Morphing into a product engineer

I have been thinking a lot about what it actually means to be a good product engineer.

For a long time, I thought the answer was relatively straightforward. Write good code, understand systems, make good architectural decisions, know your tools and ship things.

I still think all of those things matter, but the more I work on products, especially on small teams where there is nowhere to hide, the more I think there is another part of the job that is easy to ignore.

You need to understand what you are actually building and why you are building it.

The product cap

I recently had a conversation with someone I am working with about how we should work together. I asked a fairly simple question:

Do you want me to just be an engineer and build whatever you want, or should I put on my product cap as well?

The answer was yes, put on the product cap.

There was an important distinction, though. She owns the product vision and is the final decision maker on the product. My job is not to become a second product manager or start pulling the product in a completely different direction. My job is to understand the vision well enough to help figure out how to make it real.

I like that distinction, and I think it is probably where I want to spend more of my time.

This way of thinking did not come from one conversation. It has been building up through the products I have worked on.

At Bfloat, I took some time away from simply building the product to help market it, explain it to users and support customers. That experience changed how I thought about software.

When you spend most of your time inside the codebase, it is easy to think about the product in terms of features, components, APIs and workflows. When you have to explain the product to someone who does not care about any of those things, the perspective changes.

Customers do not think about the system in the same way engineers do.

They think about the job they are trying to get done.

They have a problem, a process, a constraint or an outcome they care about. They are not necessarily interested in the technology behind the product. They want to know whether it helps them do what they need to do.

That distinction has stuck with me.

I have seen the same thing through Rentobase. There are plenty of interesting technical problems that can be solved, but the existence of a technical problem does not automatically make it a product problem. The question has to come back to the customer and the business.

What are we trying to help the customer accomplish?

What is preventing them from accomplishing it today?

What does the business need to make that solution sustainable?

And then, only after understanding those things, what technology should we use to solve it?

Business first, tech second

I am increasingly convinced that the core of a product should be the customer’s demands, not the technology.

This sounds obvious, but I think it is easy for engineers to get this backwards.

We know what technology can do, so we start looking for problems that technology can solve. We find an interesting architecture, a new framework, a new AI model or an abstraction that could make the system more elegant, and it becomes tempting to find a reason to use it.

I have done this myself.

There are an almost infinite number of things you can improve in a software system. You can refactor something, introduce a new abstraction, change the architecture, add background jobs, introduce caching or build a better search system. Most of these things can be justified technically.

That does not mean they matter to the customer.

The technology should support solving the customer’s problem. It should not become the reason the problem is being solved.

For me, this is what business first, tech second means. It does not mean that technology is unimportant. It means that technology exists in service of an outcome.

The business tells us what is worth solving. The customer tells us what the problem looks like. Engineering figures out how to solve it.

Building the right thing

There is a big difference between being told to build a feature and being told what problem the feature is supposed to solve.

The first one gives you an implementation task. The second gives you something to think about.

If I understand the problem, I can challenge the proposed solution. I can think about the user experience, the technical implications, the cost and whether there is a simpler way of getting to the same outcome.

Sometimes the answer will still be the original feature. Sometimes it will not.

That is where I think product thinking becomes useful for an engineer. You stop treating the ticket as the problem and start treating the outcome as the problem.

It also changes the way I think about technical improvements.

I might have an idea for something that would make the system better, but unless there is a real need for it, I am becoming more comfortable keeping that idea in my head. If the problem eventually appears, the solution is already there. If it does not, then I have saved everyone the time and complexity of building something nobody needed.

The best technical decision is not always the technically most interesting one. Sometimes it is the boring one that solves the problem we actually have.

Opinions are cheap

The other thing I want to get better at is separating opinions from evidence.

The product can change. Ideas can morph. We can discover that something we thought was important is not important at all. I am completely comfortable with that.

What I do not want is for the product to slowly become something else because we kept making decisions based on whoever had the strongest opinion in the room.

I like the idea of being able to explain how we got from the original idea to whatever we eventually build. Not necessarily because every decision was correct, but because the reasoning is clear.

We thought the user had a particular problem. We made an assumption about it. We built something to address it. We looked at what happened and learned something.

Then we changed the product.

That feels much healthier than defending an idea simply because it was the original idea.

Working with customers has made this even clearer to me. The person building the product is not always the person who understands the problem best. Sometimes the most useful thing an engineer can do is step away from the code and listen to someone who uses the product every day.

Senior engineering

I have started to think that senior engineering is less about knowing more syntax and more about understanding more context.

Who are we building this for? Why does this problem matter? What does the business actually need? What does the customer actually need? What are the constraints? What are we optimizing for? What are we deliberately not doing?

And then, once all of that is understood, how should we build it?

I still care deeply about the technical side. I enjoy designing systems, figuring out how things should fit together, writing software and thinking about infrastructure and all the small details that make a system work properly.

I do not think product thinking replaces engineering. It gives engineering context.

It also makes engineering more interesting to me because the technical decisions become connected to something outside the codebase. An architectural decision is no longer just about whether the code is elegant. It is about whether that decision helps the business move faster, reduces a customer’s pain, lowers a cost or allows the product to do something it could not do before.

I do not want to be a product manager

At least, I do not think I do.

I do not want to own every product decision. I do not want to spend my days doing market research or managing roadmaps.

What I do want is to be the engineer who understands why the roadmap exists.

I want enough context to be able to say, “I understand what we are trying to achieve, and I think there is a better way to get there.”

I also want to be able to say, “I understand why you want this. I disagree with the approach, but the goal makes sense.”

And sometimes I want to be able to say, “I do not think we should build this yet.”

Not because I do not want to write the code, but because I do not think the code is the most useful thing we could be doing.

That feels like a more interesting version of software engineering to me.

I am still figuring out what that looks like in practice, but I think I am finally starting to understand what I want my version of being a senior engineer to look like.

Not just someone who can build the system, but someone who understands the customer, the business and the reason the system exists in the first place.