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:
https://twitter.com/joshuajames/status/965389686116990976
And here's the tweet from Dan North it referred to, which in turn referred to Melissa Perri's one:
https://twitter.com/tastapod/status/964629911318204416
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.
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 musing - 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.