As I mentioned in my last post, Friday was my last day at Google after a year and a half on the social impact team. For the last five quarters, I was the product manager for the One Today, a mobile app from Google with the purpose of creating a more socially aware and engaged world. The question we asked was this: Could we make learning about causes and taking positive action so frictionless, delightful, and engaging that we could change people's behaviors?
I could talk at length about the product and UX principles there (and who knows? maybe I will at some point), but for now, I wanted to take a moment to discuss the lessons I learned from leading a small team with a very large mandate.
Business books often say that leading a large organization is like steering a big ship; it's not easy to maneuver quickly. I would say the same goes for a small team with a large mandate. At one point, the One Today team was comprised of three engineers building and maintaining an Android app, an iOS app, and a web app. (I get stressed out just typing that sentence.) We had lots to do and any commitment the team took on meant weeks or months of work before we could take on another one, which brings me to my next lesson...
When I first took the reins for One Today, my first instinct was to try to make everyone happy. Do a little bit of what made marketing happy. Do a little bit of what made consumer operations happy. What took me a while to realize is that, at the end of the day, I would be evaluated by the success of the product, not by how happy I made everyone else. That's not to say it's unimportant to have a happy team, just that without a successful product, a happy team won't be around for very long. Fortunately, when you approach your team with empathy and you've taken the time to explain your process for evaluating ideas, it's actually not hard to focus on product success and make your team happy at the same time.
What lessons have you learned from leading a team?
I could talk at length about the product and UX principles there (and who knows? maybe I will at some point), but for now, I wanted to take a moment to discuss the lessons I learned from leading a small team with a very large mandate.
Lesson 1: Leading a small team is like steering a big ship.
Business books often say that leading a large organization is like steering a big ship; it's not easy to maneuver quickly. I would say the same goes for a small team with a large mandate. At one point, the One Today team was comprised of three engineers building and maintaining an Android app, an iOS app, and a web app. (I get stressed out just typing that sentence.) We had lots to do and any commitment the team took on meant weeks or months of work before we could take on another one, which brings me to my next lesson...
Lesson 2: Be sure before asking your team to invest time.
At least in my situation, and I'd venture to say in lots of startup situations, my most important asset was my team's time. When I first took over, a lot of my justifications for asking engineers to build things was "because we should" or "because it's the right thing to do". It took me a while to realize that if something wasn't going to contribute directly to our product's success, it didn't matter that we "should" do it or that it was "the right thing to do". But how do you evaluate if something's worth working on? That brings me to my next point.
Lesson 3: It's all about asking the right questions.
During my time at Google, I spoke to a lot of senior product leaders, and one piece of wisdom that really stuck with me was this: Good product managers know the right questions to ask. Great product managers make sure their teams know the questions too.
So what are these questions? Here are a few I use to evaluate a product:
- Why would someone use this? What’s the value proposition?
- How are we going to get new users? How can we target potential users when it’s contextually relevant?
- What’s going to keep users coming back again and again?
- What makes this different from other products in this space?
- Why are we uniquely suited to solve this problem?
I actually have a much longer list, but you can get a flavor here. If you don't have answers for any of these questions, you should take pause about your product plan. The best part is that when your team understands your thought process for evaluating products/features/ideas, it's very rare to get into disagreements.
And that brings me onto my final lesson...
Lesson 4: It's better to be right than to make people happy.
When I first took the reins for One Today, my first instinct was to try to make everyone happy. Do a little bit of what made marketing happy. Do a little bit of what made consumer operations happy. What took me a while to realize is that, at the end of the day, I would be evaluated by the success of the product, not by how happy I made everyone else. That's not to say it's unimportant to have a happy team, just that without a successful product, a happy team won't be around for very long. Fortunately, when you approach your team with empathy and you've taken the time to explain your process for evaluating ideas, it's actually not hard to focus on product success and make your team happy at the same time.
What lessons have you learned from leading a team?
1 comment:
Sage advice Ben, a lot of art in product management.
Post a Comment