Working with Engineers

When you're new to a team, engineers won't automatically respect your product decisions — you have to earn that. The fastest way is to find the most knowledgeable, influential person in the company, ask them to teach you, and visibly keep learning every day. Once people see you doing the work to understand the business and the customer deeply, they'll trust your judgment.

As a new PM, you do not need to write code, but you do need to describe what you are building clearly enough that engineers never have to reverse-engineer your intent. Think of it as drawing the boundary of the box — engineers fill it, but you have to make the box real and specific, not a vague wish list.

Your job is not to hand engineers a full spec or leave them with only a vague user story. Instead, describe the experience clearly enough that everyone can picture it — the key screens, the main flows, the core interactions — and then let the engineering team figure out how to build it. Engineers do their best work when they understand what they're solving and have room to make creative decisions about how.

When engineering wants to do a rewrite and product wants to ship a new feature, it feels like a conflict — but usually both sides are protecting something real. Your job as a PM is to ask 'what would have to be true for the rewrite to be the right call?' and 'what would have to be true for the new feature to be the right call?' That question turns opponents into detectives working the same case, and it almost always reveals a path forward that neither side saw alone.

Engineers get frustrated when PMs take all the credit and don't care about the technical work involved. To build a good relationship, share the spotlight — let engineers present their own work — and show genuine curiosity about how things are built, even if you don't understand every detail. Treating engineers as partners who have valuable ideas, not just people who execute your specs, is what separates good PMs from bad ones.