Finding A Tech Co-Founder — Startup Analytics

Finding a tech co-founder is hard and pre-assumed to be the first step in the process of building a startup/project when in reality, it comes way down the order.

Always deliver more than expected

Larry Page

Having done dozens of side projects and collaborated with multiple non-tech and tech (web development in this context). I have come to an understanding of what building a tech project is and is not.

Every firm today is a tech and data-driven firm. This goes without saying in today’s world. Despite the ubiquitous nature of tech, it’s weird that non-techies find it hard to reach out to tech folks and make things work.

In today’s age when building the product in a bootstrap fashion, the non-tech folks need to go beyond a mere idea and come back with valid data to able to convince the tech co-founder to work together. You need to validate the market and provide the evidence before the specific tech founder.

• Jobs and Wozniak met at a hacker group for computer nerds.
• There was a defined and specific need for an integrated computer system.
• Collaborated to first build the prototype.

Doing this exercise as such will allow one to do both the homework and at the same time save valuable time in terms of figuring out what to build. Because, once you define the problem, you can find your tech guy by hanging out in forums, conferences or groups which solve or revolve around the problem-solution space.

Customer -> Problem Statement

Even though all firms and businesses are tech-driven, the initiation starts with business and primarily starts with the customer in mind. 90% of my dozen side projects failed because of not starting with the customer in mind. By simply, doing this, one can avoid building something which has no need.

All greats ideas, IMHO start from a deep understanding of the specific customer base and their specific problems. Start with the single pain point instead of trying to solve 4–5 problems on the one go.

Post getting a good understanding and a belief that we have a probable use case, the next thing to look for is a well-defined problem statement with clear specifics. This helps us to frame the problem as a hypothesis that we can validate.

Problem Statement -> Community/(User Research)

Post an understanding of the problem statement and customer. The next step is to build a small community of users or join them. This can be executed as a user research exercise, where one talks to multiple users (possibly 100+). Not sure how to reach, the first set of 100+ users, you gotta fix this problem first.

This helps solve a couple of problems:

• Is the pain point genuine and an actual issue for several users.
• How can one go about reaching out to them?
• A ready-made user list to test out the beta version of the product.

Just carrying out this much of an exercise, allows one to quickly validate key aspects of the problem statement and the distribution. Having this 100+ user base is absolutely necessary to ensure, you are building the right thing. This cannot be emphasized enough. Read this book on how to talk to users.

User Research -> Finding a Tech Co-Founder

This is the phase, where once can finally embark on finding the tech co-founder. Given that we have a problem statement along with an understanding of the first 100+ users. We know what a working solution will look like.

The next step to do post this would be to write a document compiling and putting together all this information in the form of a HEEL.

• You had a hypothesis/idea with a specific customer in mind
• You ran an experiment (user research) by talking to these users.
• Understood the experience post this
• Took your learning from the entire experience.

The next great idea is to go beyond this and use a no-code tool to quickly put together a hack app using a no-code tool like Glide. This is a basic tool of all concepts/items within a GMAT exam and counter for a number of times the concept came up.

The amazing part of these tools is that despite being very simple, they will expose the non-tech folks to go an understanding of what an app, the solution will look like.

All basic apps are in some form a type of CRUD.

The App above uses an excel/google sheet at the backend. All the list does is either create an entry, read it to display, update the counter and finally delete an item/concept from the list.

While this has limited functionality. Taking this to users and getting feedback will help with understanding what this lacks and the specifics on what to improve on going forward.

For a more complicated product/functionality. Go out and spin out a Figma UX flow. While a functioning product, we close the loop on what the flow and working solution might look like.

This also helps build empathy with the tech co-founder when building out the product.

Reaching Out

Now that, we have done our homework and survived the tough challenge of user feedback and build the design prototype. It’s time to reach out to the other end of the problem, reaching out and convincing a good tech guy.

Our job is a little easy now, given that we have done some groundwork and should be quickly able to provide all evidence/data for our idea. This ensures, we reduce the number of reasons, why someone can reject us. The pitch becomes a lot more clean/smooth.

• The basic idea is not up to their alley
• The data/evidence is not sufficient
• Tech stack needed is not relevant or of interest to them etc

Based on the feedback and the plausible tech stack, we can iterate over the idea or try to collect further information.

What are the exact places to find these people?

• Public/Open Hackathons
• Developer Oriented Forums (Reddit/Hacker-news) specific to the problem
• Open Source Projects (Github) pertaining to the problem.
• Product Hunt Makers
• Ask a friend, refer to peeps.

Though these are all decent places to start people, try to see if you can get someone you have either studied or worked with together. Despite covering all these basics, there are multiple other ways, things can go wrong.

• Your working styles are different
• The developer is not synced with the required tech stack
• They are not motivated enough

And so on…

What do you do when one of these happens. Rinse and repeat. Figure out the issues and iterate by solving for the specific issues. You should be able to improve your odds of succeeding.

If you are very clear and gone through this exercise and still looking for some developers. You could drop a note below and I might be able to introduce you to some interesting folks as well.

Originally published at https://startupanalytics.in.