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

It’s never too late to start. Even if you’ve almost completely finished the new feature without any customer input, find a way to test it.

If you’re struggling to decide which approach to use to test, also don’t worry. Just pick one. Not every kind of user testing is ideal for every scenario, but imperfect user testing is better than no user testing.

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” …

How to write a hash in YAML

I was tripped up by this silly little thing whilst writing a blog post with the title Week Notes #1 - Copying, Listening, Running, Emergency, which rendered as simply “Week Notes” — losing everything from the ‘#’ onwards.

My code was:

1
title: Week Notes #1 - Copying, Listening, Running, Emergency

YAML had, as my blog’s syntax highlighting hints, interpretted everything from the # (hash or pound) symbol onwards as a comment.

The fix is simple. Put the #-containing content in quotes:

1
title: 'Week Notes #1 - Copying, Listening, Running, Emergency'
How to define a Product Vision

The past few days I’ve been researching product visions — what they are, what are the ingredients of a good one and what are some examples. These notes are the result of that research.


According to Marty Cagan, the product vision describes the future, 2-5 years from now, that we are trying to create. Its primary purpose is to inspire the teams (including stakeholders, investors, partners, prospective customers) to bring this vision to life.

Buying into a vision always involves a leap of faith. You might not know how, or even if, you’ll be able to achieve it but at this stage you should believe it’s worthwhile trying.

Principles

  1. Start with why. What is your purpose. Everything follows from that.
  2. Love the problem, not the solution.
  3. Think big. Something that can be achieved in less than a year is not ambitious enough or substantial enough to inspire.
  4. Inspire. Create something you can get excited about. You can make any product vision meaningful if you focus on how you genuinely help your users and customers.
  5. Determine and embrace relevant meaningful trends. It is not very hard to identify the important trends but it is hard to understand how those trends can be leveraged by your products to solve customer problems in new and better ways.
  6. Skate to where the puck is heading, not to where it was. Identify the things that are changing—as well as the things that are likely not to change—in the time frame of the product vision.
  7. Be stubborn on vision but flexible on the details.
  8. Realise that any product vision is a leap of faith. If you could truly validate a vision, then your vision probably isn’t ambitious enough. It will take several years to know. Make sure what you’re working on is meaningful, and recruit people to the product teams who also feel passionate about this problem and then be willing to work for several years to realise the vision.
  9. Don’t be afraid to disrupt yourselves because if you don’t someone else will. Focus on creating new value for your customers, rather than on protecting what you have.
  10. Evangelise continuously and relentlessly.

Format

There is no set format for Product Visions. They’re sometimes short. Other times they can be very long, specific and go into all sorts of details.

The folks at TransferWise suggest defining a vision for a product by listing the core properties that customers use to describe its quality, imagine ultimate values for this properties and set a goal to achieve them.

Others suggest using the following format (originally from ‘Crossing the Chasm’, a book by Geoffrey Moore):-

  • For (target customer)
  • Who (statement of the need or opportunity)
  • The (product name) is a (product category)
  • That (key benefit, compelling reason to buy)
  • Unlike (primary competitive alternative)
  • Our product (statement of primary differentiation)

Company Mission versus Product Vision

As far as I can tell they can be the same or they can be different, but if they’re different they should certainly be aligned. The company mission addresses a broader audience, whereas the product vision may be relatively more internally focused.

Clearly if your company has multiple different products, each might have its own vision. On the other hand if you are a small single-product company a single combined company and product mission-vision statement may be more appropriate.

Don’t forget Marty’s 10th commandment “evangelise continuously and relentlessly” — that evangelism will be diluted if split between multiple competing visions.

Examples

AOL

https://svpg.com/wp-content/uploads/2017/07/Example-Vision.pdf

SpaceX

SpaceX was founded under the belief that a future where humanity is out exploring the stars is fundamentally more exciting than one where we are not. Today SpaceX is actively developing the technologies to make this possible, with the ultimate goal of enabling human life on Mars.

Telenav

At Telenav, we believe the car is at the beginning of a massive innovation wave that mirrors what happened on the smartphone several years ago. Building on our long history of mobile and in-car navigation software and services, we are on a mission to make people’s lives less stressful, more productive and more fun when they’re on the go.

Anonymous CRM product

For a mid-sized company’s marketing and sales departments who need basic CRM functionality, the CRM-Innovator is a Web-based service that provides sales tracking, lead generation, and sales representative support features that improve customer relationships at critical touch points. Unlike other services or package software products, our product provides very capable services at a moderate cost.

Innocent drinks

Make natural, delicious food and drink that helps people live well and die old.

TransferWise

Money without borders - instant, convenient, transparent and eventually free. We’re powering money for people and businesses: to pay, to get paid, to spend, in any currency, wherever you are, whatever you’re doing.

Zuora

Zuora enables businesses of all industries and sizes to price, package, and sell their products on a recurring basis. Our mission is to help you grow your business by establishing, cultivating and monetizing recurring customer relationships.

Further reading