Amen to that. I'm a programmer and an idea guy (http://ideashower.posterous.com). But what I sorely need is a bad ass bizdev who I can team up with and git r done.
Why that assumption?
Added:
"I can most likely figure out whatever it is that you do with a bit of time and elbow grease."
Have you? Or are you just assuming that as well?
About the second one, I was actually paraphrasing something I heard Max Levchin state at one of his talks years ago. Not sure how much it's worth, given his partnership with Thiel.
Even though we really shouldn't feel this way, a lot of us developer sorts wrestle with the idea that we're the only ones ever really working, specifically in the pure development phase of a project.
Granted, I'm sure everybody feels that way at least once during a given venture. I've forced myself to stop thinking that way, but it seems a fairly human thing to think.
If the technical person does not execute on the MVP, the idea guy mostly out only lost time-to-market. On the other hand, if the technical person delivers, he/she is now "all-in" before the idea person typically contributes meaningful execution-value towards the business.
Its probably most fair to view the first "execution" contributors (technical team building MVP) as the first investors in the business, and therefore should be recognized with more favorable terms (equity distribution). If the idea person can create actual execution value in tandem with the MVP, then an initial 50/50 split is fair.
We generally have simple conditions for that to work: - you have to respect our work, because for us it's an art form and a craft, although we do realize that creating business value comes first. We spend decades refining this craft and want to take pride in every line of code (even though it might not always be possible). - We are concerned that you will treat us like codemonkeys and it will be a PBH-like relationship, where you'll be asking us for status every day, while doing little to no work yourself. You won't be able to code and optimize a large scale distributed system no matter how hard you try. I can most likely figure out whatever it is that you do with a bit of time and elbow grease. However, I'd still much rather work on the product, which is where you come in. - We're also concerned that you will not understand anything about how software works, and will still insist on having a large say in the day-to-day engineering. You'll need to pick one, either you learn fast about how things work and contribute bit by bit, or you let us run the show where you're not the domain expert.