Ever wondered why there is so much friction between software developers and product managers? I wouldn’t claim to have found the philosopher’s stone, though I’d offer the following partial solution, partly rooted in philosophy. In a nutshell: they are using different types of truth, and once these two are distinguished consciously, everything becomes a lot easier.
On the one hand, there are the product managers. It is their job to understand the real world and generate some kind of specification (user stories, whatever) from that understanding.
The properties of “truth” in such a context have already been examined by German philosopher Immanuel Kant. Kant has argued that truth is a “category” (special, well-defined term). “Category” among others implies that “truth” applies to “statements” (special, well-defined term, see below). It also implies that truth is never fully there nor ever fully missing.
For Kant, a “statement” relates consciousness to the real world. A statement like “this rose is beautiful”, for example, relates your concept of beauty to this rose. Well, upon closer inspection: “this rose” relates your concept of a rose to “this” specific sample you have in front of you. And so on, probably we should look even closer and even closer and even closer. Anyways, eventually, you can always ground one part of a Kant-statement in the real world and the other part in our consciousness, our collected concepts about the world. As these two are of a different nature, they can’t ever be the same, but they are always related to each other in some way, at least a very tiny very little bit.
Coming back to our product managers, they deal with “real things” (like people or goods sold or some such) and derive concepts about these things (e.g. a business process). And these concepts usually match more or less. It’s the whole point of their work to focus on what matters and leave out what doesn’t, thus creating an “imperfect” concept in one sense (because it’s no longer the thing but a concept of the thing, and because information is lost), but hopefully something useful because the essence of the abstraction is sustained.
On the other hand, there are developers. The idea of a “statement” for a developer (let alone common definitions in common programming languages) derives from mathematics and goes back to Aristotle: Aristotelian logic is more concerned with the form of a statement than with its content, to the extent that only abstract principles are considered valid subjects of logical reasoning, but not their concrete manifestations (see Logic, “Logical Form”). So, Aristotelian logic relates two abstract principles to each other and the rules of the game change: Suddenly, truth is either all or nothing.
IT entirely builds on Aristotelian logic. While our product manager can say things like “most people are younger than 100 years” (-> but there are exceptions, so it is not enough to reserve two digits to represent the age), the computer can only deal with “people are younger than 100 years” (if this holds true for my specific topic, two digits are enough. Otherwise, I need three). Always or never, black or white.
To facilitate communication, it is useful to keep in mind that both points of view have their justification.
For example, it makes a lot of sense in the early days of product creation (i.e. before developers come to the table) to distinguish between “most of the time …” and “sometimes …” – but when development starts, this needs to be made precise: “Here is the list of all cases, and here’s how to recognize each one.”