Product Management at Spotify with Former VP of Product

If you want to understand product management at Spotify, the best way to learn is to ask questions. Ask as often as possible. That’s why we’ve started weekly AMA sessions in our Slack Community for aspiring product managers or current PMs who are curious about the processes of others.

This past week we had the chance to ask any question imaginable about product management to one of the most influential PMs in the industry, Shiva Rajaraman, a product guru who has worked as:

– Chief Technology Officer at WeWork

– VP of Product at Spotify

– Director of Product Management at Google

– Senior Product Manager at Twitter

– Senior Product Manager at YouTube

Shiva is now works as the Chief Technology Officer at WeWork in San Francisco. With credentials like these, it’s a great opportunity to speak with him about all things product.

We chatted about everything from finding key metrics, and overcoming the biggest product launch challenges to the most sought after skills for a future product manager…

Product Management Skills & Qualifications:

1) Be technically/analytically competent in something.  That may be financial modeling or design; chemical engineering or CS. A lot of what we do in product management requires you to be adept in data analysis and especially interpretation of data so being weak there is a non-starter.

2) “Management” side – I prefer great storytellers and succinct communicators. For example, I and my peers often employ interviews that involve delivering a presentation to a group.  Those present in the room may critique the underlying assumptions or go in a bit deeper to get to your underlying rationale for a decision or how you framed the options. Accordingly, you need to be great at explaining things and keeping your cool while you answer smart (and often not so smart questions).  

Beyond that, it’s helpful to have end-to-end responsibility for a major project, company, volunteer gig, whatever where you were the accountable decision maker, and you were also the most passionate stakeholder.  That doesn’t have to be in a professional capacity, but it’s helpful to have experience, where you had to run the show.

Generally for new PMs here are some tips:  

1) Understand a clear story about “what success looks like” for your entire company

2) Start to understand how you would measure that and how your product or area impacts that directly

3) Focus on having the most impact against that top level goal – don’t get too caught up in tons of details – be the person that steps back and says are we on the right path or not?

4) be objective and own it – if your team or your tactics aren’t having an impact be the voice of reason that you should revisit your hypothesis or try a new approach.

The analogy for me is a building architect vs. someone who handles construction. You want to have a good sense as a PM what the limits are.  Sometimes it’s physics or the speed of light.  Sometimes it’s just that there are design/engineering norms you should understand.  So what I ask is that PMs do a 1 day “understand the stack” as they get started on new efforts.  They should be technical enough to comprehend what that means w/o having to code.  The risk at times with being too technical is that you really become a tactical project manager vs. helping to set vision and progress against that vision – that is usually where people fall short.

On preparing for a career in product management:

Great habit is to look at what other people are launching and shipping and ask yourself, what do you think they thought they were doing and what would success look like them?  10K people using the feature to do what?  Have more engagement for a type of user? Attract a new type of user?  In other words, reverse engineer their goal and how they counter-position against the norm.  The world is a series of experiments going on at any time simultaneously. Start guessing what they are trying to test or achieve.

Project management gives you the attention to detail that is a potential foundation for Product Management but one of the best things you can do is to start understanding (or helping formulate) the “why behind the what” which is key for product awesomeness. In many cases, you can start to make that a part of the stories or briefs behind your projects and you as a project manager can remind teams to measure or talk about goals or progress against goals that were part of the “why”. That’s great practice to make the transition clean.

Insights from past work at Spotify

Overall, a lot of what we do in product during a growth phase is balancing differentiation (getting people into the funnel) with retention (engaging people in ways that make them come back). Differentiation at Spotify or YouTube was often about differentiated content experiences (unique creators only on YouTube, unique content such as the behind the lyrics Genius cards associated with top tracks, or unique use cases such as using Spotify to keep you on pace for a run with music that is synced to a specific beat). Engagement is often about personalization (Discover Weekly or Daily Mix on Spotify or taste-based recommendations on YouTube)

Tribes own missions at Spotify and must own clear customer/user journeys. Used this model at YouTube as well where you have a series of constituent-oriented groups  – Viewer, Creator, etc. that have multiple teams within them. The value of constituent-oriented groups is that you ensure you have a champion for a clear user types/journeys in addition to good organizations beneath them to ideate and execute on various goals. Over time you may not need “customer-oriented” organization structures as various teams stay focused on end-to-end tasks and appreciate multiple points of view as they mature.  However, often it’s helpful to do this when you have an imbalance in attention or perspective you need to correct.

Decision making & development processes:

Good recipe for product excellence overall:

1) Craft missions that everyone in the organization believes in and tie to company goals .

2) Don’t let everyone solve the same mission but ensure anyone who owns a mission can act in any way to make an impact – don’t silo them to a specific code base, platform, or feature/view set. Otherwise, they will try to solve the goal but only with resources at disposal, or only by exerting pixels they can control.

3) Organize agile teams around missions – they inherit goals but can focus on unique tactics. However, you don’t really want a bunch of teams coming up with a cacophony of goals.  Companies need to have priorities. Similarly, you don’t want a lot of top-down “here’s what you need to do” – that stifles innovation.

4) Finally, if you don’t have clear goals and each team invents their own goals you have a disaster so remember to spend time ensuring people understand the goals and if need be pin those goals up and over-emphasize them at all hands and in written or video communication.

Goes hand in hand. Think about YouTube – sometimes you have a set of features that are about rights management – that is what Content ID was in the early days.  Just protect copyright.  But you start to realize this is a much more interesting capability not just a set of rights tools.  You are scanning 150 years of video every day and matching it with massive sets of video that have been ingested before. That is a capability built on scalable, revolutionary technology.

A good lesson is to ask yourself, “when I am building this feature do I need or am I also building a great capability?”  and if the answer is yes, ask yourself what other features could you support.  If the investment in tech gives you option value to launch many more cool and impactful features core or complementary to your mission, you have a good idea you might want to invest in the tech and not just bolt on a feature.  Content ID at YouTube. AWS at Amazon. On-demand delivery of anything at Uber.

Challenges on the job:

Everything you thought you knew ahead of the launch is typically thrown out the day you launch 🙂 The key thing is to remember (I know I sound like a broken record) is what you were trying to accomplish. Now you have real data.  So you want to go deep and understand what happened in actuality given you had a hypothesis that led you to build something.

a) You launched something new – do you people like your proposition? Do they understand it?  Are you attracting the people you thought you were? Do they try it out?

b) Assuming you have a great group you’ve attracted, and they are now using the product, start understanding how they use it (you may be surprised overtime) and live and breathe the lowlights and highlights. # of Tweets is not a metric you want to stick with for too long as fun as it is watching that timeline post-launch. Specifically, understand what usage correlates with retention – e.g. what do people who stick around 30 days after launch do in your product? And/or understand what tasks does someone complete and what to they never touch?

c) Step back after a month or so and ask yourself, “did any of my assumptions leading to this product change?” for the better? for the worse?  anything new you should act on? anything obvious you need to tweak?  Learn what worked but also question your fundamentals – maybe you have learned something exceptional you need to act on for good or for bad.

Biggest challenge I faced being a PM was often being in situations where I didn’t have a lot of context.  I didn’t see the biggest picture and assumed someone had one but I didn’t ask.  The other challenge was finding some space to make my own bets. They didn’t have to be big ones, but I was happiest when I could also have my own canvas to try something out, however, minor and increasingly that grew in scope.  This challenge is often a tradeoff – you won’t be the source of all the great ideas your company should pursue.  However, finding some headspace and time to try new things is key to learning and feeling 100% utilized.

Best practices:

Remember you are trying to achieve a result.  Features are a way to get there and typically in our world getting that result does involve shipping something 🙂  It’s important to stay focused on that result, but great PMs can’t be too abstract. I love PMs who obsess about the details of flows, logic, content/community, etc. but I also want to make sure you at some point you ask yourself: hey? Is this working? Why not?  Do we need to tweak the feature or go back to the root of the decision tree and try again? If that means you should move on to new ideas, all good. Better to learn that fast.

Cat T-shirts!

Seriously, it’s important to have cultural bonds with people – hang out and get to know each other – don’t just meet for the first time when you are negotiating a roadmap.  At YouTube, we had the whole Creator Product, and Engineering team go make videos for example with the participation of xfn peers in content management/licensing/etc. We also had them interface directly with creators for a few days and understand their pain points.  I’m not the biggest believer in empathy for the sake of it.

However, understanding someone’s life around your product gives you great context.  At Spotify, the team that built a great product for runners brought treadmills into the office. Ultimately, the best incarnation of this is to think of your “team” as not just product, design, engineering but also marketing, content, and support (+more).  Define your teams from day 1 with this mentality, and you’ll bridge the org quickly.

On Roadmapping:

I like to look at goals at least 6 months to a year out. For product roadmaps and associated tactics to achieve those goals, I like to stay within 6 months. So put another way, maybe you want to hit $100M in revenue a year from now. You’d plan several efforts/bets over several cycles to get there, ideally all less than 6 months in duration to prove their efficacy (e.g. a roadmap). Truly hard things take more time so those are maybe exceptions, but for the most part you should have a healthy stack of things that let you launch and learn.  Also, I’ve received great advice from my mentors to focus first on the “biggest” things – e.g. don’t fill up your glass with little pebbles; fill it up with big rocks and then squeeze in the pebbles. In other words, look at next 6 months and think about your biggest efforts you need to try and then squeeze in around that if you can. Ultimately your job as a PM is to manage a portfolio of lower risk and higher risk efforts that affect your key goals as a company. Make sure you don’t fill that portfolio solely with obvious but low impact efforts.

On Metrics:

It’s not either/or and given there are a few questions on research let me try to summarize a few thoughts:

1) Direct feedback is often great for first impressions. It’s hard to understand, especially for new users, why those who leave or bounce quickly do so.  I believe this is the stage you just need to ask questions:  what is this app about? What does it let you do? Do you know how to do it? Show me?  You will lose a lot of users because they don’t get past screen 1 or day 1. You live or die by those first impressions.  Logs won’t tell you much – ask them what was their impression in lab studies, in-app surveys, and/or various other research methods that involve direct feedback.

2) Instrumented behavior is great in cases where you have usage and you want to correlate that w/ levels of engagement, degree of churn, etc.  Even if someone *tells* you they love the app you want to see if they actually use it and/or in many cases find out what usage correlates most with retention. This part is hard to do with in person or diary based user studies.  People aren’t always great at describing what they really do or what they will do. They tend to be very good at articulating whether they love/hate something (perceived value) and whether they understand something (cognition of what they can do) but what they actually do is often best done through direct instrumentation.

A few questions on metrics so I’ll group some answers here.

1) Ultimately a lot of apps or services are about engagement (time spent) and/or tasks completed (jobs done).  I would first understand your top level metric and make sure things add up to that.

2) WARNING!  Don’t just measure what is easy to measure. That is the biggest trap. Proxies are fine but only if they truly map to the higher level metric. For example, at YouTube “views” are not the same as “watch time”. You can game a bunch of clicks but it’s hard to keep people watching.  Remember to focus on the true measure of your service’s quality.  Similarly, page visits aren’t equivalent to things bought.  Maybe you only link to commerce activity but that doesn’t mean you can get away without measuring it – you need to find a real proxy.  It’s easy to get people to open up a screen. You can make it bigger, flashier, or just make it the easiest thing to click on everywhere. You have to measure the ROI of every pixel so spend time understanding what your goal function really is and how to instrument it and/or the best true proxy.

3) Once you have your high-level metric, break it down.  For example, engagement time is often about # of users (growth/marketing acquisition), # of visits per user (things you help them do or experience and levers to get them back), time spent per visit (better experiences and more things to do when your users come back).  Each of these components may be what you truly act on.  But always ensure these roll up cleanly to your top level goal so you can keep an eye on one metric cannibalizing another and/or you can ensure you understand how much impact that lever truly has.

4) Often this is very very obvious and should be obvious because these goals map to easily understood behavior. Sometimes, however, you realize it’s not. On some services, for example, engagement may not matter as you might pay for something and just keep paying even if you don’t use it.  However, you likely still need to work on things to get users to come back (differentiated experiences, content, access to data, etc) which ties to user acquisition.  In some cases, it is about engagement but it’s very crowded so you need to spend a lot of time with motifs, emails, or re-engagement marketing to get people into a ritual and until it’s cemented into their habits it’s all or nothing. Tactics vary tremendously by product and service even if the goals are simple.

Ultimately, your metrics should map to staple goals for your company. If they aren’t common sense linkages you may have an issue or you many have complicated things a bit too much with your cleverness 🙂

Final thoughts for breaking into product:

1) If right out the gate it’s tough to land immediately in a PM role, find a role where you can interact with product and offer unique insights that help product managers succeed and no matter what help craft hypotheses jointly with your product partners.

2) Find a domain you love and learn more about what’s going on there and live and breathe more than just product. Understand the underlying problems people are trying to solve and what assumptions are being destroyed.  Note: I generally believe that PMs are generalists and great ones can work in many domains. But to start off or bridge into a role, having a good grasp and passion for a vertical helps make you an essential complement and often is key to developing great products though you can’t be brainwashed into thinking established assumptions are immutable.

3) Get great with data. Be the one person someone can go to who can slice and dice like it ain’t no thang and also make wise, objective interpretations.  Work with your peers to ensure you get feedback on whether your interpretations are glib or meaningful. It’s not something that is automatic on day 1 – you need discipline and feedback. Critical thought is important.  Every Time you think you’ve found a defense for something or a key insight step back and then take yourself down.  Ask how you would disprove your theory and what data would do that.  Bulletproof yourself or get help.

4) Finally, care about design. Guard every pixel, care about the UX. You won’t be designing every pixel but you should feel confident with basic patterns and be a strong custodian. This doesn’t mean saying no to everything…but you should be the person who understands that every element has a price tag in terms of user complexity or option value to do something else.