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.
BUT I do believe it is easier if you do know how to code.
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.
It is like saying a given business which sells through the phone is about phones. Phones are just a way of doing it.
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.
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.
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.
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.
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?
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.
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).
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 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.
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.
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.
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?
