We hear that good ideas often look like bad ideas, but bad ideas look like bad ideas too. This is why, as startup founders, we're always told the best way to validate an idea as "good" is to quickly build an MVP, launch, and iterate; and don't forget about market sizing. Now in 90% of cases, that works. It's perfect for web apps, a little less so for iOS (because of the 7 day turn-around) and probably the wrong approach for developer libraries.
Recently, my co-founder and I landed on an idea that isn't inherently good, nor is it inherently bad. The best way to describe it is as a GitHub for music, specifically for mobile music apps. The problem is, for users to find value, we need to convince as many developers as possible to integrate us. Ultimately, this means we need to have a developer SDK for iOS apps. As such, this idea is in the 10%, where lean startup methodology doesn't work (at least to the best of our knowledge).
Sure we can fake a few things: the developer documentation, UI made in Photoshop, etc. And even though we can cut the developer integration and use the apps we've created in the past as a testing ground, building the base technology isn't exactly a two week sprint.
So how do we validate it? We decided the best approach was not to write a single line of code for a month. Talk to as many users and developers as possible, and figure out exactly where we are adding value and how to communicate it.
We began by asking friends and mentors, who aren't our target market... They ended up giving us anecdotal evidence to justify saying "no one collaborates, or even creates music on mobile". But when we talked to our users and developers, this evidence clearly didn't generalize. As a result, we looked up the numbers. Turns out, over 150 million people today create music on mobile, a little more than anecdotal evidence would suggest.
Okay, we've established that there's a market for creating music on mobile, but will people use a "GitHub for music"? This is where people are most skeptical, and rightly so. I mean, how many of the 150m will end up collaborating, if any. It turns out that number is (relatively) small, in the few millions actually. With collaboration currently conducted via email, duplicating files, and trying to consolidate threads of feedback - but at least we know people are collaborating.
Now a few million may seem like a large number, but considering you can never get 100% market share, the company we'd soon build could only grow so big. This isn't something we're interested it in. So why didn't we just pack our bags and go home? We realized that what we're building has added value to single musicians as well, not just collaborators. This allows us to capture a larger set of the market.
But could we answer the hardest question of all, will people pay for it? This is something where we have absolutely no clue. We can look at how much musicians are spending today, find projections for the next 3 years, and convince ourselves they will. At the end of the day, if they don't find inherent value, then they won't pay. If they do find inherent value, then how much will they pay? These are questions we can "answer" for investors/whomever using market research and analysis - but at the end of the day, it's educated bullshit.
But what happens if our educated bullshit was completely wrong? We built something users use, but don't want to pay for. I mean, would you really pay for Facebook or Twitter? The way we've "solved" this issue was finding an alternative model that worked with my platform, ads. Ads may seem like the go to solution for models. However, I'd argue that, with songs publicly available to be heard on our platform, creating a music streaming service supported by ads is effective model.
At the end of the day, is this still a good idea or a bad idea? We honestly don't know. We don't feel that it has all the "backing" of a good idea, but neither does it have the red flags that would dismiss it as a bad idea. Without launching and testing it amongst untamed users, we can only create logical assumptions, talk to as many users and developers as possible, and move forwards.