Fresh Product Manager (1st 30 Days)
It has been an exciting first 30 days doing Product Management and no two days are the same here in my Product Management World. Prior to starting this role, I was doing Data Analytics and now I, together with my lead manage a B2B e-commerce platform in Indonesia, where our product serves as goods supplier to our Micro Small and Medium Enterprises (MSMEs).
Goods that we provide ranging from Grocery Items to Digital Items such as Electricity & Bill Payment Services, Internet, Post- and Pre-Paid Phone Billing. Our product has been in the market for about a year as I’m writing this. But for the context, from Marketing and Organization Maturity Stand Point the Brand of our Company has been in the market for about 8 years and its Parent Company has been around in Indonesia for a whopping 69 years, so we certainly have some advantages to support our Product. So below is some items I found that is useful for me and hopefully other aspiring Product Management Professionals.
1. Prioritize and Organize
I found it very important to prioritize all things that you do. I’ve also learned that prioritizing requires you to truly understand why you’re doing what you’re doing. So, Prioritizing takes some of your time in a sense that you need to understand the motive of building the features you plan to build, what and who is it for, and the impact the feature will create to the users and the product itself. As a “freshman”, I often ask multiple people from different stakeholders to get the answers to those questions. To understand the problem and its severity is the key to find and prioritize your solution.
2. Don’t just think about Journey, note it down
I often think I know the big picture of the feature I wish to deploy until I have to lay it down on the table. Documenting or noting down the picture on your mind is important to get the idea established and often you can find more details to add to your feature for your future phases.
3. Think alone, work together
This is one important advice that my manager gave me at the end of a new feature design task he assigned me, a task that I felt at that point required multi-team collaboration, in this case UIUX and Dev Team. So, without much thinking, I went straight ahead to have a meeting with the team, and without anticipation I had a meeting where everybody is chiming in on the solution and assuming the problem we’re all trying to solve. As you could probably expect, the meeting resulted in nothing but throwing individual’s assumptions on what the real business problem is and ironically none of us had talked with any of the business team, whose problem we aim to solve for.
So, it is very important to understand the problem yourself first, include the key stakeholder or the user and try to understand their problem. Once you understand the problem, then think to yourself how can you solve the problem, what feature or improvement should you build to solve this issue. Another thing that I feel important in the process of thinking alone is that before you present your solution to the development and design team, you already understand the end-to-end of the solution that you propose. Only then, you can influence and convince your team to build it genuinely, because they know that you just don’t pick this idea out of the sky, but you think through it and have strong reasons on your proposed solution. Think alone, work together.
4. Communicate, communicate and communicate
I can’t emphasize the importance to communicate always to the multiple facets of my team. The reason to do this is because building a product requires hands of multiple people from different departments and it’s important that you best communicate what it is that you picture in your head to them either through verbal or written documents. But, it does not stop there. As you can see in the sub-title of this paragraph, you need to communicate again and again. It reminds me of the communication game where someone gives you a picture and you have to tell the person behind you what you see, and so on the person behind you will tell the other person behind them. At the end, the last person will draw what they seem the original picture is and most of the time it’s a wrong picture that they draw. So, even when you feel that you have communicated well enough with your team and you feel that your team understand what you want, it’s always important to always communicate with them to update and verify their understanding periodically to make sure that we all are in the same page on the requirements.
