It's a Negotiation
When Product & Engineering Meet
Based on all the evidence I’ve seen—barely working releases, lianas of duct tape, “what tests?”, “we’ll clean it up later”—here’s what I presume most engineers think must happen when Product and Engineering meet:
Product: I need you to build X, Y, Z.
Engineering: okay.
Product: You have until end of this quarter.
Engineering: okay. [muttering to themselves, barely audible:] fuck.
Product says What and (at least sometimes) When; Engineers worry about the How.
I’ve heard people say that out of these three—What, When, How—you get to pick two. You can say build me X (What) until this date (When) but then you can’t say How it’s built, because that’s Engineering’s job. Or you say you want X (What) built exactly like this (How) but then you don’t get to decide When.
The pick-two idea is useful, because it makes clear that trying to pick all three is the same as waving a magic wand—wishful thinking. But I also think it’s not nuanced enough.
In my experience, the most productive relationships between Engineering & Product were based on the understanding that they need to negotiate, make compromises, meet in the middle—on all three fronts: What, When, How. Because they are all related to each other and cleanly picking two while not touching the third one barely works in practice.
Ideally, the conversations go like this:
Product: Here’s What I want—X, Y, Z—can you build that?
Engineering: Until when?
Product: End of quarter.
Engineering: Impossible, but I can give you X and Z until then.
Product: I see. But Y is more important to me than Z. Can we somehow get X and Y in? I’m happy to drop Z.
Engineering: We could get X in but Y only in small, y.
Product: That works. Small y is the important part anyway. When will you get to Z?
Engineering: Right after that.
Product: Sweet.
Both parties need to go into the conversation knowing that they only have half of the picture and that the conversation is a way to see the other half—the conversation is a way to learn, to understand the constraints and tradeoffs involved.
After all, this is what Engineering is about, isn’t it? Building things to solve problems, given a set of constraints.
Imagine you’re an engineer in the physical realm and you’re tasked with building a bridge.
Product: Build me a bridge.
Engineering: Alright. [muttering to themselves, barely audible:] fuck.
That’s all wrong, right? An engineer who works with Actual Real Stuff (you know: sand, stone, iron, and so on) wouldn’t just go off and build a bridge, they’d find out what the actual constraint are in order to solve the problem.
Product: Build me a bridge.
Enginering: Until when? What materials do we have available? What’s the budget? How many people will cross that bridge? Vehicles? For how long? How many every day? What’s traffic at peak hours?
Then, depending on Product’s answers, Engineering might go and build different things:
Product: The bridge is only for today. 5 people need to cross this river, fast.
Engineering goes and puts up a zip line.
or:
Product: Bridge needs to carry a thousand vehicles this week. Doesn’t need to survive longer than that. Budget is tight.
Engineering goes and puts up a wooden bridge.
or:
Product: Bridge needs to carry all the traffic that’s now on Other Bridge, because that one will be shut down. It can’t be a steel bridge because that’s prohibited here.
Engineering goes and builds a stone bridge.
You get the idea: the What and the When and the How are all related and when Product & Engineering meet their task is to find out how related they are—which one you can change in which ways and how that influences the other ones.
Product saying What and When and Engineering eating it and crumbling about their How is just not engineering.