Developing my own product – Where to start measuring?

So I had designed and developed a minimum viable product for my HipHopListings iOS app. I had worked very closely with Alex the developer, designed the mobile workflow and outlining the way I expected users to interact with HipHopListings on their iOS devices. I tested, tested and tested. It led to some critical bug fixes and improvements to both the back-end and the front-end of the app.

My jaws dropped when Apple approved my HipHopListings app within less then a week after submitting it. You can find the app here and I’ve added a screenshot below (see Fig. 1). Based on my previous experiences with getting apps approved by the mighty Apple, this was super fast!! I celebrated and felt like the proudest man on the planet as I’d just launched my own app and had been able to do so within less than a month from actually designing the app screens!

However, I realised that I couldn’t just rest on my laurels and had to start measuring if and how people were actually using my app. If I wanted to learn about how to best improve my app, I really needed to start measuring things, but where to begin!? I had implemented Google Analytics but wondered what metrics to focus on, especially as there are countless analytics ratios and reports to choose from.

I decided to try and identify my key questions and assumptions that I wanted to validate first:

  1. How many people are using my app on a recurring basis? – My simple reasoning was that the number of people who had installed my app (which numbers are available via iTunes Connect) is pretty meaningless when those people never use the app again. I therefore wanted to be able to do some form of cohort analysis to get a better understanding of the usage patterns of new users, developing an insight as to wether my app was compelling enough for people to keep coming back to it.
  2. Where are most HipHopListings users based?  One of my underlying assumptions when creating the app was that the bulk of HipHopListings’ target audience were likely to be based in the UK, especially given the fact that the “Shows” screen on my app only lists UK gigs. I now wanted to find out whether this assumption was actually true. Is most of the (recurring) usage coming from the UK? If not, what can I do to attract more UK users to the app? Is there a particular reason that people use (or don’t) use the app?
  3. Which screens do users tend to look at most? – I felt that looking at screen views (and the duration of each view) could provide me with a better indication of where the app could be improved. When I started creating the HipHopListing app, one of my assumptions was that people would mostly use the app to view upcoming Hip Hop shows (this assumption was part of the opportunity assessment that I did before deciding to build the app). Was this actually true? If I started making slight changes to the “Releases” screen, would these have an impact on the performance of the screen that lists upcoming releases?
  4. What are common drop-off points in the app? Again, I believed that if I wanted to get a better insight into the understanding of my new app, I’d need to understand the common drop-off points within the app: where do users typically lose interest and why?

Main learning point: I realised as I was thinking about the kinds of things that I’d like to measure about my HipHopListings app that I was falling into a classic ‘data trap’. My thinking was very much around specific questions that I hoped would give me a better insight into the performance of my app. However, I’d forgotten to think about goals, setting some sort of benchmark or baseline of what success should look like for my app. I thus learned that it would be good to first take a step back and identify my main goals, before deciding on the right things to measure.

Fig. 1 – My own HipHopListings app in iTunes

Screen Shot 2013-06-20 at 05.27.44

What to make of Twitter #music

Last week it finally happened: Twitter launched its own music service in Twitter #music. This is “a new service that will change the way people find music, based on Twitter.” Like so many other music and content-oriented services out there, Twitter is trying to crack the holy grail that is ‘discovery’.

Here are three reasons why I think Twitter is in a fairly good position to do so:

  1. It knows what’s popular – Since Twitter’s acquisition of music service We Are Hunted, which specialised in analysing the likes of Twitter and making recommendations accordingly, the question has been how Twitter would encourage its users to discover music. An obvious first angle is to highlight music that’s popular, showing “new music trending on Twitter” (see Fig. 1 below). The tracks on here are irrespective of a user’s taste or the artists you’re following on Twitter.
  2. It can point you in the direction of new talent – I’d love to find out more how Twitter’s algorithm compile the artists and bands that appear in its “Hidden talent found in the Tweets” screen (see Fig. 2 below). Twitter suggests over a 100 artists who are considered “emerging”. Because Twitter Music primarily focuses on the artist, it will let users discover new music through the artist. For instance, when I click through on The Blank Tapes, one of the emerging talents mentioned, I get a neat overview of all the artists that The Blank Tapes follow (see Fig. 3 below).
  3. It’s dynamic! – The dynamic nature of Twitter is probably best symbolised by Twitter Music’s #nowplaying view which displays those tracks tweeted by the people that you follow. The tracks that appear on this screen are likely to change in rapid succession (obviously dependent on the number and kinds of people you follow and their Twitter activity).
  4. It’s cross-platform – Users can currently access Twitter #music via the web and iOS. An Android version is set to follow soon, with Twitter also looking to expand the service beyond the US, UK, Canada, Ireland, New Zealand and Australia. One can imagine a tablet version to also be introduced soon. Apart from being cross-platform (which was to be expected), Twitter Music offers a tight integration with iTunes, Rdio and Spotify. By default, you users can listen to track snippets through iTunes and will have to log into to Rdio or Spotify account to listen to the full-length track. Twitter is thus creating its own – fairly closed – ecosystem around music and music discovery.

Main learning point: in a way, with “Twitter #music”, Twitter has launched a music service that very much does what you’d expect it to do. With the amount of ‘social data’ that Twitter has of its users and the activity on their platform, you’d expect nothing short of a highly usable and ‘intelligent’ music service. Twitter #music definitely delivers on those fronts: it provides a good user experience, it’s visually appealing and – most importantly – it does stimulate users to discover new music.

However, Twitter’s new music service still feels fairly one dimensional. Opportunities to actively engage with artists are limited and ways to find out about more things than just their music (e.g. live dates, discographies) are non-existent. It would be great to see Twitter build on its music service by adding more ‘interaction’ over the next few months.

Fig. 1 – Sample “Popular – New music trending on Twitter” view 

FireShot Screen Capture #029 - 'Popular I #Music' - music_twitter_com_i_chart_popular

Fig. 2 – Sample “Emerging – Hidden talent found in the Tweets” view

FireShot Screen Capture #028 - 'Emerging I #Music' - music_twitter_com_i_chart_emerging

Fig. 3 – Sample of viewing the artists followed by the artist you follow

FireShot Screen Capture #027 - 'Artists followed by The Blank Tapes I #Music' - music_twitter_com_theblanktapes

Related links for further learning:


Developing my own product – Assessing my product idea

After I spent some time thinking about a vision for my product, the logical next step was to assess my idea. Naturally, I was excited about creating a mobile app that lists Hip Hop gigs and releases but at the same time I worried that no one was waiting for this new product or that it wouldn’t be a viable idea.

As I tend to do in my day job, I started going through the same steps that I normally use to assess a product opportunity or idea. In short, these steps come down to the following:

  • Who? – Who make up the target audience of my product? Which of their problems is my product looking to solve?
  • Why? – What value is my product looking to deliver? How will it differentiate itself from the competition? How big is the opportunity?
  • What? – What is the product that I’m looking to develop? What are the functional and non-functional requirements that I need to consider? How is this product going to make money?
  • When?  When do I need to launch the (first version of) the product? Are there any user, client, market or regulatory expectations that I need to consider in this respect?
  • Where?  Where can the product be developed? Has something similar (or the underlying technology or platform) already been created by someone else?

When I had to apply these steps to my own HipHopListings app, I just took a blank piece of paper and started answering the following questions for myself:

  1. What’s the problem this app will solve? – A single app that provides a comprehensive overview of all Hip Hop gigs in a particular area. You don’t have to track a specific artist; HipHopListings will make sure you’re up to date on all shows and releases in your favorite genre. Since HipHopListings also includes release dates, it thus provides a great source for Hip Hop fans who wish to be kept up to date on all upcoming Hip Hop events and releases.
  2. For who will it solve this problem? – Fans of Hip Hop music who enjoy going to Hip Hop shows or events. The initial target audience is that of fans of Hip Hop music in the UK or tourists who are looking to visit the UK and going to a concert as part of their trip. In addition, the idea of genre based event and release info can easily be extended to fans of other genres. 
  3. How big is the opportunity? – Not sure. Recent Live Nation stats show a decline in people going to concerts. However, 2010 stats still indicate a value of £1.5bn of the UK market for live music. Combined with a strong concert and festival culture in the UK, it’s no surprise that there’s strong competition on the market for ticket sales and concert alerts. However, I believe there’s a clear niche (with a substantial target audience) for HipHopListings to step into: provide a single source for all UK Hip Hop events for fans of Hip Hop music who wish to be kept up to date on any gigs scheduled and discover new shows / artists in the process.
  4. What’s the competition like? – Huge. Established ticket re-sellers such as Live Nation, Ticketmaster, TicketWeb and See Tickets cover most of the market for entertainment ticket sales between them. In addition, UK-based Songkick is an incredibly well-funded provider of concert alerts.
  5. What’s HipHopListing’s main differentiator? – It’s all about Hip Hop, listing all UK concerts and events within this genre. Most of the competition cover all genres, basing alerts on a user’s selected artists or music collection, thus limiting opportunities for discovery. Instead, HipHopListings covers UK shows by well-known and lesser known Hip Hop artists alike. As I currently curate HipHopListings manually it’s easy to see the number and variety of sources that list Hip Hop events, even having different ticket re-sellers list different shows / locations for the same artist! As a result, HipHopListings offers a single resource for all Hip Hop events in the UK.
  6. Why now?  HipHopListings now enjoys a significant following both on Twitter and Tumblr which provides it with a good opportunity to introduce a new ‘channel’ in the form of a mobile app. The nature of mobile applications could fit in with well with HipHopListing’s main value proposition (see point 1. above) and the requirements of its (target) users.
  7. What will be HipHopListings’ go-to-market strategy? Start with HipHopListings’ online following. With nearly 4,000 followers, if an initial 10% of that following download the free app that will be a good basis to start building on. I can use a small group of users to both spread the word and improve the application. Once the app has a larger user base and an improved product, I can start marketing the app more widely. For example, working more closely with ticket re-sellers (providing them with referrals) and artists to promote shows or releases.
  8. What’s the business model? How will I make (some) money from this mobile app? Potential revenue is likely to come from taking commission on referrals to ticket sites and working with artists or promotors to showcase specific events. Also, the demographic data gathered through the app on a specific user group can be used for targeted marketing campaigns by brands and marketing agencies.
  9. Critical success factors – The initial KPIs to concentrate on are: (1) number of people installing the free app (2) the number of monthly active users (there’s not point in people installing the app and then never looking at it again!) (3) the number of listed events shared through the app via social media and (4) number of people clicking through to a ticket site (and subsequently purchasing a concert ticket). I reckon these four factors will provide a good initial indication of how successful the app is at addressing the problems of its (target) users (see point 1. above).
  10. How? – Starting with a basic app, concentrating on a Minimum Viable Product which will hopefully help to validate some of my assumptions (see points 1-3 above). Even though I’m not a developer, it would be great if I could create an app that’s basically a list. At this stage, that’s all I need to launch the offering, measure some key analytics and build on it. Once the app has a bit of traction, I can then always decide to get a developer to further improve the app and add more functionality.

Main learning point: even though I was very keen on ‘just getting something out there’, I was pleased that I took a step back to assess the opportunity a bit more. Even though I could have easily spent a lot more time on things like market research and working out the best business model, I instead decided to start with some initial assumptions, launch something and then validate these assumptions.

Related links for further learning:


Learning about how Spotify builds products

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:

Screen Shot 2018-12-31 at 11.05.47.png


Related links for further learning:


Developing my own product – Creating a product vision

One of my longstanding dreams has been to develop my own product. My own creation, from start-to-finish, is something I’d really wanted to do. The goal is not to become the next Steve Jobs or Mark Zuckerberg, but it would be great to having something that people can actually use and that’s ‘my own’. So I decided to go through the ‘proper product development’ process as I would with any other product and apply the same logic and steps.

My first step was to determine whether a product ‘has got legs’. What is my product idea? Who are my target customers and which of their problems is my idea aiming to solve and why? Can the product be technically and commercially viable? What’s the best business model for the app? What are my expectations with this app? With all these questions flying through my head, I decided on creating a product vision as a starting point. My thinking was that once I had worked out what problem I was looking to solve and for whom, I could start assessing the opportunity.

  1. Let’s start with a bit of context first – For the past 4 years I’ve been running HipHopListings, a simple Twitter feed and blog that informs people of upcoming Hip Hop gigs in the UK and lets them know about new Hip Hop releases. HipHopListings has proven to be very popular, with approximately 4,000 followers on Twitter and lots of interaction around what’s effectively a list. Numerous users have been asking me to create a mobile app, providing an overview of Hip Hop shows on any given date for any UK location.    
  2. Now what’s the idea!? – Existing concert tracking apps like Songkick or Ticketmaster mostly enable tracking based on a user’s location (Ticketmaster or Seatwave) or based on specific artists that you’re tracking or that are in your music library (Songkick or GigsandTours). However, none of them seem to be doing ‘genre specific tracking’, providing users with an overview of shows in a specific music genre they’re interested in. Whilst doing HipHopListings, I’ve received a lot of feedback from users who liked the fact that HHL covers Hip Hop shows and releases in the broadest sense of the word and thus lets them discover things they might not have done otherwise (see Fig. 1 below).
  3. My main goal / vision – Before I did anything else, I started thinking about a clear product vision or goal to work towards. I tied this in with thinking about HipHopListing’s target users and their needs (see Fig. 1 below) and some very rudimentary sketches of my product idea (see Fig. 2 below). I believe that a good product vision has two main characteristics. Firstly, it’s succinct but very clear. Secondly, it needs to express a clear goal that you’re trying to achieve (and which you can validate). I thus started drafting a number of possible product vision statements (see Fig. 3 below).
  4. Can my vision be tested? – Whilst coming up with potential vision statements (see Fig. 3 below) I also started thinking whether my goals and visions could be validated. I’ve learnt the importance of being able to test a specific goal or aspiration. For instance, what does a possible vision statement stating that I want to create “A great overview of Hip Hop gigs and releases at your fingertips” actually mean? Is there a way to measure whether I’ve been successful in achieving this vision? Which metrics do I need to start measuring? With the rough product vision statements that I started outlining I also started thinking about potential metrics that could help to validate some of my assumption (see Fig. 4 below).
  5. Initial product vision – In the end I settled on “A comprehensive list that lets users filter shows by location and by date”. This vision encapsulates what I’d ultimately like to achieve with my HipHopListings app: a simple but truly comprehensive list of shows that users can interact with, wherever they are. This vision leaves room to add features like ‘upcoming release information’, but my key focus is to create a list that provide info on all Hip Hop gigs (big and small) across the UK.

Main learning point: applying some common product management tools to your own idea definitely adds a different dimension! I found that taking something that’s your own brainchild and being rigorous about can certainly be challenging at times. Mind you, at this stage no one hadn’t really heard about my idea or goal, nor had seen any of my – very rudimentary – sketches. However, spending a bit of time of upfront thinking about the “why” and “who” of my idea was very helpful in refining some of my ideas and assumptions. I believe that every idea for a product or service needs a starting point. Thinking about an product vision / goal was my starting point in thinking about creating a mobile app for HipHopListings.

Fig. 1 – Target users and the problems that the HipHopListings app is looking to solve

User 1 – Hip Hop fans who wish to find out about Hip Hop gigs in their local area

“King B” – “How do u find out about concerts & gigs in uk? Is there an app for iPhone?”

“King B” is a Manchester-based finance student and entrepreneur. He has been following HHL on Twitter for 3 years and checks it regularly to find out about Hip Hop shows in Manchester. His favourite artists are J. Cole, Blu and Trey Songz.

Main problem: would like to find out about Hip Hop gigs in the UK though a mobile app.

King B screenshot

User 2 – Regular concert visitors looking to plan city trips around shows

“Beth Jo Scott” – “Sappnin 23-26th Feb in London? Anything good/not sold out?”

“Beth Jo Scott” lives in Blackburn, follows HipHopListings on Twitter and is passionate about music and Hip Hop music in particular. Beth Jo is 23 and loves going to Hip Hop gigs across the UK. However, she often tends to find out about shows once they’re already sold out or have taken place.

Main problems: (1) finding out abouts shows as soon as details are released and (2) planning trips to UK cities around a Hip Hop gig.

User 3 – Hip Hop artists or promotors who wish to promote their gigs and releases

“Skillit” – #skillitbang album launch party on @hiphoplistings tumblr#skilllitmusic make it down there

“Skillit” is a London-based rapper who does a lot of gigs in small venues across the UK. He’s not yet big enough to be picked up by big ticket resellers such as Tickemaster or See Tickets. He therefore uses a much more ‘grass roots’ approach to marketing his upcoming shows, using HipHopListings and other UK Hip Hop sites to promote his gigs. Main problem: being able to promote my gigs and releases across a wide audience of Hip Hop fans.

Skillit screenshot

User 4 – Hip Hop fans who wish to be alerted on upcoming Hip Hop shows in their area.

“Joey Del Negro aka DJ Skoundrel” – “why am I only hearing about this now??!!”

Joey Del Negro is a London-based DJ and regular visitor of Hip Hop gigs. He finds that’s he often (too) late in finding about Hip Hop gigs in London and wants to receive regular alerts about Hip Hop gigs coming up. Joey doesn’t have a specific Hip Hop artist or DJ he’s interested in, he likes to be kept up to date on upcoming Hip Hop shows, so that he can then decide what he really wants to go and see.

Main problem: wanting to find out about upcoming Hip Hop shows as soon as possible.

Joey Del Negro screenshot

Fig. 2 – Some initial sketches of possible user interface 

A basic way to list gig information, outlining date, artist, location, venue and ticket resellers: 

0306'13 Gig outline sketch V1.pdf

A basic way to filter gig information, with the user being able to select using a number of filters:

0306'13 Gig filter sketch V1 A basic way to list release information, outlining date, artist, release title and link to buy / download: 

0306'13 Release outline sketch V1.png

Fig. 3 – Possible vision statements for the HipHopListings mobile app

Long version:

“HipHopListings is a mobile app for Hip Hop fans in the UK who want to be kept up to date on Hip Hop events across the UK and Hip Hop releases. Our app lets users find about Hip Hop shows or releases by artists they might not even have heard about, but will be triggered to go an check it out. Our app goes beyond specific artists you wish to track and gives you a complete overview of upcoming Hip Hop shows and releases, making sure you have full access to what’s going on and letting you filter this info by location or date.”

Shorter vision statements:

  • “A great overview of Hip Hop gigs and releases at your fingertips”
  • “Enabling Hip Hop fans to access gig and release info where and when they like”
  • “A comprehensive list that lets users filter shows by location and by date”
  • “A single source for all Hip Hop concert and release information”
  • “An app that doesn’t track artists but tracks all the releases and shows in the genre you’re passionate about”

Fig. 4 – Assumptions and metrics to validate

  1. Assumption: Users wish to receive alerts not based on a specific artist. Instead, they wish to receive alerts on all gigs within a specific genre and within their local area. Possible metrics to validate this assumption: (a) number of alert sign-ups (b) ‘click-through‘ on alerts and (c) conversion on concerts listed (i.e. ticket purchases).
  2. Assumption: Users like having immediate access to a list of Hip Hop releases and gigs on the go using their smartphone. Possible metrics to validate this assumption: (a) number of app downloads (b) cohort analysis, e.g. comparing usage by recent sign-ups to non-recent sign-ups (c) number of retweets and shares of release and concert info and (d) conversion on releases and concerts listed (e.g. ticket purchases and purchases/downloads of releases listed).
  3. Assumption: Artists and promotors wish to interact with the app by providing gig or release info. Possible metrics to validate this assumption: (a) number of artists providing release or concert info to HipHopListings and frequency (b) number of promoters providing release to HipHopListings and frequency and (c) conversion on releases and concerts listed (e.g. ticket purchases and purchases/downloads of releases listed).

Related links for further learning: