Matthew Andrews
Product Manager ・ Software Engineer ・ Executive MBA Graduate ・ Tokyo Resident
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 ways any product team can become a little more agile

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.

However, 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 them 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, butmake 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. Used 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 work in a product team following traditional project management techniques, you can make your product team a little bit better by focusing on this prioritised list:

  1. Talking directly to real customers
  2. Testing product concepts
  3. Releasing 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” …

Week Notes #2 ・Non-alcohol, Website restructure, Alan Parsons, Into The Night

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

Non-alcohol

Thursday 21st May marked 5 months since I gave up alcohol. I miss it far less than I expected. Partly because I feel so much healthier and partly because I’ve found some really excellent alternatives to alcoholic drinks (I have comprehensively reviewed the ones available in Japan here: https://mattandre.ws/nonalcoholic)

Website restructure

Observant viewers may have noticed I have reorganised my website a little bit.

  • The home page, which used to show all my newest posts, will now only show ones I’ve chosen to feature.
  • There’s a new section “All Posts”, which is the full unfiltered feed.

I’ve done this because there are some posts (like my negotiation article) that I spent a lot of time on, am genuinely quite proud of. But sometimes I just note down coding tips or personal thoughts like these Week Notes that, frankly speaking, would be better less read.

With this change I hope to create far more content on topics of personal interest to me, without (hopefully) drowning out the good stuff.

Alan Parsons

Speaking of subtle, almost inconsequential changes, I noticed that the music being played in my local 7-11 that always seemed to have been a cheap synthesiser version of The Monkee’s classic “Cheer Up, Sleepy Jean”, has been replaced by a less irritating piano rendition of the far more obscure Alan Parson’s “Eye In The Sky”.

I’ve actually seen that song being performed live by Alan Parsons, at a gig in Shepherd’s Bush, which I went to with my parents. That same night I took them to one of my favourite Chinese restaurants in London and introduced them to authentic Peking Duck (none of this Crispy Fried Duck rubbish), which they liked a lot, and Jellyfish, which they liked a little less.

I miss live music.

Into The Night

Reading books, cooking, running and Netflix are now what we’ve been doing ‘for fun’ during this pandemic.

I used to joke that after finishing my MBA (last December) I planned to spend the whole of January in my underwear watching Netflix. It seems very hollow now we’re all locked at home hiding from the virus with not a lot else to do.

Over this week we watched “Into the Night”, the new Belgian series on Netflix where the sun’s rays have turned deadly and a group of survivors, each with dark and troubled personal histories, use an airliner to try to outrun them by flying west into the night. Lord of the flies meets Lost meets Speed. It’s utterly ridiculous. Unbelievable. Full of plot holes. Way too overdramatic. But it’s awesome and you should definitely watch it.

Week Notes #1 ・Copying, Listening, Running, Emergency

Hello and welcome to my ‘Week Notes’. This format was inspired by copied from my esteemed colleague, Alice Bartlett.

Week notes will be:

  • Weekly. Except that some weeks will be too quiet or too busy and therefore notes will not be written.
  • Containing the kind of content I might tweet then wait an hour then retrospectively realise was not worth tweeting then delete.

In other words, what follows is unreliable low-grade content. Enjoy.

Copying

On the topic of copying, I’ve written a short note before about the value of copying competitors so I felt slightly vindicated to read it being advocated in the current edition of Harvard Business Review.

The practice of borrowing runs directly counter to the conventional strategic imperative of differentiation—which traditional strategists argue is essential to avoiding the negative spiral of competing only on cost. But trying to differentiate early on in a new market can lead a company down a blind alley. A more effective approach, we argue, is to treat other companies in the space as peers rather than competitors … Borrowing [enables companies] to develop working [prototypes] of its product quickly and cheaply.

https://hbr.org/2020/05/the-new-market-conundrum

Listening

It was an excellent read … or, in my case, listen. This latest issue of HBR was also available in audio for the very first time through their mobile app. I have listened to the audio edition of The Economist for years and absolutely love the hands-free continuous listening experience whilst commuting and going to the gym (remember those?) … so I was absolutely delighted by this new feature.

Running

The gym has been closed since the declaration of an emergency in Tokyo but I’ve been pairing my audio editions with loops around Tokyo’s almost-built Olympic stadium instead. A jog around the stadium’s perimeter is an almost-flat uninterrupted 1.5km and since the Olympics has been postponed I figured someone may as well use it. On Thursday I passed the milestone of running 500km so far this year.

Emergency

The state of emergency in Japan was lifted in most prefectures this week. We never had an enforced lockdown, only a polite request to shut businesses and stay home. Tokyo, which continues its state of emergency, has already started showing signs of going back to normal. More and more restaurants are open for sit-down meals.

This is good news. Not because I’m itching to eat out but because it’s being done because Japan’s COVID 19 situation seems truly heading a good direction. Tokyo is down in the 10’s of cases per day.

It’s also good news because I am rapidly approaching the inflection point where the danger posed by going to get my hair cut is less than the danger posed by constantly touching my face to brush hair out of my eyes.

Special mention

My dear friend and former MBA classmate Laura Martinez Oliveras has launched her business in Australia. I had the good fortune of working with her during my second semester, the work we produced together was the best work I was part of during the entire programme. I highly recommend anyone to work with her and her hugely talented associates! https://www.martinezoliveras.com/