Category: Lean

Book review: Sprint (Part 3 – Day 2)

marcabraham1 Comment

Once you’ve set a target as part of Day 1 of your sprint, the next step is for you and your team to look at solutions. On the second day of the sprint, you’ll be coming up with solutions, and sketching them. This day consists of two key activities: (1) review ideas to remix and improve, and (2) create solution sketches to feed into your plan for a prototype and customer testing.

Remix and Improve

In “Sprint”, Jake Knapp, John Zeratsky and Brad Kowitz suggest a good technique to collate and assess ideas: Lightning Demos. With this exercise, your team will take three-minute tours of their favourite ideas or products: from other products, from different domains, and from within your own company. The idea here is to encourage the team to throw everything in the mix, but to do so in a short and snappy way. Each person who has suggested an idea will do a three minute demo, showing the team what’s great about his or her solution. As a facilitator, you might want to use a timer to make sure each team member sticks to the their three minute time slot.

The key thing with these three minute ‘lightning demos’ is that you capture the big ideas from each presentation. Start by asking the person who’s doing the tour, “What’s the big idea here that might be useful?” You can then make a quick drawing of this big idea, write a simple headline above it and add the source underneath. I’ve included an example of a way to capture big ideas in Fig. 1 below.

Fig. 1 – An example of capturing ‘big ideas’ from lightning demos, by Karsten Neben – Taken from: https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.27wb5fv4e

Lightning Demos

 

Sketch

In the afternoon of the second day of your sprint, the focus is on coming up with solutions. Instead of doing collective brainstorming sessions – which in my experience run the risk of becoming shouting matches or can be dominated by very vocal people – Knapp, Zeratsky and Kowitz suggest each team member coming up with ideas on their own. People will work individually, thinking about and sketching solutions. I’ve included a simple example of a sketch in Fig. 2 below.

The sketches that people create will act as an important driver for the rest of the sprint. On Wednesday (Day 3), you’ll critique everyone’s sketches and pick the best ones.

If you’re worried about the quality of your sketches, don’t! Knapp, Zeratsky and Kowitz introduce the four step sketch technique. This approach makes it easy for everyone to take some rough solutions and turn them into a detailed solution sketch (see Fig. 2 below):

  1. Notes – As a first step, the team walks around the room and takes notes from looking at all the post-it notes, whiteboards, flip-charts that you have collated over the first day and a half of your sprint.
  2. Ideas – Each team member individually will look at his or her notes and jot down rough ideas, simply filling a sheet with doodles, headlines, etc. The aim here is not to come up with fully fledged ideas or solutions. It’s purely a way for each person to drop down their thoughts.
  3. Crazy 8s – Crazy 8s is a fast-paced exercise. Each person will take his or her strongest ideas and rapidly sketches eight variations in eight minutes. What I like about Crazy 8s is that it stops you from dwelling on your first possible solution for too long. Instead, the eight minute deadlines forces you to quickly decide whether to move on from your first reasonable solution or to stick with it but iterate (see Fig. 3 and 4 below). I’ve found Crazy 8s to work particularly well if you end up sketching several variations of the same idea, exploring alternative versions. Similarly, you can use Crazy 8s to refine a marketing headline or messaging.
  4. Solution sketch – The solution sketch is each person’s best idea, put down on paper in detail. Up to this point, each team member will have worked individually on creating notes, ideas and Crazy 8s, and won’t have shared anything with the rest of the team. This all changes with the solution sketch; each solution sketch is an opinionated hypothesis for how to solve the challenge at hand. These sketches will be looked at – and judged – by the rest of the team. They will therefore need to be detailed, thought-out, and easy to understand (see Fig. 5 and 6 below).

Once each team member has put together a solution sketch, the sprint facilitator will collate them all and put them in a pile. The team will only be allowed to start looking at these solution sketches on the third day of the sprint.

Fig. 2 – Four step sketch technique – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

4-stage sketch

Fig. 3 – How to do Crazy 8s – Taken from: “Sprint”, pp. 112-113

  1. Each person begins Crazy 8s with a single sheet of letter-size paper.
  2. Fold the paper in half three times, so you have eight panels.
  3. Set a timer to sixty seconds.
  4. Hit “start” and begin sketching – you have sixty seconds per section, for a total of eight minutes to create eight miniature sketches.
  5. Go fast and be messy: As with the notes and ideas, Crazy 8s will not be shared with the team.

Fig. 4 – Crazy 8s example – Taken from: https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard

1672917-inline-crazy8s

Fig. 5 – Important rules to keep in mind when creating a solution sketch – Taken from: “Sprint”, pp. 114-118

  1. Make it self-explanatory – Your solution sketch needs to explain itself. Think of this sketch as the first test for your idea. If no one can understand it in sketch form, it’s not likely to do any better when it’s polished.
  2. Keep it anonymous – Don’t put your name on your sketch, and be sure that everyone uses the same paper and the same black pens.
  3. Ugly is okay – Your sketch does not have to be fancy (boxes, stick figures, and words are fine), but it does have to be detailed, thoughtful, and complete.
  4. Words matter – Strong writing is especially necessary for software and marketing, where words often make up most of the screen. So pay extra close attention to the writing in your sketch. Don’t use “lorem ipsum” or draw those squiggly lines that mean “text will go here.” That text will go a long way to explain your idea – so make it good and make it real!
  5. Give it a catchy title – Since your name won’t be on your sketch, give it a title. Later, these titles will help you keep track of the different solutions as you’re reviewing and choosing. They’re also a way to draw attention to the big idea in your solution sketch (see the example in Fig 6 below).

Fig. 6 – A solution sketch from Blue Bottle Coffee’s sprint; each sticky note represents one screen – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

Sketch example

Main learning point: The second day of the sprint is very solution oriented. Instead of long brainstorm sessions, the day is filled with more individually oriented activities, encouraging team members to think about ideas and to come up with their own solution sketch.

Related links:

  1. https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas
  2. https://www.youtube.com/watch?v=_ITJ5lAXQhg
  3. https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.atwi36cd7
  4. https://library.gv.com/the-product-design-sprint-diverge-day-2-c7a5df8e7cd0#.7zmlxd9aq
  5. http://www.yaellevey.com/blog/how-to-use-crazy-8s-to-generate-design-ideas/
  6. https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard

Book review: Sprint (Part 2 – Day 1)

marcabraham3 Comments

In my previous post I started looking at doing 5-day sprints to discover and test solutions for a problem that you’re trying to solve. This follows my reading of “Sprint” by Jake Knapp, John Zeratsky and Braden Kowitz. Once you’ve set the stage for a sprint, it’s time to kick things off: the first day of a sprint is all about agreeing on the challenge that you’re looking to have tackled by the end of the sprint. On the Monday, i.e. the first day of the sprint, the focus is on the following activities: (1) agreeing on a long-term goal (2) making a map of the challenge (3) asking experts and (4) picking a target.

Agree on a long-term goal (‘start at the end’)

You start the sprint by asking the the team “why”, make sure everyone is on the same page about what we’re trying to achieve. Why do we want to create this product? Why are we doing this project? Why do we want to solve this problem? Where do we want to be in 3 months, 6 months, 1 year, even 5 years from now and why? What will success look like? Agreeing on a long term will bring the answers together in a shared purpose.

Once you’ve got a shared understanding of the underlying “why” and have set a long-term goal, you come up with number of specific sprint questions, which you can derive from the assumptions and questions that the team might have. To get the team thinking about some of these questions, you can use the following prompts:

  • What questions do we want to ask in this sprint and why?
  • How will we subsequently utilise the answers to these sprint questions and outcomes?
  • To meet our long-term goal, what has to be true?
  • Imagine we travel into the future and our product or project failed. What might have caused that failure? How can we best mitigate this risk?
  • To reach customers for this product, what has to be true?
  • To deliver value to these customers, what has to be true?

Fig. 1 – Sample long term goal and sprint questions:

Long term goal: More people buying snacks online.

Sprint questions:

  • Are people looking to buy snacks online?
  • What is the experience customers are looking for when buying snacks online?

Map the challenge

Challange Map

Fig. 2 – Example of a Challenge Map: Flatiron Health’s clinical trial enrolment map – Taken from: https://zapier.com/blog/google-ventures-design-sprint/

Creating a map is a great way to understand the steps the customer has to go through to achieve a desired outcome (see a good example in Fig. 2 above). Each map is customer-centric, with a list of key actors on the left. Each map is a story, with a beginning, a middle and an end. These are the common elements of a Challenge Map:

  1. List the actors (on the left) – The “actors” are all the important characters in your story. Most often, they’re different kinds of customers.
  2. Write the ending (on the right) – Write the outcome that the customer wants to achieve.
  3. Words and arrows in between – There’s no need for any fancy drawings; the map should be functional, and simple boxes and arrows should suffice.
  4. Keep it simple – Your map should have from five to around fifteen steps. If there are more than twenty, your map is probably too complicated.
  5. Ask for help – As you create the map, you should keep asking the team, “Does this map look right?” or “What are we missing?”

Ask the Experts

Nobody knows everything and it’s therefore critical that you engage with a range of ‘experts’. One of the biggest challenges of running a sprint is that you’ve got to gather a lot of information and make sense of it in a relatively short space of time. Having short conversations – approx. 30 minutes per conversation – with experts will help massively in collating relevant detail quickly.

Pick a Target

Selecting one target customer and one target event is the final activity of the first day of the sprint. The Decider needs to decide on the target customer and the customer event. Whatever she chooses will become the focus of the rest of the sprint – the sketches, prototype, and customer interviews all flow from this decision. Naturally, this can be a group decision, but it helps to assign decision-making responsibility to a single person.

Once you’ve selected a target, take a look back at your sprint questions. You usually can’t answer all those questions in one sprint, but one or more should line up with the target.

Main learning point: The first day of the sprint should really lay the groundwork for the rest of the sprint. Avoid the temptation to dive straight into solutions. Instead, spend the first day of the sprint to agree on a long-term goal and selecting a specific target to focus on!

Related links for further learning:

  1. http://www.nirandfar.com/2016/03/good-products-start-good-questions.html
  2. http://blog.invisionapp.com/inside-design-google-ventures/
  3. https://stfalcon.com/en/blog/post/how-to-quickly-check-startup-ideas-with-sprint

No more features on product roadmaps – Have themes or goals instead!

marcabraham7 Comments

You might have read my one of my previous blog posts about the so-called goal oriented roadmap. I  prefer goal-oriented roadmaps over their more traditional counterparts. My problem is that ‘classic’ roadmaps contain a mix of features and timings, but don’t provide any context whatsoever (I’ve included an example in Fig. 1 below). I typically don’t include features on a roadmap and focus on user or business problems instead. As such, the roadmap becomes a tool for ‘working backwards’ – enabling product teams to explore solutions for given problems or desired results.

I recently learnt from Jared Spool and Bruce McCarthy about adding “themes” to product roadmaps. McCarthy told Spool about the concept of adding themes, and Spool became an instant fan. Like me, McCarthy isn’t a fan of having features on a roadmap. Instead, he suggests adding “themes” to the roadmap and this is why:

  1. Open to ‘options’ –  McCarthy believes that by having specific features on a roadmap, you run the risk of sending a product team down a certain avenue (and closing off any potential side streets). For example, if you were to just put “data dashboard” on a roadmap, chances are you’ll end up with a data dashboard. However, what would happen if you were to put “provide our customers with data to make key decisions” or “no data access” on the roadmap instead? By focusing solely on solution you run the risk of falling victim to what Josh Wexler calls solution sickness. Solution sickness is all about fixating on a solution and ignore any alternative ways of solving a problem.
  2. Customer focus – Jared Spool makes a great point when he says “When companies talk about features, they are saying, “Look at us. Look at what we can do.” He goes on to explain that “When companies talk about the problems of customers, they are saying, “Look at what you’re dealing with. Look at how we want to help.” It’s very easy to get fixated on features and forget about the underlying problems you’re looking to solve.
  3. Helping trade-off decisions – One of the things I love about both the goal-oriented and ‘theme’ approach to roadmapping is that it forces you to consider ‘why’ you want to develop certain products or services. What problem are we looking to solve and why? Why do we feel this problem is worth solving? Why should we prioritise this problem over others? Both the goal oriented and the theme roadmap approaches help make customers and their problems the core of everything you do as a product person. When I use the goal oriented roadmap, I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.
  4. “Marketing the story of solutions” – Which do you think would be an easier story to sell to customers? Option 1: “You can now use this real-time data dashboard which you can access via your content management system, enabling you to filter the data and extract reports” or Option 2: “You can use our data to decide on whether now is good time to sell your house?” … Easy, isn’t it!? As Jared Spool points out, the ‘theme’ approach makes it much easier for marketing teams to tell a story about a product or service: “Here are the problems we set out to solve and here’s how we solved them.”
  5. A more cohesive design – Design is another area which is positively impacted by a shift in focus from solutions to problems. From experience, I know how much easier it is to prioritise against a problem that you’re looking to solve, instead of trying to cram in a lot of features which you think might have an impact. As Spool puts it: ” Without a commitment to specific solutions, the team has flexibility.” As a result, product teams stand a better chance of creating simpler, well designed products.

Main learning point: I really encourage all product managers – the ones who aren’t doing so already – to think much more in terms of user problems instead of focusing on features. Not only will this help you in focusing your product efforts, I believe it will also make you much more customer centric.

 

Fig. 1 – Example of a traditional roadmap – Taken from: https://roadmunk.com/

project-roadmap

 

Fig. 2 – Goal oriented roadmap example – Taken from: http://www.romanpichler.com/blog/agile-product-roadmap/

SampleGOProductRoadmap_DanceGame

Related links for further learning:

  1. https://medium.com/@josh_wexler/beware-solution-sickness-producttank-nyc-talk-caffc23becfa
  2. https://medium.com/uie-brain-sparks/themes-a-small-change-to-product-roadmaps-with-large-effects-a9a9a496b800

Book review: What Product Managers Need To Know About Rapid Prototyping

marcabraham4 Comments

“What Product  Managers Need To Know About Rapid Prototyping” by Mike Fishbein and Josh Wexler is a great ebook for any product manager keen on prototyping before building the actual product. Mike Fishbein is a content manager with Alpha UX and Josh Wexler is a solutions director at Originate. In this book, they’ve collated their learnings and tips with regard to rapid prototyping.

I’m currently learning how to create prototypes, using tools like Balsamiq, Illustrator, InVision and Sketch. Reading “What Product Managers Need To Know About Rapid Prototyping” felt very timely. These are the main things I learnt from it:

  1. Why do we need a prototype!? – Fishbein and Wexler point out very early on in the book that experiments are critical to alleviate risks inherent in new product or feature development. Prototyping is at the core of experimentation; it provides a quick way to validate your assumptions with real users and tackling key product risks early on in the process. It can be as simple as using a piece of paper with a sketch of a new feature for initial product validation. The main thing is that you use a prototype to mitigate risk by getting feedback early and often in the product (development) lifecycle.
  2. Why do product managers need to know about prototyping? – Building on the importance of experimentation, Fishbein and Wexler argue that “the product manager’s primary role becomes enabling experimentation as a seamless capability. At the core of experimentation is rapid prototyping.”
  3. Generative vs evaluative experiments – The distinction between generative and evaluative experiments is an important one. Typically, new products or features will start with “generative” experiments, where it’s all about identifying and assessing customer pain points or problems. In contrast, “evaluative” experiments are used to evaluate different options for a product direction. You’re evaluating a number of ways to resolve a customer pain point that you’ve established during a generative experiment. Rapid prototyping is critical during evaluative experiments.
  4. Consider constraints when prototyping – Using the words “prototyping” and “constraints” in one sentence might sound like a contradiction in terms, as you might think that prototype means having a free rein. In contrast, it’s important to pay attention to constraints when creating prototypes. The book suggests a number of important questions to ask before creating a prototype (see Fig. 1 below).
  5. Use a Learning Model, plotting ‘perception of value’ vs ‘simulation of value’ – Fishbein and Wexler describe the perception of value (‘PV’) as “a conglomeration of of metrics that together provide insight into comparative user feedback.” In other words, the higher the PV the better. Simulation of value (‘SV’) shows how close the user is to actually experiencing value. Going back to my earlier example of a simple sketch on a piece of paper; this might generate a high PV, because the user gets the value, but the SV is likely to be very low in comparison. It’s fair to say that higher SV values will generate more reliable user learnings and insights, as the prototype delivers more concrete value to the user.
  6. Plotting goals and constraints – It was really interesting to learn about plotting goals and constraints when thinking about creating a prototype. A good example of a constraint is “risk-threshold”, which represents the minimum amount of data you need to collect before your business gives the green light for a product. The ‘goal’ element covers the ‘why’ and perceived value of a product.
  7. Don’t forget about the ‘story’ – In addition to perception and simulation, Fishbein and Wexler also suggest looking at the ‘story’. The story dimension represents a continuum of the user’s narrative and how they might interact with the value proposition of a product. The book talks about about a so-called ‘double dip effect’, This effect typically occurs when product managers succeed in unlocking the ‘story’ element; when iteration cycles are so short that, following positive experiment results, product teams can run another experiment to understand the “why” behind the initial results. The key point here is that when prototyping becomes a rapid process, the product manager will be able to fully learn the narrative of her (target) users.
  8. Balancing simulation of value with iteration time and resources – Fishbein and Wexler also address some of the tradeoffs inherent in rapid prototyping. They point out that “prototyping lower simulations of value costs less and has shorter iteration cycles than prototyping higher simulations of value.” However, the insights you typically get from lower simulations of value are likely to be less reliable and detailed compared to high simulations of value. I’ve included Fishbein and Wexler’s pointers on how to manage these tradeoffs in Fig. 2 below.

Main learning point: I recommend “What PMs Need To Know About Rapid Prototyping” to any product person who wants to use prototyping as a way to learn quickly and often. Fishbein and Wexler have written a very comprehensive book which provides product managers with a great overview of dos and don’ts with regard to rapid prototyping. This book has definitely helped me in thinking about prototypes in a much more structured way!

 

Fig. 1 – Sample questions and constraints to consider before creating a prototype – Taken from: Mike Fishbein and Josh Wexler – What Product Managers Need To Know About Rapid Prototyping, pp. 19 – 21

  • What’s my or my organisation’s risk or treshold?
  • What’s my capability given my current budget?
  • What’s my organisation’s domain of discretion?
  • Am I over-constraining?

Fig. 2 – Balancing simulation of value with iteration time and resources – Taken from: Mike Fishbein and Josh Wexler – What Product Managers Need To Know About Rapid Prototyping, pp. 54 – 55

  • Stay in scope – It’s not about creating beautiful designs for your prototype, the goal is to learn about the user and their interactions with a product’s value proposition as early and often as possible. Staying in scope is therefore a key notion.
  • Adapt the methodologies – No (prototyping) methodology is set in stone. Instead, Fishbein and Wexler recommend understanding the high-level purpose of each prototyping step and then adapting it to your organisation.
  • Select technology that supports your best practices – When it comes prototyping, there’s a thousand and one tools to choose from. The important part is to make sure that prototyping is an efficient and waste-reducing mechanism for learning about users and validating new product concepts.

Related links for further learning:

  1. http://thenextweb.com/insider/2015/03/10/4-steps-to-make-experimentation-a-repeatable-process-in-your-business/
  2. https://uxmag.com/articles/your-playbook-for-demand-validation
  3. http://www.ideo.com/images/uploads/news/pdfs/FultonSuriBuchenau-Experience_PrototypingACM_8-00.pdf
  4. http://www.creativebloq.com/graphic-design/16-great-tools-creating-mood-boards-91412793

Learning about how Spotify builds products

marcabraham4 Comments

It was interesting to read a very detailed breakdown of how Spotify build products by Henrik Kniberg. Kniberg is a Swedish Agile expert who consults with a lot of different companies on how to best implement Agile and Lean practices. Kniberg is well respected when it comes to iterative development and Spotify is growing rapidly within the music industry (an industry which I also happen to work in with 7digital). Kniberg’s article gives a great insight into how companies can successfully apply some of the principles around “releasing early and often”.

In this blog post, I’ll highlight both Spotify’s underlying philosophy and the 4 key stages that form its product development process. Let’s start with Spotify’s core philosophy first:

  1. “We create innovative products while managing risk by prototyping early and cheaply” – Rather than taking a product through a whole product development cycle before finding out whether it provides value or not, Spotify prefers to release early and often instead. True to the philosophy of  “Agile” and “Lean” development methodologies, Spotify’s focus is on launching new products or features as soon as possible to see how they perform in real-time. The main benefits of this approach are twofold. Firstly, risk is managed more effectively and companies are likely to get real-time product feedback (from real users) a lot sooner.
  2. “We don’t launch on date, we launch on quality” – I guess not all businesses have the luxury of not having too worry about deadlines – think of companies that have to oblige contracts or other time-led constraint – but Spotify clearly seem to value quality over time. I guess the main point of this principle is the focus on quality above anything else. The challenge for any product person and developer is to strike the right balance between releasing early and often AND launching quality products. For instance, at 7digital we aim to release continuously whilst making sure that every singly release is fully tested to ensure set quality standards (I’ve written about this practice earlier).
  3. “We ensure that our products go from being great at launch to becoming amazing, by relentlessly tweaking after launch” – “Continuous Improvement” is the key term here. I wrote about this earlier and highlighted its roots in Japanese car manufacturing. In practice, this means that Spotify will try to ensure a certain quality standard upon launch, followed by further improvements based on real-time feedback and performance. A product is never ‘finished’ and as a product person you can never rest on your laurels; I believe that iterative development is effectively a continuous loop of releasing, measuring, learning, iterating, releasing and measuring again.

Now look at the 4 product development stages that are applied at Spotify:

  1. “Think It” – The first stage of Spotify’s product development process is all about figuring out what type of product should be built and why. The “Think It” stage can apply to both completely new product ideas or improvements to existing Spotify products. What’s interesting about this stage is that the overriding emphasis seems to be on creating a compelling narrative and less on on coming up with convincing metrics or a tight business case. Like they do at Amazon, a product’s narrative is written well before its being built (see also the the scope of a standard Spotify “product definition” in Fig. 1 below). Prototyping is the other aspect of the “Think It” stage that I like very much; a dedicated “Think It Squad” (typically a designer, a developer and a product owner) will create a number of prototypes to kick things off, varying in fidelity.
  2. “Build It” – With Spotify’s “Build It” stage the focus is on creating (and shipping) a product that’s “narrative complete” and not feature complete. Going back to the focus on delivering a compelling narrative in the previous “Think It” stage, the aim is is to release a product that fulfils the basic narrative to the user. At Spotify, they don’t talk about a minimum viable product (‘MVP’) but about a “minimum loveable product” instead. It’s about creating an initial product that real users will love and that fulfils the narrative.
  3. “Ship It” – True to the “Lean” approach, in the “Ship It” stage, Spotify will gradually roll out the product to all of its users. Instead of one big bang release, Spotify will start by releasing to a small percentage of all users (typically 1-5%), in order to collect data. This is the best bit in my opinion; the use of data to incrementally improve a product, compare groups of users and spread risk. This approach is a clear example of “data driven product development” as advocated by the likes of Eric Ries, Ash Maurya and Steve Blank. This ‘staggered’ approach is used for continuous measuring and improving, making product improvements as it’s being rolled out to more and more users. This also means, as Kniberg points out, that by the end of the “Ship It” stage a product is by no means “feature complete”. It just means that the product (= MVP + necessary improvements) has been 100% rolled out and that it will continue to evolve.
  4. “Tweak It” –  This is a critical part of the product lifecycle since this is where the product is likely to spend most of its time. The product is now live and being used by all users and ‘the squad’ will continue to experiment with the product. The squad will continue doing A/B tests to make improvements (big or small) until a point is reached where the product as whole needs to be evaluated, especially when the product is starting to reach the point of diminishing returns (see also Spotify’s definition of “done” for this stage in Fig. 2 below). Do we keep tweaking the product, adding minor improvements? Or do we rethink the product as a whole?

Main learning point: Kniberg’s article on how Spotify builds products provides in my opinion mandatory reading for most product managers or developers, especially for those with an interest in lean or iterative development. The 4 different product development stages used at Spotify are well defined and really help in both spreading the risks involved in launching a new product and getting real user feedback as soon as possible. Don’t worry if you don’t have the resources that Spotify have; you’ll still be able to apply a lot of the underlying principles and techniques!

Fig. 1 – Scope of a “product definition” document at Spotify

The product definition is a short document that answers questions such as:

  • Why should we build this?
  • Who will benefit from this and how?
  • What are the key metrics that we expect this product to improve?
  • What are the hypothesis? How will we know if this product is successful?
  • Is this a “step change” (that is, a product that we expect will give at least a 2x improvement on the chosen metric)? If we expect only minor improvement on the metrics, there better be some other strong reason for building it, for example a strategic reason.

Fig. 2 – Definitions of “done” for the 4 stages of Spotify’s product development

  • Think It – definition of done: The Think It stage ends when Spotify’s management and ‘the squad’ jointly believe that this product is worth building (or that the product will never be worth building and should be discarded).
  • Build It – definition of done: The Build It stage ends when Spotify’s management and ‘the squad’ jointly believe that this product fulfils the basic narrative and is good enough to start releasing to real users.
  • Ship It – definition of done: The Ship It stage ends when the product is available to all users.
  • Tweak It – definition of done: The Tweak It stage ends when a product has reached a point of diminishing returns. The product is great and the most important improvements have been made. The cost/benefit ratio of new feature development, however, is less attractive. Looking at the metrics, new features and improvements don’t seem to be moving the needle a lot.

Fig. 3 – Scaling Agile at Spotify – Taken from: http://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/

Screen Shot 2018-12-31 at 11.05.47.png

 

Related links for further learning:

  1. http://blog.crisp.se/2013/01/13/henrikkniberg/how-spotify-builds-products
  2. http://www.spotify.com/se/blog/archives/2012/12/06/discover/
  3. http://www.svproduct.com/assessing-product-opportunities/
  4. http://www.theverge.com/2013/3/11/4080130/can-anyone-turn-streaming-music-into-a-real-business
  5. https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
  6. http://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/