Product managers have it rough. On the hook for building the right product at the right time, they have all the accountability and virtually none of the responsibility for getting it done. If the product is rife with bugs, doesn’t sell or is difficult to use, you point the finger straight at the product manager. Look under the hoods of any product failure and you’ll find--not always, but often--a burned out and uninspired development team standing next to her. And you know what? You can often blame the product manager for that, too.
Here’s why. Product Managers lead without direct authority, so they’re constantly faced with convincing stakeholders and engineers that this strategy or that feature is valuable to the customer and the business. Product managers are therefore responsible for setting the day-to-day workload of their engineering teams, so how they go about persuading and motivating developers to complete this work has tremendous impact on their morale and the final product.
Daniel Pink wrote an interesting book called Drive, and in it he examines what it is that motivates people. I’m going to summarize all 300 pages in one sentence (the fate of most business-y books, I’m afraid). Everyone, no matter what their role is, needs three things to be happy at work: purpose, autonomy, and mastery. Product managers are well positioned to fulfill at least some, if not all, of these needs. Let’s talk through each in a little bit of detail and how product managers can build a healthier office culture and, as a result, a successful product.
Purpose
People have an inclination to contribute to efforts that are greater than themselves. Engineers are no exception. That’s why the best engineers often work at the most revolutionary startups and powerful technology companies. Sure, the money helps, but that’s not the whole story. SpaceX, Airbnb, Uber--these companies are trying to change the world and such a grand purpose puts a fire in talented and ambitious people.
You don’t need to work at Google or Facebook to make the world a better place. There are a lot of companies solving hard problems you’ve never heard of (we’re hiring, btw). As a product manager, however, you do need to understand and clearly articulate how your roadmap will improve the lives of your customers. It doesn’t need to be space exploration or cancer research, but you should continuously communicate that customer value to your stakeholders and engineering teams so they have a clear understanding of why they’re coming into work.
What should you not do? Don’t conduct a sprint planning and say, “Sales asked for this, so we should do it; Marketing needs that, so let’s make sure we get it done.” Sure, helping others makes us feel good, but instead focus on why this work is good for customers. There’s an old saying that “engineers hold the keys to the compiler.” The meaning behind this adage is that they don’t have to automatically do what a product manager says. It’s the product manager’s duty to convince them to undertake the effort. If they don’t believe in the product manager’s purpose, then they don’t believe in the company’s purpose, and who wants to work somewhere they don’t believe in?
Autonomy
One of the most demoralizing thing product managers can do is decide the product priorities and then also tell software engineers how to implement the work. Writing code is a part of what software engineers do--it’s a tool, not their sole purpose--but when product managers prescribe solutions to problems, all the engineer has left to do is write the code. That’s not why we need software engineers.
Let engineers own the delivery and implementation. Even let them share ownership in the conception. Trained experts at processing and representing information, engineers bring ways of critical thinking and problem solving to the table not represented elsewhere in a company. When product managers prescribe solutions that don’t leverage engineering mindsets, they get uninspired developers and subpar results. Instead of telling engineers what to do, know the customer needs inside and out, and translate their pain points so effectively that you instill empathy for the customer within the engineering team. In the right minds, solutions--and thus killer products--present themselves effortlessly.
What should you not do? Don’t write user stories that request “Nightly XML Data Feeds.” Instead, tell your development team you need to give a partner access to some data. Explain how the partners plans on using the data, how frequently they need access to updated data and why it’s important to them. Maybe there’s a better technical solution for all parties involved, but when you request a particular delivery mechanism and markup, you shut the door to better ideas before you’ve even started implementation discussion. As a rule of thumb, avoid mentioning technical details where possible. The instant you start mentioning UI elements or languages, you’re probably taking away all fun, overstepping your bounds, and limiting engineering creativity.
Mastery
Everyone enjoys being good at something, but what they like even more is getting better at it. The worst feeling comes from toiling away on an initiative and having no way to know if it’s working. At least if you know for certain it’s not working, you can adjust your approach and take another measurement. Improvement is a strong motivator because it validates our efforts and even when the other two motivators fail, it’s concrete proof that we’re not utterly wasting our existence.
Product managers should always be setting measurable goals for features. How else can you be certain when you’ve succeeded or failed? Even when you don’t know what’s possible, you should make an educated guess. Identify a metric that represents success, take stock of where you are today and monitor it with every release. If tracking the success metric requires development, then so be it. Make sure your engineering team understands the metrics, is fully bought into their meanings and has full visibility of the reporting. Blast it on TVs and monitors throughout the office. Make success and failure transparent.
What should you not do? Don’t cop out with an excuse that the benefit exists but cannot be measured. Everything can be measured if you define success appropriately. Finally, hitting measurable goals is a momentous occasion, so don’t forget to celebrate the wins. Hitting goals is a great black-or-white indicator of success, but celebrating the effort required to get there makes people feel valued.
Everyone, from engineers to business stakeholders, love to work with strong product managers. If you’re a product manager, leverage these principles and watch your effectiveness as a leader skyrocket. While you may not directly manage those you work with, you’re a tremendous influence over everyone who actually delivers the product. That shouldn’t be taken lightly. When you look under the hood of successful products you will always find cohesive teams that highly value an aggressive vision, functional creativity and measurable progress.
Comments !