I think about product development capability a lot. It started in earnest when I left Betfair (a well-resourced company) to bootstrap my own startup (a very poorly resourced company). The contrast and shock meant that I had to think pretty critically about how I did things. And that critical thinking continued as I launched other things and worked across a mix of startup and corporates.

So what makes an organisation good at developing product? Brainstorm it and you’ll come up with 101 things: people, processes, tools, culture and so on. We could write a pretty long list – and that list would largely differ for each company and each product.

However, I think there is one key insight that applies regardless of what kind of company you are and what you’re building.

To have great product development capability, close the loop quickly and well. Over and over again.

Let me explain. When I talk about “loops”, I’m referring to development loops. It’s a cycle where you start with prioritisation, then you design, then you build – and then you evaluate. Anyone who’s heard of agile will be familiar with this idea. It’s common place. It’s even mundane.

The nuance here is the importance of this loop. The loop is key. Or rather, how fast and well you close this loop repeatedly is key. Closing the loop isn’t just one of many aspects of your product capability. It is your capability.

Do a shit job of prioritisation? You’re screwed. Skip designing and jump straight to build? Trouble. Not actually looking at the data to see your results? Goodbye. Holding back a release until you think it’s perfect? Not great.

What makes the loop so important is that each loop is a shot-on-goal. Given that product development is an uncertain process of discovery, you need a lot of shots. If you run out of them, it’s over. So you need to close the loop fast (and do it well!).

Eliminate friction to get more shots on goal

When I think about improving loops, I think about eliminating friction. Friction can come from a lot of sources. Here are some examples I’ve seen:

• The development team had no ability to release. A separate team handled it, so something as simple as a bug fix would wait for days (even over a week) to be released
• Prioritization was done by committee, which often can’t really decide, so decisions get delayed
• The team didn’t have the authority or knowledge to course correct, so when problems emerged, they got stuck until they could meet with the right person
• Meetings and processes were ad hoc, requiring a lot of scheduling coordination
• The people seeing the results are totally separate from the team
• There aren’t any easy mechanisms for data and feedback, so evaluation only happens once a quarter
• Teammates not liking / respecting / trusting each other
• Someone in the company (legal, security, etc) decides that they need to approve everything before it goes out – and they take their time with it

In other words, friction in loops basically comes from disconnect between people and a lack of authority within the team.

The friction-free checklist

How do you know if you have any major sources of friction? I’d start by talking to the members of the team. How often and when do they feel frustrated? Confused?

Aside from asking the team, here’s a checklist that might help. Think of it as a guide, not a definitive scorecard.

• Agile methodology? The point here is that the team shouldn’t be burning up time scheduling meetings and figuring out deadlines. It just happens. There’s an automatic rhythm to how this operates.
• Clear prioritization maker? This can’t be a committee. It has to be a person. And this person has to be very accessible. This person also should not be a process manager, because one can’t prioritize quickly and well without content knowledge
• Self-contained, functionally complete team? This is my 80% rule for organisations. For a team to meet its responsibilities, it needs authority over at least 80% of the resources needed to make it happen.
• Autonomy to design and build? The team should be given the problem to solve and the knowledge behind it, so they can design-and-build a solution. If they’re instead being given specific specs (“Make this font bigger”), then it’s going to end up with a lot more back-and-forth before getting to a good result.
• Frustration-free tools? If the team regularly swears at their tools, then change the tools. This is why I’m a big fan of letting teams choose their own tech and equipment as much as possible (and why it’s a terrible idea to save a couple hundred bucks by getting inferior kit).

Again, this checklist is just a guide. But use it as a starting point, in addition to an honest conversation with the team, to help you build some kick-ass product development capability.

---

GS Dun is a product management consultancy. How to build ’em. How to grow ’em. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

The next time you’re in a meeting where someone is throwing out some seemingly spurious results, try our hack-y AB test calculator, cakeAB. Mobile friendly, just punch in the numbers and get a steer on whether there really is a difference between those 2 campaigns. www.cakeab.com