Thinking About Explanations as a Product Manager — Book review: Product Management in Practice 2nd Edition

Introduction

I am Kamei from Woven Payment Solution Development G. My team's job is basically to develop a payment system for Woven City. I was transferred to Woven by Toyota, another company in the Toyota Group, and usually work there. Woven by Toyota has several businesses, one of which is the development of Woven City.

In this article, I will also follow up on the promise I made to write a book review when I entered the drawing for the product manager release gift.
https://www.attractor.co.jp/news/product-management-in-practice/

How I Became a PdM

Actually, I am not a Product Manager (PdM). Even now I am not officially one. I just self-proclaimed myself as a PdM. I was originally a software engineer and worked mainly on backend. I was also a utility player and wrote frontend code when asked. I also have experience with code payment systems, which led me to my current job. After that, I also worked as an engineering manager (EM), so I can work in areas like evaluation, organization, and recruitment.

However, when I was moved to this project, I was told that I was supposed to be sort of like a PdM, but with more technical knowledge. In retrospect, I should have asked more specifically what I was supposed to do, but probably nobody really knew. While not really understanding my role, I picked out technologies, built the first prototype, recruited more members, and worked in a hybrid role between a lead engineer and an Engineering Manager. I got a lot of questions from other teams and spent a lot of time preparing materials and giving explanations at in-person meetings (called menchaku meetings in Toyota terminology). Even so, I kept doing operational work like the rest of the staff, but as the team size grew, I started being the bottleneck for task completion. Therefore, I talked with the team, explained the payment functions that I think we needed implementation given my knowledge, and we decided that it would be more productive if I assign rather than take care of tasks myself, splitting the roles amongst us. I think from that point onwards is when I was able to start considering myself as a PdM. That was about a year ago. As for the decision to stop operational work, I made a similar decision back when I was an Engineering Manager, so I didn’t have any complaints about it. Probably the day will come where I'll need to work on operational tasks again; but not for now.

How I Got Interested in This Book

It's good that I realized that I was a PdM, but I still wasn't sure what exactly a PdM does. There were times when I did whatever job I had in front of me, but no one explained what were the results of what I did. I read a lot of articles and books about product managers, but they didn’t really resonate with me, and I was left feeling unsatisfied. I didn't read the first edition of this book, so you could say I didn't look hard enough.

Then I read some comments on this book. They were all very positive, and its subtitle "A Practical, Tactical Guide for Your First Day and Every Day After" resonated with me, but they didn’t really make me want to buy it right away. This is an excuse, but I was skeptical because the comments I saw were all from actual product managers, and I wondered if the book could be understood by people who couldn't relate. Then I found out about the gift project. I was so curious, that I just had to enter.

The Book Review

First of all, this book is really good. It is useful for people who just became a PdM like me or wants to become a PdM, as well as organizations that want to start introducing the role of a Product Manager. It can also help you find out if there's an unofficial PdM in your organization and help you start using product management in your development process. In that sense, you could say that you can use this book from day 0.

What is Product Management

It's great that this book acknowledges that the role of PdM varies from organization to organization, and that the roles required of a PdM are just as diverse as organizations in the world or the problems they face. However, if that is the case, the role of PdM does not exist. This book rejects clear definitions of PdM and product management. Instead, it tries to outline it with explanations. An example of a good explanation is "Manager of the value exchange between the business and the customer" from another book, "Product Management: Avoiding Build Traps and Giving Value to Customers". PdMs and organizations that need a PdM must make explanations for the organization based on this and other explanations.

This isn't written in the book, but I think whether the explanations match each other’s concept of one is what’s important when recruiting or assigning a PdM. Of course, this is also true for other positions. However, the PdM role is more abstract than others, and I think explanations are also more important. No matter what background a PdM has, they won't be successful in the organization if there are mismatches in the explanations.

CORE Skills

The author presents these four skills as required for the abstract role of a PdM.

• Communicate
• Organize
• Research
• Execute

Using the first letter of these four skills, we call these the CORE skills. Most of the book describes how to use them. However, that doesn't mean it has chapters named something like, "The Communication Chapter." This book consists of explanations of common development topics and how to use the CORE skills. The chapters focus on different themes, such as communication and organization building, while combining the CORE skills.

Was My Problem Solved?

Regardless of my job title, I feel that about half of what I do can be considered being a PdM. That alone made reading this book worth it. If you are thinking about adding another PdM to your team other than yourself, you may be able to better restructure your organization if you make a series of definitions on what you want them to do. You might want to try this. If you are determined to continue being a PdM or want to become one, you should make your own PdM explanations that incorporate the CORE skills. Personally, I'm still not ready to do that.

Conclusion

Once again, this book is a good guide for thinking about the role of a PdM. I think that whether you're a PdM or not, this book lets you think about how you should use a PdM or product management in your organization and how to make definitions.

I would like to thank the author, Matt LeMay, the translator, O'Reilly, and also Attractor Inc. for giving me this book as a gift.