Thought on Product Management

🚧

This Post is still in Progress

Setting the Stage

My “day job” is as a Product Manager at Sony Music. But I haven’t always been involved in tech or worked in a large corporate environment. In fact, this only represents the past 5 years of my life.

So here’s some stage setting that may provide perspective as to why I think the things I think in my Product Management context.

I have a fair bit of formal education including a business undergrad from University of Victoria in Canada, and an MBA from a University of Bocconi in Italy. I don’t necessarily see this as a good or bad thing, it’s just part of the story.

I also have a fair bit of hands-on business experience. In my second year of undergrad I started my own home painting company where I managed roughly 20 employees and generated roughly $200,000 of gross revenue over the two summers I did it. This included hiring and training those employees, and doing payroll. It also included door to door sales, logistics of running up to 5 projects simultaneously, negotiating supplier deals for paint and equipment, and everything that goes with billing customers and reporting to the government.

After that I worked in relatively small companies that were very flat, with a single decision maker. They didn’t do everything perfectly, but they got things done and moved quickly. They were able to compensate for errors with quick decision making and what today’s world might call “pivots” in strategy.

Once I got into the music business, I launched my own company as a Canadian music distribution arm of a German company. This was something I did “on the side” as an experiment while I was the COO of the German company. I grew this Canadian company to do almost a million dollars in Revenue. It involved the usual corporate reporting requirements to the tax man, including international tax legislation and registrations since I was moving physical goods across borders. We also had up to 5 employees. And I was able to secure roughly $200,000 in government grants and tax credits through the companies life.

What is Product Management?

This is a question that I have yet to properly answer to my parents. But I’ll give it another shot.

The “Product” in this case is software. And the “Management” part is the act of bringing as-yet non-existent software to life, or the maintenance and improvement of existing software. “software” is what we now call “apps”.

The role of a Product Manager is like a go-between, sitting in the middle and communicating between the people who want something and the people who actually build it.

The people who build the software are the designers and engineers.

In my case, we don’t build software for customers who then take it with them. We are an internal team building software for Sony Music. That software, for the most part, is used by Sony Music’s customers who are Musician and Music companies.

The people driving the “what” are called stakeholders, and they are mostly made up for internal non-tech folks like business executives or other employees of Sony Music who are familiar with the needs of the musicians and music companies.

My thoughts on Product Management

Ok, with the level setting out of the way, here comes the potentially controversial stuff.

A Product team at Sony Music is made up of three parts, Product Managers, Engineers, and Designers.

We approach these three parts as equals. Product Managers don’t manage designers or engineers, each group reports up into their own managers, directors, and VPs. This, in my opinion is good, but not perfect.

I carry a few key beliefs in general related to decision making

  • Good decisions cannot be made by group consensus. It’s important to have the right people in the room to provide information, but at the end of the day there has to be a single tie-breaker. Someone who can make the call and, to be fair, carry the responsibility for that call.
  • Someone needs to be accountable. People cannot be accountable, if they do not have the authority to affect change. If someone has not power, it is not fair for them to be blamed or rewarded for their actions.
  • If someone feels they will be blamed for something they cannot truly control, they will try to share the responsibility. This results in them involving more people. “I’m not sure, we should get person X’s opinion”.
  • This leads to too many people being involved and therefore leads to decisions being made by group consensus.
  • Decisions made by group consensus aren’t bad, but they will never be great, and they likely will also never be terrible. They will always be compromised because they are an average of needs of a variety of thoughts. They are safe decisions.
  • Decisions cannot rely on perfect information. There will never be perfect information, so decisions need to be able to be made based on imperfect information.
  • If the decision maker is not empowered to make a decision based on imperfect information, no decision will ever be made, or they will fall back to involving other people in the hopes the decision is made for them, or in the flawed goal of getting perfect information.
  • In order to make a decision based on imperfect information, the decision maker needs to set parameters for themselves about the decision. Usually this is a balance between time and information. How much information do they feel comfortable having vs how much time do they have to make the decision.

How this relates to Product Management

  • All three parties, Product, Design, & Engineering, play highly important roles in the product creation process.
  • I don’t believe that all three parties should be 100% equal. they should be 99% equal. There needs to be someone who is responsible and empowered to make a decision.
  • Decisions don’t need to be harsh or rash, a decision can also be “all three options look good, I’m comfortable with you picking the one you think is best”
  • Decisions cannot rely on complete information. Time allocated to collecting the information required to make a good decision needs to be the scoped and capped. Information can change and software can be updated as more information becomes available.
  • Teams need to be empowered and encouraged to make the best decision possible based on the information available at Time X.

Steering & Stakeholders

  • Steering groups are usually higher level people within the business that “steer” the North Star of the product.
  • Stakeholder groups are the other folks involved in the roughly week to week more granular details of the product.
  • This kind of structure only seems necessary in large corporations. They are the big ship. Changing course is a slow process with a risk of over- or under-steer. But once that ship sets sail, there is no stopping it, momentum keeps it moving. You have to do all you can to keep it on course.
  • In smaller companies there is direction, not steered. Clear, specific, and swift feedback loops from a tiny number of people who make the call. But here, it’s all or nothing. You move fast, to change fast, you fail fast, you start over fast.