Where can I find top notch Lamp Stack engineers with the business know how and VC connections?

The more important first impressions to leave a VC with are: 1) That you both are credible and inspire confidence that you can execute the plan you're fundraising on. 2) That there is good chemistry and a great relationship between the two of you; 3) That you can adequately address the concerns/objections/questions the VC raises. The CEO is expected to do most of the talking because the CEO should be the best person in the company at articulating the vision and value of the product and company you're building. If your CTO is comfortable presenting part of the pitch, it would be ideal for the CTO to speak to the product slides. The most important thing is for the CTO not to be a "bump on the log" meaning that you don't want them sitting there for most of the presentation with nothing to say. If you feel that's the case, you really shouldn't bring your CTO. Most VC meetings will not get technical and under the hood. Each question answered should be answered by the person best qualified to speak to that question. You should make eye-contact with your partner and use subtle body language to find a way to cue the other person to speak to that question or simply offer "CTO, would you like to answer that?" Bottom line, make sure that the CTO can speak confidently enough about the product and vision, otherwise -unless specifically asked by the VC - come alone. Fundraising is a big distraction to building and a good VC will always respect that in a first meeting, the CTO can be excused from attending in priority of building product. Happy to talk to you both on a call about helping get you feeling a bit more confident and prepared before your meeting. I was formerly a VC associate for a $500m fund and have raised money from VCs as a serial entrepreneur.

If you want information that matters in "Creative Financing Techniques" find a person with the experience/insight. Most of what is in books is dated. Many of the more creative methods are a function of current tax code and market factors (like QE).

You are right that the range is wide. You need to figure what are good values to have for your category. Also, you can focus on the trend (is your DAU/MAU increasing vs decreasing after you make changes) even if benchmarking is tough. Unless your app is adding a huge number of users every day (which can skew DAU/MAU), you can trust the ratio as a good indication of how engaged your users are. For games, DAU/MAU of ~20-30% is considered to be pretty good. For social apps, like a messenger app, a successful one would have a DAU/MAU closer to 50%. In general most apps struggle to get to DAU/MAU of 20% or more. Make sure you have the right definition of who is an active user for your app, and get a good sense of what % of users are actually using your app every day. Happy to discuss what is a good benchmark for your specific app depending on what it does.

I am assuming your question is more pertaining to empowering and motivating (rather than hiring). I can outline some of the practices I have seen really result in high motivation and sense of ownership among engineering teams: * Empathize - Your engineering team will work well and be more motivated if they see you as one of them rather than a person who doesn't understand their function. Show your geeky side to them, and show that you understand their thought process and drivers. * Pick their brain on big and small decisions (roadmap, usability, whatever it is) - Product teams value being heard. The more you position yourself as someone who is WANTS to listen, is keen to have their inputs, you will be surprised at how involved they can get, and also how you can actually tap into a lot of smart ideas/thoughts from them that you can develop on. * Take care to explain - show how you arrive at decisions. Share your research, competitive analysis, and even your thought process on arriving at a feature set or list of things for a release. Its stuff you would have worked on anyway - so no harm sharing with more eyes! * Share customer feedback - nothing motivates your engineers than a positive interaction with a customer. Get them to see customer feedback. Have them sit in and observe some of the usability studies. (B2B - have them see you do some demos or do a successful sales pitch) * Send out interesting articles, insights, business and tech articles with your comments/highlights to them on a regular basis (maybe twice a week?) - maybe even some analysis you did on competition or customer feedback * Engineers like working with people they feel are competent and complement the work they are doing to build a great product. So make sure they see how everyone else around them is also doing a good job and adding value and contributing to the success of the product. * Be transparent about the product/business - Make them feel they are responsible and involved in the business, not just technology. I've seen engineering teams happy about their annual goals having components relating to making revenues, keeping customers happy, or reducing costs. If they are enthused about the business as a whole, they will be more motivated with their engineering efforts * Have a mix of little experiments, R&D, attending to engineering debt, in addition to bug fixes and new features that each engineer gets to spend some time on (based on their interest) * Finally get to know each of your engineers personally, and be aware of what their priorities are. Each of us has different motivations in life, so there is no silver bullet to motivate people. When they know you care for them, they are more motivated :).

I like to take a rule from the Steve jobs playbook and use simple circles... one larger than the other but no more than 2. your most immediate target (realistic reachable) and one of the "enemy" competitor company. or overall untapped market cap. **for this to be effective you must provide as accurate projections as possible** no bar graphs and as little or no text as possible... remember that a deck is a companion to the speaker... avoid bullet points and use the deck to entertain rather than educate... is not a class is a pitch. :)