I think it would be better still to give a one-sentence description of what the product does first:
interview starts: “So you’re building some automation for Github?” asked Paul
response: Sort of. Our product spins up new development environments in the browser really fast, about 10 seconds right now. (optional second sentence: our MVP is for projects hosted on GitHub, but it doesn't have to be and we'll probably want to let companies host their own code in the future.)
Then go into the pain points: "One reason why we're working on this is that sometimes you need a dev environment in a minute, not a day like it usually takes, like if you're interviewing somebody..."
You can probably make it more concise by switching the pain points from hypothetical to actual examples: "We're using the project for..." or "we'd like to use this project at work because..." or even better "We've talked to Parse, Firebase, Mongo, Stripe and Mixpanel about this, and they want to use it for..."
The interview sounds a lot like first-stage interviews for academic jobs (in econ, at least), and it's usually not that helpful to approach those interviews as sales pitches or boxing matches. They work like 10 minute presentations that can be derailed by the audience at any time, even midsentence. Even in the middle of the first sentence. So it might help to prepare for the interview by preparing to give an extemporaneous 10 minute presentation without any visual aids.
The logic (in academic interviews and probably for YC interviews too) is that you believe you have an exceptional product. You don't have to "sell" it and you don't have to convince anyone of anything that's not true. You only have to explain what you have so that the interviewers understand it and then they'll see how awesome it is. (I'm not saying that everyone's product is awesome, but you'd better believe that yours is.)
Incidentally, I don't think that the right answer is "Github/Docker/Digital Ocean is not a potential competitor." I prefer, "maybe they could take our business, but they won't because our approach relies on x/y/z that we are uniquely able to provide." x/y/z can be technical skills, domain knowledge, a specialized proprietary encryption algorithm, ruthless and bloodthirsty work ethic, etc. Again, not every founder can provide some unique value to their product, but you'd better provide one to yours.
* "You" in this comment refers to the reader, not patio11.
interview starts: “So you’re building some automation for Github?” asked Paul
response: Sort of. Our product spins up new development environments in the browser really fast, about 10 seconds right now. (optional second sentence: our MVP is for projects hosted on GitHub, but it doesn't have to be and we'll probably want to let companies host their own code in the future.)
Then go into the pain points: "One reason why we're working on this is that sometimes you need a dev environment in a minute, not a day like it usually takes, like if you're interviewing somebody..."
You can probably make it more concise by switching the pain points from hypothetical to actual examples: "We're using the project for..." or "we'd like to use this project at work because..." or even better "We've talked to Parse, Firebase, Mongo, Stripe and Mixpanel about this, and they want to use it for..."
The interview sounds a lot like first-stage interviews for academic jobs (in econ, at least), and it's usually not that helpful to approach those interviews as sales pitches or boxing matches. They work like 10 minute presentations that can be derailed by the audience at any time, even midsentence. Even in the middle of the first sentence. So it might help to prepare for the interview by preparing to give an extemporaneous 10 minute presentation without any visual aids.
The logic (in academic interviews and probably for YC interviews too) is that you believe you have an exceptional product. You don't have to "sell" it and you don't have to convince anyone of anything that's not true. You only have to explain what you have so that the interviewers understand it and then they'll see how awesome it is. (I'm not saying that everyone's product is awesome, but you'd better believe that yours is.)
Incidentally, I don't think that the right answer is "Github/Docker/Digital Ocean is not a potential competitor." I prefer, "maybe they could take our business, but they won't because our approach relies on x/y/z that we are uniquely able to provide." x/y/z can be technical skills, domain knowledge, a specialized proprietary encryption algorithm, ruthless and bloodthirsty work ethic, etc. Again, not every founder can provide some unique value to their product, but you'd better provide one to yours.
* "You" in this comment refers to the reader, not patio11.
edit: formatting