5 ms·

I don't understand why all those product and marketing people don't form programmerless teams and cheaply outsource their initial programming needs. This won't

I don't understand why all those product and marketing people don't form programmerless teams and cheaply outsource their initial programming needs. This won't work for immensely complex ideas, and it won't produce award-winning code, but it'll be good enough to create a minimum viable product and see if it has traction. If it does get any traction, THEN they can worry about finding a programming partner, and the question of what they bring to the team will be clear -- a business that has already shown traction.

_pius 16y ago
I don't understand why all those product and marketing people don't form programmerless teams and cheaply outsource their initial programming needs. Because most of them are too broke to do that. Moreover, when they do have a little bit of money, they're likely to get taken to the cleaners because of their inability to evaluate and manage a technical team, especially a remote one.
nkohari 16y ago
There's all sorts of problems with this. Usually startups don't have enough money to hire good developers, so they try to pay people in equity. Most developers who aren't personally invested in the idea or the founding team aren't going to split equity with non-technical people unless everyone is clearly bringing something to the table (marketing, fundraising, etc). Unless there's a clearly even split of labor in the early days of a startup, the technical members of a hybrid team are taking the majority of the risk. To get the company on its feet, they'll need to sink a correspondingly large amount of time into developing the product versus their non-technical cofounders. Software is very expensive to build. Let's say that to take an MVP from zero to market will take only one man-month of effort (160 hours) -- which, when you consider billing systems, etc. is likely a low estimate. If you paid a good consultant $100/hour to build it for you, that's about $16,000. Many startups don't have this kind of cash sitting around. So let's say you outsource the development to offshore developers to save some money. Let's say you start to get some traction, and you want to bring on a technical co-founder. It's going to be a really hard sell to get a developer to join your project after your product is already poorly-written. Developers hate maintenance. If a group of non-technical people approached me with a post-launch MVP, I'd assume their code was bad and run for the hills. (At a minimum I would ask to see it before agreeing to anything, which would likely just solidify my viewpoint.) If you're willing to throw out the MVP code and have the new cofounder rewrite it, that might be something you could convince a developer to join up for -- but be prepared to "lose" the money for the initial MVP development. It's not enough to bring a "business that already has traction" to the group. Maybe if you were selling me the MVP, that might be interesting, but if you were looking for a partnership, I'd want to know what you'd spend your time doing.
- mikealle233 16y ago
  "Software is very expensive to build." Not necessarily. Offshore outsourcing of programming is quite cheap. The question is whether your MVP is so complex it warrants a $100/hour local programmer to handle that complexity. In many cases, it's not complex enough to warrant it, and paying $100/hour to a developer is inconsistent with building a MVP, because you're hiring a bells and whistles developer better suited to a large corporation with millions in profit at stake if the developer screws up. But, sure, if you're building something complex, you're shooting yourself in the foot by cheaply outsourcing. "If you're willing to throw out the MVP code and have the new cofounder rewrite it, that might be something you could convince a developer to join up for -- but be prepared to "lose" the money for the initial MVP development." That's exactly what I'm proposing. Who cares if you "lose" the money for the MVP development? If the MVP has shown traction, you haven't "lost" the money. You've paid cheaply for a traction proving MVP. That is money well spent, and now it's time to move onto the next level. In any event, the idea that a developer would turn down an opportunity to be a founding equity member of a startup, which has a product that's already proven traction, because the MVP contained messy code is absurd. I'm not saying some developers wouldn't think that...I'm saying such developers are irrational. "...but if you were looking for a partnership, I'd want to know what you'd spend your time doing." Your attitude puzzles me. You have two hypothetical choices, if you were offered such a partnership. 1) Say no and continue to build software with a 90% chance of failure. 2) Say yes and build software with a 90% chance of success. Even if the non technical cofounders sit on their asses and do absolutely nothing while you code all day, you'd be sitting on 33% equity in an already successful startup, when they took all the cash risk up front to prove the thing works. All you've got to do now is code and build on existing success. And you think that's an offer that you should scoff at? In reality, the non technical cofounders wouldn't sit around and do nothing. This would be a group of people who've already proven they can go from zero to traction proving MVP on their own, and surely they'd continue to work in non-technical ways to make the product a success. I don't understand why you'd be so skeptical about what they'd do with their time, unless you think their success was dumb luck.
  - nkohari 16y ago
    I think your idea of throwing away a prototype is a great one. We essentially did that when we launched our startup, although it was just a major refactoring rather than a complete ditch-and-rebuild effort. Beyond that, oh man... Even if the non technical cofounders sit on their asses and do absolutely nothing while you code all day, you'd be sitting on 33% equity in an already successful startup, when they took all the cash risk up front to prove the thing works. It's this mindset that makes a lot of would-be technical co-founders see non-technical people as a threat. I don't care if you're a technical or non-technical co-founder, if you're not going to pull your weight somehow, I don't want to be in business with you. Also, to be honest, the "cash risk" is essentially irrelevant to me because I have the skill set to build and validate the MVP myself. There's also a large enough market for my skills that I could sell consulting services (yes, at north of $100/hour) to cover any financial costs to test an MVP. All you're really bringing to the table is the first 3 steps, and asking your technical co-founder(s) to handle the next 617 or so. It's better than just a "big idea", but not by as much as you're thinking. All you've got to do now is code and build on existing success. And you think that's an offer that you should scoff at? Oh, is that all? Here's a hypothetical scenario: let's say Toyota builds a concept car and takes it to an auto show to demonstrate it to customers. They get fantastic feedback and decide to take the car to market. So, you'd be willing to take the concept car design and find a way to manufacture it in an efficient and cost-effective manner? I mean once the customer validation is done, all that "engineering" stuff must be simple, right? Metaphor aside, an MVP is vastly different than a truly sustainable product. If it's a true MVP, there will be a myriad of unsolved problems (scalability, maintainability, etc.) that only a skilled engineer can solve. Not to mention, what happens when the market inevitably shifts, rendering some or all of your customer validation effort useless? The most important aspect of any startup is the dynamic of the team. The most important part of that (in my opinion) is to have clearly delineated roles, roughly equivalent in workload and importance. The best teams have members with complementary and supplementary skills, and everyone respects the skills and contributions of everyone else. My attitude puzzles you because you're assuming that 90% of the risk comes before the MVP. Launch is very different than break-even, which is very different than sustainability or a liquidity event. I'm a huge believer in the lean startup (I launched and sold one myself) but you have to recognize that the initial customer validation is just the first step down a very long and arduous road. It's hard enough to walk that road in the first place, let alone if I have to carry you on my back.
brianshaffer 16y ago
This falls through when the business guys try to build out a spec - especially to be used by outsourced developers. They use "human logic" and the bridge between the database and user experience breaks. Spending 10 hours, learning how software thinks, will make these types of teams way more practical and effective.

_pius 16y ago

I don't understand why all those product and marketing people don't form programmerless teams and cheaply outsource their initial programming needs. Because most of them are too broke to do that. Moreover, when they do have a little bit of money, they're likely to get taken to the cleaners because of their inability to evaluate and manage a technical team, especially a remote one.

nkohari 16y ago

There's all sorts of problems with this. Usually startups don't have enough money to hire good developers, so they try to pay people in equity. Most developers who aren't personally invested in the idea or the founding team aren't going to split equity with non-technical people unless everyone is clearly bringing something to the table (marketing, fundraising, etc). Unless there's a clearly even split of labor in the early days of a startup, the technical members of a hybrid team are taking the majority of the risk. To get the company on its feet, they'll need to sink a correspondingly large amount of time into developing the product versus their non-technical cofounders. Software is very expensive to build. Let's say that to take an MVP from zero to market will take only one man-month of effort (160 hours) -- which, when you consider billing systems, etc. is likely a low estimate. If you paid a good consultant $100/hour to build it for you, that's about $16,000. Many startups don't have this kind of cash sitting around. So let's say you outsource the development to offshore developers to save some money. Let's say you start to get some traction, and you want to bring on a technical co-founder. It's going to be a really hard sell to get a developer to join your project after your product is already poorly-written. Developers hate maintenance. If a group of non-technical people approached me with a post-launch MVP, I'd assume their code was bad and run for the hills. (At a minimum I would ask to see it before agreeing to anything, which would likely just solidify my viewpoint.) If you're willing to throw out the MVP code and have the new cofounder rewrite it, that might be something you could convince a developer to join up for -- but be prepared to "lose" the money for the initial MVP development. It's not enough to bring a "business that already has traction" to the group. Maybe if you were selling me the MVP, that might be interesting, but if you were looking for a partnership, I'd want to know what you'd spend your time doing.

mikealle233 16y ago
"Software is very expensive to build." Not necessarily. Offshore outsourcing of programming is quite cheap. The question is whether your MVP is so complex it warrants a $100/hour local programmer to handle that complexity. In many cases, it's not complex enough to warrant it, and paying $100/hour to a developer is inconsistent with building a MVP, because you're hiring a bells and whistles developer better suited to a large corporation with millions in profit at stake if the developer screws up. But, sure, if you're building something complex, you're shooting yourself in the foot by cheaply outsourcing. "If you're willing to throw out the MVP code and have the new cofounder rewrite it, that might be something you could convince a developer to join up for -- but be prepared to "lose" the money for the initial MVP development." That's exactly what I'm proposing. Who cares if you "lose" the money for the MVP development? If the MVP has shown traction, you haven't "lost" the money. You've paid cheaply for a traction proving MVP. That is money well spent, and now it's time to move onto the next level. In any event, the idea that a developer would turn down an opportunity to be a founding equity member of a startup, which has a product that's already proven traction, because the MVP contained messy code is absurd. I'm not saying some developers wouldn't think that...I'm saying such developers are irrational. "...but if you were looking for a partnership, I'd want to know what you'd spend your time doing." Your attitude puzzles me. You have two hypothetical choices, if you were offered such a partnership. 1) Say no and continue to build software with a 90% chance of failure. 2) Say yes and build software with a 90% chance of success. Even if the non technical cofounders sit on their asses and do absolutely nothing while you code all day, you'd be sitting on 33% equity in an already successful startup, when they took all the cash risk up front to prove the thing works. All you've got to do now is code and build on existing success. And you think that's an offer that you should scoff at? In reality, the non technical cofounders wouldn't sit around and do nothing. This would be a group of people who've already proven they can go from zero to traction proving MVP on their own, and surely they'd continue to work in non-technical ways to make the product a success. I don't understand why you'd be so skeptical about what they'd do with their time, unless you think their success was dumb luck.
- nkohari 16y ago
  I think your idea of throwing away a prototype is a great one. We essentially did that when we launched our startup, although it was just a major refactoring rather than a complete ditch-and-rebuild effort. Beyond that, oh man... Even if the non technical cofounders sit on their asses and do absolutely nothing while you code all day, you'd be sitting on 33% equity in an already successful startup, when they took all the cash risk up front to prove the thing works. It's this mindset that makes a lot of would-be technical co-founders see non-technical people as a threat. I don't care if you're a technical or non-technical co-founder, if you're not going to pull your weight somehow, I don't want to be in business with you. Also, to be honest, the "cash risk" is essentially irrelevant to me because I have the skill set to build and validate the MVP myself. There's also a large enough market for my skills that I could sell consulting services (yes, at north of $100/hour) to cover any financial costs to test an MVP. All you're really bringing to the table is the first 3 steps, and asking your technical co-founder(s) to handle the next 617 or so. It's better than just a "big idea", but not by as much as you're thinking. All you've got to do now is code and build on existing success. And you think that's an offer that you should scoff at? Oh, is that all? Here's a hypothetical scenario: let's say Toyota builds a concept car and takes it to an auto show to demonstrate it to customers. They get fantastic feedback and decide to take the car to market. So, you'd be willing to take the concept car design and find a way to manufacture it in an efficient and cost-effective manner? I mean once the customer validation is done, all that "engineering" stuff must be simple, right? Metaphor aside, an MVP is vastly different than a truly sustainable product. If it's a true MVP, there will be a myriad of unsolved problems (scalability, maintainability, etc.) that only a skilled engineer can solve. Not to mention, what happens when the market inevitably shifts, rendering some or all of your customer validation effort useless? The most important aspect of any startup is the dynamic of the team. The most important part of that (in my opinion) is to have clearly delineated roles, roughly equivalent in workload and importance. The best teams have members with complementary and supplementary skills, and everyone respects the skills and contributions of everyone else. My attitude puzzles you because you're assuming that 90% of the risk comes before the MVP. Launch is very different than break-even, which is very different than sustainability or a liquidity event. I'm a huge believer in the lean startup (I launched and sold one myself) but you have to recognize that the initial customer validation is just the first step down a very long and arduous road. It's hard enough to walk that road in the first place, let alone if I have to carry you on my back.

brianshaffer 16y ago

This falls through when the business guys try to build out a spec - especially to be used by outsourced developers. They use "human logic" and the bridge between the database and user experience breaks. Spending 10 hours, learning how software thinks, will make these types of teams way more practical and effective.