4 ms·

The best way to get involved with Local Hackathons and Startup Events is to get involved with the Local Startup Ecosystem. The last time I was in The Valley, I

The best way to get involved with Local Hackathons and Startup Events is to get involved with the Local Startup Ecosystem. The last time I was in The Valley, I found Meetup.Com to be an awesome source of Startup Related Events and Functions. That might be a good place to start (filter by technology or language). You'll also find that some of the more popular Hackathons or Non-Profits have their own Website, such as the TechCrunch Hackathon (http://techcrunch.com/events/ http://techcrunch.com/events/), the Launch Hackathon (http://hackathon.launch.co/ http://hackathon.launch.co/), or Startup Weekend (http://www.startupweekend.org http://www.startupweekend.org). These are just a few examples, I'm sure there are many more across the World that I don't even know about. Regarding product methodologies, what you describe sounds somewhat similar to Eric Ries' Lean Startup. I hope it's not offensive to make a comparison, but I think it's good food for thought. The concept of involving customer feedback into the product development process (or any process) is extremely powerful. But I wouldn't doubt that there are different ways to apply that Approach. The Lean Startup is based on a Build, Measure, Learn methodology. What you describe sounds somewhat like a variation; maybe closer to Measure, Learn, Build. Expanding on that, other variations could relate to the number of cycles you consider and the possibility that they can be in different orders to achieve different results. For example; Build, Measure Learn might be a great process for an existing Team to develop a Product based on an existing idea. Another example; Measure, Learn, Build (cycle 1) and then Build, Measure, Learn (cycle 2) might be a good 2 cycle process for an existing Team to develop a Product that does not initially have an idea or direction. And yet another example; Build, Measure Learn, (cycle 1) and then Build, Measure, Learn again might be a good 2 cycle process for Building a Team to develop a Product based on a validated idea. These are all hypothetical of course, but it's interesting to consider. I'm sure there are many different possibilities based on how you apply the concepts. In any event, I wish you well in validating your methodology!

SVPMguy 13y ago
Thanks for the leads. I've read up a bunch on hackathons. I'm not sure what my role would be at one to be honest... I don't have a team, I'm not an Engineer and it seems like there are two groups who benefit: coders hoping to win a beauty contest in front of investors and investors who see it as a cheap way to find creative labor. Am I wrong? What would I do if I just showed up at one of these? The Launch Festival looks quite interesting though... It's not till Feb, but I'll buy a ticket for sure. The Lean Startup is a good book -- I read it last night to re-familiarize myself with the ideas. MVP, "getting outside the building", innovation accounting and Measure-Learn-Build are extremely useful concepts. As you suggested, some of my thoughts revolve around the ideal order of the steps. But beyond that, I believe there's more accurately a crucial missing step up front. I have no doubt that he wants you to measure stuff, refine and then re-measure to see if there's better alignment, until you've developed a solid 'customer archetype'. But it seems that you're sort of tainting the initial conversation with prospects by forcing it down the path of discussing what's right and wrong with your MVP. How likely are you to throw it all out and start from scratch if your MVP just isn't cutting it? You have to have serious fortitude to do that, especially if your MVP took many weeks or months to develop. And aren't most prospects just going to think 'inside the box' once you've placed a potential solution in front of them? So I suspect that what often happens when employing the Build-Measure-Learn paradigm is that either you end up with incremental improvements to existing solutions or eventual success ends up depending on how good you were at really nailing that initial MVP... and that could require Steve Jobs-like intuition or plain luck. What if you could put a reliable methodology around those crucial, very early conversations with prospects that would lead you to build an MVP that meets their basic needs up front without any kind of super-human foresight or luck and without having to pivot over and over (which I contend is mentally a very hard thing for most people to do)? To go with the Lean Startup nomenclature, my idea could sort of be summed up as Discover-Build-Measure-Learn, at which point you'd cycle through Build-Measure-Learn after the first iteration.

SVPMguy 13y ago

Thanks for the leads. I've read up a bunch on hackathons. I'm not sure what my role would be at one to be honest... I don't have a team, I'm not an Engineer and it seems like there are two groups who benefit: coders hoping to win a beauty contest in front of investors and investors who see it as a cheap way to find creative labor. Am I wrong? What would I do if I just showed up at one of these? The Launch Festival looks quite interesting though... It's not till Feb, but I'll buy a ticket for sure. The Lean Startup is a good book -- I read it last night to re-familiarize myself with the ideas. MVP, "getting outside the building", innovation accounting and Measure-Learn-Build are extremely useful concepts. As you suggested, some of my thoughts revolve around the ideal order of the steps. But beyond that, I believe there's more accurately a crucial missing step up front. I have no doubt that he wants you to measure stuff, refine and then re-measure to see if there's better alignment, until you've developed a solid 'customer archetype'. But it seems that you're sort of tainting the initial conversation with prospects by forcing it down the path of discussing what's right and wrong with your MVP. How likely are you to throw it all out and start from scratch if your MVP just isn't cutting it? You have to have serious fortitude to do that, especially if your MVP took many weeks or months to develop. And aren't most prospects just going to think 'inside the box' once you've placed a potential solution in front of them? So I suspect that what often happens when employing the Build-Measure-Learn paradigm is that either you end up with incremental improvements to existing solutions or eventual success ends up depending on how good you were at really nailing that initial MVP... and that could require Steve Jobs-like intuition or plain luck. What if you could put a reliable methodology around those crucial, very early conversations with prospects that would lead you to build an MVP that meets their basic needs up front without any kind of super-human foresight or luck and without having to pivot over and over (which I contend is mentally a very hard thing for most people to do)? To go with the Lean Startup nomenclature, my idea could sort of be summed up as Discover-Build-Measure-Learn, at which point you'd cycle through Build-Measure-Learn after the first iteration.