[BadassFractal]

To the biz guys here who might think that we're unicorns, I'd like to point out that there are definitely people out there who are very technical and would love to co-found with someone more business-oriented.

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.

[itmag]

To the biz guys here who might think that we're unicorns, I'd like to point out that there are definitely people out there who are very technical and would love to co-found with someone more business-oriented.

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.

[larrys]

"while doing little to no work yourself. "

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?

[BadassFractal]

Regarding the first question, I have been burned before by non-technical co-founders who turned the project into their own little "I want to learn how to program" experiment, while spending zero to no time actually hustling, talking to people, getting feedback, finding more early adopters, engineering requirements and so on. I have learned to be a better judge of character through that experience, and am much pickier now.

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.

[bendingoutward]

I have another possible explanation for that first question, and I am making the assumption that I'm not the only person that has had to work on not feeling this way:

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.

[ryanhuff]

Already said (far) below in this post, but the work on the part of the technical team to produce an MVP is often front-loaded, which means that the technical person (team) assumes most of the initial execution risk. Equity distribution should recognize the assumed risk.

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.

[jasonglaspey]

If you have an "idea" person, you're screwed. You need a product person. I don't know how to code, but I can help with wireframes, customer interviews, feedback, marketing plans, pricing strategies, partnership opportunities, etc. The very idea of an "Idea Person" needs to go away and people need to be accountable to providing value. And you don't need an MVP for the Product Person to start working. And I use that term very loosely. Because if they aren't building the product, they should be supporting/defining/selling it.

[rbarooah]

Why shouldn't we respect each other's work simply because we're people, and we suffer when we try to cooperate with those who don't respect us?

Doesn't this go both ways?