How to evaluate a non-technical co-founder
blog.hirelite.com
blog.hirelite.com
Common philosophies I hear exposited in tech circles is, "Biz co-founders are a dime a dozen" and “Good ideas, in and of themselves, are worthless”. The argument being everyone on the planet is capable of formulating ideas, thus “good” ideas can be found in overwhelming abundance. One may hear this suggestion advanced amongst mostly “tech types”, such as programmers, developers, engineers, etc. Many of them believe value is derived from the conversion of an idea into a physical product. What group of people are typically required to convert the idea into a physical product? Why the programmers, developers, and engineers of course! In this type of climate, the notion that good ideas alone being worthless or that biz co-founders are worth less than their tech counterparts becomes a self-fulfilling prophecy. This notion is advanced by none other than those that stand to gain the most from it: the programmers, developers, and engineers. Sorry guys. I don't buy it. Read more on this phenomenon here: http://thegeoffreyhull.com/post/3767537182.
I think a major problem is that neither the biz nor the tech co-founders are the lynch pin, it's the correct combo of both + an amazing idea + that 'never give up' determination + timing.
I think there are a lot of people getting full of themselves, be it devs, biz people, or VCs. I think it would do us all well to realize that yes, we DO need each other.
For someone who values original ideas highly, this is a theft of the highest order. Wouldn't you agree?
I am glad you edited the article to explicitly give credit where it is due.
Afterall, if ideas were worthless, wouldn't having a biz co-founder with domain experience be worthless? Or, really, for hiring anyone to do anything? Experience is important because it helps us recognize what is a bad idea in the given field, allowing us to save precious time on execution.
Execution seems little more than the filtering of good ideas from bad ones that you didn't know were bad.
If "the idea" is so valuable, why doesn't it survive first contact with the customer? Why the need to pivot?
You seem to think that "the idea" is valuable, so feel free to point out where "the idea" was a crucial factor in success.
Since it's fair for you to respond with "okay, but you point out where execution mattered", I will.
Amazon, Google, Apple (wrt IPhone and IPad), IBM, Intel, Walmart.
In all of those cases, a competitor had "the same idea", and was first and better funded.
If you think that that's unfair, feel free to give us some examples of actionable "ideas" that biz people had first.
Even though my prototype was terrible and even made the other founders laugh, they could see my level of dedication and my ability to get something done.
To me being a biz founder we need to be the scapegoat of the startup, no pride all humility and can sell the shit out of anything.
---------------------
I think thats a little much.
Part of being a good business man is knowing where you weaknesses lie, and knowing how to plug those holes in your game. So why would you waste valuable time trying to pick up a skill that you're probably not interesting in having and will probably not put to use, when you can spend that time raising money to hire a developer or get one to come in with you and handle the development?
If you were to open a farm in the midwest, would you really hire an IBM sales rep to sell your farm products who never milked a cow before?
That said, raising money (or investing your own) would indeed serve the same purpose.
What I was responding to was this -----> If the non-tech founder can't even learn enough code to get anything built then I would be concerned for their level of dedication for their own idea
Just because a guy doesn't go to learn how to code doesn't mean you should immediately get worried about their dedication to their project.
I see the point you're trying to make, and I agree with it, but it quite different from what I was addressing.
I've got a lot of respect for somebody who can scrape up some dough, envision a product, and get somebody to make it. Unfortunately, too many people think that their skills as a salesperson, manager, hairdresser, chemist or whatever empower them to lead a software development effort and too frequently they fail.
Prototyping a product, and implementing said prototype, are hallmarks of people with vision and determination. If you have an idea but can't execute, why bother?
Bare minimum reason: You understand how the product is created, and can empathize / call bullshit when something is delayed.
If they can make (and talk through) a mockup that demonstrates a grasp of the problems of real-life UI/UX design -- including the little details that normally just get hand-waved over, like "when & where exactly will we get all of the data that's required to build this screen?" -- that counts for quite a lot.
Writing code for someone who doesn't have the background has a huge learning curve -- if someone sets them down with the exact language(s), libraries, editors, references, etc. to use, it's not so bad, but someone who doesn't know the landscape will go down a lot of very time-consuming dead ends on their own, and the lessons they'll learn will very likely not be worth the time wasted (assuming they have no plans to change careers...).
2) They should also have strong, well-informed opinions about UX. Take them to task on what makes a good UX or even a good UI. Press them for examples of good and bad UX design, or have them walk you through a mockup of something you've done in the past. You should be interviewing them just as much as they're interviewing you. They should have theories and opinions on how UX affects business strategy, and vice versa, and not just opinions on what looks pretty or simple. You want to get the impression that this person would have made (or was) a great product manager at a big company, had he or she not been a founder.
3) They should be great salesmen (or women), but not bullshit artists. There's often a fine line here, but the red flags are usually obvious. Look at his or her track record. Look at the realism of his or her vision. Look at his or her ability to model and properly account for risk, competitive threat, etc. If you can pinpoint a critical dependency or risk to the business that he or she can't, that's a bad sign.
4) They should be willing and able to bust their asses and constantly learn. They should not expect to kick back and let you build the product for them. Sort of hard to suss this out in conversation alone, but track record evaluation -- and careful probing about the vision -- should tease out some hints in this direction. A sense of entitlement, or of learned helplessness, usually outs itself under polite conversational fire.
If you're looking at someone with a history, that history needs to be evaluated both in the context of the corporate resources available and the size of his team. Be aware that managing a large team might mean helplessness in a small one.
Personally I'd like to know what to do if you're a technical person with some technical ~AND~ business ideas, who's got a product that's got a little traction and is looking for someone who can help with marketing and execution.
Non tech cofounders that are getting 30 users before trying to find a technical cofounder aren't having trouble finding tech cofounders. Non tech cofounders that have 10 people committed to paying up to 1000/mo and signed letters of intent from the 5 of them (120k/year, 60k guaranteed) before building a product are few and far between.
These guys are gems, and betting on them is a good bet. Its like non-tech founders trying to partner with proven Facebook employee #13. Unless you're equally proven as a dev, its hard to justify asking for that level of accomplishment from your cofounder.
Much of the "find a cofounder" game is about making good decisions when its not such an obvious call.
They have some basis that developers are more valuable based on market forces alone, which means that you need to set your expectations accordingly.
What? I would suggest that the abovereferenced set of cofounders is equal to the null set.
I can't imagine anyone dumb enough to commit to a $12k annual contract for vaporware from a company whose very existence is contingent on finding 9 other suckers just as dumb as you are. The closest model I can think of is games software publishing, but that exists in an area with a known customer base. Nobody in the real world, running a real enterprise, with real money on the line, would gamble like that - at least none of the people I work with.
Why fund the development of new software to a third party who will then resell it to your competitors, versus hiring a software shop to develop it and deliver it to you for internal use?
Equity split? lower maintenance costs? I can't really grok such a decision.
For the non-tech guys, in an early stage startup, i would definitely look at :
- product skills => can the guy understand what customers/users need ? and if he doesn't, will he ask them?
- tech skills => you guys need to speak the same language. even if he's a beginner, has he tried coding in RoR, php, python, ...? will you speak the same language?
- network => does he know investors and bloggers? or at least know people who know them?
- traction and community => can the guy move heaven and earth to get people on board?
- recklessness => is he okay with the risk, the absence of salary, the non-benefits, ...?
- Can sell without BSing.
- Knows how to get in touch with important people
- Good at pitching to investors
- Real personable and good at communicating with customers
- Can write well
- Has an eye for UX
- Has enough technical knowledge to communicate technical issues with customers
- Understands startups
A non-technical co-founder needs to have skills. They just aren't technical. I think the term non-technical co-founder is misleading because it defines someone but what they can't do. I'd rather say sale founder or biz-dev founder.
a. the "right attitude",
b. someone that can "challenge you" and
c. "know the industry" which your competing in really well.
The rest can be learnt on the job.
(54 hour hackmarathon, but not just developers, but marketing and biz people also)