1. Become a domain expert - know the problem you are trying to solve inside and out. Know the market size, sales cycles, etc. Make connections in the industry.
2. Find Customers - Bring an idea, along with a 14,000 name mailing list that you generated via blogging on the subject.
3. Bring a design - Actually mock up a set of flows for an MVP. Show it to 20 people, and iterate on their feedback. Find out what is important so when you do start building you build traction right away.
All of these are things that a good "Business Guy" should be able to do and will ultimately be responsible for when they do find a cofounder. Sure, pick up a little RoR or JS, but you aren't going to become a startup quality dev in 6-12 months (or likely more). However, in that same time you could do all of the above many times over.
But, I have HUGE respect for devs. I honestly am amazed at the stuff my staff developer can do. At a certain point I just had to give and say, "Well, I just need to make sure I can attract good developers and treat them like the wizards that they are".
As a "non-technical" person myself, I hate when some frat-boy has a pizza/movie delivery service "idea" and is just looking for someone to build the website. Ughh. I never want to be that business guy.
I think that's why I love Hacker News. It gives me an insight into a world I really respect, and I want to understand as much as I can....without actually hacking.
Not understanding what it takes makes it harder for non-technical people to appreciate talent. You could use your failure here as your selling point.
Of course, now non-technical "frat-boys" here are going to wave the "I tried and I failed" flag, but know that it's not hard for technical people to find out if you really tried or not.
I do all the mockups and am orchestrating the product development, but the more I learn about programming the more I learn that a single extra box on my "mockup" can mean hours and hours on the backend.
It's so easy to do a mockup and say, "this is how it will work"...turning that into an actual application is where the magic is.
disclaimer: I'm mostly a back-end person, and I appreciate how difficult it is to not have sense of design, and I don't take good design work for granted.
That being said, at least to me, knowing even a layman's amount about programming will gain major points with the potential technical co-founders you do meet.
I get approached by friends/acquaintances on a weekly basis with some startup idea. And I mostly think, "So basically you're suggesting I spend 10 hours a week of my free time for six months to build Facebook For Cats, while you make some half-assed attempt to do some marketing or whatever, and if there are any technical issues I can't even discuss them with you because it'll go over your head, and if there are any tedious technical issues you can't even help with those." It's pretty much a non-starter right there.
But knowing even a little bit about programming could go a long way. It means your idea is probably a little bit better than "Facebook For Cats," because maybe in programming you learned about some company's API and how to leverage it. It means I can split up work and give you some of the easier programming tasks and feel like we're putting in close to the same effort. And it means I can tell you things like, "the service doesn't always return well-formed XML so we should find a validator and then run it on the response before we insert it into the database," and you'll know what I'm talking about.
It all starts with the product, and the product usually means code, and having one and a half heads coding will usually be more productive than just one. Learn enough to be that half a head and you'll go far.
Really, I don't want to discourage anyone from learning, but suggesting that you can learn enough to launch a startup is kind of like deciding that you can do web design because you've used Word. Some people will be able to pick it up in a month, and some will never learn to write decent code.
There's a reason people pay me to sit and stab buttons on a keyboard.
In six months you can easily pick up the basic ideas need to converse with someone about technical issues, and at least understand what the other person needs. Maybe you'll even learn enough to help out and create the demo, or something.
a.) Someone who says they have a 'killer' startup idea but no technical ability to execute it.
b.) Someone who has an idea and has already executed a working prototype of that idea for you to check out.
If so I would take the one that can handle that side better.
The first iteration of a startup will almost always be wrong and you'll have to throw most of it away. So it doesn't matter so much whether its the best code in the world or not. The important thing is that you learn from your first iteration. If you don't have a tech background and hand off the first implementation to a superstar, it's very possible that you won't learn anything. If you do it yourself, you will learn a lot one way or another.
Also, it helps in many ways to be able to demonstrate that you are not an idiot.
Being able to call BS from your developers or a perspective co-founder doesn't require you to be a programming god.
I am a developer that hangs out in startup circles and I get approached several times a week by "idea / business people" if I'm interested in joining a venture as a technical co-founder. My answer so far has always been no.
It's very hard to convince someone that your idea is golden. Even if you do find a co-founder, it's even harder to instill your ideology and passion into them. You should be founding projects with people you know already, not strangers. You don't want an employee -- you want a missionary.
Many non-technical people seem to think that developers lack creativity and need their guidance. What gave them this illusion? The majority of great web products came from people who could write a prototype. Do that and you'll attract attention from developers who will want to join your project.
Writing a prototype is not rocket science, and if you'll try it, you'll also see that programming is very fun and rewarding. Kate Ray hits the nail on the head -- all you need is regular old hard work. I started programming when I was 12 and it's not because I'm Doogie Howser. I just wanted to learn it, so I did.
YES IT IS.
LEARNING to program, with the goal of building a prototype or MVP to attract interest (investors, better devs) is not hard.
Programming WELL, as in solving large technical problems, is obviously hard. But how many founders stay on as technical leads?
I saw Dennis Crowley (of Foursquare) speak a few weeks ago. He and Naveen built the prototype and as soon as they generated some interest, they hired Harry to be the dev lead so he could "fix up their crappy code."
The code for your prototype is allowed to be crappy. It probably SHOULD.
Coding takes an immense about of focus, mental energy, and perseverance. You have to love solving problems. Sure, you can teach yourself basic if/else statements. But there's a threshold when coding becomes extremely difficult, especially when it comes to complex algorithms and mathematics.
I've been a tech co-founder a few times. If you can't convince me -- someone who wants to be working for a successful startup -- that your idea is worthwhile, I really doubt you will be able to convince users and investors either.
Do things in whatever order you'd like, but I have a hard time believing that time spent learning to program, starting from zero, is an effective use of an entrepreneur's time.
The larger issue? The technical illiteracy of the general population. Knowing how to point and click (and nothing else) has brought user's expectations down to a point where they think some piece of functionality that takes them three seconds to interact with is a one hour unit of "coding" when in fact, it's more like days worth of thinking, typing, writing unit tests, and debugging.
My cofounder ATM is handling all of the business, marketing, and customer interaction. She only won my allegiance though because she is technically literate - not to the point of my expertise (otherwise she would be doing it herself) but she does understand that those 40 hours I just spent last week on writing unit tests is worth it instead of breathing down my neck about "let's launch it in a week, this has gotta be ready to make money once it launches, users are expecting it in a week, you just spent a whole week coding and I don't see any changes or updates...".
Kudos to KateRay for taking the reigns; I sincerely hope she/he finds as much joy in programming as I have and do. I also know that in the future, she/he will be more technically literate for a serious programmer to actually be interested in working with her/him.
My only con about this post, as hinted at above, is that it makes out what we [programmers] do to be: "yay I've read the RoR book now I can program!"
I tell everyone that asks me about finding a technical co-founder to just learn the basics of databases and a web language (PHP, Ruby + Rails, Python + Django). Either 1) you'll actually learn enough to make your MVP or 2) you'll learn enough to figure out what your product really is and what to look for in a technical co-founder. If you don't have any clue what your technology portion is going to look like, you aren't very attractive to technical co-founders and those that are interested probably aren't the best fit.
Sure, a "can do" attitude is great, and coding is very learnable, however we are talking about Founders starting a business for profit here, where time is actually of the essence in many cases. A linguistic example is how one can learn survival French in a mere 3 months, but true fluency takes years.
I think it is important to realize there are people who are amazing at doing exactly the things you need done, and though you could learn to do it fairly well yourself in a short enough time, why re-invent the wheel? This holds especially true when a seasoned hacker has much more than just recently learned skills but also has a mental roadmap of pitfalls and work-arounds from their years of experience. No amount of study replaces years of "muscle memory" from projects that have both succeeded and failed.
So, about five years ago, I learned how to program.
And the really fun thing I discovered is that I enjoy programming about as much as I enjoy creating user experience. The passions become entwined in way that's meaningful and fun.
No matter how far you take it, understanding programming is going to pay off if you want work in the software business, startup or not. You'll often be able to participate in the problem solving process alongside your technical colleagues, understand when you're being bullshitted, and maybe even prototype things to prove your arguments.
And maybe you'll think it's fun. As long as you're comfortable taking a few years to get there, this is great advice.
Edit: note that attaining a reasonable level of skill in technical matters will pay huge dividends, especially in hiring. There are currently no objective measures for determining developer skill. The better your technological chops are the better you will be at determining the skill of potential employees / co-founders. Making sure your startup is populated by the most skilled engineers can make all the difference between success and failure.
Founders care about their companies the way parents care about their kids.
I've seen this asymmetry cause some issues where founders don't get why their employees aren't as enveloped in the company as they are. A respectable salary and less than a percent of the stock doesn't get the same commitment as a founder does.
I'm certainly going to be following the path suggested by the OP. I've already been thinking about it for a while.
Me and a friend, both non-technical, started a service oriented company 6 years ago.
Now we're switching our focus to SaaS and even have some $$ to pay contractors / employees...
But how do we evaluate talent?
How do we delegate?
How do we understand (much less give input) on technical decisions?
What happens when (not if) they leave and move on?
Being vulnerable to and leaving that much decision-making responsibility to 'employees' who aren't invested like you are is a recipe for failure - entrepreneurs make things happen and get things done, but how much of that can you do if you don't understand the core of what your business does - software?
All of which already have high paying careers. They're young enough to defect, but only if they have a chance to make their mortgage payments.
Getting to know your way around a language like Ruby isn't all that hard.
As a technical person, I run into people all day long that have 'big ideas' which are often mashups of existing sites, "Its like Facebook for FOO", and will never find a technical co-founder because they don't have any idea what the scope of the real problem is, or how to distill it down to something small, useful and graceful. Lots of ideas, but having an idea of implementation is great too.
I strongly believe being really good at one thing means you shouldn't try to multi-task or wear too many hats. That's counter-productive and recipe for moderate work quality. At the same time, the early days of the startup are the most fragile times. The business guy who speaks engineering or visa-versa will have a huge competitive advantage.
The spirit of this post is admirable, but rather than producing more successful startups it will likely only spur the unqualified but ambitious to create nasty spaghetti-coded PHP monstrosities with gaping security holes, which will only serve to make the public at large less trusting of web apps and startups in general. Steve Huffman was a Real Programmer when he wrote the first version Reddit; heck, he even used Common Lisp! ... and he also stored user passwords in plain text. Imagine what those with even less knowledge and skill are capable of doing.
In closing, the people here are either:
a) much smarter than I am and much faster learners;
b) trying to falsely give others the impression of (a);
c) too optimistic;
d) or don't remember how bad a programmer they were when they first started.
Being aware of the basics is a huge advantage, but after some serious time invested, don't ignore that coding really may not be for you. It is going to take you forever to get up to speed. You may waste a lot of time and it may become a big mess. It is more beneficial to find a technical co-founder, code less, search more. You also may find that you're a born coder, and it is an extremely valuable to continue going at it, keep coding.
I studied Engineering Mechanics for 6 and a half years, so I'm not exactly non-technical, but when I finished and was trying to start a company, it had been probably 6 years since I'd taken any serious programming (or taken a programming class), and I knew nothing about web technologies. When I originally met my now co-founder, he had an up-and-running website generating revenue that he had started building at 16, and developed entirely on his own, from scratch. (He stored all user data in a plaintext file until he learned about databases.)
When I first approached him about starting a company, he gave me the same line he still gives many others who ask him to join about being very busy with his own projects. So, I went home and started myself. I remember coming across a page on Wikipedia about "relational databases" and thinking "yes, this is what I'll need." So, I downloaded some MySQL software and put together some database architecture, then made some storyboards in PowerPoint, and came back to him a week later. He was a little impressed, but still said he didn't really have time to work on this.
So, I went home and bought a ROR tutorial book and built the Pragmatic Programmer Bookstore model, then changed some colors and page titles and went back a week later and met with the co-founder again. This time, a little more impressed, he agreed to help me put together a really basic MVP that I could use to pitch investors.
In the meantime, I had met with a local group of angel investors, and was accepted to pitch, at an "angel live-fire" session at an Entrepreneurship Summit in town. So, seeing as this thing was going to be presented to a group of potential investors, we both had a bit more motivation to work kinda hard on it.
Through this time, we became really good friends, and he finally became convinced that I'm not just some random non-technical person trying to start a company, that I'm really willing to do what it takes. So, a month later when we were accepted to a seed program and took investment, my co-founder deferred an internship at MS to the Fall in order to spend the summer on the startup with me, then turned it down completely when Fall came around and things were going really well. I've also learned a ton about development from him, and we've put together an MVP really fast that we're rolling out in a few days.
The point of this story is that if I had accepted his "no" and not tried to do it myself, he wouldn't have joined me, and if he hadn't joined me, we wouldn't have had a demo to show investors, and we probably wouldn't have a startup right now. So, "Learn to Code Yourself" doesn't mean just found a company yourself, it means that you do whatever you have to do to start a company, and if people see that you are that hell-bent on making progress every day, they'll be more likely to want to join you.
I will say no single effort has been more enlightening to me regarding computer science than trying to understand C. I highly recommend it to anyone with any programming experience.
If you have a prototype/demo and some level of traction, you can much more easily attract better technical talent.
- domain experience
- a good network in the target market / sales leads
- ability to manage customer relationships and close sales
- good communicator
- familiarity with software development process, even if as an outsider
The caveat here is that my interests lie in business systems, not in doing the next Facebook/Twitter/4sq clone.
I generalize of course, the best person I've ever worked for was a non technical founder and he had an uncanny ability to understand this stuff at some level despite no direct experience in it.
Jobs chose Woz. If you can't find good people and get them on board with your plan, no web app or meetup will save you. Go out. Meet people. Choose the best guy whose company you enjoy and make friends.
Still lots to learn but at least I can put out a decent app in a few weeks time.
Should have done it years ago but I guess it's not too late to learn...
Just a couple of hints: don't store your users passwords, don't trust inputs from your users and enjoy yourself.
Thanks for your tips.
You think you got a minimal feature set for your project? Think again. Cut it in half.
I have a travel site as my personal project, and I still don't have the ability to select the dates for when you're traveling. Sounds crazy, but it's something that not many of my users have asked for... yet. It probably helps that the main focus isn't about selecting dates you want to travel, however.
Yet it's unlikely you're going to master a given language within a few months, so there may still be room to seek out someone who has had experience with it for a long time.
tl;dr Learn how to code, but there's still a time to work with longstanding hackers.
While it's true there have been people that have been good on both sides of the fence: coding and selling (Bill Gates)
Some people are just not technical people, and are not meant to code because they're just more cut out to sell, market or pitch ideas to people.
One of my good friends is a person who is comfortable socializing with clients, and is a very persuasive salesman, but he is not a coder; never was and never will be.
That's kinda what I was hearing lurking around HN for the past 6 months. I've never written a line of code in my life but 3 weeks ago I stopped looking aimlessly for someone with skills, and I'm back to the drawing board learning Ruby. Of course, I'll almost surely still need a technical co-founder in 6-10 months. But I'll be in a better position to see if he's good and I'll understand what he's doing. Also, I'm meeting lots of programmers this way. If all I get out of these 2/3h per day is a great co-founder, it'll be very well worth it.
As a noob, I find the stuff suggested on the post a tad intimidating. It was good for me that my first contact with ruby was the very soft http://tryruby.org/ and the second one was Chris Pine's book http://pine.fm/LearnToProgram/?Chapter=00
Works both ways, too. If you don't know enough finance to understand a cashflow model or enough about writing to appreciate how to craft a pitch (or put together an effective landing page - whichever matters for your business), then you aren't a founder, you're an employee with a fancy title.
This is a high bar, but foundin' ain't easy.
One that kept popping up often in my search was "Python." Consensus was that it was pretty user friendly. Plus, the guys at Dropbox built their application with it...if it's good enough for them, it's good enough for me. I say, just pick one and get started.
This is because I'm at an advantage. I can easily learn and do whatever it is they know and do. Things such as marketing, refining the UI, feature ideas, user interaction, etc. These are things that are MUCH easier to do and learn than programming.
I would not start a company with anyone who wasn't an EXCEPTIONAL programmer. No, a weekend programmer will not do. Honestly, you'd have either provide funds, or something of extremely high value for you to receive equal ownership of any company I spend my valuable time and work on.
The only time I would recommend you spend your time learning how to program is if your roadmap includes hiring programmers better than you to improve or redo the code. You'd have to build the prototype yourself, get funds, hire good programmers and take off from there.
Other than that, I wouldn't automatically join your project, even with a prototype.
"Personally, I find no use in people with simple technical skills. Not even if they can program a time machine into a Commodore 64."
"This is because I'm at an advantage. I can easily learn or hire whatever technical skills they have. Things such as coding, databases, server architectures are trade skills and basically a commodity. These mechanical skills are MUCH easier to do or find than imagining a valuable product, finding a market and customers, selling the product, and building a business."
Etc, etc. Undervaluing the contributions of other fields such as sales or marketing is the mark of someone with little real-world battle scars, regardless of the direction of the contempt vector.
Unless this was satire, in which case Bravo.
I'm not 'undervaluing' the skill I'm simply weighing them and engineers win.
'the mark of someone with little real-world battle scars....'
The opposite is more true with engineers, we hate it when we are shown products by people without the 'battle' scars to properly gauge the value of a project.
Like I said, I can more easily learn those lessons than they can learn to program.
I, as a 'technical' person find absolutely no value on someone who doesn't understand the deep technical implications of any project. As a team we'll learn the marketing. In the end, we can outmaneuver any silly person with just ideas that delegates them.
BTW, this is my opinion. Not to say it won't work, that's just how we 'technical' people see ideas people.