Listening for a living

Listening for a Living
Working as a product manager with a completely distributed team requires techniques and shifts in emphasis that are not
needed if the team is colocated. This deck lays out some of those I found useful over the two years I worked with a distributed
team building an analytics application from a shed in my garden.
Created with Haiku Deck, presentation software that's simple, beautiful and fun.
By Rod Nicolson
page 1 of 12

The distributed team I worked with consisted of developers in Minnesota and Ohio and Toronto, supported by a UX team in
Denver and others spread around all over the USA.
By Rod Nicolson
page 2 of 12

The team worked to agile principles and so I've used these to organise my thoughts and what I learned.
By Rod Nicolson
page 3 of 12

Being removed from the people you work with means meany hours on the phone or Skype calls. Not being able to see them
(even video is a very poor substitute) means it is important to listen carefully to what they are saying, what they are not saying,
and the way in which they say it. All this can be as revealing as body language, sometimes more so.
In calls, whether video or audio only, it is important to make time to connect personally with individuals to build the kind of
relationships you would if you worked next to each other.
As the team don't have a shared physical space it can be hard to make what the team is working on visible. You don't have
walls around the team that you can stick stuff on, but you do have wikis, kanban boards, Jira, Slack, email footers, etc. This
helps people remember what, why and how you are working on something.
You can see if someone is busy if they're sat next to you. You can't if they're a thousand miles away. Work out what people's
work patterns are and leave them alone at key times.
Product managers deliver nothing by ourselves. Our team is our #1 most valuable asset. Being distributed tends to magnify the
effort required to build and maintain productive and happy teams, but can deliver great results.
By Rod Nicolson
Photo by perpetualplum page 4 of 12

Creating good software is hard, even if you are all working in the sample place.
A team where all the members are distributed and either work from home or in separate offices is harder, but distance is not the
primary influence on difficulty.
A team that combines colocation and distribution might be more tricky to manage, as this can create cliques and us/them
feelings in the separate teams, even if the remote workers are reasonably close.
Every team is different, and will have different needs and solutions to help it perform.
By Rod Nicolson
page 5 of 12

Studies show that moving people even six feet away from each other in an office significantly degrades the quality and quantity
of their communication. So to compensate, processes and tools become more important in a distributed agile environment.
Clear, agreed and regularly reviewed processes add structure and ensure everyone knows what their involvement is expected to
be at all points in the process.
With no corridor, water cooler or kitchen, we can't have so many adhoc chats to work out issues or generate those 'ahah!'
moments, so regular, scheduled calls can help fill the gap. But...
Keep meetings focused. Ensure every call has a stated goal, and keep on top of whether each call is continuing to deliver value.
For key points in the process where information has to be communicated between people or teams, I find that working out who
needs the information the most helps identify who should run that part of the process.
By Rod Nicolson
Photo by Stéfan page 6 of 12

Absolutely nothing beats getting everyone face to face. This is vital to creating and maintaining reliable, productive and happy
teams.
Depending on the maturity of the team and the culture of the organisation, you should meet between once and four times a year.
By Rod Nicolson
Photo by Werner Kunz page 7 of 12

Working software is our goal and so is valued more than documentation, but distributed teams might require more to be written
down than those working closely together. A lot depends on the needs of the team and the correct level should be a matter for
retrospectives and reviewed regularly.
Two types of documentation I found useful were a glossary of key terms, and short notes in the stories added by the developer to
explain the logic they implemented.
Both provided useful and quick ways to get an answer when I couldn't remember what data the Blooper used, or exactly what the
Awesomizer did.
By Rod Nicolson
Photo by ºNit Soto page 8 of 12

Although the shed is warm and comfortable and I was happy in there with the spiders and the crates of cables and bike parts I
can't bring myself to throw away, a product manager does need to get out of the office.
So travel is part of the job, but much can be done on the phone and online.
Clever product manages build good relationships with those who have relationships with their customers. The data and contacts
Sales and Ops provide will extend the range and volume of feedback available without adding to the travel budget.
By Rod Nicolson
Photo by Peter Ras page 9 of 12

All the usual rules around this apply, plus, if you are also remote from the rest of the business, you need to at least triple the level
of your communication. If it's a global business then you may need to multiply it by more.
Communication can be made easier if you are as transparent as possible with the rest of the company. Kimonos don't have to
be abandoned entirely, but be as open as you possibly can. It helps explain why you have to say "no" and it builds trust for when
things go wrong.
Allies and evangelists for your product are invaluable and should be both formally and informally recruited. Appoint enthusiasts
as product champions and help them learn everything about it, so they become the person in Singapore or Denver or Edinburgh
who people turn to instead of you.
Make yourself visible - it's tough from thousands of miles away, but if you own a product you need to ensure your presence is felt
in the right places.
By Rod Nicolson
Photo by spierzchala page 10 of 12

All the usual rules around this apply, but I found that communication to the rest of the business needed to be multiplied many
times compared to a product manager working in, say, a head office.
Agilistas want to respond quickly to changes in the market, but deviations from the published plan must be explained to all the
relevant stakeholders, who wouldn't all fit in my shed even if they weren't 3,000 miles away.
Communication can be made easier by being as transparent as possible with the rest of the company. Kimonos don't have to be
abandoned entirely, but need be as open as possible. It helped to explain why I had to say "no" and built trust for when things
went wrong.
Finding allies and evangelists for my products is a life-saver. Try to appoint existing enthusiasts as product champions and help
them learn everything about it, so they become the person in Singapore or Denver or Edinburgh who people turn to, and who will
pass on important information.
Lastly, it is important to make oneself visible - it's tough from thousands of miles away, but making your presence is felt in the
right places even when you're not there is important.
By Rod Nicolson
Photo by spierzchala page 11 of 12

And I always try remember that my products' successes are largel because of other people's efforts, and where they're not, it's
almost certain that I was just lucky.
By Rod Nicolson
page 12 of 12

Listening for a living

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Listening for a living

Similar to Listening for a living (20)

Recently uploaded

Recently uploaded (20)

Listening for a living