How to do product as an engineer

At most companies an engineer is handed a ticket and asked to build exactly what it says. Here you're handed a problem and trusted to figure out what's worth building, ship it, and find out whether it actually helped. That's a bigger job and a better one, and it's the autonomy we promise made concrete. This page is about how to do it well, because "own the outcome" is easy to say and takes some real habits to live.

Good product engineers, and the other kind

The difference isn't talent, it's a set of habits. Good product engineers:

• Ship quickly, so they get a real feedback loop instead of an imagined one.
• Understand where the company is going, and prioritize on that plus what they believe users actually want.
• Can propose what to build, rather than waiting to be told.
• Check that the things they've built are actually being used.
• Follow up after shipping to make the thing better, instead of moving on the moment it merges.
• Are good at descoping, and get a rough, useful version into people's hands fast.
• Know some of their users by name, and are friendly with them.
• Build without needing a pile of internal meetings first.
• Go deep when they have to, because shipping the visible thing sometimes means solving three invisible ones underneath it.

The pattern to avoid looks like this:

• Treats research as something that takes two weeks rather than two hours.
• Can't explain the company strategy, or who the thing they're building is for.
• Only works on what they've been told to, and never asks why.
• Doesn't know the name of a single user.
• Spends months on a big feature before anyone can touch it.
• Never removes anything, so complexity only ever grows.
• Optimizes for internal agreement over what users actually need.
• Waits for someone else to fix the adjacent broken thing.

Validate by shipping, mostly

The industry oversells up-front validation. Plenty of teams run flawless user interviews, hear enthusiasm, build the thing, and find nobody uses it. Real usage is a better teacher than any amount of pre-planning, which is why we ship the smallest useful change and learn from it in the open.

That doesn't mean skip thinking. It means the cheapest way to test most ideas is to build a small, real version and see what happens, not to schedule three more meetings about it. Spend two hours understanding the problem, not two weeks. Then ship something and watch.

Talk to users, directly

You, the person writing the code, should talk to the people using it. Not a summary relayed through three others; the actual conversation. It's the fastest way to understand what's really wrong, and the fastest way to tell whether what you shipped landed. A product manager will often set up the systems that make this easy, regular calls, somewhere feedback is stored and retrievable, but the point is that they bring you closer to users, they don't stand between you and them.

If you don't know who your users are or how to reach one, that's the first bug to fix, before any code.

Own the whole arc

You build it, you watch it, you improve it. That's the deal in feature ownership and it's what makes product engineering different from ticket-closing. Follow up after you ship: is it being used, did it help, what's the next small improvement. If it isn't being used, find out why, and be willing to delete it. A feature nobody uses is a cost everyone pays, so removing it is progress, not failure.

Know where the company is going

You can only prioritize well if you understand the strategy, so learn it. Read who we build for, which products to build, and how we make users happy. An engineer who can hold the company's direction in their head makes a hundred small daily calls in roughly the right direction without needing to ask. That, more than any process, is what autonomy actually runs on.

Work with product, not under it

Product managers here are context and clarity, not command. They keep the team close to users and honest about how the product is performing, and they make sure the right conversations happen. They don't hand you a backlog to execute. So treat them as a force multiplier: lean on the discovery systems and the metrics they maintain, and stay just as responsible as they are for understanding who you're building for and why.