The Best Relationship in Tech (Part 2)
Continuing on from my previous post about the best relationship in tech, and how it gets product to market fast and accurately - or stalls it completely.
The seasoned product manager knows about this dynamic. The seasoned engineering manager does as well. It's no surprise, then, that the PM must (in their minds) reach into the world of the EM, and the EM must reach into the world of the PM. What is at stake with a given initiative, presented by the PM to the EM? Does this new project keep an existing big account onboard? Is this the final tweak that will win us that first or third customer? Is this an idea handed down from the founder? Are we running out of funding and racing to market...for the fourth year in a row? Is there a solid set of requirements, further hammered into place by an elaborate, multi-week Figma design, or are the requirements loose and vaguely connected to a roadmap? All of these questions could be treated separately, and will be over time.
Product is doing a ton of work to figure out how to keep this SaaS afloat or how to bring in more customers. If they are not the founder themselves, their discovery work is critical to enable sales. They need engineering's support, not their friction. They need to know - is this idea or design doable, or does it involve a level of work that would be impossible to deliver in time to prevent that giant customer from churning? We can only hope the requirements come in small increments. But if they don't, can we devise a strategy to deliver them incrementally, offering glimmers of hope (in the form of traction and customers)?
There are specific, street-level conventions for dealing with literally every one of the questions posed here: technical feasibility, speed & accuracy of delivery, and so on.
Those conventions are: refinement and, in some cases, pre-refinement (the act of straightening out requirements such that, when the rubber does hit the road, the engine of delivery (engineering!), actually flies along, without getting mired in the mud of missing, ambiguous, or conflicting requirements.
At the end of the day, it's no surprise a mutually respectful, empathetic relationship wins here: it is a huge unlock for a SaaS business.
...And all of this presupposes an organization large enough to require separate product and engineering managers. There is of course an emergence of the most intimate possible relationship between EM and PM, thanks to AI: the Product Engineer. But that's another post.