In the good ‘ole days I used to earn my keep as a software developer. Those were some of the best and most carefree times in my career. I had few responsibilities other than writing code. I had no clue where my paycheck came from and didn’t think twice about how customers discovered our product. I didn’t question why my boss asked me to build features X/Y/Z — I just built them. My time was spent solving challenging technical problems and that’s pretty much what my life revolved around.
The Real World
However as time went on, I came to notice a whole other world outside of my engineering team. This was the world of “business”, or as I call it now, the “world of reality”. It’s where money is raised, products are marketed and sold, customers are serviced, and paychecks are cut. This is the world where Product Managers live when they’re not working with engineering teams. In a technology startup, the CEO is often the Product Manger. In a larger company, Product Managers are like mini-CEOs. (If you want to understand the impact Product Managers can have, check out this article about Marissa Mayer which discusses the role Product Managers have at Google.)
A Product Manager’s job is to align the efforts of the engineering team with the goals of the business. Obvious goals include producing a product that the sales team can sell, the marketing team can attract eyeballs to and the customer support team can service. Less obvious goals include competitive threat mitigation, strategic positioning, catering to investor sentiment, and building long-term shareholder value. While these are lofty concepts, they help set the context for the Product Manager’s everyday decision making.
If I could describe in one word the daily life of a Product Manager, that word would be “NO“. Once a product gets off the ground, ideas for improving it (aka feature requests) will far outstrip your project team’s velocity. At New Relic, we tracked enhancement requests for two years. Once it reached 1000 requests we stopped, scratched our heads and deleted them all. We stopped tracking new ones separately and instead switched to broadly counting them. Given this reality, a Product Manager needs to focus on a small number of things that will have the most impact to the business and say no to everything else. (An easy way to do this is to keep a prioritized list of upcoming work.) When the inevitable two or three requests per day flow in, you can evaluate them against your “top 10” list and they either make the cut (and push something else out) or they don’t.
While business goals may differ between companies, what’s normally consistent is that you’re building a product for “someone” who is doing “something”. That someone is given the fancy name of “Persona”. Sometimes there is one Persona and sometimes there are a couple. And it’s extremely important to understand who these people are. How can you expect to build something for someone if you don’t understand them? Software developers often make this mistake and assume they are building a product for someone like themselves. (Hey, that person is using a computer isn’t s/he?). Take Salesforce — those guys understand exactly who their Personas are: sales reps, sales management and executive management.
The something is important because your product is likely targeting a specific set of “pain points” or “problem domains”. For example, if your product is an Application Performance Monitoring solution, it’s important that your customers can solve application performance problems with it. In fact, the second most common statement out of my mouth (other than “no”) is “what problem does this solve?” Here’s a real world situation you may have run into. The designers on the team don’t like the layout of a page and insist on changing it. This change will make the product better, so what’s the harm, right? The danger comes if (a) users don’t appear to have problems with the current layout, but (b) they do have other design related problems that will be back-burnered as a result.
If you simply ask yourself what the biggest problems are with your product and have the team work on those, you’ll have correctly prioritized your backlog. One final comment I have on “problems” is that sometimes they masquerade as other things, like “opportunities”. For instance, customers may not tell you that your product takes too long to install. There’s no obvious problem there. However, being the smart person that you are, you recognize that a quicker install leads to more sales. The reason being that installation friction is in fact a problem since prospective customers have notoriously low attention spans. Another example is Apple’s iPod. The iPod didn’t bring much in the way of new features, but it did bring simplicity and style – aka coolness. The cool factor doesn’t look like it’s solving a problem; people just have a desire to be cool. By offering a cool product you are solving a problem for them.
While I do miss coding, once I became a Product Manager there was no going back. I love being critical to the success of New Relic — and I love how successful New Relic is!