The Product Engineering Matrix

Product managers and engineers often have very different notions of project status, because they view the project from orthogonal axes on (what I call) the Product Engineering Matrix.

The Product Engineering Matrix

For most PMs, the only observable aspect of a project is functionality, so they think in terms of feature completeness. Their notion of project doneness must be extrapolated from demo versions, and from asking engineers: “How much longer until Feature X is ready?” At worst (but all too often), PMs think particular engineers are responsible for distinct features, so they interrogate Alice about progress toward Feature A, and Bob about Feature B, every few days.

Engineers, on the other hand, often have no real sense of who their users are or what features matter. It’s the nature of the job: Most engineers are not in client-facing roles, and many have never even met an actual user of their product. They can, however, envision the architectural layers needed to support features in the abstract. For example (using deliberately vague labels as strawmen):

Strawman layers and features

To succeed, Product and Engineering must value each other’s perspective. Here are some tips:

1. A single person, the Engineering Lead, must understand the technology through and through, and communicate effectively. The latter part of this description is rarely treated with the importance it deserves: If the lead has a thick accent; if they write poorly; if they are sullen; then communication will be impeded, and the project will suffer. Great engineers do not always make great leads.
   
   Accents merit special discussion, because they can be a touchy topic. The issue is not whether someone has an accent at all—we all have some accent—but whether they speak intelligibly. One need not be a native speaker of English (or any specific natural language) to use it effectively. This is a tough issue to tackle, because it’s correlated with xenophobia and racism, but it really does matter.

2. All project status updates must come directly from the Engineering Lead. Product must never try to debrief individual engineers. Instead, the Product Lead and the Engineering Lead should meet regularly: Twice a week is usually about right. Use a matrix like the table above as a framework for discussing progress. If your product has N features and an M-layered architecture, then O(M * N) topics are available for discussion.

3. Adjust the matrix as you go, even if it's no longer technically a table. For example, it may become a graph of interconnected microservices. Its sole purpose is to help product and engineering teams understand the relationship between tech and features: between form and function. It is not a square mathematical formalism like a DSM.