4 ms·

In general, when doing sales, sometimes it is easier to lead with the pain point and then introduce the solution. For example, "Setting up a dev environment ta

by patio11 13y ago

In general, when doing sales, sometimes it is easier to lead with the pain point and then introduce the solution. For example, "Setting up a dev environment takes a day. Sometimes you need one in a minute, like if you're interviewing somebody and need them to demonstrate coding ability on a company laptop. We turn any browser window into a fully-functional dev environment, and it's as ephemeral as the browser window is, so if you close it the company laptop is back in its original state without requiring a sysadmin to wipe it and start over. Next applicant gets a new browser window. Is everyone clear on why a dev environment which doesn't take 2 days to set up or tear down is a useful thing to have? Great! Would you like me to talk about who is willing to pay serious money for this, or do you want to hear what special sauce goes into making this Just Work for your favorite programming stack?" My guess is that even technically inclined people connect to that more than "OK, so we have cloud-based virtualization technology which spins up ephemeral application containers then hooks them to a proprietary in-browser IDE and shell prompt. It's a Frankenstein monster of Docker, Github, Heroku, and a browser-based IDE. No, the IDE's not the primary value add. No, AWS/Heroku is not a direct competitor. No, no, you don't get it, let me try again..." Edit: Incidentally if you just conceptualize the product as pain-first rather than solution-first then you'll phrase your strapline as "Dev environment for any stack on any machine in a minute" rather than "Virtualized insert words increasingly disconnected from anything you care about here."

dully 13y ago
They would cut you off less than half way through that pitch.
- withdavidli 13y ago
  Care to explain why? I thought it was a pretty concise explaination. Do you have personal experience with YC interviews and know that they would for a certain reason?
  - rdl 13y ago
    I think they'd interrupt almost exactly at "Is everyone clear..." with "who uses it now?" or "what stack?" or "have you built this already?" Some other key questions you'd need an answer for, either in some kind of prepared way or in response to a question, are: 1) Why do you want to work on this (this is a great opportunity to talk about personal experience, showing the depth your technical skill and market knowledge indirectly 2) Who else does this today, how to do people do it now ("wipe laptop, spend a few hours setting it up" is one way; a lot of people have nice VMs already pre-populated for this and shared within a company, either local or VDI) 3) Any special risks, regulatory issues, etc. (e.g. if you're a medical startup you should know about HIPAA at least in sufficient detail to talk about it) 4) How do you get people to use it (namedropping current users is good, but your understanding of the market and how it's sold would be good to show) 5) (more key for non-YC investors) general market numbers. The top-down analysis is usually bullshit ('we need 1% of a 10b market..."), but being able to do bottom-up and based on comparables is good for a lot of things. In a 10 minute interview with YC, or a meeting with a consulting client, you don't know what they're going to care the most about. You want to make sure you hit your key points, but also can address their likely concerns in depth -- if you hit your points in 5 minutes and they spend 5 minutes drilling into the sales model, it's good to be able to talk about the sales model for 5 minutes, even if your original plan was to only talk about the sales model for 2 minutes.
- suchow 13y ago
  This pitch is already strong, but is actually improved by the suggestion (inspired by your comment) to cut it to half its previous length: "Setting up a dev environment takes a day. Sometimes you need one in a minute, like if you're interviewing somebody and need them to demonstrate coding ability on a company laptop. We turn any browser window into a fully-functional dev environment, and it's as ephemeral as the browser window is, so if you close it the company laptop is back in its original state without requiring a sysadmin to wipe it..."
  - chc 13y ago
    Well, the second part is just responding to an anticipated first question.
- guymorita 13y ago
  Agreed. You generally don't get off more than a couple sentences before they fire more questions off. They're looking for concise answers.
- nl 13y ago
  Provided you get this far, it's enough: Setting up a dev environment takes a day. Sometimes you need one in a minute, like if you're interviewing somebody and need them to demonstrate coding ability on a company laptop. We turn any browser window into a fully-functional dev environment. Once you are that far you've framed your offering.
- grayclhn 13y ago
  That's not necessarily a bad thing. When they cut you off, respond to their question. The goal of an interview isn't usually to talk interrupted for 10 minutes.
dchuk 13y ago
Or: "Instant development environments, anywhere, anytime...all in the browser"
- netcan 13y ago
  That works well on a sign. Not as well in a conversation.
- edanm 13y ago
  That's not as good. Note that you didn't tell me the problem. If I hear this pitch, I'll think "I set up an envirovnment once, then never touch it again. Plus, I don't develop in the browser. So why do I care about this again?" Note that patio11 specifically gives an example use case within the first sentence, so that I now connect to what this is useful for. And that is a use case I come across. Not sure I'd pay for this, but that's something.
guymorita 13y ago
Good thoughts. Yeah, we led with a high-level description of the product (it went much better during the second interview). When they asked followup questions, we dug into the pain points that we both had as engineers.
grayclhn 13y ago
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. edit: formatting

by patio11 13y ago

dully 13y ago

They would cut you off less than half way through that pitch.

withdavidli 13y ago
Care to explain why? I thought it was a pretty concise explaination. Do you have personal experience with YC interviews and know that they would for a certain reason?
- rdl 13y ago
  I think they'd interrupt almost exactly at "Is everyone clear..." with "who uses it now?" or "what stack?" or "have you built this already?" Some other key questions you'd need an answer for, either in some kind of prepared way or in response to a question, are: 1) Why do you want to work on this (this is a great opportunity to talk about personal experience, showing the depth your technical skill and market knowledge indirectly 2) Who else does this today, how to do people do it now ("wipe laptop, spend a few hours setting it up" is one way; a lot of people have nice VMs already pre-populated for this and shared within a company, either local or VDI) 3) Any special risks, regulatory issues, etc. (e.g. if you're a medical startup you should know about HIPAA at least in sufficient detail to talk about it) 4) How do you get people to use it (namedropping current users is good, but your understanding of the market and how it's sold would be good to show) 5) (more key for non-YC investors) general market numbers. The top-down analysis is usually bullshit ('we need 1% of a 10b market..."), but being able to do bottom-up and based on comparables is good for a lot of things. In a 10 minute interview with YC, or a meeting with a consulting client, you don't know what they're going to care the most about. You want to make sure you hit your key points, but also can address their likely concerns in depth -- if you hit your points in 5 minutes and they spend 5 minutes drilling into the sales model, it's good to be able to talk about the sales model for 5 minutes, even if your original plan was to only talk about the sales model for 2 minutes.
suchow 13y ago
This pitch is already strong, but is actually improved by the suggestion (inspired by your comment) to cut it to half its previous length: "Setting up a dev environment takes a day. Sometimes you need one in a minute, like if you're interviewing somebody and need them to demonstrate coding ability on a company laptop. We turn any browser window into a fully-functional dev environment, and it's as ephemeral as the browser window is, so if you close it the company laptop is back in its original state without requiring a sysadmin to wipe it..."
- chc 13y ago
  Well, the second part is just responding to an anticipated first question.
guymorita 13y ago
Agreed. You generally don't get off more than a couple sentences before they fire more questions off. They're looking for concise answers.
nl 13y ago
Provided you get this far, it's enough: Setting up a dev environment takes a day. Sometimes you need one in a minute, like if you're interviewing somebody and need them to demonstrate coding ability on a company laptop. We turn any browser window into a fully-functional dev environment. Once you are that far you've framed your offering.
grayclhn 13y ago
That's not necessarily a bad thing. When they cut you off, respond to their question. The goal of an interview isn't usually to talk interrupted for 10 minutes.

dchuk 13y ago

Or: "Instant development environments, anywhere, anytime...all in the browser"

netcan 13y ago
That works well on a sign. Not as well in a conversation.
edanm 13y ago
That's not as good. Note that you didn't tell me the problem. If I hear this pitch, I'll think "I set up an envirovnment once, then never touch it again. Plus, I don't develop in the browser. So why do I care about this again?" Note that patio11 specifically gives an example use case within the first sentence, so that I now connect to what this is useful for. And that is a use case I come across. Not sure I'd pay for this, but that's something.

guymorita 13y ago

Good thoughts. Yeah, we led with a high-level description of the product (it went much better during the second interview). When they asked followup questions, we dug into the pain points that we both had as engineers.

grayclhn 13y ago

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. edit: formatting