The search for cofounders is tough. And there’s a notable tension out there in the world between engineers and perceived “idea guys” – go to any Meetup or founder dating event, and you’ll meet people on both sides of the divide about who’s bringing what value to the table. Engineers invariably think pure idea guys are bringing something akin to the hamster-creating-art image above – and admittedly, idea guys often only have a rough sketch of what they want to build. This article helps bad idea guys become legitimate non-technical cofounders.
My cofounder and I often have a conversation that revolves around :
F1: Engineers are constantly approached by people with ideas who want us to work for equity only, many times for a minority stake. When pressed, it’s clear that most have not put much effort into developing the idea. I have my own ideas and many people approaching me. If I can’t separate you from the crowd, I’m not going to jump in with you.
F2: Well, for us business types, it’s simply a matter of plowing through enough meet-and-greets to connect with that one technical cofounder who has enough balls and vision to jump on board what I’m selling.
F1: Your time is better spent working on developing your idea, getting any sort of traction to separate yourself from the crowd, and understanding engineers. If you have a good idea with even minimal traction and true respect for your potential technical counterpart, you’ll be surprised how much easier it is to find a strong technical co-founder. Remember the ratio of idea guys to technical cofounders (anecdotally 40 to 1) and find a way to set yourself apart. Establish an online presence for themselves as a domain expert, get potential customers lined up, pull together marketing collateral, narrow in on some designs…
We have a general hypothesis (and discussions thereon) that the matching process between non-technical and technical cofounders needs to be improved upon. And if you couldn’t tell from the above exchange, my cofounder is the coder and I’m the non-tech.
WHAT ROLE WILL I PLAY?
I met my prospective cofounder during a purposeful search. I had a Big Product Idea, I had a working prototype that some friends & I had coded together during a hackathon weekend that was well-received and was actually fun to use, I had the start of a promising advisory board, I had lots and lots of political capital and marketplace news stories piling up in my idea’s favor – but I didn’t have a great marketing plan other than “we’re going to steal the thunder of the existing apps that don’t have the features this does,” and I didn’t have a tech team to help me build a polished MVP or take the product through iterations. And my own attempts at learning Objective C were dismal – I was looking at probably 1-2 years of a solid dedicated learning environment before I would be able to connect my own dots into a meaningful app beyond Hello World. So while trying to chat up my cofounder about my idea, he shared one of his, and I liked his just as much. But now I was in a quandary: if I’m not THE idea guy -if I’m not originating the product- and my technical cofounder is, what role would I play?
I figured out that even if he had the original idea, I would still play the role that the Idea Guy needs to play on his own ideas. I would take early lead on marketing, customer development, branding, design, financials, and operations. (And I hopefully already passed the beer test.) But sometimes, when strangers are duking out the cofounder process, the conversation gets sideways into a “Me vs Him” workload discussion. Check out this exchange on Hacker News. And this thread between Idea Guys and Engineers. And this bash. And this guy who apparently argues with himself.
VISION: UNCLEAR vs. CLEAR
In economic terms, the area under the effort curves represents the respective value of each person’s effort.
Here is how BAD-IDEA-GUY Professionals (BIG PRO’s) conceptualize the amount of work involved in building a tech product, where the BIG PRO effort is in Red, and the Engineer’s
effort is in Blue. ->
BIG PROS tend to think that their own effort only starts in earnest as soon as the Engineer has built an early version of the BIG PRO’s product (the red curve starts after 0 on the x-axis). Even though they recognize the Engineer will be doing more at the beginning, BIG PROS inherently believe that they are going to be doing at least 2/3 of the work for the company in the long term, and the Engineer will have it easy once the product is released. (In economic terms, the area under the Effort curves represents the respective value of each person’s effort, so double the area means double the effort and value.) To make matters worse, even though BIG PROS internally recognize that the Engineer deserves at least 33% of the early enterprise value, they then try to cram the Engineer down to take 5-10%, thinking they’re being shrewd dealmakers. As a seasoned dealmaker, trust me – there’s nothing shrewd about screwing your potential partner.
But legitimate non-technical cofounders, know that the workload looks more like
this second chart ->
where the x-axis has been shifted to the left to reflect that the non-technical cofounder’s work actually starts well before the Engineer gets involved. This early work is made up of customer discovery and audience building (the early product-market fit exercises and the early efforts at establishing a marketing channel for the eventual product). Note: If you look at the efforts of each contributor on the second chart, they’re somewhat counter-cyclical, meaning that when one guy is cranking hard, the other guy has a little less to do. One guy is more heads-down on his work than the other. When they raise their heads in a pause, they think they see that their counterpart “isn’t working as hard as me,” when in fact their timing is just mismatched on their workload. The workload is much, much closer to 50/5. And if the non-technical cofounder is doing his job right, he’s de-risking the product vision ahead of time, and acknowledging that they will need to go through future technical iterations to get the product right, requiring more and more Engineer commitment over time, not less.
EARN “NON-TECHNICAL CO-FOUNDER” STATUS, DON’T BE JUST AN IDEA GUY
So what kind of cofounders do engineers want to work with? If you’re going to recruit a rockstar engineer, how can you be a rockstar non-tech in return? First and foremost, you must transcend the pure “Idea Guy CEO” mentality into becoming a full-on executive, as in: “one who executes” not as in “white collar, with a title.”
Here are the 4 basic building blocks of execution as a Non-Technical Cofounder:
1) Customer Development & Marketing
As mentioned above, Engineers want you to own the customer experience. You should know your potential customers inside and out. What software do they currently use? What’s their pain point you’re trying to solve? Are they Mac or PC guys? Where do they eat lunch? This is obviously just a representative list of what you need to know about your potential customers. You need to know what makes them tick, how much money they’re going to spend on your solution, and most importantly, how to reach them effectively. Build an Ideal Customer Persona, complete with name, age, etc., as well as the likely online resources they typically use (i.e. LinkedIn, Gawker, Aha!, US Weekly, etc.), what their goals and concerns are – both that your product might address, and the ones that are just outliers. Find a stock photo of a person you think typifies the persona. Do research to verify all of the above.
2) Product & Prototyping
You need to be responsible for at least half of the product vision. I say “at least half” because don’t forget that your technical cofounder is going to have good ideas about what should be there, how to implement it, and how to position it in the market. Definitely don’t discount his/her input simply because you sold them on your idea. So in owning this much of the product vision, you also need to play lead on defining how the product will work from a UX perspective. Don’t know what that means? Look it up and figure it out because that’s your job. You should study UX as much as you study your product domain because it is via UX that you lead your customers through your domain solution. Two years ago, Harvard Business Review listed UX as a corporate asset that needs to be managed like a brand would be managed. Get on this.
3) Branding & Design
This is probably the hardest part for pure Idea Guys to play. But if you’re truly handling #2 above, you’ll need to start ballparking design elements and branding (name, logo treatment, color scheme, etc.), if not handling them outright yourself. Learn some photoshop skills and study the latest branding efforts in your product’s sector. At least get on Dribbble or Behance to get ideas, then hit Fiverr or Elance and get a cheap first version up on the board, against which you can iterate in the future. Better yet, get a real designer to commit even before your Engineer. You need to have some vision about how this product is going to sit in the marketplace, and good designs will help explain the idea but also inspire others in your solution. Pure Engineers often struggle with their own design skills, and want to know that you can help deliver on this crucial piece. FYI to all you natural-born marketers: a good domain name or tagline is NOT a replacement for good UI and branding.
4) Personality & Hustle
Lastly, you have to be easy to work with and know how to just get shit done. You have to pass the beer test. And you have to be willing to get out and sell the product. You. Not AdWords. Not a VP of Sales. You. You have to deliver the customers, the strategic partnerships, the financing, without being a PITA to your Engineer. Startups are an all-hands-on-deck exercise – sometimes the team will need you to play a role that you’re ill-suited to play. And sometimes your technical team will have to help with sales. So buck up, get it done with a smile rather than an attitude, and make your business happen. Be a leader.
You want the status of cofounder and a technical cofounder deserving of the CTO title? Take responsibility for the full half of the business that you actually have to deliver on, and recognize that a good chunk of that needs to happen on your idea before you build anything. And for you Engineers out there dismissive of the business guys – in this day and age of >1 million apps on the market, breakneck evolution of consumer trends, globalization of products and markets, and enough noise in the market to drown a DJ, remember that your technical chops need the support of people who can market effectively, close customers, and operate the minutiae of a fledgling business. These things can’t be solved with a plugin. And the following admonishment applies to both sides of the Biz/Dev (no relation) divide: don’t be stingy on the equity – if you’re not staying up til 3 in the morning coding your own product while also conning rich kids out of their lunch money to fund your project, then you’re no Zuckerberg, so don’t even think of offering the other guy 5% or 10%. The work on both sides is equal, and equally important to the success of the company.
This post also appeared on LinkedIn here.
(Title Image courtesy of Christophere Campbell)