How a programmer became a product manager

Original author: Jim Gochee
  • Transfer
Jim Gochee, New Relic Inc.
September 11, 2012

translation of an article A Developer Becomes a Product Manager

In the good old days, I made a living from programming. It was one of the best and most carefree stages in my working life. Besides writing code, I had few other responsibilities. I had no idea where the company took the money for my salary from and I had no idea how the customers would find out about our product. I did not think about why my boss asked me to program features X / Y / Z - I just wrote the code. My time was spent on solving interesting technical problems, and in general, my life revolved around programming.

Real world

Time passed and I began to notice that outside my engineering team there is a whole different world - the world of "business", or as I call it now - the "real" world. In this world, investments are attracted, products are advertised and sold, customers are served, and salaries are reduced. All the time that product managers
do not spend with engineering teams, they spend in this real world. In technology startups, the role of product manager is often played by the CEO. In large companies, product managers are mini-CEOs. (If you want to learn more about the impact product managers have, read the Marissa Mayer article , which discusses the role of product managers in Google.)

Product management diagram

The task of the product manager is to ensure that the work of the engineering team goes in the direction that coincides with the business goals of the company. One of the obvious goals is to create a product that the sales department can sell, in which the marketing department can interest potential customers and which the technical support department can support. Less obvious goals include mitigating competitive threats, strategically positioning the product, satisfying investors' wishes, and creating long-term benefits for shareholders. Although these concepts are rather vague, they help determine the context for the daily decision-making by the product manager.

If I wanted to describe the everyday life of a product manager in one word, it would be the word "NO." Once the product is launched, the number of ideas on how to improve it (aka “new features”) will significantly exceed the ability of your team to implement them. At NewRelic, we tracked improvement requests for two years. When their number reached 1000, we stopped, scratched our heads and removed them all. We stopped tracking new requests individually and just started counting them. In such a situation, the product manager can focus on a small number of cases that will bring the greatest return in the business, and say no to all other requests. (One simple way to achieve this is to keep a prioritized list of future work.) And when those inevitable two-three requests come in a day,

Defining Goals

Business goals may differ in different companies, but usually common to all projects is that you have to create a product for “someone” who does “something”. This someone is called the fashionable term "Person". Sometimes there is only one person in the product, sometimes a couple. And it’s very important to understand who these people are. How can you build something for someone if you don’t even understand them? Programmers often step on this rake and believe that they are creating a product for someone like themselves. (Well, after all, our users also use computers, right?). Take Salesforce for example - these guys understand exactly who the Persons are for their product: sales representatives, sales managers and top management.

“Something” is important because your product is most likely designed to solve a specific set of “problems” or “pain points”. For example, if your product is a Performance Monitoring Solution, it is important that your customers use your product to solve the performance problems of their applications. The second most frequently used expression (after “NO”) is “what problems does this solve?” Here is an example of a real situation that you may have to face. Designers do not like the layout of the web page and they insist on changing it. This change will make the product better, so there should be no problem, right? But danger can lie in wait in two places:

If you ask yourself - which of the problems in my product are most acute and send a team to solve precisely these problems, then this will be the correct prioritization of the backlog. And the last point about “problems” - sometimes they disguise themselves as other things, such as “opportunities.” For example, users will not tell you that installing the application takes too much time. There is no obvious problem. However, as a smart person, you will be able to recognize that speeding up the installation process will increase sales. The long installation time of the application is a problem because users have a short period of attention retention. Another example is the Apple iPod. The iPod did not bring new functionality to the market, but it was simple and stylish - a fashionable product. The fashion factor at first glance does not solve any problem, people just want to be fashionable. But having offered a fashionable product on the market, one can satisfy the desire (to solve a problem) of a large group of people.

And although I sometimes miss programming, I’m not ready to exchange product management for it. I like to play a key role in the success of NewRelic, and I like how successful NewRelic is!

Also popular now: