Product management is about learning how to communicate

Eleven principles for communicating as the Head of Product at Tinybop.

There are a lot of voices in the world of product management: how you build a good product, scale a team, adapt and grow your processes, ship on time, and keep everyone accountable.

But when I talk to product leads or product managers in person, the conversation is inevitably more nuanced, and almost always more about learning to be the most effective communicator possible. It’s about sensitivities and boundaries and respect and autonomy on your evolving team. How do you demonstrate kindness with firmness at the same time? How do you create value, motivation, and show empathy? How do you show compassion to the process, while getting the outcomes you champion for your company? Everything about what you’re building is also about how you make people feel while they are building it and that comes back to communication.

For the last few years I’ve been at the helm of the product team at Tinybop, a collaborative studio in Brooklyn making educational iOS apps for kids. I was here when it was just me and one other person (the Founder & CEO, Raul Gutierrez) in a scrappy little office overlooking the East River; now we’re a team of 20+ with 5,000 more square feet, and five apps being played by five million kids in hundreds of countries around the world (with a few more in development).

Our team is made up of designers and engineers, illustrators, educators, production artists, web folks, translators, writers, and product managers. The members of our team have a tremendous range of previous work experience, startup experience, creative and technical skills, and different expectations about leadership and management. We have different working styles and different strengths. We have detail-oriented perfectionists and out-of-the-box dreamers. We have process nuts, and process rebels.

Here are some of my guiding principles for communicating as a product lead. Putting these ideas fully into practice is an ongoing practice unto itself. I‘d love to get your feedback.

1. People can’t know what you don’t tell them. Be thorough and provide context.
2. Always be learning. Read and have conversations with people who know more about topics you are interested in. Here are some things I’ve read and learned a lot about in the last few years: the app market, educational theory, (opinions about) screen time, the ins and outs of iOS devices, localization, pros and cons of Android and iOS, gaming frameworks, gaming culture, user interface design for kids, sound design in games, the VC world, how to manufacture toys, OKRs, how to generate beta test groups, flat organizations, creating diversity, efficiency, social media advertising, productivity tools, and much more. It’s so easy to let your knowledge get out of date which is prohibitive to innovation and your ability to communicate.
3. Familiarize yourself with the tools and language of engineers so you know how to facilitate technical problems even if you consider yourself a non-technical person. This fantastic piece by Aaron Schildkrout dives deeper into this.
4. Frame problems rather than prescribing solutions.
5. Be as clear as possible about project ownership. People would rather be accountable for their own successes and failures than be part of a mediocre outcome without ownership.
6. Avoid chiming in on everything. I think of this as the ‘infinite dialogue’ problem. Product managers are often the catalyst for this. It often seems ideal (and the most democratic) to ask for open-ended feedback and create an environment where everyone is encouraged to have a voice. This often leads to spiraling further away from a decision and a direction. Frame questions (and processes) so you can hone in on solutions with buy-in.
7. Just because you know how to do something doesn’t mean you’re the best person to do it. You’re probably in a product role because in many ways you’re a highly competent generalist. Learn to watch people try (and sometimes fail) at things in order to become better at them.
8. If you asked for feedback and you’re not hearing back, reconsider how you’re asking for feedback (try not to assume people have nothing to say).
9. Ask. A. Lot. Of. Questions. Create situations that enable others to articulate what they need and want.
10. Stay open to better solutions than the ones you thought of and make people aware that you’re open to those solutions.
11. Provide a place for ideas to go. Keep track of the ideas that keep you and your team up at night or come out in the chatroom. Make sure people know they have input and that someone is looking and listening to those ideas. This is something we’ve recently started at Tinybop; every project has an idea funnel that also asks the contributor to consider the business value of the idea. It helps everyone understand why some some ideas move into the product, while others don’t.

I’d love to hear from you — product folks, people building apps, managers of growing teams + companies— on what guides your approach. I hope you’ll leave a comment here, or reach out to me directly. You can find me @youngna on twitter or at youngna@tinybop.com.