The Mistake I Made as Product Manager
I wanted to capture some of the things I’ve learned, mostly for my own memory. But if others find them useful, that’s great! Though I never planned to become a Product Manager (PM), I now couldn’t imagine having any other role within; I feel like I was born to do this, lol. Honestly speaking, I was very nervous to start my job as an Associate Product Manager. Everything about this transformation (from Marketing student to Product Management) seemed foreign, jarring, and even a little bit lonely to me.
After two years of working in Product Management across a fin-tech and e-learning company, I still often struggle to define the role of Product Manager succinctly. Two years in, and it feels like the only thing I’ve learned is that there is so much more to learn.
Mas Hendra (My previous CEO) ever told me that.
Product Management isn’t an academic subject; because that major didn’t exist, and most PM is learned by apprenticeship.
That is why he gives me some e-books to read and ask me to present what I understand from that, I remember how nervous that moment is, but yeah I did it.
Day by day, I joined some product talk sessions, meet-up with #producttank #productpeople, product conference, and read some medium articles. I come to understand why there is no one (standard) definition for a Product Manager and why different companies are likely to have variants of the role. This is because Product Managers go by many titles, (including product owner and program manager, product lead, etc.). Even though there are many different roles and titles, each position will require you to bridge between the business teams and the developers.
However, it’s so much more than that. It is figuring out what is important for the product as a whole. It is prioritizing tasks because development resources are limited. It is understanding what the most urgent needs of the business team are and ensuring they are met. It is knowing that the technical challenges faced by the development team.
I do remember that Mas Aldith (My previous PM) said that.
You either get better at the things you should be doing, or you learn to stop doing the things you shouldn’t be doing. You can be PM who can control or the PM who gets controlled.
I write that word on my phone cause till today, that’s still the best advice I ever get. And ya, of course, I make many mistakes but here six things what I’ve learned and I need to improve on, based on team expectations, feedback and also my reflections
1. Write detail product spec
They said, “Great PMs write well; they are succinct, structured, thorough, and persuasive”. When I leaped into this role, the first thing I learned is writing product spec. I put my best effort into it, my 1st product spec was done within a week. I used to write long-winded product spec and story but I forget that the idea of writing a spec is has changed. The product spec is not a final call, not final documentation.
So, I try to have detailed specs but keep changing every other day. At first, seem like I’m good on it cause I keep the spec up-to-date till one day I stopped the practice of writing a spec altogether when I realized most people don’t even read the doc and I had to explain all features in person.
I update the product spec every single day but still explain all features in person, am I really good at writing?
I have come to understand the importance of a well-written spec. Our product spec should have the clarity, why we are building the feature in the first place. What unique problem we are solving and how we planning to measure the success of it. This means that the “Why, What and How” is a must things, day by day I also include the flowcharts on my product spec. I think everyone (my team) getting more understand by reading the flowcharts instead of reading the detailed product spec.
I still use this way till I find the new one to make this one better.
2. Engineers are creative problem-solvers too
I was so wrong when I do not involve my tech team early in the process and do a proper tech feasibility analysis.
The mistake I made was trying to craft a very clear idea of what and how we should build something before presenting the idea to the team. I thought I must come up with at least a high-level solution for a problem before “handing it off” to an engineer to figure out the technical details.
I learn that everyone owns the product not only the product people itself. Everyone in the company owns the product, and its success or failure lies in the hands of everyone who touches it. A product manager’s job is to lead the team to tackle the product challenges together
Even though there will be times when I’m the only one in the room who doesn’t know what’s going on with the huge number of acronyms and unfamiliar terms thrown around in every conversation, it’s easy to get into the feeling that “hi… I’m lost”. The funny thing I learned is that it’s ok to feel like that cause the important thing is how you react to this: should ask questions because that’s what product managers do. Ask questions because I’m curious and because I want to learn.
Dev team will talk about technical infra and other technical things and I must be there to make sure that we (as a team) still focus on the problem cause solutions can come in many ways.
3. Estimate developer task -not using story point very well
I will ask the developer team which task they will work during 1 sprint after the product manager explains the spec. My question is “How long does it take to finish this sprint, estimate the time” It could be 2 weeks, 3 weeks, or even 4 weeks.
But some tasks are difficult to estimate precisely. If one developer estimates a project but another completes the task, the estimate becomes invalid. The time needed to complete a task will vary based on a developer’s level of experience. Senior and junior developers need different amounts of time to complete the same task.
Story Points will eliminate this problem because they are a universal measurement across the whole team. The estimate doesn’t depend on who’s implementing the story. All team members, with different skill levels, can discuss it together and come to a single conclusion.
For more story point, please read this
4. Be data-driven
Data is a key part of the decision-making frameworks and that is the one of PM role. I was so wrong when I started to create the spec without understanding the data, how do I define the status quo? Of course, I use my assumptions when I have limited information. I have to learn that my assumptions will never represent what is happening. Decisions made based on an assumption without proper discovery and validation will not likely point the product team in the right direction.
I will Immerse myself in data analytics. Know SQL and dashboards. Make correlations between what you are seeing in the data and what is needed in the business. Go beyond the art of having an opinion of how things should be. I like the William Edwards Deming quote, “In God we Trust, all others bring data” I like that quote because it reminds us to be data-driven.
5. Focus on a solution over the problem
Our customers want us to solve their problems as soon as possible. Daily, they are much better at describing their problems than they are at envisioning the best solutions for their problems. That’s where PM comes in. The best product strategy focuses on the problem, not the solution. By focusing on the problem you’re trying to solve, you get much closer to the customer's true needs and can bring a wealth of information back to the team to design a solution with.
A large part of my job is to ask questions, challenge ideas, and push changes based on evidence gathered from those questions and repeat.
6. I’m not the mini CEO
“A lot of people say the product manager is like the CEO or the captain of the ship. I don’t think of it that way because when you describe things like that it makes it seem as though you’re making all the decisions, or you’re driving how everything works together, and you’re not” adds Mina Radhakrishnan, the first Head of Product at Uber.
I’m trying to hide the fact that half the time I’m totally confused and in a completely new situation, in a field that I have not experienced before. How can I become the mini CEO?
Luckily, I have tons of smart people around to help me figure that out. That’s why I do believe that Product management is a team sport, and the best teams don’t have bosses -they have coaches who ensure all the skills and experiences needed are present on the team
I need to get more comfortable with saying “I don’t know”. I need to feel freer to stumble, trip, and fail. To be more open to critique, to think of it more as iteration, instead of something was done wrong. If I still think that I’m the captain and the boss, the things above will not be able to happen.
