Your Team Is The Enemy
If you're like most product managers, you don't get to choose your team. You get whatever resources the company has available - engineers, QA, design, project management, and so on.
Sometimes you get a team of great people. Sometimes you get so much deadwood and burn-out cases you're afraid a spark may ignite the whole bunch.
You will almost certainly have fewer people than you'd like, and you may have fewer people than you need.
But regardless, they are your team. They are the ones who will be doing most of the actual work of creating the product.
Your job is to make sure they make the right product. And it's tricky, because without proper guidance and structure, your team is the enemy, and they will wreck your product.
Lights, Camera, Action
In many ways, Product Managers are like directors, and products are like films. The products have themes. The participants need to understand their motivation - why are they doing what they're doing? And the Product Manager needs to make it all happen.
If you don't direct them, your team will wander, literally and metaphorically. Good products come from teams that know exactly what they're building and why. Teams need to know what's important about their product - what makes it worth building? They need to know the most important use cases (things users will do with the app) and invest development effort there.
They need to know where the value in your product is coming from. Is designing a new kind of scroll bar a good time investment? (probably not, because it's not what's driving your product's value) How about a whizzy new database? (only if it's something your product relies on). Many teams wander because the individuals have their own agendas...because the product manager wasn't clear about what the team's agenda should be.
Imagine a bunch of actors on a set. They all have particular goals and takes on their characters. They may even have different acting styles. In good movies, the director works to blend everything together and pull it in service of a common goal. Gratuitous, unnecessary, or inappropriate elements are cut. The same should be true with products.
Focus
Once I worked on a software product intended for audio playback. The engineers had a very cool interface technology that allowed for some very ahead-of-its-time customization of the UI. We all thought it was neat, so we included it in the player. The code was solid, and it had minimal CPU impact...but it was a mistake.
The feature did not drive the core value proposition of the app, and actively distracted users and the company from the app's true value proposition. The sales guys were showing off that part of the product because it was visual and different. People got excited and wanted enhancements. But improving that part of the product didn't help the business. It was a huge distraction.
If you let your team drive the product, you may get a bunch of cool features and designs, but they won't cohere, and they may not drive your core value proposition.
Democracy Is Bad
On a movie set, the director makes all the decisions. Right or wrong. In most of the successful rock bands, one person makes the final decisions. Same is true of the best product teams. And that person is the product manager. YOU are responsible for whether or not it's any good.
Product management is not a democracy. Many people have opinions and perspectives, but only one person has responsibility. Some refer to the Product Manager as the "one neck to wring". The trade-off for that liability is "final cut" or final approval. Use it.
If you don't, you are not likely to end up with a great product - one that has a vision, a theme, and some bold direction. You'll get oatmeal. A bunch of things that are OK. Or you might get a bunch of stuff in a box which sort of works.
I believe the best design visions, the best products, the best art all come from single perspectives. They can be made richer via other input and may require other people to execute, but there should only be one "designer".
Don't Be A Dictator
That is not to say you should be dictatorial. You should strive to build a harmonious team. And you must listen to everyone with great care, and take their comments and concerns seriously. Build consensus where possible.
The key words are "where possible." Despite best efforts, you are going to reach a point where your team disagrees. There are many ways to drive consensus ("Fist of Five" being a good one). Don't be afraid to make a call. Just make sure you have reasons for doing it, and make sure the team understands.
Alienating your team is a fast-track to failure. You cannot succeed without them.
Fires
Most of the time, you work with grown-ups. Even if they aren't in love with the project or your decisions, they will bring their "A-game" (or at least their B-game) every day and get stuff done. But sometimes you get stuck with a bad apple.
This can be the person who simply doesn't pull their weight. It can be someone who undermines the team explicitly, by being a jerk to the team, being overly negative about the project, or who constantly argues with you about direction. This can also be someone who is talking to people in the company above you without your knowledge.
These are small fires. If you don't put them out, they can grow quickly and result in product wreckage. It might be cancellation, reduced buy-in, or just demoralization.
The first and best approach is to find out what's bothering the team member and see if you can mollify them.
But do not be afraid to request their removal from the team. Often it's best just to get them out of the picture.
Feedback
Provide lots of low-latency feedback to your team. In other words, talk to them a lot, and talk to them as the project is in motion.
Important things to do:
- Talk to all team members every work day. Not just to pester them about "are you done yet?", but ask what obstacles they're encountering. What can you do to help them succeed?
- Know your team. If you want to understand your team, get to know them. Maybe your developer is slow this week because he's having personal problems.
- Eat lunch together. Buy your team lunch every now and then. Even if the company won't expense it, you can get everyone a sandwich somewhere for not that much money. It's hard to be a jerk to someone you had a sandwich with yesterday, and everyone likes the surprise of a literal free lunch. Plus it fosters communication. And I don't mean "bring in a pizza and keep working." I mean get OUT of the office, go sit down somewhere, and relax.
- Regular reviews. Periodically review the accomplishments. Praise hard work. Look for things causing problems. This is most important early in the project and at the conclusion of the project.
This stuff may seem overly basic, but I am always surprised at how often people don't do one or more.
Up next: YOU are the reason.
