25
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

Spotify Running: Lessons learned from building a ‘Lean Startup’ inside a big tech company

Embed Size (px)

Citation preview

Spotify RunningLessons learned from building a 'Lean Startup' inside a big tech company

A minimum viable presentation

Brendan Marsh, Agile Coach / PO @ Spotify

@brendanmarsh

Hi everyone, thank you for coming! :) My name is Brendan Marsh and Im an Aussie from Perth Western Australia.Agile Coach, Spotify, Stockholm Sweden, 2 yearsBig data infraRelease infrastructure for our mobile & desktop clientsSpotify Running - < 1 yearTopic of presentation

About me :)Agile Coach, Infrastructure & OperationsCoaching teams that build & maintain big data @ SpotifyAgile Coach, Spotify RunningCoaching a product discovery (Innovation) squadProduct Owner, Desktop Infra (now)Our Desktop Infra team releases our desktop client on OSX / WindowsInnovation Guild Owner (now)Coordinating our Innovation Guild and also working on a company-wide initiative around Innovation

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 weve 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 arent going to cut it. The following values drove our ways of working.

The OpportunityDifferentiation - Streaming music is becoming commoditisedData People are creating running playlists, music is importantMarket Opportunity~ 30 million runners in the USBelief This could be awesome!We have the technology! >

Lets start with a bit of context.End of Q3 2014, explore this opportunityOur data suggests that music is an important part of their running experienceHack weeks, prototypes

Core HypothesisHigh level hypothesisWe believe that a unique running experience will result in an increase of registrations (from runners) with a higher 6 month retention rate than regular usersBrand hypothesisWe believe that a unique running experience will differentiate our product from our competitors

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.

A team is born (Team Pre)Product OwnerAgile Coach (me!)UX / DesignerUser ResearcherMobile DeveloperContent CuratorMarketing

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.

What should Spotify build around the running use case?(If anything?)

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 wed 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 didnt 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 & Im not sharing personal conversations)

To recap:There is an opportunity around the running use caseWe should explore this opportunity through building a team to solve the question of what should we buildProduct discovery is hard, were going to have to do things a little differently.

Our guiding principles(Validated) Learning > Working SoftwareAlso known as Getting out of the building our comfort zoneLots of ideas + Natural selectionDiverge & Converge Then do that a bunch more timesShared understanding but diverse opinionsShared understanding of the problem space allows us to move fast. Diversity of opinion, knowledge and experience will produce the best product.Focus on the customerSeems obvious, but the urge to build for ourselves is strong.

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 weve 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 arent going to cut it. The following values drove our ways of working.

How we worked

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, Ill very briefly run you through how we worked.

Step 1: Build shared understanding of:PeopleGet to know each otherBuild trustProductWhat is the problem we are trying to solve?How does that problem relate to the business?ProcessHow are we going to work and why?Team AgreementExpectations workshop

As a team, were going to have to make decisions quickly. Doing so is difficult when we all have different understandings of the problem were trying to solve and how to get there. I facilitated many different workshops to help us get on the same page.

Step 2: Visualise your business plan

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 were 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 werent 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.

Step 3: Hypothesis CreationPersonasWhat are our assumptions about our customers?OutcomesWhat are our assumptions about the outcomes they desireFeaturesOn a broad level, what features do we believe will satisfy those outcomes?

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.

Step 4: Ideation & Validation

The final step was to take our first hypothesis and attempt to validate it or invalidate it. We took inspiration from Google Ventures design sprints methodology by using 1 week design sprints.

Step 5: ProfitApprox 4 sprints (Oct - Dec 2014)MVP Pitched EOYGreen light - Build itLaunched May 2015

Mid December when we were asked If we were going to start building this now, what would we build?.

And it was a huge success :D

Outstanding coverage from the press and amazing feedback from our customers on social media.

We contributed to differentiating our product

Apple Music vs the streaming competitionhttp://mashable.com/2015/06/08/apple-music-comparisonApple vs Spotify vs Tidalhttp://www.mtv.com/news/2180613/apple-music-spotify-tidal-comparison

So what did we learn from this experience?

Confidence > ValidationProduct Discovery is weird balance of science and subjectivity.

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.

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 :)

For us, we werent just learning, we were learning how to learn. Its 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 youre terrible at it.

Educate stakeholders to align expectationsOur primary context in our organisation is building stuff. This is totally different, not just for us, but for stakeholders too.

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 teams goals and what we were doing.

Acknowledge & discuss biasBias is everywhere.

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. Its not terrible, but should be visualised and acknowledged.

Visualise EVERYTHINGWorking fast makes you prone to forgetting stuff. Dont lose important information, make it visible and surround yourself with it.

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.

If its easy, youre doing it wrongSeriously, this is hard. Its frustrating, time consuming but oh so worth it.

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 thats the point, youre going out of your comfort zone, wearing hats youve never worn before, be prepared for that or get the hell out of the kitchen! Finally, you definitely cant do this part time. Clear your calendars folks.

If there is time

Thanks!

Brendan MarshEmail: [email protected] @brendanmarshBlog: brendanmarsh.com

(PS. Were hiring!)