Learning to be a Product Manager | Day 6

Today I arrived at office at 10:30, which is normally my starting time for a day, and then started deciding what to do. A senior PM asked me to help her with data requirement document and event tracking setting, so this became the very first task to do. For a fast-paced and thriving internet startup like my current company, data collecting and analysis are as important as product design. As the person who knows the product goal and direction the best, we product managers have to write data requirement document and set event tracking details ourselves, so they can be shipped to engineers for implementation. Usually we’ll ask data analyzer for help, in order to make sure we get the right results. Sometimes a desired data could be missing just because we forget to include the needed event or parameter, so we need to be careful with it.

Then I had a meeting with engineers, discussing matters related to data uploading, where things get a little bit tricky for me to understand and make decisions. I’m not a technical guy and I get afraid of dealing with technical problems, but it’s a necessary part of my job because it affects user experience. So I need to figure out the outcome of each implementation approach and make a best decision under the given circumstance. It’s not easy for a green hand like me, because I lack enough experience and sometimes simply cannot see the whole picture. The solution to today’s problem goes to a little redesign of our UI, which allows users to retry uploading data when it fails for the first time. Not perfect, but perhaps the best I could think of at this stage.

Today I also had a little argument about the product feature with our content team. The problem is that they insisted on a feature we agreed to give up in this version. The current product logic and visual design cannot support the feature, if we redesign it, it would cause delay of this project, which is not allowed. I persuaded their leader in detailed reasons listed clearly and explained the interest from several angles, and finally she gave it up. This accident taught me once again the importance of staying on the same page, and remember to send meeting notes to synchronize the conclusions we make. It would be a disaster if we don’t have any written notes to help review our decisions and claim responsibility when arguments happen afterwards.


Lesson Learned

  1. Take simple and common implementation rules into consideration when designing the product in the first place. If not, sooner or later, you’re gonna have to pay the debt in a more miserable way 😂
  2. Take notes, especially conclusions that are agreed upon every time you have a meeting with others, and send them in email to everyone attended. If not, sooner or later, you’re gonna have to pay the debt in a more miserable way 😂

Making product in 100 words:

“Prioritize. Have strong opinions, weakly held. Plug the gaps. Launch and iterate. Know the user. People > products. Create team culture. Always over communicate. Work with people whose strengths and weaknesses complement your own. Take good notes. Your calendar is sacred. There is no such thing as an easy launch; launching good enough > never launching. Have fun, detach, do not burn out. Always have a 20% project. Follow passions and connect the dots later. Always have a cofounder. Begging forgiveness > asking permission. Embrace the struggle. Take big risks; your failures won’t matter in two years and your successes could change the world.”

I’ll keep writing this journal every day I work. No excuses no matter what. I believe in writing and thinking. Let’s see what happens! Here’s to perseverance 🍻