Please help me name this product triangle thing

I’ve worked as a developer, a sysadmin, a user researcher, a product manager, and UX’er, with different teams, and I’d like to share an idea here I want to be able to present visually, as a way to identify common patterns of behaviour that make products less successful.

This is a work in progress, and it’s not fully thought through – it’s based on a couple of tweets from people who I follow and really enjoy reading, and I don’t have a snappy title for it, but I’ve tried running by a few people from UX, product and engineering backgrounds, and so far:

  • they’ve been able draw with a marker where they think their efforts in their own product teams lie among these three regions
  • we’ve been able to use it to help guide our own discussions about how we build digital products.

3 things you need, to build a successful product

In short, I think that to build a successful product or service, that is able to sustain itself, your team needs to be competent in all three of three broad areas. Here’s how I picture it, and I’ll explain the terms in more detail below:


I’ll just say product for the rest of this post instead of the more clumsy product or service, as I increasingly find it more useful to think of these as the same kind of thing these days.

What I mean by Value, Quality and Flow

These are extremely broad terms, and I’ll try to be a bit more specific:

Value – Build the right thing

I’m calling one these value, in the eyes of the user – this might be the customer paying for it, or it’s a public service, the people whose specific needs you’re meeting.

You need clear understanding of the needs you’re meeting, the value provided by it, and a way to validate that this is actually valued by them.

Quality – Build the thing right

The next one here is what I’m calling quality. Depending on the disciplines your team has competency in, this might be an intuitive user experience, an easy to maintain, safe, secure, easy to extend codebase, or a beautifully presented design system that communicates the values you want.

It’s typically the stuff you might consider your putting in your portfolio if you were a visual designer, or put on github as developer.

Flow – Keep on shipping the thing

The final one is what I’m calling flow, and when I use the word flow, I’m thinking in terms of continuous delivery.  So, delivering frequent, small batches of new work, in a sustainable fashion, in response to the things your team learns about what’s valuable to your users, or what’s happening in the market.

What happens when you miss one out

When you have quality, and value, but no flow.

You might have commissioned a load of in-depth research to understand a group of people who have a clear need, and are prepared to pay for it. You might then have hired a fantastically skilled team to build a beautiful product with a wonderfully thought through set of  features.

If you don’t have a clear way to get this in front of people, and regularly respond to what’s happening outside of the team, then one of two things will probably happen.

Probably the most demoralising is having it never seeing the light of day – something that happens depressingly regularly, especially in agency work.

The other is that if it does make it out the door, and you’re unable to respond to feedback fast enough, then your product loses relevance, you end up with no one using it anyway. Sad times.


When you have value and flow, but not quality

Let’s say you’ve been able to find an unmet need, bash together a prototype, and then find a way to get progressively less clunky versions of it in front of people, up to the point where you have enough people using it that some pay for it, or it provides a valuable enough service for some other sponsor wants to cover the cost of running it.

This is common too – you might see an idea start at a hackday for example, or you might be able to get something either built speculatively, or very, very cheaply by inexperienced developers or people who should know better, thinking they can fit it in around the rest of their life, and cutting corners to get something out the door (I’ve been this fool before – it’s always a bad idea).

To begin with, can get changes and updates out regularly, but they’ll often miss edge cases, introduce bugs, and so on. When given the choice, of fixing these bugs, or covering the edge cases, and pressing on in favour of new ideas in new features, the shiny takes priority.

All these hacks build up, and eventually, it becomes a horrible ball of mud, with so much deferred clear-up work (i.e. all flavours of tech debt, ux debt, or whatever flavour of debt your team grumbles about) that it’s absolutely horrible to work on.

It becomes impossible to find anyone who will touch it, or it becomes so hard to change without breaking everything, that you essentially become unable to ship anything meaningful. Sad times, again.


When you have flow and quality but no value

In our last case, let’s say you have a a really proficient team, who are masters of their craft, and you’ve invested in building or buying a top notch continuous delivery pipeline. You can ship new changes a bajillion times a day, your builds are evergreen, your designs atomic, and consistent across all the channels you support.

Everyone is blogging on the product blog about the latest thing your company has open sourced, and stoked to be helping the community, and the move the state of the art forward in their field.

But… it’s not obvious how the users’ needs are met by the product, in way that is much better than the other options they have available. Or, it’s not clear how the product sustains itself financially, or where the money might come from to pay for everyone. If this isn’t clear, it’s often because the money isn’t there.

In this case, if you don’t have a way of seeing which parts of what you’re offering are already valued by people, and what else they want, there may not be time to discover it this before you run out of money.

You might see this if you’re working to a deliver roadmap that’s been decided up front ages ago, and there’s no chance to discuss or check if the things being delivered really are valuable, or which parts of the product are really being used.

Alternatively, rather than working to an overly rigid roadmap, where you’re not acting on feedback, the other extreme would be indiscriminately acting on all feedback, with no real way of telling of it’s valid or relevant, and making sweeping changes to the product.  In this case you might have accidentally discovered something really valuable, or a really valuable set of users, but not realise it, and as a result totally miss your last lifeline, as you thrash around frantically trying to pivot out of a horrible death spiral.


You need all three – value, quality, and flow


This is increasingly how I see digital product development – these three things aren’t in opposition with each other, and ideally you want to be slap bang in the middle.

In my experience most teams, end up drifting towards one of the edges of this triangle over time, and if they don’t take steps to make sure they’re not missing the third piece of this triangle, you start to see increasingly severe cases of the bad things in these red boxes.

A ways to use this diagram

One really simple way, is to try drawing this on a whiteboard or flipchart, and asking your team to mark where in the triangle they reckon they’re at (assuming they’re okay with these comically broad definitions of value, quality and flow here).

If you see clusters of marks towards one corner, it gives you an idea of what changes to your process you might want to make, or what changes to the makeup of skills in your team are worth considering.

You might also use this to acknowledge explicitly in a team that you’ve chosen to temporarily drift away from one corner – maybe you’re deferring some work to hit a deadline, and deliberately taking a hit on quality (this is your call to make, not mine), and you want to have a visible reminder, so you can get back to the sweet spot later.

I’d be curious about how it’s useful.

Other ways of telling

I did think about listing a few other signs to look out for, but:

  • this post is already huge, and I think these are best explored in future posts
  • I really want to use this post to see if this way of presenting is a help to others

Is this useful to you?

If this is, I’d love to hear from you – I’ve used it a few times in workshops and as a discussion tool, but this it the first time I’ve shared it online.

This isn’t my idea

I need to be clear – this is based on a load of ideas I’ve come across elsewhere.

Tom Stuart put me onto Donald Reinertsen’s book, Lean Product Development, which is full of absolute gems, not not an easy read, and has informed a lot of my thinking about this now.

If you’ve heard of Donald Reinertsen and Cost of Delay, Black Swan Farming do a great job of making the ideas much easier to digest. I’ve found the ideas on their site defining what they mean when they say value extremely useful, and I follow @joshuajames on twitter.

In fact, here’s the tweet I read that got me thinking about presenting this visually in the first place:

And here’s the tweet from Dan North it referred to, which in turn referred to Melissa Perri’s one:

Presenting it as a triangle and marking it

I think the idea for visualising it, and asking people to make a mark among three points probably came from seeing this video here, of a severe-looking Dave Snowden presenting Sensemaker, a research tool I started looking into again, after getting involved in the nascent researchOps community on slack,

As the video outlines at 2:50, getting someone to mark a single point here between three points in a triangle forces a bit more thought than just asking for three numbers and building a radar chart from the results.

If someone can share with me the cog sci principle behind this, I’d love to know more – it was totally new to me.

Screen Shot 2018-03-18 at 00.12.25.png

Who looks after Flow, Quality and Value in a team?

You can interpret this triangle as the tension between three roles – a product manager, a tech lead, and a delivery manager.

I think it’s more helpful to think of these as three areas a team that is building a product needs to be competent in. Most importantly, I think the team needs to be able to talk constructively about this interplay, and tension between the three areas to work best.

Naming this

I have no idea what to call it. The lazy option would be something like Lean Product Triangle, given that putting Lean in front of anything seems to be the new agile.

There’s another framework called the Product Management Triangle. I had no idea it existed before googling it just now.

Using this yourself

You’re welcome to use this – it’s licensed under the Creative Commons CC BY SA, and the google slides document I was working in, is publicly visible here.

Feedback I’ve seen so far

I’ll summarise some of the feedback I’ve had since sharing this.

A bit more on quality and flow

I’ve had a few kinds of feedback when I speak about this, and I think it’s down to the terms I am using – as they’re pretty broad.  When I speak to people in engineering management roles, their response is typically – I get flow anyway, by investing in quality, as I’m able to deploy and respond to change quickly, so why are these different?

I’d argue that you can end up with a codebase, that is well documented, has lots of well written, passing tests, is secure and performant – lots of developers would refer to as a relatively nice codebase to work in.

If you see your job as a developer is to write code (after all when you were hired they were testing your ability to write code more than anything else), you might call this a high quality codebase. And you might be maintaining this level of quality making sure tests are passing, you’ve written documentation, and your pull request was merged into master after a review by at least one other person.

There might still be an convoluted deployment process, and you might be releasing relatively rarely as a result.

When I refer to flow here as optimising for the time from an idea being accepted as worthwhile to work on, to being used by people it was intended for.

In this case, I’d say you might have quality, but not necessarily flow. Depending on the company you might have a coach, a scrum master, engineering manager or delivery manager seeing this as their responsibility – it’s more important that someone is thinking about it, and arguing for it than who is doing it

The iron/engineer’s triangle

The most common triangle people refer to in software development is the iron triangle:

“good, cheap, fast – pick two”

The idea is that you can’t have all three, and trying to go for all three is folly. You might see it referred to as Scope, Resources, Time instead. The idea that you get to only get to choose two remains, so in agile circles it’s best to be flexible about scope, as Time and Resources are usually already fixed.







2 responses to “Please help me name this product triangle thing”

  1. Tom Stuart (@adistanttowel) Avatar

    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. mrchrisadams Avatar

      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.