How Songkick is doing a “Detour”

I’m a big fan of Songkick, a London-based company that enables users to track live shows of their favourite artists. Songkick was founded in 2007 by three friends who felt that finding out when your favourite artist was coming to town could be made a lot easier. Songkick enables users to track their favourite artists and will automatically send an alert once an artist or a band announces a show in your area (see Fig. 1 for a screenshot of my personal artist tracker on Songkick).

Co-founder Ian Hogarth recently referred to Songkick  as “the second most visited ticket site after Ticketmaster” in a recent “Tech Weekly” podcast by the Guardian. Songkick have received backing from well-known venture capitalists like Index Ventures and, recently, Sequoia Capital. Apart from capturing already scheduled concerts, Songkick has now also started crowd funding concerts. This recent initiative is called “Detour” (see Fig. 2 below) and is based on the idea of fans paying upfront for a gig by an artist or band that they really want to see.

  1. Will fans use Detour to get Nicki Minaj to come and perform? – Can you imagine how many fans one would have to gather and how much money one would have to pledge to get Nicki Minaj to come and play in, let’s say, Huddersfield!? That’s not what Detour is for, it helps to bring those artists who otherwise might not come. Songkick’s Detour kicked off with a campaign to get Tycho, a small electro band from San Francisco, to come to Europe. Tycho had never played in Europe before and this is how the Detour initiative came about.
  2. Fans make it happen – To gage interest in bringing Tycho to these shores, the guys at Songkick started emailing those Songkick users who track Tycho’s live shows through Songkick. Over 100 of these users pledged money for a ticket. Since that number still didn’t make it viable for Tycho to come over, the Songkick users started contacting their friends to get them to pledge too. Soon enough a sufficient number of people had pledged money to buy a ticket, which made it feasible for Tycho to come over and do a show in London.
  3. Can make Songkick make a lot of money out of Detour? I’m not sure whether Songkick will be able to make a lot of money out of Detour (and I’m not sure whether that’s the goal), but it can nevertheless become a self-sustainable revenue stream where Songkick perhaps take a fee to recoup its operational cost and the transaction fee which normally would go to ticketing giants like Live Nation or Seatwave.
  4. Where does the (user) value come from? For Songkick, I can see the value of Detour being in (1) user engagement, finding another way of actively engaging with the Songkick user base and (2) a reduced dependency on other ticket sites, being more in control (and generate revenue) of organising events and creating a platform for ticket and merchandise sales. For users, Detour provides a great platform for getting to see artists that one probably wouldn’t be able to see otherwise.

Main learning point: crowd-funding initiatives like Kickstarter are rapidly growing and gaining momentum and now Songkick has launched its own version in Detour. An interesting extension of its services, tapping into Songkick’s solid user base whilst providing Songkick the opportunity to take over from ticket vendors. I guess the success of Detour will be largely determined by the scale of its user base and by Songkick generating sufficient interest for the artists ‘in the offering’.

Fig. 1 – Screenshot of my artist tracker on

Fig. 2 – Screenshot of Detour homepage

Related links for further learning:

Book review: “Implementing Lean Software Development”

Books like “Implementing Lean Software Development”, written by Mary and Tom Poppendieck, act as a good reminder of the principles behind Agile and Lean development practices. The book explains in great detail (and supported by relevant real-life examples) the main things that underpin an ‘iterative development approach’.

In some of my previous blog posts I concentrated specifically on applying Agile practices in a product management context. By contrast, “Implementing Lean Software Development” focuses on developing software from an Agile point of view.

As a starting point, Mary and Tom Poppendieck emphasise the importance of creating a “just-in-time flow”, which addresses one of the things I really like about applying Agile methodologies: making any bottlenecks or constraints immediately visible as you soon start working on things. This visibility then helps one to address the underlying issue(s) and to improve processes accordingly. Mary and Tom Poppendieck refer to this latter aspect as the “learn-by-doing approach”, which is similar to the “plan-do-check-adjust” approach which I wrote about earlier. It all comes from the well known (and often misused) concept of “Kaizen”, meaning ‘change for the better’ in Japanese.

Poppendieck’s “7 principles of lean software development” form the backbone of this book. These principles prompted me to have a think about those areas of “lean” which I try to apply on a daily basis or where I can improve:

  1. Eliminate waste – In their book, the Poppendiecks list “The Seven Wastes of Software Development”. I’ve learned over the last few years that it takes quite a bit of discipline to reduce or remove common types of waste such as “partially done work”, “extra features” and “defects”. Particularly as a product manager, I believe there’s an important role in defining upfront when a product can be considered “done” . This doesn’t mean writing lengthy product specifications upfront but does imply a certain rigour around following set steps when working on a feature or a bug (e.g. define acceptance criteria, write acceptance tests, develop, launch, test and iterate).
  2. Defer commitment – Especially with complex products, the Poppendiecks advocate an approach whereby tough problems are tackled though experimenting with a number of potential solutions, leaving critical options open in the meantime. In my experience, this means starting with a clear idea of what a product or feature is supposed to do (and user problems it aims to solve) combined with rough idea of complexity. Instead of taking on all of the expected complexity head first and committing to a set solution/technology, one starts by first exploring a number of technologies and solutions (by, for instance, developing the bare minimum product first) before making critical decisions about the technology to use or the solution to use.
  3. Deliver fast – To me this is an absolutely crucial element of lean software development and product management. Fast delivery does’t mean that one should simply rush things out of the door, quite the opposite. I always try to work closely with developers, testers and stakeholders to work out what the “minimum marketable product” looks like and what the minimum requirements should be (I’ve written  about both iterative product development and the risks of releasing too early too often before). This is is then followed by development, testing and deploying the highest priority/value feature set first, followed by further iterations.

Main learning point: reading “Implementing Lean Software” will be of benefit both to people who are completely new to lean software and to those who are already familiar with this development approach. The book provides a good outline and explanation of the key principles which underpin lean software development as well as a lot of practical guidance on how to apply lean software development on a day-to-day basis. Even if you feel that “lean” isn’t for you or that it doesn’t fit your organisation or product, “Implementing Lean Software” will at least provide you with all the information to base your approach or decisions on!