4 Qualities of an Excellent Non-Technical Cofounder

Hamster

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)

10 Strategic Steps to Reaching Product-Market Fit for New Markets

“Product-Market Fit” is the idea that a company needs to 1) create a product that 2) fits a need in the market – a need that is 3) poignant and sustainable enough to generate continued interest by customers, and 4) thereby generate revenues (or other benefits) for the company.   By relying on the term “market” in this definition, we are forced to start with the concept that a buy-sell process pre-exists – that a market’s needs can be defined and addressed.  What if you’re developing a product that is creating a new market?  How does a product owner evaluate whether his efforts are worthwhile, or headed in the right direction?

Booz-Allen product innovation occurrence

What are the steps involved in evaluating whether you’re developing a product that the market may want or need in the future, when the market isn’t currently mature enough to express its needs?  I think it’s these 10 points:

  1.    BUILD FOR THE PROBABLE FUTURE.  Hypothesize the future that you would like to see built.  Hypothesize multiple futures.  Evaluate these possible futures against what you think is the probable future.  What is your preferred future?
  2.    COMPARE SIMILAR PRODUCT LINES.  Look at the evolution of other product lines in other categories.  Evaluate their market impact, their rate of adoption, the relative rate of technological advancement.  Do some predictive mapping of your proposed product line to these external similes.
  3.    LOOK FOR MOVES BY LARGER COMPETITORS.  Look at the current biggest players in the (nearest related) market – but ones that have shown some interest or ability to move in the direction of your new market.  Evaluate their near-term and long-term strategic needs from a product line and revenue perspective.  Think in terms of those companies’ pro-active developments as well as defensive positioning.  Evaluate how your proposed product might fit into, or counter to, those strategic drives.  Will those strategic drives:
    • facilitate market awareness of or applicability of your solution?
    • destroy value created by your solution?
    • lever your solution into bigger market shares?
    • make your solution an acquisition target?
  4.    WHEN POSSIBLE, BUILD YOUR PRODUCT OUT OF STAND-ALONE COMPONENTS.  Evaluate the development roadmap for your proposed product.  Are there milestones or product building blocks that you can use in other product lines as well, or to create new opportunities?  In other words, is the new product salvageable in any way if the new market does not ever emerge?  Closely evaluate this roadmap to optimize for later scaling requirements if the future product is successful.
  5.    BUILD A BRANCHING PRODUCT LINE.  To minimize being early, spend extra time developing those building blocks in Item #4 into peripheral revenue sources and/or products.  You are not creating a direct line of product development towards the future product, like stops on a subway.   You are creating a river delta where the future market is the sea, and the building blocks are the rivulets branching outwards towards it. Delta Analog Prioritize building blocks and derivative products that are themselves critical components of the new proposed product.  Prioritize blocks/products that strategically support 1st) customer development, 2nd) revenues, and 3rd) corporate brand-building & marketing.
  6.    IDENTIFY A TIME RANGE OF OPPORTUNITY.  Specific attention must be paid to timing.  A common refrain you’ll hear from investors is that it’s just as bad to be early as it is to be late.   But “market timing” is a false premise.  If someone (or you or the investor) could perform accurate market timing, then you shouldn’t be an entrepreneur – you should be a billionaire money manager.  Instead, focus on establishing a “time range” of when things can go right in the market, based on the above analysis (principal and secondarily enabling technologies, customer identification, investment industry trends that will help fund future expansion, strategic partnership developments, etc.), as well as smaller time ranges for when things could spin sideways or your operating funds disappear.  Where those ranges overlap – which will probably be 75-90% of the time – establish Plan B’s that revolve around the building blocks in Item #4.  Early is harder to manage than late because early is harder on cash flows.
  7.    EVALUATE COSTS OF EDUCATING YOUR CUSTOMERS.  What are the expected costs of customer education about the new market?  Are any of the players in Item #3, or any other market forces, already doing this, or will be doing this for you?  How easy will it be for you to get the attention of the first customers and get quality feedback so that you can iterate on your first version faster than any subsequent market entrant?  The customer education piece is particularly expensive in new markets.  Overestimate this expense in your budgets and assessments.
  8.    EVALUATE YOUR AVAILABLE BUDGET IN LIGHT OF THE ABOVE.  Evaluate how much investment will be required to develop the proposed product, bring it to market, and educate the market on the problem/solution.  Do you have enough to cover this and does this amount represent a barrier to entry for followers or fast followers?  If any of these answers are negative, you  might eventually have a market, but no sustainable product, therefore no fit.  Refer back to the last sentence of Item #7.
  9.    WILL YOU BENEFIT FROM MONOPOLISTIC FORCES?  Is there a natural monopoly available in the new market?  How hard will it be to successfully fend off well-executed “fast followers” in the market that try to capitalize on your hard work of establishing a beachhead? Is the market set up as a “winner take all” where the first-mover will secure 70%+ of the market because customers typically can commit to only one option due to network effects, or is it likely that the market will require constant iterations?
  10.    COMPARE FIRST-MOVER VERSUS FAST-FOLLOWER STATUS.  Take a critical look at how important it will be to have first-mover access to early customers, versus the relative benefits of being second or third to market.  Do you gain more from early access to customers than you would from learning from the mistakes made by another first-mover? Considering your budget versus the potential monopolistic returns, is it more cost-effective to follow fast and iterate than it is to do your own original market research and education?

Then of course, you proceed with the standard customer interviews and market building exercises as advocated by Steve Blank & Eric Ries.