This week, Product School hosted Sandhya Ganesh, Sr. Product Manager at Tinder, for a special #AskMeAnything session. Sandhya tells us about her experience switching from Amazon to Tinder, how she involves Engineering in the discovery process, and what to do when gut feeling conflicts with data.
Sandy Ganesh is a Senior Product Manager at Tinder, specializing in engagement and retention growth. She has been praised by colleagues for her creativity and insightful ideas. She is data-driven and makes sure to keep her customers’ wants and needs in mind in every step of her work. Before her current role, Sandy spent just over a year at Amazon as a Senior PM building software products for their Workplace Health and Safety Pillar. During her time there she led the growth strategy for a survey product which gave her team data to effectively drive product and program strategy in order to improve the well-being of the team.
Being an international student interested in Product, what would be the best way to enter into PM roles, because applying to these PM roles have a demand for more than 2-3 years of experience?
It comes down to 3 things based on my experience:
- Upskill and grow your PM skills
- How you convey the story about your skills and experience (this can be a college project, a personal project as well if you are fresh out of school). The story needs to show your thinking, your drive to take an initiative and learn and the impact you have created. These are the skills you need as a PM as well.
- Network. By network I mean identifying the people who can help you understand the interview process of the companies you are interested in and networking with people who can be your potential mentors. And last networking with Hiring Managers by sending them a thoughtful note on LinkedIn on who you are and why you would be a fit for the role on their team.
PS: Don’t take the years of experience as a hard rule.
As you are very data-driven, in a case where your instincts/gut feeling are pointing in a direction different from the data, which do you choose?
When we look at data I always like to look at multiple data sources instead of just one i.e. data from user research which can be in the form of user interviews, surveys, observing a focus group, data from analytics, data from our customer support/member experience.
Typically the key insights and problem will find itself in multiple data sources and once we see a pattern emerge I like to pursue the ones that are recurring most number of times and that’s the biggest issue for most of our users.On the other hand, there are always instances when we don’t have the data we need. In this case, I like to use learnings from past experiments and my instincts based on experience working in that industry and understanding the user groups to form a hypothesis and do a quick and scrappy test to validate.
Can you tell us about your experience of leaving Amazon and looking for a new role? Can you describe the experience of applying and interviewing with Tinder? Why did you end up going with them?
This was an opportunity that came to me (I got reached out to by a recruiter) and I decided to learn more about the role and have a conversation. In terms of the interview experience it was pretty similar to the FAANG – i.e. interview with the HM and then a virtual onsite with different Product Team members and cross functional partners. This role presented a good challenge and opportunity for career growth and hence I decided to take it up.
How do you involve engineering teams early in the process without diverging focus? How do you integrate (continuous) discovery with a team that is focused on the current bet/experiment?
I typically like to work on identifying the problem/opportunity areas and brainstorming a couple of solutions first. I then like to run it by my engineering manager(s) as an idea in a 1:1 and see what they think. Most of the times they provide very valuable feedback that I like to think about and incorporate.For continuous discovery, first step is to create a culture and forum to discuss new ideas from PMs, engineers or anyone. Typically I like to do a Jam session once a month with the team including eng., design and analytics.
So you don’t include engineering at all in the discovery phase and then brainstorm potential bets (I suppose with the designer) before running these by the EM?
Not really. I would consider the ideation as discovery. What I have learned after trying several methods is that going in with an idea for engineering to react and respond to works better than going with a blank slate and saying let’s brainstorm. That doesn’t mean my idea is final it’s just a method that has helped me have a more meaningful brainstorm with my engineering counter part. I do the same exercise with my design and analytics partner.
Check out: Product Discovery 101 for Product Managers
This jam session is about sharing findings with the whole team? Basically a summary of all your learnings that you could synthesize from tracking/feedback/tickets & interviews over the past month?
Same with the Jam session. Going with a potential solution based on synthesizing past experiment/research data rather than a blank state helps with more productive conversation. We have come out with totally different solutions than what we started with before in many instances.
And in terms of discovery – do you aim to have a flow of continuous interviews (which can be focused on specific problems, but also to continuously build insights on your domain) e.g. 1-2 interviews per week – or do you interview only when diving into specific discoveries?
Mostly latter. But we share and leverage the insights received from research/ focus group studies requested by other PMs.