45
Dmitri Pisarenko How to find a technical co-founder

How to find a technical co-founder

Embed Size (px)

Citation preview

Dmitri Pisarenko

How to find a technical co-founder

Table of contentsTable of contents...................................................................................................................................2Preface..................................................................................................................................................3

Structure of the book........................................................................................................................3Chapter 1: Why do technical people reject offers to join a startup......................................................3Chapter 2: How to validate your business model without a technical co-founder?.............................5

Proof of business model vs. proof of sanity.....................................................................................5Case study: Crowdsourced bodyguard............................................................................................6Step 1: Prepare proof of sanity........................................................................................................9

Step 1.1: Definition of the problem or need that your product fixes or satisfies........................9Step 1.2: Hypothesis of who your customers are (including information on how you intend to validate these hypotheses).........................................................................................................10Step 1.3: Hypothesis of your total addressable market size (including information on how you intend to validate these hypotheses)..........................................................................................15Step 1.4: Hypothesis of how you will make money (including information on how you intend to validate these hypotheses).....................................................................................................15Step 1.5: List of assumptions, on which your business model and profitability calculation are based..........................................................................................................................................16Step 1.7: Business model canvas or lean canvas of your current business model....................17Step 1.8: Rough profitability calculation..................................................................................18

Step 2: Contact the potential tech co-founders..............................................................................19Step 3: Find out the reasons to reject the proposals.......................................................................20Step 4: Improve your proof of sanity.............................................................................................20

Chapter 3: What do you want your tech co-founder to do?................................................................21Step 1: Identify the actors..............................................................................................................21Step 2: Identify the use cases.........................................................................................................21Step 3: Draw the user interfaces for the use cases.........................................................................23

Chapter 4: The tech co-founder readiness level.................................................................................29Criteria...........................................................................................................................................30

Criterion 1: Problem definition.................................................................................................30Criterion 2: Customer segment definition.................................................................................30Criterion 3: At least one early adopter......................................................................................30Criterion 4: Lean or business model canvas.............................................................................30Criterion 5: List of use cases.....................................................................................................31Criterion 6: GUI mockups for all use cases..............................................................................31Criterion 7: Assumptions for the profitability calculation........................................................31Criterion 8: Profitability estimate.............................................................................................31

Tech co-founder readiness level calculator....................................................................................31Afterword...........................................................................................................................................31Appendix 1: The survey experiment..................................................................................................32

Purpose of the experiment.............................................................................................................32Process (how I will conduct the experiment?)...............................................................................32Potential co-founders.....................................................................................................................32Message.........................................................................................................................................32Results............................................................................................................................................33Reasons to reject an offer to join a startup.....................................................................................38

Appendix 2: Sample profitability estimate.........................................................................................43

PrefaceThe purpose of this e-book is to explain to non-technical startup founders how they can find a technical co-founder and avoid most common errors.

Structure of the book

In chapter 1 I explain, why technical people reject offers to join a startup.

Chapters 2, 3 and 4 explain what you can do to maximize your chances of finding a good programmer by showing that

1. your idea is worth pursuing and communicating it to the developer (chapter 2) and

2. you have a basic understanding what technical system you want the developer to build (chapter 3).

In chapter 4 I present a metric, which allows you to determine, how close you are to approaching a potential co-founder with a compelling offer.

Chapter 1: Why do technical people reject offers to join a startupNowadays it is relatively easy to get in touch with software developers, willing to join a startup. Apart from events (e. g. Startup Live), there are match-making web sites like CoFoundersLab, which allow non-technical entrepreneurs to connect with potential technical co-founders.

But nevertheless – finding a technical co-founder remains a hard task, even, if you have enough cash to compensate his or her efforts. If you are reading this book, chances are that you've tried to find a technical co-founder and didn't succeed. Before we can figure out, how to fix this problem, let's look at its root cause.

So, we need to find out - why do technical people reject most proposals to join a startup?

I asked this question 100 technicians willing to join a startup on CoFoundersLab. You can find the details of this experiment in the appendix (including answers they gave me).

Here, I want to focus on a few important results. 2 most frequently mentioned reasons to reject a proposal to join a startup are:

1. Lack of a validated business model (mentioned 12 times in 16 responses)

2. Inadequate compensation or no funding (mentioned 7 times in 16 responses)

Problem № 1 means that there is no evidence that

• the product the founder wants to create solves a real problem,

• there are people, who are willing to pay for the solution of that problem,

• there are enough such people to make the business viable etc.

Problem № 2 is a consequence of problem № 1. Since there are neither paying customers, nor a tested business model, the author of the idea can't raise money to adequately compensate the developer – neither from borrowers (like angels, venture capitalists), nor from customers (e. g. crowdfunding).

Let's look at what developers say, when they mean that there is no validated business model (parts of answers from people I asked):

• The idea doesn't solve a problem. It's a lot easier to sell something that solves a problem foryour customers.

• They only have an idea. They have zero validation for the market viability for the idea.

• They cannot identify a specific problem and how they want to solve that problem. This is theabsolute deal breaker for me. I usually at least need to have a pilot customer lined up beforeinvesting time and money into an idea.

• The main reason I reject offers is the lack of business sense. They may have that but they have to communicate it better as when I see their profiles it doesn't appear they're strong with business.

• Potential co-founder haven't done his homework: no market research, no customer interviews

• Cofounder thinks his idea is unique and he'll be the first player on the market. That means he doesn't understand what he's doing

• Cofounder says market is huge and there will be huge revenue and we'll be rich soon. That means he doesn't know how difficult it is to run a business.

• Many people spend ages describing all the features they want in their application, but do not mention anything about how the launch should happen, and who the first customers should be and where to get them. In summary, they just think that by creating the platform / application and making it look nice, the customer will magically come and use it.

• WhatsApp purchase left me with 20 new instant messenger proposals in my inbox within a week.

• The idea isn't fully conceived and/or the target market isn't clear/promising.

• no marketing plan or any clear understanding how we may sell the project

The wording of these answers may be different, but they all point in the same direction. If you are asking a technical person to join your startup, he or she needs to weigh costs and benefits against each other.

If he or she accepts your offer, it means that he'll invest 2-3 years of his life into your venture. That's the cost. It's alright to carry that cost, provided that there is a realistic chance these efforts will pay off.

Whether they will pay off or not, the developer decides based on the information he gets from the founder. Usually, that information does not contain any sensible evidence that you can build a viable business around the idea. The developer, being a rational human, naturally won't invest 2-3 years of his life in order to get nothing in return.

So what can you do to find a technical co-founder most effectively?

You can do following things:

1. Provide a basic validation of your business model.

2. Describe the software you want to build (what it will do).

3. Approach potential tech co-founders.

4. Improve.

Step 1 involves collecting evidence, which will be enough to convince a technical co-founder to invest his time in your idea. It may look similar to a VC pitch, but it's different. Programmers are not VCs and they think differently. For example, if you show to a programmer that you understand the basics of technology (steps 2 and 3), it will be an important reason in your favour for a developer. A venture capitalist is probably not interested in these things. A venture capitalist expectsyou to have assembled a great team. If you don't have a team, your chances of getting support from the VC are close to zero.

For a developer, lack of a team isn't a show stopper, provided that the idea is more or less validated

(I personally know a non-technical founder, who found a co-founder at a time when he had no team).

In step 2 you describe (in written form) what software you want the developer to create. It is a basis for first discussions with the developer. It's important for several reasons:

1. Better understanding on your side. Writing down the requirements forces you to understand what exactly you want to build. If you are like me, you will write several drafts before you have a description, which reflects your wishes adequately. That's fine, because bydoing this work you will gain clarity about your goals.

2. Better communication. Having a description (even an imperfect one) of the software, will allow the developer to understand you much, much better much, much faster (compared to asituation, when he has to elicit that description from you verbally). From my personal experience, getting a rough idea of what the commissioner of the software wants, takes 2-3 hours. If you do your homework, these 2-3 hours of work (on the side of the technical person) won't be necessary. You'll get straight to important questions. And if you don't do your homework and the technical person will need to elicit the requirements from you... well, this means he or she will need to invest 2-3 hours (at least) of time (when he or she might have been earning money). More likely than not, the technical person won't do this work because in most cases it doesn't pay off.

3. Proof of seriousness. When you approach a technical co-founder and have a description of the software you want to build (at least a couple of user interface mockups), it shows that you've thought about what you want to build. This means that you are serious about your idea. By doing your homework you stand out from the crowd of losers, who claim that they have a billion dollar idea, yet are too lazy to draw user interface mockups and to describe what features the software is supposed to have.

Step 3 is actually getting in touch with potential tech co-founders. There are some tricks, which youcan apply to get the most out of these interactions – regardless, of whether you decide to partner or not.

In case step 3 doesn't lead to finding a tech co-founder, you will need to repeat the process.

In the subsequent chapters I will explain how to do each of these steps.

Chapter 2: How to validate your business model without a technical co-founder?

Proof of business model vs. proof of sanity

As we figured out before, the key to finding a technical co-founder is to have a validated business model. There is a problem – inventing and validating a business model is a complex undertaking, which may require lots of resources and time. So what can you do in a situation when,

a) you don't have enough time to properly validate your business model and

b) desperately need a technical co-founder nevertheless?

If you can't prove that your business model is viable, you can at least prove to that you aresane.

Let me explain this in more detail. You have a proven business model, if there are enoughcustomers, willing to pay money for your product and there are enough of them to cover yourexpenses.

You have proven your sanity to the tech co-founder, if you can show him or her that

a) you understand, what a truly validated business model is,

b) you understand, to what extent your business model is validated at the moment, including

c) the shortcomings of your research and

d) you have a plan, how to fix those shortcomings.

If you don't have a validated business model, but are sane, then it is only a matter of time andpersistence until you have validated it. This means – if you can prove to a potential technical co-founder that you are sane, he or she is likely to join your startup.

Let me illustrate my point using some examples.

Case study: Crowdsourced bodyguard

Imagine, I want to build following system.

You wear a device, which measures your body parameters (heart rate, skin conductivity). That device transmits the data from the sensors attached to your body to your mobile phone, on which anapp is running. The app transfers these data to a server.

The server keeps track of these body parameters during the day, as well as the location where you are at the moment. If one of them is too high or too low for the time of day and the place, it means that you may be in trouble.

For example, let's say that every day from 17:00 to 18:00 you travel home in a bus. On most normal days you just get into the bus and sit there until you arrive at home. Let's assume that during one of those trips you are frightened by something. Your heart rate gets up and becomes atypical for that place and time.

In this case, the server sends messages like „Please call X and ask him or her, if he or she is alright“ to all your friends.

This solution gives its users the feeling of security – it automatically notifies their trusted people, if they might be in trouble automatically (you don't need to press a red button).

It would take a lot of time and effort to prove that enough people will buy such system.

It is much easier to prove that I am sane enough to iteratively refine the business model. For example, I could do following things:

1. Find out, how much the device, which measures the heart rate is going to cost by finding devices already on the market, which are capable of doing it.

For example, I found such device and a heart rate sensor, which cost me approx. 70 USD (including shipping from the US to Russia).

2. I asked several people I knew about whether or not they would use such system. I found 2 single women, which were interested in using the system for their own security and one mother of a child, who wanted to use the system for tracking the location of his child.

3. I checked the competition and found out that in the region of interest (Moscow, Russian Federation) a major security company offered a comparable service – you can call a team of bodyguards using a mobile app.

4. Another company sells a device, which tracks the movements of an old person inside his or her flat. If one of those movements is too abrupt, it means that the old person may have fallen. In this case the system calls the ambulance.

5. I went to a venture capitalist and explained to him my idea. He told me that the idea sucks for several reasons:

1. The solution of the security company from step 3 isn't selling very well according to his research.

2. Imagine, the user of this system was attacked by a gang. Imagine further that one of his friends got the emergency signal and wants to help the first person. This friend is not a professional cop. What will happen, when a civilian tries to protect a person from a gangof professional criminals? That friend probably will be hurt. Without using the system, only one person would have been hurt. But when the system is used, more than one person is likely to get hurt (victim of the crime plus all friends, who get to the crime scene and attempt to help).

The venture capitalist draws an analogy between my proposed system and personal surveillance systems (which allow you to view via a web cam whether a thief is operating in your flat).

Imagine I would tell you these things about my idea and show the results. They don't prove that my idea is validated, but they do prove that I'm

• realistic about the idea and

• willing and able to run experiments to verify whether the idea is good or not.

And if you can prove it to your potential tech co-founder, you are already ahead of 80 % of other people, who offer him or her to join the startup.

The following diagram shows you the algorithm of finding a tech co-founder.

The first step depends on whether you have a validated business model already. If you do (that is, you have people, who seriously want to buy your product and there are enough of them to sustain a business), then you need to write down these results and present them in a way your potential co-founder can understand.

In the more likely case, you don't have a validated business model yet. In this case you need to craftproof of sanity, i. e. materials, which will prove to a potential technical co-founder that

1. you are realistic about your idea and

2. you are able to test your hypotheses empirically.

When you have prepared those materials, you prepare to a contact with a potential technical co-founder (I'll cover the topic of preparation later).

Imagine you contacted him or her, either online or personally. You need to decide whether or not thechemistry between you two is right. Let's assume that it is, i. e. you think that you can work effectively with that guy or gal as a co-founder.

In this case, you need to ask whether your feelings are reciprocated – whether the potential co-founder wants to invest his time and maybe money into your venture. If he or she does, great – you've found your technical co-founder.

But let's assume that he or she isn't ready to jump into your boat right now. What is the best thing you can do in this situation?

The answer is simple – find out, why he or she doesn't want to co-operate with you?

Let's assume that the person gave you 3 weak points of your business model as a reason to reject your offer.

Next thing to do is to fix those problems, i. e. to improve your proof of sanity. Once you've done it, you can repeat the whole process – prepare for contact with a tech co-founder, talk with him or her, gather feedback.

If you follow this algorithm, you will find your co-founder sooner or later. And you can benefit even from rejections.

Let's look at these steps in more detail.

Step 1: Prepare proof of sanity

Proof of sanity consists of several parts:

1. Definition of the problem or need that your product fixes or satisfies.

2. Hypothesis of who your customers are (including information on how you intend to validatethese hypotheses).

3. Hypothesis of your total addressable market size (including information on how you intend to validate these hypotheses).

4. Hypothesis of how you will make money (including information on how you intend to validate these hypotheses).

5. Hypothesis of how you will acquire first customers (including information on how you intend to validate these hypotheses).

6. List of assumptions, on which your business model and profitability calculation is based.

7. Business model canvas or lean canvas of your current business model.

8. Rough profitability calculation.

Let's look at these parts in more detail.

Step 1.1: Definition of the problem or need that your product fixes or satisfies

Every product either

• solves a problem or

• satisfies a need.

You need to formulate what problem or need the product you intend to develop, satisfies.

Example: Crowdsourced bodyguard

The Crowdsourced bodyguard product solves both a problem and satisfies a need.

Problem: If a person doesn't arrive at home and doesn't answer phone calls, the police can startsearching for him or her only after he or she has been missing for 3 days.

Solution: The Crowdsourced bodyguard notifies trusted people of th user. In case of trouble theycan start searching for him or her even before 3 days have expired.

Need: Need for security of the loved ones.

How the product satisfies this need: Mobile app regularly (every 5 minutes) notifies the serverwhether the user is frightened or not. As long as there is no emergency signal, the trusted person ofthe user can be sure that he or she is alright. It's like asking a loved one „Are you alright?“ every 5minutes and getting a response.

Step 1.2: Hypothesis of who your customers are (including information on how you intend to validate these hypotheses)

Next step is to find out, what people have that problem you want to solve. In scope of this step, youneed to find at least one real, living, breathing person, who says to you „Yes, I have the problemyou want to solve“ and really means it (i. e. doesn't say it to you because he or she is your friend).

First, you need to describe the customer segments.

Example: Crowdsourced bodyguard

There are several possible target audiences for the Crowdsourced Bodyguard system.

1. Parents of children, who want to track the location of them and be notified, when thechildren arrive at home, school, or their friends.

2. Men, who want to get notified, when their girlfriends are frightened.3. Children of old people, who want to get notified when their parents get in trouble (e. g.

have a heart attack, or fall down).

When you have done it, you have a list of hypotheses „I think that customer segment … has theproblem I want to solve“.

Example: Crowdsourced bodyguard

Here, we have the following hypotheses:

1. Parents of children have a need for security of their children, which is currently notsatisfied.

2. Men in relationships have a need for security of their girlfriends (wives), which is currentlynot satisfied.

3. Children of old people have a need for security of their parents, which is currently notsatisfied.

Next, we need to figure out, what experiments we can run in order to find out, whether a particularcustomer segment actually has the problem (need) we want to solve (satisfy). To do so, we need tofind people (at least one person), who belongs to one of our customer segments and ask him or her,if he has the problem.

There are several ways to do it:

1. Your social network (family, friends, current and former colleagues). Sometimes, especiallyif you develop B2C products, you can find representatives of your target audience amongthe people you know.

2. Physical places, where your target audience is concentrated (is likely to be present there, is likely to visit frequently). In these places, you put paper ads with texts like

Are you worried about the security of your children?

We have a solution, which allows you to always know, where your child is. Interested?

If so, please call … or write to … .

Since your potential customers visit those places, it is likely that they will notice those ads and – if interested – contact you.

Example: Crowdsourced bodyguard

Possible places of concentration of target audience (places, where you can put ads).

Customer segment 1: Parents of children

1. Schools2. Kindergartens3. Places, where activities for children are performed (e. g. places where martial arts courses

for children are taught)

Customer segment 2: Men in relationships

1. Bowling clubs2. Places, where pre-natal courses for fathers are held (courses, which explain to future

fathers, how to handle pregnancy and first years of their children).3. Flower shops (if a man buys flowers, it is likely that he has a girlfriend or wife, to whom he

will give those flowers as a present).4. Jewelry shops (same logic as flower shops)

Customer segment 3: Children of old people

1. Retirement homes2. Folk music events (in some countries the audience of folk music are primarily old people)3. Adult evening classes (in some countries there are many old people, who attend such

classes)4. Pharmacies

5. Hospitals3. Run a Google AdWords campaign. Google AdWords are paid advertisements, which

appear, when the user enters a particular search text (e. g. „CAD software“) in Google (seered rectangles in the screenshot below).

In order to find representative of your target audience to interview, you can

1. setup a Google AdWords campaign for the search items your target audience is interested inso that

2. when the user clicks on the ad, he or she is re-directed to a landing page with a text like „Ifyou are interested in this product, please enter your e-mail in the box below“ and an e-mailtext box.

You can configure Google AdWords so that the costs of your experiment are limited. For example,you could setup the campaign so that you spent at most 5 dollars per day for a week (35 dollarstotal). For more information about how to research the market using Google AdWords, refer to theexcellent book Google AdWords for Dummies by Howie Jacobson, Joel McDonald and KristieMcDonald.

As of 27.07.2014, you can implement step 2 (landing page) for free using the landing page builderLaunchRock (http://launchrock.co/).

4. Run Facebook ads. This option is the same as the previous one, except that now you runthe ads on Facebook. Facebook ads can be configured so that they are shown only to thoseusers, who fit into a certain demographic (see example below). When people click on thoseads, they can be redirected to a landing page with a text box for entering the e-mail address.

Example: Crowdsourced bodyguard

If we wanted to show our ad to men in San Francisco, age between 18 and 35 years, who have awoman to take care about, we could setup the ad like shown below (see red rectangles andellipses).

5. Find people using Facebook Graph Search, then ask them. Facebook allows you to find people on Facebook, which satisfy certain criteria like location, age, gender, relationship status, education level. Using this tool, you can find representatives of your target audience on Facebook.

Then, you send them a message, in which you describe your product.

For examples of Facebook Graph Search queries, please look at https://www.evernote.com/shard/s35/sh/b6c36a3e-609e-4452-b714-1866435fb793/e9b282066c0919da0269619a12dc6901 .

Example: Crowdsourced bodyguard

If you want to find all men between 18 and 35 years old, who live in San Francisco and are in arelationship, you can enter the query „Men who live in San Francisco, California and are between18 and 35 years old and are in a relationship“ into the search box at the top of the Facebook page(see red rectangle in the image below).

You may then contact some of them and ask whether they have the problem you are trying tosolve.

6. Specialized online communities. In some cases you may find that there already places onthe Internet with lots of people from your target audience (forums, social networks, blogswith active communities). In this case, you can do two things:

1. Contact the members of those places using private message and/or

2. Place a post with a request for feedback about your idea (it is advisable to first contactthe moderator of the forum and ask him or her, if it is OK to post your message –otherwise it may be regarded as advertisement and deleted).

Example: Crowdsourced bodyguard

One of the target audiences are parents of kids. A Google search revealed following onlinecommunities of parents:

Mothers

1. http://www.cafemom.com/2. http://www.mamapedia.com/

Fathers

1. http://www.dadsonline.com.au/2. http://newdadsnetwork.com/

After you have done one or more activities for finding you customers, you should end up with atleast one person, who has the problem you want to solve and is willing and able to give youfeedback on your idea.

Next step is to find out, how much of your product you can realistically sell.

Step 1.3: Hypothesis of your total addressable market size (including information on how you intend to validate these hypotheses)

Total addressable market is the quantity of your product you can realistically sell to your target audience.

Example: B2B software

Imagine you want to produce and sell some software for a large corporation. Imagine that there will be one salesperson in the company you are building. Imagine further that personal sales is the only channel, by which you intend to acquire customers.

In this case, the size of the total addressable market can be estimated like this:

1. Per week, the salesperson can contact 40 potential customers for the first time.2. On average, 30 % of these 40 customers want to have a live presentation of the product.3. 10 % of people, to whom the salesperson gave a live presentation, eventually order the

product.4. How many items can we sell per year?

1. 40 first contacts per week is equal to 120 first contacts per month, which equals to 1440first contacts per year.

2. 30 % of first contacts want a presentation, which means 432 (1440 * 30 %) presentations per year.

3. 10 % of people, to whom a live presentation was made, buy the product. This equals 43(432 * 10 %) buyers per year.

Given the restrictions (one salesperson, no other sales channels) the total addressable market of thecompany is equal to 43 items per year.

Example: Online sales

Imagine you want to sell some product via Internet, using Google AdWords as the one and only sales channel.

In this case you can calculate the total addressable market size in the following way.

1. One click in a Google AdWords campaign for search items relevant to our product, costs 50cents.

2. When the user clicks on the Google AdWords ad, he or she is directed to a landing page. 10% of people, who visit the landing page, actually buy the product.

3. In order to sell one item of the product, we need 10 people (1/0.1) to visit our page. Since 1click costs 50 cent, we need to spend 5 dollars to sell one item.

Imagine we want to spend 1000 dollars per month on Google AdWords. This translates into 200 (1000 dollars / 5 dollars per customer) orders per month, or 2400 orders per year.

Step 1.4: Hypothesis of how you will make money (including information on how you intend to validate these hypotheses)

The next step is to provide a set of hypotheses (including descriptions of how you will test them) about how your company will earn money.

Example: Crowdsourced bodyguard

The revenue of the company will come from 2 sources:

1. Sales of devices for measuring the body parameters (fearomats).2. Subscription fees for premium users.

Revenue source #1: Sales of devices for measuring the body parameters (fearomats)

Let's say that the primary costs of building such device are 70 dollars. We add 30 % markup and sell them for 91 (70 * 130 %) dollars to the end users. On each device, we earn 21 dollars.

Experimens to validate this revenue source:

1. Talk with potential end users (e. g. women, old people, children) and ask them, if they are willing to pay 91 dollars for this device.

2. Talk with parents of children, and ask, if they are willing to pay 91 dollars for a device, which will increase the security of their children.

3. Talk with children of old people and ask, if they are willing to pay 91 dollars for a device, which potentially can save the life of their parents.

Revenue source #2: Subscription fees for premium users

In addition to a free version of the service, there will be a premium version, which includes features like guaranteed help (if no of user's friends responded to an emergency signal, a human operator calls the user on the phone and if it is a real emergency, she will ask the police to go to theplace, where the user was last time).

The competition offers a comparable service for 14 dollars per month, so we want to offer our service at the same price.

Experiments to validate the hypothesis:

1. Ask the end users (e. g. women, old people, children), if they are willing to pay 14 dollars per month for premium features.

2. Ask parents of children,whether they are willing to pay 14 dollars per month for premium features.

3. Ask children of old people,whether they are willing to pay 14 dollars per month for premium features.

Step 1.5: List of assumptions, on which your business model and profitability calculation are based

Your idea about how the future company is supposed to work, is based on a set of assumptions. Often, these assumptions are implicit. In order to communicate with your potential co-founder as effectively as possible it is a good idea to make those assumptions explicit. That is, to write them down.

Bad news: By writing down the assumptions you become vulnerable to criticism. Your costs and revenue calculations hold only as long as the assumptions are correct.

Good news: Some of that criticism will be constructive and thus help you build the company.

So let's look at what assumptions we might have in our Crowdsourced Bodyguard example.

Example: Crowdsourced Bodyguard

We have several assumptions, which are used in the costs and revenue estimate.

1. We assume that the company will have 3 employees.2. Each of them will have a desk in a co-working space, which costs 280 dollars per month.3. Each employee will have a salary of 4230 dollars per month.4. The number of paying customers is 10000.5. Monthly subscription fee is equal to 27 dollars per month.6. Primary costs of building or buying the measurement device are equal to 70 dollars.7. Markup for the measurement device is 30 %.8. Each month, 100 new paying customers are acquired.9. The fearomat sends 144 messages to the server (location and body parameters of the user) ?10. To process these requests, we'll need 0,72 hours of machine time per user per day.11. One hour of machine time costs 60 cents.

Step 1.7: Business model canvas or lean canvas of your current business model

Next you can capture your business idea in form of a lean canvas. It is a means to visually representyour business idea and its components on one page.

You can find a detailed description of it in the book Running Lean by Ash Maurya (http://runninglean.co/). The image above was created using Rod's Lean Canvas Template, which you can download from https://github.com/rodw/paper-forms/tree/master/lean-canvas.

Work with a lean canvas happens like this:

1. You create an empty lean canvas with 9 areas, each of which represents a part of your business model.

2. You generate hypotheses for each part of the business model and put them on the canvas likestickers.

Each hypothesis describes an aspect of the business model and is assigned to one the following 9 areas:

1. Problem: 1-3 problems of your customers that you want to solve.

2. Customer segments: Customers (buyers) and users of your product. Note that you should focus on people, who are likely to become early adopters (not mainstream customers) of your product.

3. Unique value proposition: In this part you describe, as Ash Maurya puts it, why your solution is different and worth getting attention.

4. Solution: The product, which you want to build and which will solve the problem of the target audience (more information on the description of the solution is provided later in the book).

5. Unfair advantage: Some aspect of your business idea, which cannot be easily copied or bought like insider information, right „expert“ endorsements, a dream team, personal authority, large network effects, community, existing customers, SEO ranking (Ash Maurya). Note that if you don't have an unfair advantage yet, you should leave this box blank. Leaving it blank is way better than writing a fake unfair advantage (like the „first mover advantage“).

6. Revenue streams: How do you intend to earn money to cover the expenses of running the business?

7. Cost structure: What resources will you need to run the business and how much will the most important one of them cost?

8. Key metrics: A few metrics, which you can use to quickly determine, how well your business is running.

9. Channels: Here you describe how you will notify your customers that your product exists (e. g. Google AdWords, advertisement in newspapers, blogging etc.).

Step 1.8: Rough profitability calculation

Finally you create a spreadsheet, in which you calculate monthly

1. revenue,

2. costs and

3. profit (revenue minus costs)

based on the assumptions from the previous steps.

Whether the business is profitable depends on the values of your assumptions. You tweak them until

1. the monthly profit is greater or equal to zero (i. e. you don't have a loss) and

2. your assumptions are more or less realistic.

If you can't, then you should modify some part of your business model.

Once you have prepared all materials, you can start contacting prospective tech co-founders.

Step 2: Contact the potential tech co-founders

Next, you can start searching for potential co-founders. There are at least two ways to do it:

1. Offline

2. Online

Offline means going to events, where you are likely to find people, who are willing to join a startup,e. g. Startup Weekends. During some of these events, you pitch your idea (sometimes with a time limit) and then you can talk to people, who got interested in it.

Online approach includes, among other things, contacting potential co-founders using match-making sites like CoFoundersLab.

Some tips for contacting a potential tech co-founder:

1. Practice your pitch. If you intend to contact them verbally (e. g. in scope of a startup weekend), practice your pitch. Some events impose a time limit (e. g. you can talk for one minute, thereafter the mic is turned off). It is very hard to keep that time limit and convey your message to the listeners, if you are doing it for the first time. Therefore I recommend that you record your pitch using your smartphone, then listen to it, find out what can be improved. Then, you repeat the process. From my personal experience, after 30-40 record-listen-improve cycles, you will be able to pitch your idea keeping the time limit without having any notes, without learning it by heart and with a healthy dose of expression.

2. Provide enough details. When you are contacting a potential tech co-founder, give them sufficient information about your idea. If you did the previous steps, you will have a lot of information about your business model and the product you want to build. Show this information to the potential tech co-founder. Note that many of them get proposals like „let'sbuild another photo-sharing app“, or „let's clone WhatsApp“, or, my favorite, „let's build an iPhone app“. You should show them that you have thought your idea through better than 80 % of other people, who contacted them (if you apply what I preach here, your proposal will, indeed, be more detailed than the vast majority of the proposals they get). By showing them your materials, you will demonstrate that you are sane, serious and you will stand out from the huge crowd of your competitors, who are not.

3. Send personalized messages. If you are contacting the potential tech co-founders online, write a personalized message to each of them. No templates, no spam. Find out as much as you can about them before writing your message (e. g. by looking at their LinkedIn and Facebook profiles). If you are using a match-making site, read what they have written in their profiles (in particular – what kind of startup are they willing to join). If there is anything, which they are looking for and which you can provide, then emphasize this commonality in your message. For example, let's imagine that you are building a B2C startup and a potential tech co-founder writes in his or her profile that he or she wants to work in a B2C company (or something, which implies this). In this case, you should emphasize the fact that both you and he (she) want to work in a B2C company.

4. Contact enough potential tech co-founders. Finding a tech co-founder is a numbers game. You should contact at least 10 potential co-founders before you can expect one response.

5. Don't be fixated on the technology. Imagine you want to build a mobile app. You meet a successful tech professional with 10 years experience, who has been developing web sites, but doesn't know anything about mobile apps. Let's assume that the chemistry between you two is OK. You may think – I can't do business with this guy because he has created lots of web sites, but no mobile apps. Don't reject a good-looking tech co-founder because he or shelacks expertise in a particular field.

Any good engineer can learn any technology in a limited time frame.

Every software system built by man obeys certain laws. During his or her career, a good technician gets in contact with many types of software and – provided that he or she is reallygood – the invariant, universal principles of software building (as well as relevant skills) get into his or her bones and flesh.

Even though mobile web sites (where our rockstar developer has experience) are very different from mobile apps (what you need) on the outside, from a programmer's point of view they are different manifestations of same principles.

In practice this means that every engineer worth his or her money is able to learn any new technology relatively fast, provided that

a) there is publicly accessible documentation on that technology andb) the engineer has a strong incentive to learn it.

Condition a) is satisfied for most technologies available on the market and definitely it is true for all relevant mobile platforms.

Condition b) is likely to be satisfied, if your idea has market potential (as shown by the materials you prepared).

Analogy. There are principles of how you drive a car with an internal combustion engine. If you learned how to drive one such car, you can drive other cars of that type as well. For example, if you can drive a BMW (can develop web sites), you can drive an Opel (develop mobile apps) as well. If you hire a taxi driver, who is supposed to drive an Opel, and in the past he has driven BMWs only, it would be ridiculous to reject him because of lack of experience with BMWs (provided that he didn't have many accidents).

Note that this statement applies only to professional developers, who have experience and relevant skills like systemic thinking, communication abilities (can explain to other people complex things in a simple language) and are movitated enough.

If in doubt, you may ask him or her, if he ever learned a new technology. If he or she confirms (and, ideally, can prove it), then it is very likely that he or she will be able to learn the technology stack you need as well.

Step 3: Find out the reasons to reject the proposals

It is possible that not all tech co-founders you contact will instantly want to do business with you. Some of them will reject your offer. Sometimes, after the first contact with a potential tech co-founder, you will find out that you don't want to work with him or her due to chemistry mismatch.

In case a capable tech co-founder you like does not reciprocate, it is advisable to find out, why.

At the end of the communication with a tech co-founder, ask him or her: What things can make you reject my proposal?

Step 4: Improve your proof of sanity

If the reason to reject you has something to do with your business model (which probably is the case), you can use this feedback to improve it.

For example, the potential tech co-founder may tell you that the weakest point is your problem part

(he or she is not sure that the people you think are your customers actually have that problem, or that the problem is severe enough for them).

In this case you could

1. find additional people from your target audience, who have this problem (i. e. conduct more customer interviews) and/or

2. run a Google AdWords campaign, measure the response rate and provide evidence that thereare people with that problem

Both would make your business model stronger and increase chances that a potential tech co-founder finds your business model compelling enough to participate.

Chapter 3: What do you want your tech co-founder to do?When you contact a potential tech co-founder, it is necessary to demonstrate a basic understanding of the technology. You don't need to know how to build your product (that's the job of the technical person), but you need to have a rough idea on what should be built.

Imagine, you talk with a potential tech co-founder about your business idea. Let's assume that he is convinced that it has potential, and the chemistry between you two is right. In this case, sooner or later the question will arise – what exactly should be built by the technical co-founder?

You better prepare a first version (basis for discussion) to this answer before you meet the tech co-founder. In this chapter I explain, how you can create a description (draft requirements specification) of the product you want to build.

Step 1: Identify the actors

First, you need to identify actors – types of users of the system to be built.

Example: Crowdsourced bodyguard

Remember our system, which automatically notifies trusted people of the user, when he or she getsin trouble?

In that system we have at least 2 actors:

1. User2. Trusted person

The trusted person is supposed to take care of the user in case he or she (the user) gets in trouble.

Step 2: Identify the use cases

The next step is to identify use cases – actions, which each of the actors can do using your system. Normally this is done using a so-called use case diagram.

Example: Crowdsourced bodyguard

The people figures represent actors, the ellipses the use cases. A line between an actor and a use case indicates that the use case is available to the respective actor.

Let's look at them in detail.

1. UC-1: Sign-up. In scope of this use case both user and the trusted person register with the service.

2. UC-2: Log in. In scope of this use case, trusted person and the user log in into the application on their mobile phones.

3. UC-3: Send invitation „become my trusted person“. Using this feature, the user can ask

someone to become his or her trusted person.4. UC-4: Accept invitation and UC-5: Reject invitation. In scope of these use cases the

invited person can accept or reject the invitation.5. UC-6: Connect the Fearomat. In scope of this use case the user makes sure that the

mobile phone can receive data about his or her body parameters from a measurement device (Fearomat).

6. UC-7: Start tracking. In scope of this use case the user tells the system that it should observe his or her body parameters and notify his or her trusted people, if they become atypical.

7. UC-8: Stop tracking. In scope of this use case, the user tells the system that it should stop monitoring his body parameters (e. g. because he or she has arrived at a safe place).

8. UC-9: Receive emergency signal. In scope of this use case the trusted person receives an emergency signal from the user.

Step 3: Draw the user interfaces for the use cases

Next step is to show to the potential tech co-founder what UI (user interface) will be required for each of the use cases. You don't need to know exactly how the app will work internally, but you do need to give to your potential partner a feeling what you want your app to be doing. Sketching user interfaces is one of the most powerful techniques of telling another person, what a piece of softwareis supposed to to.

There are several ways you can sketch the UI:

1. Manually, i. e. you draw it on paper, then scan the drawings to be able to share them digitally. This option is OK, if other people can recognize your handwriting.

2. Using specialized software.

If you are using the second method, you have several options, including, but not limited to

• the free Evolus Pencil program (http://pencil.evolus.vn/) and

• the paid Balsamiq software (https://balsamiq.com/).

Example: Crowdsourced bodyguard

UC-1: Sign-up

The user enters his or her e-mail address. Thereafter, an e-mail is sent to that e-mail address. Insidethis e-mail is a password, using which the user can login into the system (see next use case).

UC-2: Log in

UC-3: Send invitation „become my trusted person“

On the main screen, there is a „Settings“ button. When the user presses it, several menu items will appear, including „Add trusted person“.

When the user presses the „Add trusted person“ button, following screen appears.

Then, the user enters the e-mail address of the person, he or she wants to invite and presses the „Invite“ button. Then, the system sends an invitation to the entered e-mail address.

UC-4: Accept invitation

When the user asks someone to become his or her trusted person in scope of this system, that person gets an e-mail.

If ther person accepts the invitation (actually want to be notified, when the user gets in trouble), the trusted person installs the app on his or her smartphone and registers with it (like shown in use cases 1 and 2, „Sign-up“ and „Login“, respectively).

After the user has logged in for the first time, the system checks if there are any invitations for himor her. If it is the case, the user will see following screen.

By pressing the „Accept“ button the user can accept the invitation. Thereafter, when the protected person gets in trouble, the trusted person will get a notification and an e-mail with the map of the latest movements of the protected person.

UC-5: Reject invitation

The user can reject the invitation in two ways:

1) Simply not open the invitation e-mail2) Press the „Reject“ button in the screen from use case 4.

UC-6: Connect emergency detector

UC-7: Start tracking

In order for the app to notify trusted people, when the user gets into trouble, the user has to put the „Tracking“ switch into the „on“ position.

UC-8: Stop tracking

In order for the app to notify trusted people, when the user gets into trouble, the user has to put the „Tracking“ switch into the „off“ position.

UC-9: Receive emergency signal

When the user gets in trouble (the bodily parameters get atypical for the current place and time), his or her trusted people get an

1) e-mail, which contains the map of the movements of the user during the last 24 hours and2) SMS with the emergency signal and the last known location of the user.

Chapter 4: The tech co-founder readiness levelThe tech co-founder readiness level is a simple technique to find out, whether you are ready to go find your tech co-founder or not. First, you go through the table below and mark those criteria, which are satisfied at the moment.

№ Criterion Score

1 Problem or need defined 1

2 Customer segment defined 1

3 Found at least one early adoper (person with the unsolved problem or unsatisfied need, who is willing and able to provide feedback on MVP)

10

4 Lean canvas or business model canvas is there 5

5 List of use cases prepared 1

6 GUI mockups for all use cases created 1

7 Assumptions of the profitability calculation are written down 5

8 Profitability (revenues and expenses) estimate is created 5

For each satisfied criterion you get the number of points written in the „Score“ column. Then, you sum up the points. This sum is the tech co-founder readiness level. If the amount is equal to or greater than 20, then you are ready for finding the tech co-founder.

If it is less, you should do your homework.

Now let's go through the criteria in more detail.

Criteria

Criterion 1: Problem definition

This criterion is satisfied, if you have written down, either

1. what problem your product is going to solve or

2. what need your product will satisfy.

Criterion 2: Customer segment definition

This criterion is satisfied, if you have written down, what kind of people are likely

1. to have the problem and

2. for whom the problem is so severe (important) that they want to actually fix it (and are readyto pay for it).

Criterion 3: At least one early adopter

This criterion is satisfied, if you have found at least one person, who

1. has the problem you want to solve (or has a need you want to satisfy with your product),

2. wants to solve it (or to satisfy the need),

3. is not your friend or relative (i. e. doesn't say the former 2 items just to please you) and

4. is willing and able to test the prototype (once it's ready) and

5. provide honest feedback on it.

If you find more than one such person – great, but you need to have at least one living, breathing early adopter with the problem you intend to solve.

Criterion 4: Lean or business model canvas

This criterion is satisfied, if you have written down the hypotheses of your business model in form of either

1. a business model canvas (created by Alexaner Osterwalder) or

2. lean canvas (created by Ash Maurya).

Criterion 5: List of use cases

This criterion is satisfied, if you have a list of use cases (descriptions of actions that the user can do with the product you intend to build).

Criterion 6: GUI mockups for all use cases

This criterion is satisfied, if you have GUI mockups for all use cases.

Criterion 7: Assumptions for the profitability calculation

This criterion is satisfied, if you have listed all assumptions, on which your profitability estimate is based.

Criterion 8: Profitability estimate

Finally, you need a rough estimate of revenue and costs. You will find a sample profitability estimate in appendix 2.

Tech co-founder readiness level calculator

Attached to the message with this e-book you got some additional materials. One of them is the file tech_cofounder_readiness_level.ods, which allows you to easily calculate your tech co-founder readiness level.

Simply put 1 into the „Is the criterion satisfied?“ column, if the respective criterion is satsified. At the bottom you will have your tech co-founder readiness level. If it is equal to or greater than 20, it is reasonable to start searching for a tech co-founder.

AfterwordIf you follow the recommendations from this text (do your homework and present the results to a potential tech co-cofounder), the probability of you finding a good technical co-founder is much higher than if you do it the usual way.

Last, but not least, I'd love to hear from you. Especially, I want to know if this text helped find you a technical co-founder as well as any suggestions on how to improve this e-book.

You can contact me via

1. e-mail ([email protected]),

2. LinkedIn (https://www.facebook.com/dp118m) and

3. Facebook (https://www.facebook.com/dp118m).

Appendix 1: The survey experiment

Purpose of the experiment

To find out most frequent causes, why potential tech co-founders reject to co-operate with non-technical founders.

Process (how I will conduct the experiment?)

Step Action

1 Send a message to at least 100 potential technical co-founders (criteria see below) on CoFoundersLab.com.

2 Write down all responses.

3 Group together similar responses.

Potential co-founders

Potential co-founders are those people, who satisfy all 2 of the following criteria.

№ Criterion Notes

1 The person is a developer. In the field „I'm a“ there is a text „Engineer“or „Programmer“.

2 The person is looking to join a startup. The lettering „looking to join a startup“ is present on his profile page.

Message

Why do you reject proposals to join a startup?

Hello, [Name]!

My name is Dmitri Pisarenko, I'm an experienced software engineer and now want to create a blog,which will help non-technical co-founders implement their ideas.

I asked several of them about their most pressing problems.

One of the most frequent answers was this: I can't find a technical co-founder.

You are a technical person and probably you get proposals to join a startup.

I would be very glad, if you told me the 3 most frequent reasons why you reject those offers.

After I get the answers from you and other technical people on this site, I intend to write a short e-book about how non-technical people can increase the chances that a technical co-founder - like you - will join their startup.

If the idea of the book works out (non-technical startup founders, who read the e-book apply the advice), there will be more sensible startup ideas on the market.

As a result you may get better proposals than you are getting now.

Best regards

Dmitri Pisarenko

Results

I got following responses.№ Text

1 Hi there

Yes I receive proposals to join startups mostly every month 3 or 4. I reject them based on:

1. Plan bad ideas: "A Photo Sharing App that will revolutionize..." 2. No Funding3. People without passion on their own startups.

Thanks to you

2 Hi Dmitri,

Sounds like an interesting project. Here are my most frequent reasons:

1. The idea doesn't solve a problem. It's a lot easier to sell something that solves a problemfor your customers.2. They're not invested. Sitting on an idea (or business plan) for more than a couple monthsis a red flag that they aren't serious.3. They aren't open to ideas. A technical co-founder doesn't just write code, they help shapethe product.

I'd love to see a copy of what you end up writing.

Cheers

3 Some of the biz people dont value technical person as much. They consider the tech personas lacking business sense. Hence dont offer a reasonable compensation or equity.

4 Dmitri,

Many people have no budget and just an idea. Idea which may or may not work out, mostlikely not. They over-value that idea and want you to do all the coding. I'm often notconvinced they can deliver on the marketing part, however, so it seems like a high-riskproposition (well, start-ups are such, but it seems even more high-risk than it should).

Also, we often get to the point where I say "OK, so what do you really want to build? Do youhave mock-ups? Wire-frames? Something drawn on a piece of paper that you can scan andsend to me?"

They say "not yet, but I will certainly draw some very soon". And then disappear :).

Please drop me a link to your article / e-book when done.

And/or just let me know if my experience is similar to others - as maybe problem is with mehaving too high expectations :)

Regards

5 Hi Dmitri,

The most common problems I get with proposals from non-technical co-founders are:

1. They only have an idea. They have zero validation for the market viability for the idea.

2. They underestimate the technical effort it takes to bring a product to market.

3. I guess this builds upon #1 above, but they lack focus. They cannot identify a specificproblem and how they want to solve that problem. This is the absolute deal breaker for me. Iusually at least need to have a pilot customer lined up before investing time and money intoan idea.

Feel free to quote me in your blogs and e-book.

Best regards

6 1) The main reason I reject offers is the lack of business sense. They may have that but theyhave to communicate it better as when I see their profiles it doesn't appear they're strongwith business. Its bad if I feel I have more business knowledge than them and I have minimalbusiness sense. 2) I just don't believe in the product they're after. As a co-founder I have to believe in it. 3) They're asking for a skillset I just don't have. Usually they're after someone to work with aspecific framework and that really limits what coders can do. Just let us code how we see fit.

7 Dmitri,

I'm a full time employed software developer, it's only recently that i've been pondering withthe idea of working on a startup and joined cofounderslab.

I see that the demand for tech co founders are high by the amount of members contacting me

every day.

although i probably don't have enough experience on this to form an opinion I find that thetwo reasons i reject new ideas are

1) the person does not have the minimal technical skills to understand what he/she is takingon.

2) because software development by nature is almost a one sided time-investment in the firststages I cannot afford the liberty to take on a project without knowing that there is a hundredpercent commitment from all sides.

I hope this helps.

Thanks

8 Dmitri:

Your timing is interesting. I only recently signed onto this forum and have been activelyapproached by over a half-dozen contacts in just the last week alone. In addition, I have alsobeen contacted by a couple based upon my LinkedIn profile and another three who havereached me through other referral sources. However, at this point, I only plan to go beyondthe initial introductory chat with a couple of them.

In my opinion, the key to finding a technical co-founder is the same as for maximizing thepotential for success in a start up. I have certain guidelines which I am not sure I really wantto share with everyone. The bottom line is that not everyone is meant to be an entrepreneur,not every start up is destined to succeed, and most business schools do a poor job ofpreparing people for the real world.

Good luck with your e-book.

9 Hi Dmitri,

Yes, I do get proposals, and have recently accepted one after vetting several others.

Here are three reasons that come to mind why I rejected some :1) I didn't believe in the idea/product/company2) I wasn't impressed by the founding team3) Didn't like what I was being offered in terms of the work involved, title, or equity

Hope this helps. Please do share your e-book with me once you publish it.

10 Hi,My top 3 reasons:

1. Potential co-founder haven't done his homework: no market research, no customerinterviews2. Cofounder thinks his idea is unique and he'll be the first player on the market. That meanshe doesn't understand what he's doing3. Cofounder says market is huge and there will be huge revenue and we'll be rich soon. Thatmeans he doesn't know how difficult it is to run a business.

11 Hi Dmitri,

I think your e-book is a brilliant idea. The main reasons I reject offers are:

1. People want to build a massive application up-front... they want to build the full platformand are not clear about what their core business assumption is. They generally use the termMVP but when talking with them it turns out that MVP means the full thing for them.2. Unclear launch roadmap. Many people spend ages describing all the features they want intheir application, but do not mention anything about how the launch should happen, and whothe first customers should be and where to get them. In summary, they just think that bycreating the platform / application and making it look nice, the customer will magically comeand use it.3. I am passionate about technologies and many people contact me to develop with PHP(which is no fun).

Cheers

12 Dmitri,

I'd be more than happy to provide feedback as this is a common irritation for me. Non-technical co-founders often provide flawed proposals. Personally, I receive 20 to 40proposals a week, and, although I attempt to respond to each individual proposal, I tend tofind most provide too little information for a response. It's not uncommon to receive aproposal such as, "I have a great idea. Let me know if you're interested!". With no content asto what that idea is.

Other pointless proposals include, "I've found a gap in the e-commerce market worthbillions." From experience, that just won't be the case and provides nothing constructive. Orthe fashionable ideas; WhatsApp purchase left me with 20 new instant messenger proposalsin my inbox within a week.

As a highly-rated technologist, my priority is innovative and interesting projects.

Regards,

13 Hi, Dmitri --

Thanks for reaching out! Briefly, here are the top three reasons why I reject proposals to joina startup:

1) The idea isn't fully conceived and/or the target market isn't clear/promising2) The venture will require more time and effort than I believe it is worth3) The individual with the idea either lacks experience, or a background check revealsincidents of inappropriate and/or unprofessional conduct

Hope this helps!

Regards

14 In no particular order:

* Only so many hours in a day* Lack of funding* Weak idea

15 Hi Dmitri,

It's good to know about your intentions and this would ease way of finding cofounders.As you have asked for my opinions why I would reject offers to join a startup:1. For me first reason is about my current job, i get many offers where I should leave mycurrent job to join them. Until we have incoming revenues without my job I would be withoutcash till that time. So I am unable to join those startups.

2.Second reason, suppose if I agree to leave my current job and join as a full time cofounder,then there may be problems with equity shares and we may be having conflicting reviewsabout it. I have seen many occurrences where for tech cofounders equity options are notjustified.

3.Last reason is my technology domain, I was unable to join few offers as android developerbecause my area of interest includes asp.net technologies and I have not much idea of anandroid.

16 Hi Dmitri,

the answer:1. i can't imagine that this idea may take off2. concept is too raw3. no marketing plan or any clear understanding how we may sell the project

good luck with blog & ebook :)to be honest i really don't have a lot of offers from non-technical cofounders. so i have tochoose from what i have :) it would be kind of you if you may give me a piece of advice aboutwhere i may find those guys to choose some really good one :)

regards

17 Hi Dmitri,First of all I would like to congratulate you on your initiative to do the e-book.

Frankly speaking I have not had many offers come my way yet..as I am not actively pursuingit.But with whatever experience I have, this is what my opinion is about:

1. Technical co-founders think systemically/methodically about opportunities, exploringpossibilities and ruling out the ones that doesn't benefit the objectives. Non-technicalfounders usually think at abstract levels, try not to get their hands dirty.

2. I feel ego plays a major role irrespective of whether the co-founder is technical or non-technical.

3. Non-technical co-founder in my experience tends to over evaluate the current position /the projected position of the company.

This is what I could think of right now! Hope it will be useful to you!

Wishing you all the best in all your endeavors!

Warm Regards

Reasons to reject an offer to join a startup

№ Rejection reason Count Message Numbers Formulations

1 Lack of validated business model

12 1, 2, 4, 5, 6, 9, 10, 11, 12, 13, 14, 16

Plan bad ideas: "A Photo Sharing Appthat will revolutionize..."

* * *

The idea doesn't solve a problem. It's a lot easier to sell something that solves a problemfor your customers.

* * *

Many people have no budget and just an idea. Idea which may or may not work out, mostlikely not. They over-value that idea and want you to do all the coding. I'm often notconvinced they can deliver on the marketing part, however, so it seems like a high-riskproposition (well, start-ups are such, but it seems even more high-risk than it should).

* * *

1. They only have an idea. They have zero validation for the market viabilityfor the idea.[...]3. I guess this builds upon #1 above, but they lack focus. They cannot identify a specificproblem and how they want to solve that problem. This is the absolute deal breaker for me. Iusually at least need to have a pilot customer lined up before investing time and money intoan idea.

* * *

1) The main reason I reject offers is the lack of business sense. They may have that but theyhave to communicate it better as whenI see their profiles it doesn't appear

they're strongwith business. Its bad if I feel I have more business knowledge than them and I have minimalbusiness sense.2) I just don't believe in the product they're after. As a co-founder I have to believe in it.

* * *

I didn't believe in the idea/product/company

* * *

1. Potential co-founder haven't done his homework: no market research, nocustomerinterviews2. Cofounder thinks his idea is unique and he'll be the first player on the market. That meanshe doesn't understand what he's doing3. Cofounder says market is huge and there will be huge revenue and we'll be rich soon. Thatmeans he doesn't know how difficult it is to run a business.

* * *

2. Unclear launch roadmap. Many people spend ages describing all the features they want intheir application, but do not mention anything about how the launch should happen, and whothe first customers should be and where to get them. In summary, they just think that bycreating the platform / application andmaking it look nice, the customer will magically comeand use it.

* * *

Other pointless proposals include, "I've found a gap in the e-commerce market worthbillions." From experience, that just

won't be the case and provides nothingconstructive. Orthe fashionable ideas; WhatsApp purchase left me with 20 new instant messenger proposalsin my inbox within a week.

* * *

1) The idea isn't fully conceived and/or the target market isn't clear/promising2) The venture will require more time and effort than I believe it is worth

* * *

* Weak idea

* * *

1. i can't imagine that this idea may take off2. concept is too raw3. no marketing plan or any clear understanding how we may sell the project

2 Inadequate compensation or no funding

7 1, 2, 3, 7, 9, 14, 15 No Funding

* * *

They're not invested. Sitting on an idea(or business plan) for more than a couple monthsis a red flag that they aren't serious.

* * *

dont offer a reasonable compensation or equity.

* * *

2) because software development by nature is almost a one sided time-investment in the firststages I cannot afford the liberty to take on a project without knowing thatthere is a hundredpercent commitment from all sides.

* * *

Didn't like what I was being offered in terms of the work involved, title, or equity

* * *

* Lack of funding

* * *

1. For me first reason is about my current job, i get many offers where I should leave mycurrent job to join them. Until we haveincoming revenues without my job I would be withoutcash till that time. So I am unable to join those startups.2.Second reason, suppose if I agree to leave my current job and join as a full time cofounder,then there may be problems with equity shares and we may be having conflicting reviewsabout it. I have seen many occurrenceswhere for tech cofounders equity options are notjustified.

3 No passion 1 1 3. People without passion on their own startups.

4 Don't allow the tech co-founder make business decisions

2 2, 3 They aren't open to ideas. A technical co-founder doesn't just write code, they help shapethe product.

* * *

They consider the tech person as lacking business sense.

5 Don't know what theywant to build

2 4, 7 Also, we often get to the point where I say "OK, so what do you really want to build? Do youhave mock-ups? Wire-frames? Something drawn on a piece of paper that you can scan andsend to me?"They say "not yet, but I will certainly draw some very soon". And then disappear :).

* * *

1) the person does not have the minimal technical skills to understand what he/she is takingon.

6 They underestimate the technical effort it takes to bring a product to market.

1 5 They underestimate the technical effort it takes to bring a product to market.

7 Don't allow the tech co-founder to make technical decisions

2 6, 11 3) They're asking for a skillset I just don't have. Usually they're after someone to work with aspecific framework and that really limits what coders can do. Just let us code how we see fit.

* * *

3. I am passionate about technologies and many people contact me to develop with PHP(which is no fun).

8 I wasn't impressed by the founding team

2 9, 13 I wasn't impressed by the founding team

* * *

3) The individual with the idea either lacks experience, or a background check revealsincidents of inappropriate and/or unprofessional conduct

9 Want to follow the waterfall model in software development

1 11 1. People want to build a massive application up-front... they want to build the full platformand are not clear about what their core business assumption is. They generally use the termMVP but when talking with them it turns out that MVP means the full thing for them.

10 Too little information about the idea

1 12 I receive 20 to 40proposals a week, and, although I attempt to respond to each individual proposal, I tend tofind most provide too little informationfor a response. It's not uncommon to receive a

proposal such as, "I have a great idea.Let me know if you're interested!". With no content asto what that idea is.

11 Lack of time on the side of tech co-founder

1 14 * Only so many hours in a day

12 Lack of skills on the side of the tech co-founder

1 15 3.Last reason is my technology domain, I was unable to join few offers as android developerbecause my area of interest includes asp.net technologies and I have not much idea of anandroid.

Appendix 2: Sample profitability estimateYou can download the profitability estimate from

• https://dl.dropboxusercontent.com/u/11776689/altruix/additionalMaterials/2014_08_30_profitability_estimate.ods

• https://dl.dropboxusercontent.com/u/11776689/altruix/additionalMaterials/2014_08_30_profitability_estimate.xlsx .

It consists of following worksheets:

1. Parameters

2. Expenses

3. Revenue

4. Monthly profit (revenue minus expenses)

Note that expenses and revenue depend on the values of the parameters as show below.

You can change the parameters until monthly profit is sufficiently large (at the very least – greater than zero).

Next step

If you liked this e-book and want to be notified, when I write something new, please visit the URL below and join my mailing list.

http://forms.aweber.com/form/23/1023662023.htm

I won't give your e-mail address to anyone and you can unsubscribe at any time with just one click.

Also, don't hesitate to contact me, if you need help implementing the advice given in this book.

E-Mail: [email protected]

Web: http://altruix.cc

Skype: dp118m (voice calls must be scheduled in advance)

Best regards

Dmitri Pisarenko