Becoming an Effective Product Manager

By Therese Lim

In our OPower class, we talked about the role of a Product Manager and how he/she can best be effective in dealing with multiple stakeholders. It is truly difficult, as I found out over the summer when I had the opportunity to be a PM on a Kindle team. Although Amazon has far more resources than a startup, the responsibilities of the PM are no different. In fact, because Amazon has so many products (even within the Kindle team), I found that I had to compete fiercely for people’s limited time and attention if I was to make any progress. It was initially difficult adjusting to a softer means of persuasion, but over time I learned some best practices for becoming a more effective PM:

1.    Have a vision. This sounds simple but you’d be surprised at how many people form a product by cobbling insights from every “stakeholder”. From what I’ve seen, that usually results in a frankenproduct that has no internal cohesion. More importantly, there is no surer way to lose credibility among your cross-functional peers than by saying, “I’m designing X. What do YOU think it should look like?” [Insert stony stare here.] Your product should be the result of extensive customer research, but it should be your vision. Not your boss’s or the sales team’s, or the result of a voting process. One really good practice Amazon has is “working backwards”: the PMs will first create a mock press release that forces them to articulate a simple product vision that addresses customer needs. Only afterwards will they investigate its feasibility. It encourages risk-taking and a customer-centric mindset unencumbered by internal issues.

2.    The best way to sell your idea internally is to excite people with something they can see and feel. I initially had trouble getting colleagues to pay attention to my project. “Not on the roadmap,” they would say. The breakthrough came after I created a set of mocks on PowerPoint. They weren’t the most beautiful mocks, but they made the product I was describing instantly real. I had thought that I needed high fidelity prototypes in order to persuade people, but I was wrong. They just needed to visualize how they could contribute to the project, and the mocks helped catalyze that mindset. Finally, framing is key. I broke down my requests into small chunks that seemed almost unreasonable to say no to. But I made sure my time estimates were accurate; no one likes to be misled. 

3.    Prioritization = making tradeoffs based on data. Every engineer I approached at Amazon had the same concluding point to make after our meetings: “show me the data on how this moves the needle, and tell me what you’re willing to give up to get it.” Implicit in this directive are two things: you must be back every recommendation up with clear data, and you must understand technical tradeoffs. For the latter, I found some engineering allies who were able to do some quick scoping and tell me how much development time my request would take up. I then compared that to the features on the existing product roadmap in terms of expected outcomes (revenue, users) to determine where in importance it fell. Ultimately, these decisions can’t be outsourced to another team who doesn’t understand the competing interests involved. The buck stops with you.

As many people have said, the job of the PM is often the hardest. You’re the first to be blamed if things go wrong, but often have no formal authority when driving a product forward. You have to balance competing interests and make tough decisions that will make at least one party unhappy. But at the end of the day, you’re supposed to be the advocate for your customers, and you should make sure you’re optimizing for their interests above everyone else’s.


Popular posts from this blog

Quiz Time 129

TCS IT Wiz 2013 Bhubaneswar Prelims

The 5 hour start-up: BrownBagBrain