My radeo helps you share songs with your friends and discover new music. We think this project is part of a larger trend – the growing need for curation of music.
1. There are more songs than ever before
Imagine the amount of music that is available across generations and music genres. Some of my friends have over 200GB of music with 20k plus songs (most of which I have never heard and probably never will)
2. Its hard to keep up with new songs
With the rise of digital song making tools and the internet as a media publishing channel, the rate of publishing songs has increased dramatically. Thousands of new songs are released every day. For example, some genres such as Hip Hop have a strong mixtape culture which encourages artists to release several albums a year.
3. Traditional discovery channels aren’t personalized or fast enough
There are only few music radio stations in every given town or city and those stations have limited time slots so they have to stick to small playlists. They also typically have to cater to the “mainstream” in order to serve the broadest audience possible.
Music blogs, iTunes, and online music sites like Pandora and Last.fm help you discover new music but they also can’t keep up.
Lots of good new music slips through the cracks.
4. Your friends can help
Your friends typically know what type of music you like and why. They already share songs with you during parties and car rides. Also, many of them share songs with you via Facebook and Twitter.
Even when you don’t like the same artists or types of music, your friends’ tastes influence you and your tastes influence them. The context that you give to the music – why you like it and how it makes you feel - make a world of difference
These ideas are inspired by an article - "Can 'Curation' Save Media?" by Steve Rosenbaum, a talk by my good friend Greg Hochmuth on Design Patterns for Smarter Crowds (video | PPT) and a fun video made a couple years ago by a Professor for his media class – “The Machine is Us/ing Us”
Thursday, January 14
Monday, January 11
Incorporating user feedback in an early prototype
We use user feedback to figure out what to do next.
The type of feedback you get depends on who you ask and where you ask for the feedback. Each type of feedback is important and should be weighted equally for prioritizing features
Observation
Watching people use your application or a particular feature for the first time helps you find user interface bugs and instances where the mental model that people have of your application differs from the designer's mental model (e.g., where users expect buttons to be located and what they expect those buttons to do)
Email
Email comments are typically a stream of consciousness -- what people say is almost always true and honest but not always literally what they mean. For example, when someone says, "I want video" there are many different ways to apply this feedback. Once you hear similar feedback more than once, you need to increase the priority of the feature and experiment until you stop hearing the feedback. It helps to re-read the comments every couple of weeks because they yield different insights when you are further along in the product and you can cross things off the list :-)
Phone
Phone conversations tend to start directed and then transition to hypotheticals/options. People wait for you to ask them a question and then respond with their gut feeling. "What did you think of the new rankings? Would you prefer fun/creative badges or more straightforward?" You can also get insight from people's intonation (e.g., are people excited about a feature or reluctant to discuss it because they don't want to hurt your feelings?)
Off hand conversations (coffee shops and Gchat)
These can be baselining -- someone mentioning a powerful concept or technical strategy that you may have overlooked entirely (e.g., "Did you know that Google App Engine supports the fan out problem out of the box? You should use the Adobe AIR for your desktop application"). These conversations can also be visionary statements that just make sense as a future goal but would never to occur to you as a designer because you are too deep in your current version (e.g., "You should make this real time")
Stats
Recording feature level stats (e.g., searches, plays) help to validate whether people are using a feature and how often. You have to be careful to record and analyze features that you can act on rather than vanity metrics which don't tell you much (e.g., page views)
Surveys,A/B testing and other mass data collection techniques only start to make sense when you have a large batch of users and you are very clear on what you are testing. In an early prototype, you have a vision but you end up throwing a bunch of features at the wall and hoping that something sticks
The type of feedback you get depends on who you ask and where you ask for the feedback. Each type of feedback is important and should be weighted equally for prioritizing features
Observation
Watching people use your application or a particular feature for the first time helps you find user interface bugs and instances where the mental model that people have of your application differs from the designer's mental model (e.g., where users expect buttons to be located and what they expect those buttons to do)
Email comments are typically a stream of consciousness -- what people say is almost always true and honest but not always literally what they mean. For example, when someone says, "I want video" there are many different ways to apply this feedback. Once you hear similar feedback more than once, you need to increase the priority of the feature and experiment until you stop hearing the feedback. It helps to re-read the comments every couple of weeks because they yield different insights when you are further along in the product and you can cross things off the list :-)
Phone
Phone conversations tend to start directed and then transition to hypotheticals/options. People wait for you to ask them a question and then respond with their gut feeling. "What did you think of the new rankings? Would you prefer fun/creative badges or more straightforward?" You can also get insight from people's intonation (e.g., are people excited about a feature or reluctant to discuss it because they don't want to hurt your feelings?)
Off hand conversations (coffee shops and Gchat)
These can be baselining -- someone mentioning a powerful concept or technical strategy that you may have overlooked entirely (e.g., "Did you know that Google App Engine supports the fan out problem out of the box? You should use the Adobe AIR for your desktop application"). These conversations can also be visionary statements that just make sense as a future goal but would never to occur to you as a designer because you are too deep in your current version (e.g., "You should make this real time")
Stats
Recording feature level stats (e.g., searches, plays) help to validate whether people are using a feature and how often. You have to be careful to record and analyze features that you can act on rather than vanity metrics which don't tell you much (e.g., page views)
Surveys,A/B testing and other mass data collection techniques only start to make sense when you have a large batch of users and you are very clear on what you are testing. In an early prototype, you have a vision but you end up throwing a bunch of features at the wall and hoping that something sticks
Wednesday, January 6
Why start My radeo?
It's March 2009, my buddy, Q, and I are walking from our hotel to the SXSW conference in Austin and throwing around different product ideas just for fun.
Q drafted the essay and designed cool mockups (share, discover) while I coded up a prototype (screenshot). It was a proof of concept that YouTube could be used as a streaming music library. The prototype included three of my favorite songs. John Coltrane's My favorite things , John Mayer's I think that she knows guitar cover, and Jay-Z's Can I live
Our submission was rejected by Y Combinator -- neither of us are programmers, the prototype was very limited (<100 lines of code), competition for music products (e.g., Pandora, Last.fm) is substantial, and the online music business is a graveyard for startups because of music licensing costs. In spite of all of this, we said "Build it anyway."
The time was right. A product like this could never have existed without a few key predecessors and underlying technologies
My radeo is a stable service that has a few passionate users (who we are extremely grateful for) who login every couple of days to share and discover new music with their friends. My radeo, today, is the result of a tremendous amount of feedback, advice, suggestions and encouragement from friends. The online music industry is still just as treacherous as when we started, but there is still opportunity afoot.
Special thanks to Adanna, Albert, Alper, Amanda, Amos, Arnita, Ayush, Brian, Camille, Chika, Chinny, Cynthia, Dan, Deen, Eden, Ekene, Eki, Fauna, George, Grant, Greg, Ike, Ikezi, Jamie, Jasmine, Jason, Jessica, Joissa, Julia, Julie, Linus, Liz, Matt, Mike, Min, Min Li, Morin, Nick, Nicole, Nwando, Patrick, Payam, Prashanth, Rami, Ricky, Rishan, Ronojoy, Russ, Samantha, Sanjay, Sinan, Sydney, Teff, Theresa, Thomas
Q: "Wouldn't it be cool to have something that helps you share songs with friends?"
Me: "Agreed -- everyone already shares, but make it faster and easier. Go beyond playing songs for your friends in the car, sending email links or posting music videos on Facebook. Someone's probably built it already, but lets hold on to this idea"Fast forward a few weeks later, I asked Q if he'd be interested in submitting our idea to to the the Y Combinator startup competition, which would give us some funding and a community of advisers to develop the idea. Q was in. Even if we didn't get in, it could be fun to go through the process and learn from it.
Q drafted the essay and designed cool mockups (share, discover) while I coded up a prototype (screenshot). It was a proof of concept that YouTube could be used as a streaming music library. The prototype included three of my favorite songs. John Coltrane's My favorite things , John Mayer's I think that she knows guitar cover, and Jay-Z's Can I live
Our submission was rejected by Y Combinator -- neither of us are programmers, the prototype was very limited (<100 lines of code), competition for music products (e.g., Pandora, Last.fm) is substantial, and the online music business is a graveyard for startups because of music licensing costs. In spite of all of this, we said "Build it anyway."
The time was right. A product like this could never have existed without a few key predecessors and underlying technologies
- YouTube - The largest and freshest music collection ever (e.g., unreleased tracks, live versions, covers, remixes)
- Facebook Connect - An automatic social graph and content from your News Feed with no account signup. A built in distribution mechanism for sharing with your friends
- Google App Engine - The ability to experiment and scale the service without any infrastructure cost or maintenance overhead
My radeo is a stable service that has a few passionate users (who we are extremely grateful for) who login every couple of days to share and discover new music with their friends. My radeo, today, is the result of a tremendous amount of feedback, advice, suggestions and encouragement from friends. The online music industry is still just as treacherous as when we started, but there is still opportunity afoot.
Special thanks to Adanna, Albert, Alper, Amanda, Amos, Arnita, Ayush, Brian, Camille, Chika, Chinny, Cynthia, Dan, Deen, Eden, Ekene, Eki, Fauna, George, Grant, Greg, Ike, Ikezi, Jamie, Jasmine, Jason, Jessica, Joissa, Julia, Julie, Linus, Liz, Matt, Mike, Min, Min Li, Morin, Nick, Nicole, Nwando, Patrick, Payam, Prashanth, Rami, Ricky, Rishan, Ronojoy, Russ, Samantha, Sanjay, Sinan, Sydney, Teff, Theresa, Thomas
Subscribe to:
Posts (Atom)