Things I brought to our startup:

- convertible note on great terms

- crappy-but-functioning prototype

- fully-designed HTML wireframes for prototype v2

- meaty customer pipeline including 2 customers pre-sold

- extensive network of sales contacts in our space

- extensive network of press contacts in our space

- 2 years experience running a site where I used and helped sell the early version of our product

I feel I bring a lot of value to our company. And I am very intent on proving that I will continue to do so. I try to justify my involvement every day. So when I talk to technical friends of mine thinking about working with someone non-technical, I tell them about the stuff I do and that they need to ask these "biz-dev" guys if they can bring stuff like that to the table.

When someone's awesome, their value-add should be clear and obvious. If you find yourself talking yourself into someone, that's a bad sign.

To answer your question, not all non-programmers are equal: much like not all programmers are equal. The types you see "seeking a technical cofounder" are the equivalent of 1990s "HTML programmers". On the other hand, a seasoned startup veteran who may not be actively coding (but, most probably holds a BS or MS in CS or EE) but has a track record of raising funding, selling the product, effectively handling business operations and the like has a lot to contribute (if you're at a stage where you need assistance in anything beyond product development: when this stage comes depends heavily on the kind of product you're building), even if his role won't be development.

If you are looking at the enterprise space strlen's advice is sound. What you really need is an adviser with connections in your target industry to mae connections and open doors.for you. (Get legal advice on how to structure the relationship, so you dont get blindsided by a submarine co-founder later on.) Find the industry associations; attend their conferences; read their journals/rags. At the conferences you can find customers you can work with.

Design and mockups are helpful. If you have an idea for a web app, create mockups, diagrams, and flow-charts. Explain what every link and button does on the webpage. How it should behave, what should be happening behind the scenes, etc... Balsamiq Mockups, Photoshop, and Visio/OmniGraffle are your friend. The more detailed the better, so long as it's intuitive and easy to follow along.

If it's an iOS app, build the GUI. There are a lot of apps that help you mockup iOS stuff. Same goes for Mac OS X and Windows programs.

And of course, you should be able/willing-to-learn how to do business stuff. Finance, accounting, legal work, incorporating, all of the overhead that's part of running a company. Get deals with vendors, payment processing companies, capital planning (e.g. budget out how much it'll cost to host on Amazon AWS vs. Rackspace vs. Linode, etc...). Market research, what competitors are up to, how you plan to outflank them, etc...

In a nutshell, you need to make yourself valuable to a programmer. The more refined your idea is (assuming it's good, has an achievable revenue model), and the more you bring to the table, you increase your likelihood of finding someone who wants to work with you.

Where do most programmers hang out? StackOverflow, Github, Bitbucket, blogs, IRC, Hacker News, at work, in front of their computers hacking. There are programmer meetups you can find on Meetup.org too.

And of course, nothing is stopping you from learning how to code! I'm also a business/finance guy, but taught myself Objective-C/Cocoa and Python/Django. It's perfectly doable, but takes time, dedication, determination, and patience. Grab some books and get crackin! :)

The sales/marketing person has made connection with all the right people in the industry, has generated a huge interest in our product, has gotten some RFQs running, and has mapped the competitive landscape better than any of us techs could do. (Especially since we are busy coding) - things that you wouldn't necessary look at, such as - who are the key decision makers with a customer organization, what are their internal conflicts and pain points.

Do not underestimate the value of a good bizdev / bizint / sales / marketing person (bbsm).

That said, it is much harder to evaluate the capabilities of such a person -- even for people who do that well -- than it is for a tech guy to evaluate the capabilities of another tech guy. So not every bbsm person is worth their weight in some precious metal - but some (including ours, luckily), do.

And he also does some technical stuff when he has the time.

He is not a "manager" in the sense of making a plan for others to follow. Maybe at this point "organizer" and "facilitator" is a better description. But the usual title for this is manager / CEO. Regardless, even at this stage (for our kind of market) it is almost a full time job on its own.

We value all three partners equally - literally and figuratively. Sure, we could outsource the code, or outsource the design, or decide no idea has value if you can't build it yourself, but that is just not how we are constituted as people. We're very comfortable with our configuration.

There is nearly infinite non-programming work for most startups. Design, fundraising, writing, support, sales, bizdev PR, QA, accounting, talking to lawyers/tax-folk, recruiting, marketing etc.

That said-- a hackathon-style event is a different critter than a startup. You need coders, designers, and (a distant third), people who can write compelling copy.

I think I read this in the book "Apple Confidential"

Speaking as one of those non-programmer types, I'd tend to agree with you. If you're a small team of developers cranking out code, there's not much value to having someone who can't contribute to your product.

As far as meeting programming partners goes -- in Portland at least -- I always recommend user groups or technical focus groups (e.g., Mobile Portland). We're lucky to have a very active user group community and those are the events that tend to draw the types of resources you're seeking. Not the startup events.

I've found that engaging earlier--and attempting these efforts sooner--is a mistake. It tends to cause more conflict than not. To me, engaging too early is like standing there and telling a painter "maybe you should use more green" or telling a musician "try a different chord."

I find I'm most helpful when I can engage with a developer who has realized the initial iteration of his/her vision.

Admittedly, this may result in a little wasted time and some backtracking. But more often than not, that's a small hurdle for the benefits of a) having someone realize their vision and b) reaching a point of being comfortable with, seeking, and accepting criticism and guidance. It just starts the whole relationship out on a much better footing.

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.

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.

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.

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.

Yes, there are many possible software products that can be done cheaply with outsourced labor. The problem is, because they can be done cheaply, they are done. Why should anyone use your Groupon clone when they could just use, well, Groupon.

You can go through a whole lot of MVPs and find out that all of them aren't really viable.

And then if it is viable, why should the developer work for you instead of competing with you? If you're throwing away the initial outsourced prototype and starting from scratch, what advantage do you have over him? While you're scrambling to find a technical cofounder to replace your cheap outsourced team, he could just reimplement the thing, plus all the improvements that actual usage has suggested, and keep 100% of the equity. You're just asking to get Winklevossed.

There's a reason why Paul Graham advises people to take a look at their alternatives and then do whatever's hardest. Business is about competition, about having a durable competitive advantage that other people can't easily replicate. If everybody can do it, nobody makes any money off it.

Groupon isn't successful because of its programming prowess. It's successful because of its sales, marketing and business development prowess. Groupon is a great example of a startup that's not that complicated in the technical department (or at least it wasn't when it started...now it's large enough to where it's justifiable to bring in programming all stars to make sure scalability, maintainability, etc. are in order).

So, as to why a developer should work for a proven MVP rather than building his own clone, the reason is simple...why is it more attractive to be an equity technical founder of Groupon vs. starting your own Groupon, if Groupon approaches you after it's already gained traction?

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.

Absolutely, most startups fail because they build something that people don't want. That doesn't mean things like scalability and maintainability don't matter. It means you're putting the cart before the horse if you're worrying about those things before you even have a product that people want.

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.

Aren't your same gripes just as valid against venture capitalists? I mean, all they're giving you is money, and they're trying to take a huge chunk of equity while you have to worry about the next 617 steps?

Aren't your same gripes just as valid against venture capitalists?

Arguably. But, good venture capitalists give you not only huge sums of money that you wouldn't otherwise be able to pool, but also advice and access to their professional network.

I just find it peculiar how this entire HN community seems in love with the idea of giving away equity in exchange for money and advice, to hopefully increase the odds that your programming work will eventually turn into a big payday...but you seem completely standoffish about the idea of receiving equity in exchange for working on a product that already has proven traction, which would sky rocket the odds of your programming work eventually turning into a big payday.

In other words, you'd get the same increased odds of success that venture capital brings, but you'd be receiving equity instead of giving it away.

In one case, you're bitter about the prospect the person who increases your odds not putting in as many hours as you; in the other case, you gladly accept the prospect of a person increasing your odds but not putting in as many hours as you.

My question is why you're so fixated on hours of work, and instead aren't just look at it in terms of business opportunity where you can make a ton of money? Hours of work seems to be a bad, arbitrary metric to obsess over.

http://news.ycombinator.com/item?id=779448 <- HN post

http://spencerfry.com/whats-a-non-programmer-to-do <- full article

If you're looking to add someone to your team, you want someone who will do as much from this list as possible.

if you want to have a successful company, start collecting their cards, if you dont need them now, you will do later.

said that: beware of talkers, if they do not yet have or had at least one (side) business then they do not have a clue.

I consider myself to fit in this category. I've always been a hobbyist programmer, but it is my damned penchant for humans over social code hosting platforms that has prevented me from becoming a professional developer, for better or worse.

I'd say the biggest challenges have not been technical. Understanding business law, import/export, promotion and marketing, getting photography, sales, dealing with accounts. That side of things has taken up 50% of my time, but it's been 90% of my stress.

If you are selling big enterprise products priced above ~ $10K you absolutely need marketing/sales.

If you are lighting a powder keg, you got lucky and probably don't need much.

If you are trying to start a movement, you require hype, which can come from a dedicated community (e.g. tech) and may not require independent marketing. But you may need a community person. Or you may not be so lucky (e.g. your market is used car sales) and may at some point need a full-time SEO/partnership/etc. person.

If you are going "empire" you will eventually need these sorts of people, since they reach people that can't be reached otherwise. If you are going empire you will also need management people, since large organizations get unwieldy and there are lots of things they learn in b-school about wielding spreadsheets and org charts that will probably be useful.

Conclusion? I tend to think in general you don't need a marketing/sales person until you have a product, but it may be good to get them on board early in some circumstances, particularly if you are also searching for VC or trying to define the product better and need someone who can interface directly with potential clients and gather requirements, etc.

Over the next few weeks I didn't have to think about any of the work that went into the partnerships: responding to emails, making decks, prepping for meetings and building relationships. I was free to continue work on the product without distraction. And in the end she delivered in a huge way.

I love thinking about and building product, but building sales and distribution partnerships is well outside of my wheelhouse; having someone on our team who I trust to execute on that half of our business is invaluable.

- Money

- Domain knowledge

- Patents (not yet confirmed, starting this process soon)

- Office space in a cool location

- Over thirty years of communications experience including technical editing, ad copy, press releases etc.

- Lots of experience with web content management systems (contributed a lot of documentation for one open source project)

- Previous founder experience (though not a tech startup)

- The idea. Yeah I know what you're thinking. An idea + $2 will get me a cup of coffee at Starbucks but this is truly an innovative approach to a huge under served market. That's worth something.

- Journeyman graphic design and layout abilities

- Courage, creativity, sense of humor and perspective

-

Of course it's a big plus if the person that you'll have as an partner is a great programmer, designer or business developer. But to be honest, the most important asset of a co-founder is his engagement. Find people who are highly motivated to work with you, your idea and your product and you'll be able to achieve awesomeness.

I'm not a developer, but I am doing a high-tech startup. My cofounder is extremely good at the overall backend work of our product. He's also very good at talking (sometimes I can't get him to stop) and understanding the overall UX the product should have. How have I helped? Well, for starters we established what he's good at and figured out where the gap is. He hates frontend work, so I have designed the site and learned some HTML/CSS to expedite the frontend development. We're also both taking on 500 hats a minute. There are things he's good at (the technical speak) and things I'm good at (the non-technical speak) and things we're both good at (client meetings, processing feedback, making sure the product is working quickly). We're working on a security problem. As it is, we have completely different ideas; he's always been somewhat more of a blackhat, whereas I'm more of a whitehat, so our complementary ideals have been helping us get great publicity and great customers lined up.

I don't think a non-technical cofounder is necessary, but if you can find someone who can or is willing to do what you don't want to deal with (the books, the legal work, the frontend; everyone has something they aren't good at/don't like), who is also someone who can balance your ideals and personality you can get a great working team going.

Startup success boils down to two problems:

1. Building the product

2. Finding customers

Be it personal powerpoint presentations, meetings, preparation of advertorial material, giving talks, or website content, the presentation of your product is really important. It is what differentiates a company solving real problems from a bunch of geeks doing some geeky stuff in a lab. It reveals the potential of your solution to real users.

1. Finding customers 2. Building the product

Where finding the customers is something that they can be incredibly passionate about and actually affect. This is what the non-programmer worth their salt can add to a 2-3 person start-up. A skill-set aimed at focusing the pivots to those most likely to sell.

Valuable non-programming skills include, in order of immediate product utility: user experience design, visual design, customer support, business development, marketing. And, more importantly, and much rarer, the ability to find all those people that fit with the team and to create a working environment of mutual respect.

- The ability to build a product

- The ability to bring in money (either VC or sales)

- The ability to tolerate risk

As a technical founder who has worked with many non-technical people, I have found it quite rare that a non-technical founder can bring in much on the product side. Almost every non-technical founder I have worked with claims that he is a "product person," but I have found that pretty much none of them are.

Some non-technical founders are good sales people, and can bring in either VC, customers, or both. Some technical founders can do this too, but if you are good enough at this, you will be pulling your weight.

The final thing is the ability to tolerate risk. If you can keep the team motivated and on-target even when things are going badly, that is almost enough in many cases. Very few technical founders can do this well (since most engineers are pretty risk averse), so this is an opportunity to distinguish yourself.

In summary, if you can raise money AND keep everyone else happy and productive, you are pretty much doing your job at the early stage.

So perhaps the question shouldn't be about what does a non-programmer bring to a small team, but rather what do you as current co-founders not personally bring to your own business?

If building a scalable money making app/service/product/thing is what you want to do, then customer development is going to be just as important as product development, and connecting the dots between customers/users and your idea/features cannot be written with code alone.

Either the existing co-founders will need to share an equal level of interest/skill/time for the other parts of the equation (design/ux/sales/marketing/support/bizdev/funding/everything else), or you will need to acquire these skills via payroll or equity.

Knowing in which areas you suck will help this process a lot, and this only comes with giving something a go yourself.

Once you know your weaknesses you will be in a good position to assess what skills/experience a new co-founder will need to have to balance things out.

- Founder, the idea guy. He was technically competent but by no means a programmer. He mainly handled all the sales an customer interactions.

- 2 very excellent programmers.

I was the fourth person to join the team. I had never been a programmer but had attended school with a CET major. So I had done some minimal programming. This was my first attempt at getting a full time, real world, kind of job.

I was not hired on as a programmer, though in the interview I told them I was just trying to get my foot in the door and ultimately wanted to be a programmer. I was hired to handle customer support for their 30 plus customers around the world.

First and foremost what I brought to the team was passion for the work. Aside from that, provided dedication and a technical skill set. It was a very technical product, so they needed someone who could understand it and who could also explain it in sometimes simpler terms to the customers.

Over the years I worked very hard and received good reviews from customers. I made some mistakes and learned from them. As time progressed I took on more technical responsibilities while maintaining my role as the 'go to guy' for support. By the time the company was sold and changed hands I became a full fledged developer and relinquished my support responsibilities to the support department of the company that acquired us. Now I am an equal partner with the two developers from that venture in our own startup.

We recently had a conversation about what each of us was bringing to the table. My two partners made it very clear, the reason they asked me to be involved was not because of my uber programming skills. These two guys are seasoned while I am still a beginner. They wanted my passion.

A developer can build, but what can sell and actually selling it are another matter entirely.

I really gained a lot of respect for sales people at one startup I worked for. How they were able to cold call into a company and find a need and money to pay for addressing it is pretty amazing (to me anyway).

Comparative advantage is huge here. Yes, you could probably fill out all the business incorporation paperwork, write all the copy,etc,etc - but having another person do that work lets you focus on your primary skill.

Biggest thing for me working w/non-programmers? They keep me focused on building features that are useful to users. They still applaud the non-noticeable things like a sweet Hadoop cluster I built but the overall focus on product is key.

Secondly, imagine you're talking about someone who is willing to learn programming, with your help. Even someone to just do HTML wireframes. If you spend 20 hours teaching them and over the course of several months they then independently do work that would have taken you 35 hours - that's still a net gain for you.

Part of being a boss is figuring out what other people's skills are and how you can fit them into your team. If they're enthusiastic about what you're doing, you're far, far ahead of Cubicle Corp which has to bribe people into working for them.

First, you should look at some tutorials before you find this individual so you understand the very basics of whatever language you are looking to grok. If you are looking for PHP, www.w3schools.com is a decent place to start for the super basics.

Once you have a very basic understanding of the language, the best thing to do is find a developer who will work for equity, or a minimal salary, and make it your job to watch him/her as he/she builds your product. It is definitely going to tie up most of your time when you could be doing "other things," but it will serve two major purposes. For one thing, you will have at least a rudimentary understanding of the technologies which will compose your product, thus assisting you in future hires. Secondly, assuming the individual you bring on initially is patient enough, you will have a private tutor who can step you through the creation of a real product, as opposed to contrived academic problems which you will lose interest in very quickly. Granted, this is really just "minimum viable programming" insofar as you will probably not have the occassion to really generate a deep understanding of the concepts behind software development, but at least you can contribute more directly to the actual product.

Ultimately, this approach is dependent on the individual you bring on to build the initial product. If he/she is patient and willing enough to be your teacher, then it can work out nicely.

Best of luck!

  - Hiring
  - Usability
  - Accounting
  - Copywriting
  - Customer Service
  - Project management
  - Business development
  - Knowledge of the market
  - Website optimization
  - Online advertising
  - Fundraising
  - Analytics
  - SEO

Most of the people schlocking their half-baked, consumer-oriented, web 2.0 knock-offs at these events are looking for "technical co-founders" because they have no money. If they haven't made it before, I wouldn't trust their ability to make it in the future.

The above statement you made is a good reason why you do need someone who is is not a programmer (as well). There are many skills necessary for a good startup and many of them don't involve programming.

The fact that you have to ask a question like that of others and can't figure out the answer yourself is a good indication of how you lack certain skills that are necessary.

You've been reading to many stories about all that counts is top programming skills to be a success and the world will beat a path to your door.

   Also how do you meet programming partners.

My advice is to go find find some open source projects that tackle a problem you find interesting and contribute. In the process of working on open source projects, you'll find people that you can work with well. They might be useful in the future.

Depending on the idea/product/vision, you could argue that that guy is as valuable or more valuable than a coder.

The best way to meet programming partners is to go where the programmers are - tap your friend network and, if you're close to a technical school, your location network.

The bottom line is that a successful business needs a LOT of things to come together well, programming is just one of them.

The most important requirement is vision. You need someone with a clear vision of where the company is, where it is going, and how it will get there.

Now, if you can build a prototype or get traction using your existing team, do it first. You'll get better candidates that way, and be at a place where you have a better ability to choose between them.

I agree with other comments here that state their value add should be obvious.

If after a 8-10 hours programming day you still can do any of these things (and do them well enough), you might not need a marketing&sales&business partner ;)

If a business person hasn't been able to generate value for himself (be it money, connections, social proof) then he's the equivalent of a programmer who hasn't written a line of code. It's that simple.

As a developer, I'd definitely found a company with someone who has those skills.

Perhaps others who did go can chip in whether it's any good.

Also if you're near Delft I can point you to an upcoming event.