Matthew Andrews
Product Manager ・ Software Engineer ・ Executive MBA Graduate ・ Tokyo Resident
Platform Products: Shared Responsibility vs. Gatekeeper vs. Custodian

My previous post, 3 things any digital product team can do to build better products, generated a passionate and robust rebuttal from a close colleague who I deeply respect.

In my post I argued that no matter how successful or dysfunctional your team, there are always three things any team can do better. In prioritised order these are: talk directly to real customers, test product concepts with customers and release incrementally.

My colleague rightly pointed out this can result in a single-minded focus only on the parts of a product the end customer sees, which can lead teams to neglect the shared platforms multiple product teams depend on.

In my experience the way those platforms are managed tend to match one of the following patterns below, which I’ve written in order of increasing maturity and efficacy:-

Shared responsibility

Imagine ten factories surrounding a lake. Each factory relies on clean water to operate. But each could choose either to properly clean their waste water or save money and not clean it before discharging back into the lake. When driven by one short term goal, to maximise profit, the factories may choose to neglect their responsibility to keep the lake clean until none can operate and they all lose money.

When it works

  • At the beginning when a need for a platform-like capability is still emerging.
  • With small, very mature teams that are able to exercise strong self-discipline.
  • When teams are not being rushed and don’t feel they need to cut corners.

Gatekeeper

The lake is now polluted. The factories have all shutdown. The local economy has collapsed. The government have appointed a powerful new Lake Management Authority, who will solely be responsible for discharging and extracting any water to and from the lake to ensure it remains clean for the benefit of all.

It takes significant effort to put in and maintain those strict controls but resources are limited — there’s only so much the factories can pay for water access and still remain profitable. Innovative but uncertain new uses of the lake struggle to get attention because the authority is already behind on meeting existing demands. Water access drifts to larger, richer, more powerful factories. The economy still grows but not up to its potential. Some factories discuss moving to another lake further upstream, outside of the jurisdiction of the Lake Management Authority.

When it works

  • When the need for the platform has clearly emerged.
  • For platforms in a state of disrepair during a recovery phase.
  • Where there’s value to protect the platform from the pressure to cut corners from product team.

Custodian

Recognising the economic impact of the strict control over lake management, the Lake Management Authority loosen their control. Their role changes gatekeeper to custodian, working in collaboration with rather than in conflict with factories. The authority retains power to approve or deny lake access but empowers factories to take greater responsibility for extracting and discharging water. Innovative uses of the lake emerge more quickly, the cost to protect the lake falls and the economy grows. The lake stays clean.

When it works

  • Where there’s strong communication between platform and product teams.
  • Where it’s possible to scale the platform improvements by empowering product teams to take some responsibility for developing them, with oversight from the custodians.
  • The system can tolerate and recover from occasional ‘damage’ that is inevitable due to the less strict oversight.
Week Notes #3 — Running (again), Goals, Waterfall → Agile

This is third weekly note of my weekly Week Notes. Why not read post one first?

Running

Running continues to go well. I ran my first half marathon 21km in a single session, smashing my 2 hour goal by completing it with a time of 1 hour, 45 minutes and 45 seconds.

I’m closing in on 600km total so far this year so it looks like I’m going to need to revise my other goal of running 1,000km by the end of this year.

Goals

Except for running 21km within 2 hours and 1,000km within 1 year, some other personal goals include:

3 practical tips to improve your product management process

What I loved about the talk itself was how it did not paint a picture of a perfectly idealised product process that is unreachable for most teams. Instead, it focused on practical, prioritised tips to make any product process a bit better.

The vast majority of us do not work within a perfect Discovery & Delivery culture. We work in situations that exhibit one of more of the old ways of doing things. Furthermore, the speaker, Todd Birzer, recognised not every team should be working in the new way. The old way can be appropriate in situations where there is a high degree of safety risk, or where it is expensive to fix mistakes.

In spite of this, there are 3 things all product teams can learn from the new way of product development, even those bound (for sensible reasons or otherwise) by sequential processes:-

  1. Talking directly to real customers
  2. Testing product concepts
  3. Releasing incrementally

What Birzer said about A/B tests also resonated very deeply with me:

A/B testing is one of the ways that product teams can accelerate the evolution of their product. But just looking at the data is not enough, you need a deeper understanding of the qualitative reasons behind it. Why are people leaning one direction or the other?

For more, please read my summary or watch the original talk.

3 things any digital product team can do to build better products

27th of May was World Product Day and to celebrate I virtually attended the online Tokyo meet-up, which was fantastic not just for its content but for another surprising reason not relevant to this post. You too can watch the whole meet-up on YouTube.

What I loved about the talk itself was how it did not paint a picture of a perfectly idealised product process that is unreachable for most teams. Instead, it focused on practical, prioritised tips to make any product process a bit better.

The vast majority of us do not work within a perfect Discovery & Delivery culture. We work in situations that exhibit one of more of the old ways of doing things. Furthermore, the speaker, Todd Birzer, recognised not every team should be working in the new way. The old way can be appropriate in situations where there is a high degree of safety risk, or where it is expensive to fix mistakes.

In spite of this, there are things all product teams can learn from the new way of product development, even those bound (for sensible reasons or otherwise) by sequential processes.

Old vs. new

Product teams tend to work in one of two ways. Birzer uses the terms Stage-Gates and Discovery & Delivery. In my head I was substituting them with the frequently used terms waterfall and agile, but they are not exactly equivalent — not least of all because the terms ‘waterfall’ and ‘agile’ come with a lot of baggage.

Stage-Gates

‘Stage-Gates’ are where a project moves sequentially through the stages of:-

Scoping → Business case → Development → Testing → Launch

Each Stage is a phase of a new product or service development and each Gate is where product development is reviewed, go/kill decisions are made and the next-stage’s funding is allocated.

Stage-Gate processes are very common in companies around the world. For some types of products it can even be the right approach.

Discovery & Delivery

‘Discovery & Delivery’ is the newer approach. Rather than pushing the entire product’s development process through distinct steps, it breaks the product down into ideas that each, individually, go on their own journeys at their own speed through:-

Ideas → Discovery → Delivery → Optimisation

It works like a funnel: starting with a lot of ideas, picking a few of them to put through discovery, then filtering them further to choose only those that have tested very well to take to delivery.

Unlike Stage-Gates, Discovery & Delivery is non-linear. Ideas that test well will move onto delivery. At the same time, ideas that do not test well will go back to the beginning. New ideas will continuously be added. Often, all stages will be happening concurrently.

Discovery & Delivery is clearly a more lean, agile process. Requirements are defined immediately before (not months before) delivery. Very few resources are devoted at the beginning as you’re just quickly sorting through ideas. Significant resources are only allocated at the end when product-market fit has really been found.

Comparing the two processes

Market requirements

The Stage-Gates process forces requirements to mostly be defined upfront and decisions on what will be built will be made at the beginning. It might be a year later when the product is finally released and shown to customers.

With Discovery & Delivery, requirements are figured out as you go. You’re rapidly prototyping, learning as you go along, developing requirements at the same time as doing development.

Risks

Following a Stage-Gates approach risks being beaten by faster Discovery & Delivery competitors as they are more flexible and therefore better able to respond to customers.

Whereas those following the Discovery & Delivery process suffer risk of poor coordination as their progress is less easy to track and increased financial risk as the process is more chaotic.


How to make your waterfall process a little more agile

Not every team can (or should) move from Stage-Gates to Discovery & Delivery. Besides, it’s not realistic to try to change everything at once. Changing how people work, much like product management itself, is best done incrementally, but where to start?

There are 3 best practises every product team can learn and apply from the new process:

  1. Talking directly to real customers
  2. Testing product concepts
  3. Releasing incrementally

1. Talk directly to real customers

The first rule of excellent product management is interview customers early and often.

We should understand our customers in many ways. Customer satisfaction surveys, net promoter scores, third party research reports, product usage data, etc.

In particular we need to understand not just what the customer wants but what they are trying to achieve. The underlying needs your product is aiming to fulfil.

And because of that our most insightful source is direct conversations with customers.

Talk directly with your customers, not to (or through) your sales team

Customers are defined as the companies, groups and individuals who are benefiting from your product. Or competitors’ products. Or potential customers. Not your sales reps, not your sales channels.

Sales reps have a lot of bias — they will often filter the information from customers to highlight the demand for features they think they need to meet their own sales goals. We need to have product conversations with customers. We need to understand the customers without trying to make a sale at the end of the conversation. We need to test our product concepts. In order to do that, you need to talk directly to your customers and not go through sales channels.

How to interview customers remotely

Through video conferencing you need to be more disciplined. When you’re face-to-face you can be a bit more casual, go off on tangents because you have the personal rapport. It’s a little tougher when you’re on the video conference to develop that. You have to be more strict and focused. Your subjects might not be as patient with you. Stick to the time.

With a video conference it’s easy to invite a lot of colleagues but be careful. Make sure they’re not disruptive because if too many people are talking in at once it gets a little out of control.

Think about security. Use password protection. Ask your subjects not to show confidential information on their screen. Only record when you have permission.

2. Test your product concepts

We have many ideas for product enhancements. Some are excellent and some are worthless. The goal is to quickly screen ideas, discarding the bad and keeping the good.

Do not decide at the beginning on a set of features to build, then go through the full development cycle only to find out it doesn’t have a good product-market fit as this would be a huge waste of effort.

Instead, aim to filter out bad ideas and refine the good ideas with minimal investment by going through the test-feedback-test loop cycle, refining concepts to find product-market fit.

It’s a funnel process, you’re getting rid of a lot of ideas early on and only moving the ones that are truly testing well to the next stage.

Product concepts should start as simple as possible, such as a paper print out. Then a video. A clickable prototype. Only when you’ve gathered significant evidence that there is demand for your feature should you start to write code for beta software.

3. Find ways to release incrementally

We often think it’s the first-to-market company that has all the advantage but it’s often the company that evolves the fastest that ends up winning in the long run.

Smaller and sooner is better than bigger and later.

Why do we want to release incrementally?

  • Offer value to customers sooner
  • Get revenue faster
  • Course correct sooner if we are off-track
  • Learn and evolve faster than our competitors

My own experience with FT.com resonated very strongly with this — I’m proud to say that we deployed code multiple times a day. New feature releases would be controlled by switches, instantly turning them on or off, or showing to customers through an A/B test. New feature ideas would typically be released this way every week or so.

A/B testing

A/B testing is one of the ways that product teams can accelerate the evolution of their product. But just looking at the data is not enough, you need a deeper understanding of the qualitative reasons behind it. Why are people leaning one direction or the other?

Summary

If you do just one thing differently after reading this post make it talk directly to real customers.

If you’re already doing that, then find ways to test your product concepts with customers and release new features incrementally.

Additional reading

Email: the best task management app

Inspired by the note on hey.com, I wrote up some notes how I use email.

I spent years trying out fancy task individual management apps. Omnifocus, Evernote. Trello. Notion (which I love for other purposes). Trying to apply David Allen’s Getting Things Done principles in the quest for ever better personal productivity. Each time coming back to the same, boring, blisteringly effective solution. Email inbox. But not just emails other people write to me, emails as reminders from me to me.

Email is everywhere. It works on my laptop. My phone. My tablet. Other people’s phones and computers. Always in sync. Always up to date.

It works offline. When I’m on a plane, I can write myself an email and it will sit there waiting for connectivity to be restored. I can also access all my existing notes, and delete them. Again, waiting for a new connection to get in sync again.

Using email means I have one todo list for everything, regardless of whether someone else has asked me to do something or I have written myself a reminder.

It’s free.

It’s also an open standard. That means if I find a better alternative to gmail, I can switch to another provider whilst keeping all my data and my email address. I can also try out new apps on my phone, tablet, etc … Every component can be chopped and changed more-or-less seamlessly. As an email address comes with every job in the world, I can also keep this same workflow regardless of which organisation I am working for.

PS. Whilst I agree with pretty much all the issues Hey.com identified in email, I disagree with No. 16. It’s super simple to put stuff in your inbox. I do it all the time. Just write to yourself. As my colleagues I’m sure will attest, it’s common to hear me say “let me just write myself an email” …