What does a non-technical co-founder do?

This question is impossible to answer in such a general form.

It really depends on the product, the market, etc.

For a very simple mobile app, for example, you may not need a non-technical co-founder at all in the early stages. For an expensive B2B software product, on the other hand, you will likely need a non-technical co-founder to do sales, pitches, etc. while you are building the product.

So, again, it depends, so we can't give you a one size fits all answer. Each startup is unique, and each will have their own set of unique needs and challenges. But, in my mind, generally speaking a non-tech co-founder should be working on everything that is not technical, so that the tech co-founder can focus solely on developing the product. Some startups may require more than one non-tech co-founder to handle these issues, while others may not need a non-tech guy at all in the early stage.

Just to get you thinking, here are some things a non-tech co-founder could work on in the early stages:

• Looking for investors
• Sales to potential customers, beta testers, etc.
• Marketing
• Business financials
• Dealing with the legal, administrative, tax, accounting issues

As you say in your post, the phase of growth is everything. You haven't even approached the chasm, let alone crossed it (assuming this is an innovation going into a non-existent market category). Here's some random thoughts to chew on...

You make a comment about "user acquisition" not being important early on. It's actually everything IMHO. I know there are famous quotes (a la Steve Jobs) about how you should never ask customers what they want, because they will never envision a brilliant, unknown, yet-to-be-invented product. But...

The true insight into deep product requirements comes from attaining a statistically significant number of interviews from target users and -- here's the critical point -- drawing conclusions from patterns in their common needs. The other thing you are looking for are areas where clusters of needs seems to show up in sub-types of users (that's where your API's and platform architecture must evolve).

Anyhow, my point is you need to get NTCF immersed in the target user community asking questions, taping conversations, snapping pictures with the iPhone, whatever it takes to build up a library so that patterns can be ascertained. If the NTCF doesn't trip over $100,000 of prospects (B2B) or 20 people that say "I'd actually pay for that!" (B2C) during this needs analysis process, then the TCF has to really wonder if the innovation is heading in the right direction. Check out Founders at Work for plenty of mind-bending stories of 180 degree turns that made them millions.

Consider everything (non technical) that a company needs to do in order to be successful - there is more than enough work for a non-technical person.

Finance, marketing, customer acquisition, sales, fund raising, research, customer interviews, testing, design... the list is endless.

Sometimes it helps to consider a situation from the other person's prospective. Think about all the business people out there who know nothing about computers or programming who have what they consider to be a great idea. They think, "How hard could it be to build a website to do X and sell Y?" After all, it's just a simple matter of programming, right?

Then they interview a programmer who wants say $50/hr and tells him the project would take a few months. He then thinks, heck eBay went from nothing to their first auction in just a few weeks back in 1995 with just one guy and the tools and computers were not nearly as fast or easy to use as the tools today. If eBay can be done in a couple of weeks, why is this programmer wanting to take months to get the first version of my program up - should be able to be done in a weekend, a week tops. This guy is trying to rip me off; and $50/hr? He should be glad to do the job for 1% equity in my great idea, heck if he were any good and not trying to rip me off it would only be a couple of days and he would be rich.

Now as a technical guy you can see the fallacy in this logic. Perhaps you can also see why such a businessman with no understanding of programming might think this way.

The point is that there are a lot of things to consider and which need to be done which seem trivial if we don't understand them. (Security? don't worry about that now, just get the prototype done and we'll come back to it after we go live...) Perhaps more importantly is the knowledge of what needs to be done and when. Forget to file your trademark application on time and you could loose the chance forever. Forget to file your taxes on time and the government might shut you down or worse. How easy is it to pick the correct corporate structure? Easy if you know how, if you don't know then not so. Just as you bring technical knowledge a business partner should bring valuable business knowledge.