Jason Shah — Product Manager at Yammer
Ryan Hoover — Director of Product at PlayHaven
Blake Barnes — Product Manager at Facebook
Nathan Bashaw — Moderator — Product Manager at General Assembly
Q: What do you do on a day-to-day basis?
- Figure out what to build this but also thinking how it fits in to what we want to build in 5 years
- Work with engineering and the design team
- Constantly measuring success — Very data driven
- Work on broad vision for the product
- Meet and talk to customers
- Collaborate with everyone on the team (engineers, designers, etc.)
Blake: (Explained as an analogy)
- It’s as if you are running a small company within the company. You are the one leading the product.
- You have to define the mountain your team is going to climb. You must help your team to get up the mountain, celebrate your victory and then choose another mountain for your team to climb.
Q: What is your favorite aspect of being a Product Manager?
Jason: Thinking about what people are trying to do and understanding the “micro-interactions” users have that affect the product. He obsesses in thinking about very miniscule things in general and is very aware of his surroundings so he enjoys seeing the small interactions people have
Ryan: Talking to customers
Blake: Launch day — Everything your team has been working on is done and at Facebook, you have the pleasure to see your panel with the user chart as a legitimate hockey stick of almost a billion users
Q: How much technical knowledge is necessary?
Jason: Need to make sure you at least understand technical concepts
Ryan: Varies on the company + product
— Earlier at PlayHaven — did not have to be as technical
— Later — very necessary to clearly communicate with everyone
— a few benefits if non-technical — ask naive questions + make engineers rethink some problems. However, these do not outweigh the benefits of being technical
Blake: Pros outweigh the cons in being technical
— The more you know, the more you are able to leverage your knowledge
— Being technical brings you street cred to your team. It is very important to make sure your team trusts you
— Being non-technical should not prevent you from getting shit done but have to make sure you at least understand for example the interactions between client + server
Q: What is the difference between working at a small vs. big startup?
Jason: Small — more hands on
— Big — needs to talk to people out of your group
— learn from people who did it before
Ryan: The best PM’s have a high emotional intelligence and know how to relate to people
— Small — much more diverse role. You need to reinvent and evolve every 20 people that are hired as you scale
— Now — more process and project management is needed as a team scales. Something PM’s are responsible/help out with until we hire someone dedicated to this role.
Blake: a lot more design work as a PM at a small startup
— at FB, much more removed from the actual product
— It is like inception to convince your team to do something without them feeling as if they are being told what to do
Q: How do you deal with technical debt?
Jason + Ryan: Tech debt is often a byproduct of moving fast and making conscious decisions that you know you’ll pay for later. Sometimes it accumulates and later invest in paying back tech debt when it becomes a problem.
Blake: Hire people to focus primarily on this — some people are obsessed in dealing with these issues
Q: What 3 tasks do you spend the most time doing in %?
Jason: Not specific percentages
— Staying current on everything around him + how they are building their product
— Spec’ing things out
— Focusing on data
Ryan: 50% — work with enginering + design teams as well as project management of filling in the holes
— 10% — talking to customers. Trying to do this more though
— 40% — miscellaneous — everything else — data, internal stuff, competitors
Blake: More than 3 things to mention
— 20% — design team work
— 20% — cross-functional work with other teams
— 20% — Tracking the pulse of what everyone is working on
— 10% — breaking up work (project management)
— 10% — figuring out next thing to be built
— 10% — runs the bootcamp program for PM’s at FB
— 10% — Worrying — this leads to everything else
Q: How do you set goals for a product?
Jason: Solving a problem — Always trying to up MAU’s
Ryan: Long-term vision
— Goals for each quarter and making sure they are very clear throughout the company
— Focusing on engagement
Blake: Big strategic plays — more vision oriented
— Shorter term is very metric driven
— Speed matters — if a user can get the same action done in less time, it is a big upgrade
Q: What mattered to get where you are today?
Jason: Demonstrate ability to get shit done. You have to do anything it takes to succeed
Ryan: Learned under VP of product at a gaming company. Fell into the position under a mentor
— Being proactive and regularly contributing ideas and helping my boss as well as always be asking to help
Blake: Craigslist — Got first PM role through it
— Lucky to be on a team that needed help with specs and mockups and he took the role into his own hands
— Didn’t wait for anyone to tell him what to do. Just went for it
Q: Does data trump anecdotes?
Everyone: True — People get upset at decisions made by the company but data shows you what people are actually doing
Q: How do you use data?
Jason: Focus on 4 factors — retention, engagement, virality, revenue
Ryan: Focus on how much the use features — Breadth + depth
Blake: FB has literally tons of internal features. Privilidged to be at a company that has teams thats only job is to work on internal data
Q: What is most unexpected as a PM?
Jason :Analytics — Cannot mention enough how much statistics matter
Ryan :Always needing to evolve. Everything is constantly changing
Blake :Recruiting helps build product vision. At Facebook, each team must try to recruit the candidates to choose to work with them. By continuously recruiting for his team, he is always refining the product vision.
Q: How is your success measured?
Jason: Based on what people around you think
Ryan + Blake: Some PM’s have more qualitative metrics but its hard to measure
Q: Where do you want to end up?
Jason: Go around the world and do develepment projects as well as start another company
Ryan: Ambitions to start own company or join another early stage startup. Longer term, I can see myself doing more advising/investing.
Blake: Not sure where he would like to end up
Q+A from the audience
Q: How do you prioritize what to build next?
Jason: Need to weigh against engineering costs — short vs. long term
Ryan: Based on quarterly goals
— Sometimes have requests from biggest clients — need to be very careful to make sure their requests align with the product vision
— Always looking at numbers
Q: As a PM, would you rather be a jack of all trades or a master of one?
Blake: You want to be a jack of all trades. As a PM, you should never be better at any given task than anyone is on your team. Everyone on your team should be specialized in what they do.
Q: How do you decide what to do with now vs. later?
Ryan: Really likes what Medium does by organizing “Jank N Drank” on Tuesday nights on which they completely focus on fixing bugs and usability issues
Q: What are some red flags when you are looking at a feature?
Blake: Always be checking in on how things are progressing
Jason: Sad faces mean a lot. Being able to gauge emotions of your team and be connected to them will help you understand situations much better
Q: What % of projects do you kill?
Jason: 30% gets killed — dont get blinded if something is not the right product
Ryan: Need to be sure the team understands why something is killed and that’s it’s often a necessary part of building a great product
— if A/B tests fail, don’t think it is a failure. A majority of tests do fail
Q: Where do you draw inspiration for the next feature?
Blake: varies by company size
— empathize with your customers
Jason: Be observant of your surroundings — watching people to see what they’re annoyed with always gives the best insights. Pay attention to inneficiencies
Everyone: Seeing how people piece together hacks on your product and then providing that action in an easier manner.