Product Engineer Is Not a Rebrand

Somewhere right now, a company is renaming its Support team to Customer Success. Same people. Same tickets. Same queue. Same person named Jody who handles the angry ones. The only thing that actually changed is the Slack channel name, and half the org will keep typing the old one for two years out of muscle memory.

We're about to do this to "Product Engineer." I can feel it coming. There will be a LinkedIn wave, then a conference talk, then a recruiter will message one of your developers about an exciting Product Engineer opportunity that is, on inspection, a Rails job with the same salary band and a founder who says "we move fast here" in the first ten minutes.

So before the term gets hollowed out and sold back to us on a t-shirt, I want to write down what I actually mean by it. Not the vibe. The specific things that are different on a Tuesday.

Let's get into it.

The rebrand version

Here's how you know it's a rebrand.

Titles change. Nobody's calendar changes. Nobody's definition of done changes. The tickets still arrive fully specified from somewhere upstream, the developers still build exactly what's in them, and the retro still ends with "we should have caught that earlier" and no mechanism by which anyone could have caught it earlier.

Congratulations, you have Product Engineers. They do the same job with a nicer noun.

This is not a hypothetical failure mode. It's the default one, because renaming is free and changing how decisions get made is expensive and annoying and involves telling several senior people that a thing they enjoy is no longer their exclusive property.

So what actually changes

Five things. If none of these are true, it's a rebrand.

You have to be able to say who it's for.

Before you write code, you can name the person who has the problem and describe their day. Not a persona document. A person. "The site supervisor who's doing this at 6:45am in a truck" is a real answer. "The user" is not an answer, it's a placeholder we all agreed to stop questioning about fifteen years ago.

This sounds soft until you watch how many builds it kills. A shocking number of features die the moment somebody has to say out loud who wanted it.

You're expected to say no.

Not allowed. Expected. There's a difference, and every developer knows it, because "you're allowed to push back" in most orgs means "you're allowed to push back once, and then be quietly known as the difficult one."

If a developer spends a day investigating and comes back with a well argued "we shouldn't build this," that's a good day of work. It has to be treated like one, publicly, or you will get exactly one of them and then never again.

You go to the source.

Not the summary of the source. Not the ticket that summarizes the summary. You get on the call. You watch someone use the thing. You read the support threads.

Everyone nods at this and nobody does it, because it's never urgent and there's always a sprint on. It has to be scheduled or it doesn't happen. I'll get to that.

You review the idea, not just the diff.

Here's the one that's actually hard. The code is clean. Tests pass. Naming is good. And the whole thing solves a problem nobody has.

Under the old rules, you approve it. It's not your call, the ticket said to build it, and blocking a PR over product direction is how you become the difficult one again. Under the new rules, that PR is wrong and saying so is part of the job.

This one takes about a year of consistent leadership behaviour to make real. People need to watch it go well for someone else before they'll try it.

You own the outcome, not the output.

Shipping is not the finish line. Did it get used? Did the number move? Did the thing you were worried about happen?

If your team's definition of done ends at deploy, everything above is decoration.

What it is not

Three quick ones, because every time I talk about this someone hears something I didn't say.

It's not "engineers do product management now." The PM still owns the why and the for whom. What changes is that they're not the only person carrying it. There's a whole post coming on this because the boundary is genuinely tricky and I've watched it go badly.

It's not "engineers do design now." Please, no. I've seen my own attempts at UI. There's a reason I write backend code and my wife picks the paint colours.

And it is emphatically not the end of deep technical work. I wrote a whole post about legacy code and I stand behind every word. Somebody still has to know why the system does the weird thing, whether the machine's confident output is wrong, and what happens at 300 concurrent users on a Monday. That skill went up in value, not down. The difference is that it's no longer the whole job description.

What we're doing at Corfix

We're partway through this. I'm writing from the middle of it, not the end, and some of it is going better than the rest.

Things that are working:

Developers in the room early. This is the big one. Product doesn't finish a plan and then hand it over. Developers are in the early conversations, and the conversation is about how a specific user is going to use this specific thing to solve a specific pain point. Not requirements. Not acceptance criteria. How does this actually go for the person holding the phone.

The change is that developers aren't waiting for a ticket to appear anymore. They're helping shape the thing while it's still soft enough to shape, which is roughly one thousand times cheaper than pointing out the problem after somebody's built it.

Problem statements in the ticket. One or two lines, at the top, before anything else. Who has this problem, and what happens to them today. It takes ninety seconds to write and it kills bad builds before they start.

Things that are just getting started:

Developers on customer calls. We've done it a few times now and it's ramping up. It's going to become a normal part of the job, not a special occasion. Not everyone, not every call, but on calendars, with what they heard coming back to the team afterward.

I expect the first several to be a bit awkward for everybody involved, including the customer. Doing it anyway.

Things that are not working yet:

Saying no is still rare. I can count the number of times someone has come to me with a researched "let's not" on one hand. That's on me, not them. It means I haven't made it safe enough or visible enough, and I suspect the fix is that it has to happen to a senior person first, loudly, with a good outcome.

And we're still measuring output more than outcome, because output is easy to count and outcome requires you to go back and checking, and going back and check is nobody's favourite Thursday.

If you want to start this week

You don't need a reorg. You don't need a new framework or a consultant or a title change.

1. Add two lines to your ticket template

Who has this problem. What happens to them today. Make it required. Watch what happens to the tickets nobody can fill in.

2. Put one developer on one customer call

One. This month. Volunteer, not assigned. Then have them tell the team what they heard. We're a few of these in, so I'm not preaching from the summit here, but it took about one call to convince me it needs to be routine.

3. Celebrate the first no

The first time someone kills a feature with good reasoning, make a thing of it. Demo it. That's the whole intervention.

4. Change what your demo covers

If your team demo is a list of things shipped, you're measuring the wrong thing. Ask "what changed for a customer" and sit through the silence the first couple of times.

5. Go back and check

Pick one feature from last quarter. Find out if it got used. This is the least fun item on the list and the one that changes the most.

The point

A Product Engineer is not a developer with a better title. It's a developer whose job officially includes the part that was always unofficially the difference between good software and expensive software.

That part used to be invisible because everyone was too busy building to do it. It's not invisible anymore. The building got cheap and the thinking got exposed, and standing in the light is uncomfortable for everybody, me included.

So change the title if you want. Nobody will stop you. Just don't confuse the noun with the work.

The work is the work.