Give them problems, not solutions

Give engineers problems, not solutions. It’s more constructive to tell the team “User engagement is dipping. What’s the optimal solution?,” than to tell them “Change the color of the SIGN UP button on the home page.”

When you give team members problems in context, they find their own steam to comprehend, overcome, and own the solution. Now you’re free to focus on the big picture. By way of contrast, when you motivate isolated solutions, engineers fulfill the letter of the solution then rush off in search of juicier problems.

Tell them things they don’t know

You aren’t going to enlighten engineers on systems or algorithms. Go beyond the four walls of the office, talk to customers, sift through the data, and bring fresh insights to the table. The team will see you as a source of insight and a guide to the future.

“I don’t know” is a fine answer

The honesty of “I don’t know” builds trust. Just because you’re the product manager doesn’t mean you’re the expert on everything related to the product. Engineers respect “I don’t know.” And they disdain half-baked answers.

Always have an opinion

Your job is to keep the team moving forward. You do that by making decisions and breaking deadlock. All other things being equal, make a decision and run with it. You can change course later if the decision turns out to be wrong.

Think before you churn

Course corrections drain morale and waste effort. Before changing a feature midstream, be certain that the change nets a valuable win. Better yet, plan features carefully and completely, before implementation starts, so that you don’t have to change course.

Set a high bar

The higher the bar, the higher the team will jump. Pushing for the best possible customer experience is a powerful motivator. Engineers can and will walk on water to make things right. Just as creativity loves restraint, quality loves direction. You provide that direction by setting the standard for what constitutes “good enough to ship.”

Let the customer win

It’s easy to get caught in the dynamics of argumentation and stick to an idea just because it’s your own. But good ideas come from anywhere. Trust the team, the conversation, and the data to collectively compute the optimal solution. If someone else has a better idea, run with it. At each step, seek what’s best for the customer, not what’s best for your ego.

Be technical

A software product manager should know software like the Colosseum architect knew stone. The more you know about the medium of your art, the better you jell with the team. If you’re a software product manager and you can’t code, or don’t understand the system architecture, there’s a substantial communication gap between you and the engineers. Engineers respect and respond to people with technical chops.

Be precise

Systems, software, and compilers operate with a cold and logical consistency. So do the engineers that build them. Be complete, clear, and accurate in your communication to engineers. Eliminate inconsistency and ambiguity from the plan of action—or expect push back from the engineers.

Don’t lecture birds on how to fly

No matter how technical you are, the engineers know the system better than you do. Trust them to solve problems as they see fit.

Always be prioritizing

A product manager’s prime duty is to aggressively prioritize features according to their value. Prioritize stability, performance, analytics, design, and new features. In that order.

The forgotten foil to prioritization is filtration, what aren’t you doing? Avoid everything that’s not a priority.

Insulate the engineers

Shield the engineers from churn, random directions, and useless meetings. Engineering is a heads-down activity. The more space you give engineers to ply their craft, the faster they’ll complete their work.

Be transparent

Business pressure, C-level feedback, and customer feedback belong out in the open. Instead of hiding your influences from the team, tell them exactly what’s up. The same factors that motivate you will motivate them.

On the flip side, secrecy and politics deprive engineers of valuable context and make your requests appear random.

Embrace feature ideas from engineers

There’s a narrow-minded view among product managers and designers that engineers don’t understand user-centric design. That may have been true ten years ago, but times have changed. Today’s engineers want to build killer user experiences. Partner with them.

Plan sprints together

Collaborate with engineers to determine features, milestones, and release dates. Don’t hand the roadmap down on stone tablets. Instead, create a shared sense of ownership around what the team is delivering for the customer. The more you trust engineers to prioritize, criticize, and think through the road ahead, the more motivated they’ll be to deliver.