Simplifying The Trinity
For those of us working on product development or project work, we’ve seen a diagram like the one below at some point in our careers:
Some people refer to it as the “product engineering trinity”. The gist of it is you can’t have all three when developing or delivering a product. You must sacrifice, to some extent, how good something is, your performance goals and how much you are willing to spend building it. However, in my opinion, those terms are vague (for instance, what does it mean for something to be “good” or “fast”?) and tend to confuse people in the industry.
You could go down the proverbial rabbit hole trying to define what each of those terms mean and get on endless arguments about semantics therein for years and still not be able to come up with a sufficiently generic solution that would fit most cases.
So, how do we go about simplifying it? It’s actually quite simple once you make the mental leap and come to the realization that both “good” and “fast” in the diagram above are really two distinct parts of the same category, namely, the user experience. It matters not one little bit if your application/product is robust, built 100% to spec and fulfilling a large number of use cases if your app or product is not performant. Sooner or later your users will get sufficiently unhappy to start looking for alternatives. Same with the other side of the coin: it matters very little your application or product meets or exceeds all performance benchmarks you and your users have in place if the application crashes often, unexpected behavior, wrong behavior, etc.
With that in mind, we then flatten the trinity as shown below. The Product Dichotomy:
The choice is yours: you build a product your users want or like to use or a product they will jump ship from as soon as they find a suitable alternative.