Product School Takeaways by Product Management Alum Sophie Guo
Product School alum Sophie Yaqi Guo, Machine Learning Engineer at BrightCrowd, took part in one of our Product Management courses in Silicon Valley this summer.
As she lists her main insights from Product School, learn what Sophie gained from the classes and what to expect as a PS student. Check out her key takeaways!
Sophie Guo’s Bio
Sophie has worked in the tech sphere since graduating from Duke University. She was a Consultant for Motion Math, and then Machine Learning Intern for FoxType. At the moment, she’s a Machine Learning Engineer at BrightCrowd. She’s hoping to break into Product Management after obtaining her Product Management Certification at Product School, where she validated and curated a book list feature for Goodreads.
First impressions after finishing Product School’s Product Management Course
I finished Product School today! The past 8 weeks have not been easy: 5 hours every Saturday plus readings and preparation for the final project along the way.
It was a lot of time and effort that I put into the class, but I enjoyed every part of it and would recommend it to anyone who wants to learn more about product management or just want to brush up on their product and business thinking.
Product Management course content and practical exercises
There are a lot of great contents we went through, from finding and validating product opportunities, to working with design and engineering teams, to building a business case and aligning team members through PRDs (product requirement documents), to prioritizing and evaluating features with different metrics.
On Product School’s Product Management Instructor
Hearing him explain the framework he used for approaching certain situations and problems along with concrete examples from his daily job is immensely helpful and is something I would not be able to learn elsewhere.
Product Management frameworks I learnt during the course
Here I want to share some great takeaways I have from the course, mostly from Patrick’s answers to some of the questions I asked in class as well as his feedback to my final presentation. Although the details may not be relevant to everyone, I believe the framework and principles can be beneficial to people building a team, building a business or working with cross-functional teams.
Planning ahead to motivate teams and react fast to product test results
The one piece of advice from Patrick that touched me a lot is to think and plan a few steps ahead when designing a feature.
It is awesome that companies run small, quick tests to validate hypotheses. It would be more awesome if they spend more time walking through the different scenarios and thinking about how the different test results would inform the product direction.
The benefits are twofold (or more):
- The team would be more aligned and motivated given that there is a clearer vision of where the product is going.
- On the business side, the company would not need to spend time thinking about how to react when test results do come in — they can instead act fast, which in turns saves time and speeds up the whole validation process.
Turn competing metrics into a math problem
In the first class, I asked the question of how to handle competing KPIs/metrics. Patrick’s response, in a nutshell, is to turn it into a math problem. And this was something he kept emphasizing throughout the entire course– tie a problem/feature to numbers.
For example, if an opportunity is proposed, it is helpful to ask ‘how does that affect our users?’, ‘what percentage of the users are being affected?’, ‘how does that in turn affect the business (revenues, growth, etc)?’.
Often times, great ideas come from team members’ personal experience with a product, but it is risky to take actions purely on the ground that someone thinks it is (or is not) a great idea.
There are times when it can be a guess game to pin a number on a problem, but the mere fact that we do not have complete information on the situation illustrates the importance of learning through experiments — setting a prior belief and updating the belief based on experiment results (excuse my Bayesian statistics language, just couldn’t help it).
Taking time to know your team as a Product Manager
Product management is a very soft role and involves working with teams of different functionalities. Patrick is a big supporter of taking time to know your team and meeting them where they are at instead of taking a one-size-fits-all approach in dealing with people.
In fact, conflict is an inevitable part of any type of human relationship, and when it occurs and neither side is convinced, the best course of action is to disagree and commit. What matters is that at the end of the day, the team is learning, making progress and getting better.
This post was originally published on Sophie’s Medium profile, and has been reposted here with her permission.