Spotify Running Lessons Lean Startup Big Tech
•Download as PPTX, PDF•
10 likes•2,811 views
The document summarizes Spotify's efforts to build a running experience on their platform. A team was formed with the hypothesis that a unique running experience would increase registrations and retention rates for runners compared to regular users. The team followed an agile process of building shared understanding, visualizing plans, creating hypotheses, ideating solutions, and validating ideas with customers. After 4 sprints of customer validation, an MVP was pitched and approved. The running experience launched in May 2015 and helped differentiate Spotify's offering from competitors like Apple Music. Lessons included failing fast, educating stakeholders, acknowledging bias, visualizing work, and accepting that product discovery is difficult.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
Similar to Spotify Running Lessons Lean Startup Big Tech
Similar to Spotify Running Lessons Lean Startup Big Tech (20)
Recently uploaded
Recently uploaded (20)
Spotify Running Lessons Lean Startup Big Tech
- 1. Spotify Running Lessons learned from building a 'Lean Startup' inside a big tech company A minimum viable presentation™ Brendan Marsh, Agile Coach / PO @ Spotify @brendanmarsh
- 2. About me :) ‣ Agile Coach, Infrastructure & Operations Coaching teams that build & maintain big data @ Spotify ‣ Agile Coach, Spotify Running Coaching a product discovery (Innovation) squad ‣ Product Owner, Desktop Infra (now) Our Desktop Infra team releases our desktop client on OSX / Windows ‣ Innovation Guild Owner (now) Coordinating our Innovation Guild and also working on a company-wide initiative around Innovation
- 3. The Opportunity ‣ Differentiation - Streaming music is becoming commoditised ‣ Data People are creating running playlists, music is important ‣ Market Opportunity ~ 30 million runners in the US ‣ Belief This could be awesome! ‣ We have the technology! —>
- 4. Core Hypothesis ‣ High level hypothesis “We believe that a unique running experience will result in an increase of registrations (from runners) with a higher 6 month retention rate than regular users” ‣ Brand hypothesis “We believe that a unique running experience will differentiate our product from our competitors”
- 5. A team is born (Team Pre) ‣ Product Owner ‣ Agile Coach (me!) ‣ UX / Designer ‣ User Researcher ‣ Mobile Developer ‣ Content Curator ‣ Marketing
- 6. “What should Spotify build around the running use case?” (If anything?)
- 9. Our guiding principles ‣ (Validated) Learning > Working Software Also known as “Getting out of the building” our comfort zone” ‣ Lots of ideas + Natural selection Diverge & Converge … Then do that a bunch more times ‣ Shared understanding but diverse opinions Shared understanding of the problem space allows us to move fast. Diversity of opinion, knowledge and experience will produce the best product. ‣ Focus on the customer Seems obvious, but the urge to build for ourselves is strong.
- 10. How we worked
- 11. Step 1: Build shared understanding of: ‣ People Get to know each other Build trust ‣ Product What is the problem we are trying to solve? How does that problem relate to the business? ‣ Process How are we going to work and why? Team Agreement Expectations workshop
- 12. Step 2: Visualise your business plan
- 13. Step 3: Hypothesis Creation ‣ Personas What are our assumptions about our customers? ‣ Outcomes What are our assumptions about the outcomes they desire ‣ Features On a broad level, what features do we believe will satisfy those outcomes?
- 14. Step 4: Ideation & Validation
- 15. Step 5: Profit ‣ Approx 4 sprints (Oct - Dec 2014) ‣ MVP Pitched EOY ‣ Green light - Build it ‣ Launched May 2015
- 16. And it was a huge success :D
- 17. We contributed to differentiating our product “Apple Music vs the streaming competition” http://mashable.com/2015/06/08/apple-music-comparison “Apple vs Spotify vs Tidal” http://www.mtv.com/news/2180613/apple-music- spotify-tidal-comparison
- 18. Confidence > Validation Product Discovery is weird balance of science and subjectivity.
- 19. Fail fast at how you work, talk to some customers ASAP! Our goal for our first sprint? Get to the end without strangling each other :)
- 20. Educate stakeholders to align expectations Our primary context in our organisation is building stuff. This is totally different, not just for us, but for stakeholders too.
- 21. Acknowledge & discuss bias Bias is everywhere.
- 22. Visualise EVERYTHING Working fast makes you prone to forgetting stuff. Don’t lose important information, make it visible and surround yourself with it.
- 23. If its easy, you’re doing it wrong Seriously, this is hard. It’s frustrating, time consuming but oh so worth it.
- 25. Thanks! Brendan Marsh Email: brendanm@spotify.com Twitter @brendanmarsh Blog: brendanmarsh.com (PS. We’re hiring!)
Editor's Notes
- Hi everyone, thank you for coming! :) My name is Brendan Marsh and I’m an Aussie from Perth Western Australia. Agile Coach, Spotify, Stockholm Sweden, 2 years Big data infra Release infrastructure for our mobile & desktop clients Spotify Running - < 1 year Topic of presentation
- To start with, we needed to agree on what values were going to drive the way we work. Most teams at Spotify are guided by lean and agile values that we’ve established over the past 7 years or so, but Product Discovery is totally different. We quickly realised that agile principles such as “Working software is our primary measure of progress” aren’t going to cut it. The following values drove our ways of working.
- Let’s start with a bit of context. End of Q3 2014, explore this opportunity Our data suggests that music is an important part of their running experience Hack weeks, prototypes
- Our primary hypothesis is that we can convert roughly 30 million of the worlds runners in our key markets to Spotify customers. Upon joining us, we hope to see a higher-than-usual 6 month retention rate.
- To explore this opportunity, a very cross functional team was put together. What I particularly liked about our team was that no one competency was over represented. We were incredibly diverse and we liked it that way.
- Our team was formed around one simple question - What should Spotify build around the running use case?
- We were formed to solve 1 piece of the puzzle, the “Think It” phase of our product development lifecycle. What made this challenge interesting was that technically we’d not really done this before. Most of our teams are already setup to iterate on a part of our product, but this was an entirely new use case that we didn’t fully understand. Most teams work with a higher degree of certainty, we had to navigate a high degree of uncertainty. We all agreed that we would have to “do think-it right”. We were even called an “innovation squad”, to set the expectation that we needed to truly explore & innovate in this area.
- And the land of Product Discovery is still pretty new. I like this example of Henrik explaining Scrum and showing the Product Discovery phase as a cloud of mystery. (and I should point out that this is a public Facebook post & I’m not sharing personal conversations) To recap: There is an opportunity around the running use case We should explore this opportunity through building a team to solve the question of “what should we build” Product discovery is hard, we’re going to have to do things a little differently.
- To start with, we needed to agree on what values were going to drive the way we work. Most teams at Spotify are guided by lean and agile values that we’ve established over the past 7 years or so, but Product Discovery is totally different. We quickly realised that agile principles such as “Working software is our primary measure of progress” aren’t going to cut it. The following values drove our ways of working.
- So once we had our values, I worked hard to come up with a way of working that follows these ideals. I drew inspiration from many different sources. Because I want to focus on learnings in this presentation, I’ll very briefly run you through how we worked.
- As a team, we’re going to have to make decisions quickly. Doing so is difficult when we all have different understandings of the problem we’re trying to solve and how to get there. I facilitated many different workshops to help us get on the same page.
- The next step was to visualise our business model. If we can visualise the problem we are trying to solve, then we can keep our shared understanding of it and update that as we go along. The canvas helped us uncover our assumptions about what we’re trying to accomplish and why. Importantly, it also uncovered unknowns, which is crucial in a discovery project. After our first attempt, we learned that there were some pretty crucial assumptions we were making that we weren’t aligned on. This exercise uncovered them and we were able to act on them, for example, meeting with our Chief Product Officer to ask about whether we are primarily targeting non-spotify users or existing users.
- Our next step was to create some hypotheses in which to work from. They become the backlog that we work through and update. We also attempted to prioritise these hypotheses using a risk matrix.
- The final step was to take our first hypothesis and attempt to validate it or invalidate it. We took inspiration from Google Venture’s design sprints methodology by using 1 week design sprints.
- Mid December when we were asked “If we were going to start building this now, what would we build?”.
- Outstanding coverage from the press and amazing feedback from our customers on social media.
- So what did we learn from this experience?
- We quickly learned that in the early days of product discovery, you can not scientifically prove or disprove your assumptions, but you can gain more (or less) confidence in them. By the time we pitched our MVP, we switched our language to say “we have more confidence in X and less confidence in Y”. Discovery is not a binary yes/no process.
- For us, we weren’t just learning, we were learning how to learn. It’s easy to sit around arguing over how we should work, but the best thing to do is to just grit your teeth and do it. We said “even if our design sprint is a total failure, we would have at least learned what to do for next time”. Also, your feelings of doubt and uncertainty will eat at you until you get the courage to go out and speak to some customers. Just do it, even if you’re terrible at it.
- One of our failings was we were out learning from customers, but sitting down with our stakeholders talking about a prototype that they were interested in using. If I had my time again, I would have tried harder to be more explicit about our team’s goals and what we were doing.
- We were biased by many things, which caused us to slow down or make errors in judgement. If I had my time again, I would try to surface what our biases are and where they come from. Our initial prototypes that we inherited biased us, our work environment biased us, our discussions with Senior Product Management biased us. It’s not terrible, but should be visualised and acknowledged.
- Visualise your current understanding of the product, of the business model, of who you are, how you work, of the feedback from customers. The moment you lose sight of these things, you slip into operating off of your own opinions, which is dangerous.
- We had a cross functional team of people doing everything, all the time and trying to stay aligned because we wanted the best possible product. You are constantly making micro decisions about the product and you need everyone there to do so. Acknowledge that this is going to be damn difficult, but that’s the point, you’re going out of your comfort zone, wearing hats you’ve never worn before, be prepared for that or get the hell out of the kitchen! Finally, you definitely can’t do this part time. Clear your calendars folks.
- If there is time…