It depends how clear your idea value is without it, or with a rough one, or mock ups vs polished. There are a few goals you are trying to conquer with a prototype, overall its about concept clarity and valuation. 1. customer/investor acceptance: "i want that" 2. customer feedback: "you should ...
I think the main reason would be the obviously mis-perception of the value of your company. I do believe people still look at crowdfunding sites like kickstarter and indiegogo as hobby or fun-type of investing as opposed to serious investment. Another reason would be the amount of investment doll...
By not focusing on being the CEO for the name and focus on your customers, employees, and the services you offer.
There is no formula for that. Read as you need to. Have your mentor(s) suggest books that are specific to your needs. A good starting point might be one relevant book per month to start. There are also those book summary services that can give you the themes of the books in 5 minutes of reading. ...
I think that the answer is dependent on the level of technical talent that is already on-board. If you have an engineering focused squad, you can get away with rudimentary understanding. To your description a "non-technical CEO" is just that. Of course, whenever there is a gap in the team, it is ...
Agree with Chris (Above). Here's my 1-2-3. 1. A warm intro is brilliant - especially from a company they funded before OR missed out on that did darn well. 2. Keep answers short, but loaded to enlist questioning from them. This creates a discussion rather than a bombardment. Ask them questions...
Have a product that users / customer are using and continue to use. The goal is to derisk the opportunity for investors and the biggest risk is that you'll build something that nobody wants. Once you have that, then try and find a big enough market and opportunity that justifies a venture inves...
Mashable is the best blog a tech CEO should connect with. There are literally hundreds of books to sort through and you need to find books specific to what you are doing and what you will connect with.
Usually Programmers are only slow when they don't know how to solve a particular problem. So they will spend a lot of time researching and a lot of trial & errors to solve a problem. It is important that before you engage a programmer on a project, you break down the entire project into simple, e...