Please help me name this product triangle thing

2 thoughts on “Please help me name this product triangle thing”

  1. I really like this way of thinking about things, and I have certainly seen examples of organizations that are in the corners or on the edges of the triangle. I’m still struggling with the triangle as an illustration, though, because it’s an image which presents quality, value, and flow as in opposition to one another, with the ideal situation being a compromise between all three.

    For me, a high-functioning organization achieves all three of quality, value, and flow, and the three become self-reinforcing. For example: to deploy often with confidence, I invest in quality in my code, tests and deployment tools. Deploying often lets me get feedback from the market, which helps me build the right thing. That is: by moving into the “middle” of the triangle, I’m able to get more of each of the three things on the edges, and go further in those directions than if I had simply concentrated on one or two of them. I don’t know how to make the triangle metaphor illustrate this.


    1. Thanks for the comment Tom – I think I need to make this clearer that I’m thinking of this as a diagnosis tool, to help a team look at how they work, and take steps to improve in the areas they might be forgetting.

      I agree with you that they reinforce each other when you get all three – when you have a high quality product, that’s easy to change, and push these changes to users without compromising how well it works, you’re in a good position to make sense of the feedback coming in, and act quickly on it, shipping new changes, and reinforcing this virtuous cycle.

      I think it’s relatively rare to find organisations that have nailed all three, and in most cases at least one of these ends of the triangle is being neglected, which is generally bad for the product.

      I imagine people using something like this at retrospectives or similar exercises to look at their process and say something along the lines of:

      “Okay, we’ve got these two nailed, but are we forgetting about this stuff here? Maybe we should invest some effort there before the bad stuff in red happens”

      There are absolutely measures you can take to invest in improving how well you’re doing in each of the three areas, so it’s probably to better to think of the triangle in terms of where your investment in improving your process is being spent, relative to each other

      If I thought you could track this is in absolute terms, I’d probably just present it as a radar chart, so you can just assign a number in each area independently of the other, but I think most of us have a finite amount of attention we can spend on improving how we work, so we have to make trade-offs.

      The triad thing is there to force a team to think about harder about the interplay between these, and what might be being missed.

      So maybe that’s the thing – it’s not necessarily about tracking attainment in absolute terms like some maturity model, but making explicit about where you are focussing your efforts, so you can talk about what steps you can take to improve in the neglected area.

      If it’s value, you might think about your user research efforts to check that your assumptions about your users and what they value are correct.

      If it’s about flow, you might look at your delivery pipeline, where in the process your queues are building up, or what your lead time is.

      It’s about quality, you might do something about how a your team might be deferring necessary cleanup and documentation work on features you build every week , and the tax that imposes on delivery in general. Or it might be about whether the architecture you had started with fits how the product is being used now.

      As I mentioned earlier, I think there are concrete steps, and techniques we know how to take, to get us back to the middle, assuming you’re in a team which is at least open to working in a somewhat cross-functional fashion.

      Alternatively, if it turns out you’re operating further from one end of the triangle, this might be a deliberate decision you’ve made (there might be valid reasons you chose to do it – it’s your product after all).

      In this case, I think it’s useful to be explicit about it, as a reminder to revisit this decision later, or to communicate with stakeholders about why you’re not doing a particular thing for them right now.


Comments are closed.