What Does a Product Manager Really Do?

Software engineers architect systems, code and configure the infrastructure. Marketers put together web pages, information leaflets and create press releases, etc. Project managers put together project plans and check in with engineers. They also start asking "is it done yet?" as the deadline approaches.

But what does a product manager really do?

When I joined Twilio's Real Time Data team, we had an amazing piece of technology - but no customers or revenue. Today, a year later, we have three products built on top of this technology. Our customers now include one of the largest banking groups in the world, as well as some of the hottest startups in Silicon Valley and London.
Product managers played a key role in making this happen - among many other people, of course. In this post I'll be sharing my personal experience, as one of the three product managers working on these products.

The two most important PM responsiblities

Within my team I was responsible for the Notify product, which we publicly launched at the end of May. This meant two core responsibilities. First, I had to figure out how we'll make money off of our existing technology. Second, I had to make sure that we successfully execute that plan.

When I joined Twilio, we had a powerful framework to send messages to mobile and web clients. At the time, we only used this technology for our first product IP Messaging, a chat API.

About Viktor

Viktor holds a computer science degree from Budapest University of Technology and Economics and MBA from Harvard Business School. He worked as a developer and research intern for a year at IBM Research in Zurich, Switzerland. He then joined The Boston Consulting Group as a consultant where he advised the C-suite of banks and telecom companies in Hungary, Abu Dhabi, India and Turkey.

During his studies at Harvard he worked with multiple American, British and Hungarian startups, mostly advising on strategy and product development. Since 2015 he works as a product manager in London at Twilio, heading up the Notify product.

First responsiblity: How to make money

The problem was clear: figuring out how we could make money off of our technology for sending notifications. To answer this question, first, I took the time to understand what our technology is capable of. Next I researched the other companies active in the space. I collected all available information. What use cases do they advertise on their web sites? What features do they have? How much do they cost? I experimented with some APIs they offered, so I could get a feel for why one of them is better than the other.

Based on the above, it was clear that Twilio needed to add push notifications to its portfolio so I drafted a product proposal that would do just that for Android and iOS. I picked up the phone and called up a few potential customers. I told them about the product we were considering building, and what it could be used for. Eventually many conversations turned out like this:

Customer: So tell me, how is this different to the product that company X is already offering?

Viktor: Ummm... to be honest, currently it's not different at all. But could you tell me what problems you'd like to solve, and what user experience you're looking for?

Customer: Well, we really love using push notifications. But sometimes the users just delete the app or for other reasons don't receive our notifications. It would be great to fallback to SMS when this happens. But building this ourselves would take a lot of time.

Light-bulb moment... so basic push notifications is a solved problem but combining it intelligently with other channels is not.

I now had a clear idea of what we needed to build. However, I knew that I cannot do this on my own. To go from idea to product, I needed support from the top of the company and from my peers. So I put together a strategic proposal for management. I described the problem that our customers are facing, outlined the vision for how to solve it and included a roadmap for how to get there. The executive team loved it, so I had the support from the top. What this really meant was more resource to build the product and take it to market. :)

But it won't be the CEO who does the coding, and if the engineering team does not believe in the product, then that product will either never be ready, or it will suck. This meant that in order to succeed, I had to get full buy in from the team as well. Luckily this was not difficult - our software engineers are really interested in solving problems for our customers. As soon as I could describe specific use-cases that our customers are trying to build, I had buy in from the team.

The next step was to build and ship the product.

Second responsibility: execution

We had to break down the roadmap I presented to the CEO into one that was more detailed. The first step to this was defining the minimum scope that we could publicly launch, which really meant specifying the Minimum Viable Product (MVP). In this case it came down to an address registrar with user segmentation, plus an iOS and Android push notification channel.

We drafted a detailed specification. Then we broke it down into tasks that could be completed in a couple of days each. We created tickets in our issue tracking system and got to work. Every week we agreed on which tickets we will be working on and every Friday the engineers demoed what work they completed.

MVP: Minimum Viable Product

There are many definitions around but this is a pretty good one:

"A Minimum Viable Product is the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back)."

In other words, an MVP is the product that you can build fastest that people will pay for. Often it is much, much smaller than you initially think.

Shipping an MVP to customers as opposed to trying to build the final version at once allows you to start collecting customer feedback very early on and rapidly focusing in on what delivers the most value.

Having a product available also earns you the right to talk to people and talk to them seriously. Of course you should talk to your potential customers way before you have a product ready but they will have a much harder time to give you useful feedback. (Here is a [great guide](http://momtestbook.com) on how to conduct those early interviews.) Even within Twilio it was much easier for me to convince account managers to organize meetings with customers once we had a product in sight.

However, for this product to succeed, we needed more than just an API that our customers would use. We needed reference documentation and guides for getting started. We needed a portal to store configuration and provide debug information. We also needed to integrate this product with the other Twilio systems. We needed marketing materials, a demo application, a press release for launch, and the presentation for the launch at Signal. Finally, we needed customers for beta testing who could identify any rough edges in the product that we needed to fix.

Coordinating all these is the responsibility of the product manager. If no one else is available, then the product manager rolls up his sleeves and writes documentation, tests the new portal and the demo app, and creates marketing materials. And of course, he is the one to talk to potential customers that are interested in getting early access.

All set for launch. Except there's this tiny new feature to add...

After we finished most of the above, we were good for launch. But of course life always holds unexpected surprises. A few weeks before the launch announcement, the executive team asked if we could integrate SMS and Facebook Messenger channels for the big reveal. And if we were planning to ship automatic failover from push notification to SMS on day one. All of these features were on the roadmap but out of scope for the launch (remember we were building an MVP). Also, none of them seemed trivial to do - and since we were heads down working on the MVP, we never took the time to explore them in detail.

It was at this moment, when the product manager became really useful again. The engineering team never got bombed with these requests, as I was the one being asked first. This meant that they did not feel the pressure and could focus on finishing what they were already working on. We were slightly ahead of schedule with the original MVP so I thought let's go through some of these requests and figure out if there is anything we could take on.

Together with the tech lead we went through the list and agreed that the SMS and Messenger integration could be viable but the others would be too much. I echoed this back to management and we all agreed that this is the best trade-off. It gave us a very high-impact launch without taking too much risk.

We then presented this - more realistic - work to the engineering team, asking them if they agreed that it would make sense to give it a go. The team was enthusiastic so we started working on it. And the rest, as they say, is history. We managed to build and ship these new features for the launch on 25 May - which then was greeted enthusiastically by our customers and by the press.

Work of course, is not done with having shipped the product on 25 May. Things still to do include putting professional customer support in place - as of now I am customer support by myself. The product needs to be priced and priced reasonably so that it allows a sustainable business while keeping it affordable for our customers. But pricing is just the first step, we need to also integrate with the our billing system to be able to charge that price. We also have to start monitoring sales data, tweaking our marketing and communication based on this data, and training and supporting our sales people. This is all, of course, on top of the continuous and iterative development of the product, adding new features, while scaling the underlying infrastructure.

So what does a product manager really do? She figures out how to make money from technology, and makes sure the plan is executed. In other words: she is responsible for making the product successful.

(As the stories on this blog are mostly told by Hungarian software engineers, product managers and designers, all articles are also published in Hungarian. You can read the Hungarian version of this one here: Mire jó a product manager?)