>>I am not a developer, but I believe having an idea -> finding a developer is the wrong flow. It should be like this: 1. Have the idea. 2. Get customers who give you real money to build this idea. 3. Get a developer by telling "I already have paying customers".
Actually, I disagree. Even if you're not a developer, you should still strive to learn enough development such that you can push out the first version of the product yourself, even if it's imperfect. Doing so will have several advantages:
1. It will make it easier to find a developer (they will respect you a lot more)
2. It will make it easier to get customers
3. It will make you appreciate the technical aspects of the business
Number 1 is the most important. The reason non-technical people have difficulty convincing developers to work on their ideas is that developers tend to look down upon non-technical people, especially "sales types." In addition, most developers have a thousand ideas of their own - you need to give them a reason to work on your idea instead. And that's a lot easier to do if you already have a version 1.0 out there that you have developed and have customers paying for it.
And I would disagree. I think you're underestimating the time and effort required for a complete beginner to produce version 1 of any non-trivial product.
As a developer what I'd be looking for before coming onboard is a) a clear idea of what is being built b) that there is the money in place to pay me.
I would also disagree. I've almost finished v1 (literally, a bare bones MVP) of my SaaS idea, and my God, it took so much more time than I expected. And I'm a veteran developer who's shipped tens of projects.
The thing is, there's a lot more that goes into a viable product than just the core features.
Completely agree! For my start-up, beyond the core features, there's been a versioning system, front-end framework, database set-up, server maintenance, keeping up with patches to your coding language, fine-tuning CSS, analytics packages, user feedback tools, and that's just the list that I came up with in 10 seconds. In reality, there's actually much more.
> The thing is, there's a lot more that goes into a viable product than just the core features.
Yes, yes, YES! I'm doing this now, and just figuring out the "business" side of the product code is so much more work than the core idea (which is simple to code).
And getting the actual sales/marketing/accounting/admin/etc stuff is going to be 10x worse, I am sure.
>> The thing is, there's a lot more that goes into a viable product than just the core features.
This! I agree wholeheartedly, a useful tool/hack must travel a long road before it can become a product. Even if it's essentially solving the same problem.
In my experience of being a developer and building my own idea I actually found there were occasions when my inbuilt technical idealism caused me to make some wrong decisions on my product. I found it quite difficult to make product decisions independently of technical ones.
I've had some really good bosses who couldn't code, though there is certainly a skill in winning over devs when you're not a programmer yourself.
There are advantages to being a non-technical founder, if you're able to bring the right techies on board.
I agree with some of what you say (e.g. a non-technical founder that learns some technical aspects of the business will be more respected).
Though in practice I've experienced too many cases where I couldn't imagine non-technical founders I've worked with learning enough, and fast enough, to launch a v1 on their own. It's possible, but between OP's suggested flow vs. yours, I'll side w/the OP's. As a developer and co-founder, I'd much rather a non-technical founder concentrate on finding paying customers (or other cash flow), marketing, becoming immersed in the target market, etc. than learning how to code.
To supplement, the article's Where it went wrong and Where it went REALLY wrong sections cite non-technical reasons for failure. So while you raise great points, it's not clear that the OP's situation would have been better if he had learned to code first.
I agree with enraged_camel, but not for the straightforward reasons. First, as a non-technical founder who recently learned (basic) coding skills, I can confirm his first and third claims - learning to program does make it easier to find developer support and it will greatly improve your appreciation for the technical aspects of the business.
However, most important should be the second claim since learning to code will help you build a crude MVP, allowing you to reach customers and validate your idea. In this sense, enraged_camel and OP are both correct because they both point back to the same concept of reaching customers.
IMHO though, it comes down to what value a company is providing. If it is a tech start-up where the software product is the main value-add, then a core competency must include programming. If it is a real estate start-up with a website, then learning to code can probably be pushed off in favor of customer development. So in the OP's case, the question would be, are we in business to build a SaaS tool to help teams or are we satisfied helping team management improve in any way possible?
I suspect the reason non-technical people have difficulty convincing developers isn't so much about respect but more to do with the idea itself and the person presenting it.
Its come to a point that hiring development staff for web based applications isn't that expensive if you focus on hiring people that aren't in North America and don't need to use the whiz bang language or framework (I would put even Ruby on Rails and Django in this) but instead use PHP.
What I do think is important for non-technical founders is to have an understanding of what software development actually involves, so that they can judge and critique the work. It's worth knowing why a company might quote you, $10K for some work versus another $50K. Is one company using PHP or ASP.NET? Does one company's quote include all tasks such as requirement's gathering, mock-ups, development and production deployment. Where does system testing and end user testing fit into all of it? What's the hosting costs after the fact. Are they using Rackspace, AWS or their own provider and charging $300 a month for it.
I think a smart person can take a good 30-50 hours and read up on all this and get a good grounding as there is no lack of materials to get this knowledge from. I don't need to know the intricate details of how to build a car to appreciate the manufacturing process for a car. We all know there are many makes and models of cars but the design and manufacturing, distribution and sales of cars follow similar patterns (not taking into account the new entrants such as Tesla).
As an added check, a non-technical founder should find a trusted technical person that can help guide the development of the product even if the technical person themselves won't build it.
I think doing this would go a long way to get something built and off the ground. It's easy for a lot of us who have grown up with technology and understand computers, the internet, programming languages, algorithms, software development etc. but for the non-technical person who grew up as a user of the tech not but not a tinkerer its hard to catch up and go beyond and build a product (even an MVP).
Interesting! Indeed if you work with freelance developers, or you work as freelancer, getting "quotes" is quite some work, and understanding if it is a good price or not, also.
As I am working on a side-project trying to help others with making quotes, would you have some time to chat more?
If the founder is a developer, yes, I totally agree. But for business person, no, I don't. Just like OOP programming, I think a team needs to be comprised of unique committed talented professionals that can do their own job very good: marketing, sales, social networking, programming, designing, business managing, legal, etc. (skills might overlap).
Even if you are Jack of all trades, you won't have the time to execute all the tasks well on your own. If the developer looks down on you because you don't know how to code, then that is not your ideal candidate or your business or talent is not convincing enough.
It is true a team ideally is made up of experts in different areas.
It is true having technical skills can make it easier to hire developers, get customers (only one way to make this easier), and appreciate the technical side.
If a 'developer looks down on you' why does this not make them an 'ideal candidate'?
And what is the value of an ideal candidate? Is finding one even possible? Isn't 'the ideal' hard to reach in anything? My ideal life is to make millions while making the word a better place, have a six pack, lots of interesting friends, write rap, write a novel, have an uberman sleep cycle and not go crazy, and have many beautiful and intelligent woman.
Isn't 'ideal' more of a standard then an actual possibility? If so, isn't not the end of the world if this developer is not ideal? Don't you only need a talented developer who will do the work that is asked of him?
And what is 'business or talent ' not 'convincing enough' for? (hiring the developer, creating a business etc..)
It'd be great to fully understand your point of view.
As a developer and solo founder, I just can not finish a serious project in one year.
For example, it took me two years to get version 1 of torapp guilloche designer
(www.torapp.info). We did not get consistent/significant customers and we need a new product to survive.
To evaluate more ideas and to be familiar with respective areas took me another year easily (without deep knowledge in the area, how can you beat your competitors?).
So how can you guys roll out a product in 3 months? How can you quickly pivot?
>So how can you guys roll out a product in 3 months? How can you quickly pivot?
Tooling. To elaborate, if you're hand writing code to call an API, then you're doing to much. This is a 15 minute task at most, and that includes production level validation, security, etc. on both the client and server.
Also, basic code quality checks should be running non-stop in a separate terminal and automated tests should also be running. Plus the core automated tests should themselves be automated.
Developing an API is again a 15 minute task.
To be totally clear, proper tooling will take you from prototype to (early) production. Obviously, tooling does not write your application for you, but standing up a basic app where you can use the UI and move data to/from the backend needs to happen with a minimum of effort. Once the core design/structure is done, you can spend your time on value add activities such as UI customization, custom business logic, and so on.
In fact I am learning how to program, so I agree with your points - but I don't think it is for every one. There is plenty of space for non tech founders.
BUT I do believe it is easier if you do know how to code.
"There is plenty of space for non tech founders."
In the tech startup ecosystem, I don't think there is that much space for founders that don't want to code.
Saying "I want to start a tech startup but I don't want to code" is as ridiculous as saying "I want to sell horses but I don't know anything about them and I certainly don't want to have to learn anything about them".
It's possible, but you're gonna have a hard time doing it...
Saying "I want to start a tech startup but I don't want to code" is as ridiculous as saying "I want to sell horses but I don't know anything about them and I certainly don't want to have to learn anything about them"
I disagree. Not wanting to code is not the same as not knowing anything about the product, or wanting to. There's so much more that goes into a successful product or company than time spent coding (marketing, design, testing, sales, industry/market immersion, etc.). As a developer and co-founder, ideally I want complimentary skill sets. Being able to write code may be an overlapping skill, but it's not required.
I disagree because most "tech business" are empowered by tech, they are not ABOUT tech. My business was about team management/leadership, we just used tech as a means to an end. We could have done the same thing with consulting, but decided to get scale using the web.
It is like saying a given business which sells through the phone is about phones. Phones are just a way of doing it.
Definitely a good analogy, but I think your conclusion is wrong (although I do still think having a non tech founder is not ideal). If you only want to sell horses then not knowing about horses is going to be a tough time. Same with trying to sell some kind of programming tool or something. However, as soon as you start to do something involving horses and not just selling them, it opens up a bit more.
Instead of just selling horses, you can make a startup that makes it easier for for people who want to ride horses but can't to ride them. You could have a stable with restaurant to let people watch others ride them, etc. Simply because you don't know about horses is not the problem, because the problem is finding ways to bring people to horses based on the public's opinion of horses. Your horses don't need to be looked after by the world's most knowlegable horse lover, just someone who sort of knows horses and is willing to learn will hopefully keep your horses in good enough condition until you can hire more horse caretakers.
This analogy works very well for tech startups too. You don't necessarily have to know how to make the website, it can be enough to know how to create something around the website (physical deliveries, or whatever) and just get some bare-bones barely functional web presence that you improve when you get traction and funding.
The thing is, non-tech founders rarely have ideas for tech startups. They usually wanna do real estate startup, social network startup etc. which just uses tech as a tool.
Agreed. You need founders who can turn their hand to anything, not just their primary skill.
I ran a startup back in 2005 with another founder who was primarily focussed on marketing. It was a SaaS that was heavily dependent on data which had to be manually maintained. When he said "I'm not going to sit there wasting hours of my time entering data when I could be selling" it was the beginning of the end. From then on, I couldn't trust him to help out when needed.
We folded in 2008.
Actually, I disagree. Even if you're not a developer, you should still strive to learn enough development such that you can push out the first version of the product yourself, even if it's imperfect. Doing so will have several advantages:
1. It will make it easier to find a developer (they will respect you a lot more)
2. It will make it easier to get customers
3. It will make you appreciate the technical aspects of the business
Number 1 is the most important. The reason non-technical people have difficulty convincing developers to work on their ideas is that developers tend to look down upon non-technical people, especially "sales types." In addition, most developers have a thousand ideas of their own - you need to give them a reason to work on your idea instead. And that's a lot easier to do if you already have a version 1.0 out there that you have developed and have customers paying for it.