Dear Product Managers: Build great teams
A company is only as good as the people within it. Similarly a product will be as good as people allow it to be. Here are some “team-isms” I’ve learnt building products and nurturing teams.
Put the teams knowledge to work
Let technical people solve technical problems. Let design people solve design problems. Let business people solve business problems. That isn’t to say you shouldn’t be involved, have input, guide discussion however you don’t hire a knowledge worker to then dictate to them how they should think. Let your team use and grow their knowledge — everyone benefits.
Learn for the team
It is vital to understand what members on your team do. Whatever your background is, having well rounded knowledge that compliments your teams skills allows you to empathise and efficiently communicate with them. Making someone explain themselves 3 times slows down work, can make you both frustrated/misunderstood and you very much want to void this:
The single biggest problem in communication is the illusion that it has taken place.
George Bernard Shaw.
Advocate for the team
Whatever your title is, Product Owner/Manager/other, if you are managing a product coming to life or iterating on an existing product there needs to be a vision for that product. That vision needs to be known within your team and the rest of your organisation. It should be more than just your team that knows and is enthused about what you are building. This advocacy is ongoing; humans are forgetful creatures.
Shield the team
Even with advocacy there will be friction of ideas, timelines and more from the wider business. While you should portray a sense of urgency to your team, they shouldn’t be distracted by every whim and change of heart in the direction of the product. The time for roadmap planning or re-defining MVP isn’t every other day and so you need to shield your team from that. Agile product development isn’t about cognitively overloading your team with a potential change of product direction every other iteration.
Understand the team
This team-ism I find particularly interesting. It’s similar to “Learn for the team” but less about skills, more about human nature and behaviour.
One insight for me came from the logic of “makers schedule vs. managers schedule” by Paul Graham. Managers schedules are largely broken into 1 hour units. For makers however (engineers/designers) units are half a day i.e. 2 units per day. Throw a mid-morning meeting into a makers schedule and you have broken 1 maker unit into two pieces that are often too small to get deep knowledge work done.
Most of your team will be on Makers time — cater to that.
Another great read is Implementers, Solvers, and Finders by Randall Koutnik. Some people want to plow through pre-defined work, others want to solve problems, others want to find problems to solve. If you only offer pre-defined work, problem solvers will look elsewhere for problems to solve or will stay, be unhappy, and as the idiom goes: one bad apple spoils the barrel.
Tell the team
Be upfront with the team. Build trust. Trust is vital in teams and leading people down a garden path only to end up in a rocky ravine will deteriorate trust. Don’t make promises you can’t keep and don’t tell different team members slightly different stories. Similarly if you don’t know, say “I don’t know” and find out what you need to get back to the team with an answer.
You will at some point have to tell your team something that isn’t ideal. Having built up trust is a much better place to be than a team that is untrusting.
Celebrate with the team
When launching a product you can often be planning or already building the next feature or next product. Make sure you take the time to celebrate, both as a team and also a wider group/company. This has a multitude of benefits both for appreciate in the team, advocacy amongst the wider company and mentally closing a loop.
What team-isms have you learnt?
If you liked this you can find more at http://matthewardeljan.com :)
