I don't think that YC is trying to identify teams that can create the maximum amount of value in 72 hours. They're looking for teams that will create the maximum amount of value over thousands of hours (or more).
It's not at all clear that the former correlates with the latter.
I think you're correct a long-term push is different from a 72 hour scramble but they're only looking to "win" an interview, not a place in a starting class. I think it's reasonable a team could be unsuccessful at filling out an application (which previously required an idea) but still be extremely strong candidates. I hope YC accepts, they don't stand to lose anything (save time) and there's no obligation to accept similar copycat offers in the future. They might also get a problem solved.
Ya, I'd tend to think it's at least worth pg sending them a challenge.
That being said, I don't think that what successful YC applicants are doing should be characterized as "filling out an application." The application just captures their past work in a form. It's the actual past work that matters, not the simple transcription.
I think my larger point is that an awesome 72 hour hack session probably isn't as good of an indicator of future success as a track record of successful medium to long term work in the past.
Why would he limit the number of potential solutions to one? If they wanted to try this it seems like it would better to put the challenge to everyone.
Getting a prototype out in 72 hours is a pretty good start, from there you can validate whether the approach is good, and if it is go into greater resolution about specific parts of the pain point and solve those too in the next iterations
And if the basic business premise is just plain wrong you've you've only lost a few days of dev time rather than months
When building the new Facebook photo viewer, we would ship a redesign to a small percentage of users, look at its metrics impact, and ship another redesign 2-3 days later based on the data. Simply being able to execute on something like this for 72 hours, no matter how blindly you do it, is indicative of a worthwhile skill that many people don't have.
That's a great way to iteratively develop a new design (which, BTW, is quite a nice improvement) for an existing product, but what if you didn't have the existing product? How long did it take to build the all the dependencies of the photo viewer?
While engineering the front-end can be done on a 2-3 day turn-around, I'm fairly certain that the engineering problems of storing and retrieving the petabytes of photos that Facebook users upload took far more than 2-3 days. If it used existing infrastructure then you need to count that engineering time in too.
I'm currently 2 months into developing the core technology for my project, working 1-3 hours in the evening after a 10 hour day at my client. Much of this work is with new technologies and mathematics/algorithms I'm unfamiliar with. In this situation, being unable to iterate on a front-end UI design in 2-3 days has nothing to do with skill.
I disagree. You don't need any skill. Anybody can ship a crappy photo viewer in 72 hours.
But many people can't ship a quality photo viewer even in months.
What heavily distinguished Facebook from Myspace in 2006 when it became open to public was the product culture and quality. It took 3 years to build.
Although I completely understand the point of being able to make quick decisions and execute, the problem is far from solved after spending 72 hours on it. It takes at least weeks to deliver a good solution.
I'm 100% sure you've spent a lot of time with that viewer afterwards until you were confident users will have no problems using it.
It's not at all clear that the former correlates with the latter.