5 product lessons I wish I knew sooner — The Product Constitution

You ready for the product?

I recently graduated in Economics with a minor in Data Science — important to mention that I studied Computer Sciences for the first two years of my university. As I grew closer to my senior year, an instructor recommended me for an opportunity that would change my career path for good. That’s when I discovered a career pathway to “Product”.

This article will highlight 5 critical lessons I wish I knew sooner that I eventually learned with time.

I was fortunate to land a Product-role in one of the unicorns of Pakistan. This unicorn owned almost 11 local and international brands and fate held me captive among the people who were responsible for handling, operating, and decision-making for two of them.

Handling a unicorn’s product can be fast-paced, and dynamic and you’re always experimenting with ideas and the industry’s best practices — keeping this for another day, let’s hop into the 5 critical lessons in the product I learned over time.

1. Stay focused on the Problem Statement
   As a person of product, your decisions will affect everyone involved. Hence, there will be a lot of communication with the stakeholders that can put you off-track. It is important to identify the “Problem Statement” from the chatter and remain focused on it. Remember, there is no one way of solving a problem. Do your homework to find the best solution.
   
   

2. What is the Frequency of the Problem
   In case you are in direct contact with the Sales team, please note there’s a lot that is going to be thrown at you. Many feature requests would not make sense even however it will be your responsibility as a Product Manager to at least pay heed to them.
   You can ask this question in two cases to identify whether it is worth messing with your roadmap.
   
   - Case 1: You are requested to develop a new feature. No matter how shiny it may seem, all that glitters is not gold. “How many users will this feature impact?” can be your go-to question in this case.
   
   - Case 2: A module update request is made in the current feature. “Does the current feature offer hindrance in any form for the end-user or the business?”
   
   

3. Organized Workflow
   As a Product person, it is important that you remain organized from day 1. From the files on your computer’s desktop to the items on your desk, keep them organized.
   It is crucial to keep your mind clear of the unnecessary clutter that may cause you to digress.
   Keep a note of all the problems that may arise on your product as “live issues”, a separate note for all the ideas from brainstorming sessions for new features, and all the unsolicited advice from people around.
   
   

4. Transparency on timelines
   Don’t be over-ambitious and give a few hours of resolution time. Nor be too cautious to scare them with looooong resolution times. Keep in mind that the problem occurred in the app you are responsible for. Therefore, taking responsibility and being transparent on timelines is what you can offer best.

   
   Understand the issue well; Talk to developers; communicate, communicate, and communicate a lot. Write a problem-solution document if needed. Seek ETA for the problem resolution from developers and give cushion to the affected stakeholder accordingly.
   
   

5. Well curated replies
   If you receive a follow-up email to a request that was previously made, don’t just write “Noted” or (even worse) choose automatic replies. Explain what is causing the delay. Remain transparent. Inculcate a healthy response that showcases your steadfastness to resolve the issue.
   The very stakeholders sending you these emails are gripped under the higher-ups who await your response too. You definitely don’t want to get yourself in hot waters just because you failed to respond clearly.

Have any feedback? Let me know in the comments below.
Follow my growth account on Instagram @dsandwichguy