We're creating a mission-critical hospital communication system. Given its our startup's 1st app, how do we convince Execs we'll be around in 12mths?

I would disagree with Laura's advice about allowing your communication system to operate in-tandem to what you're trying to displace. Hospital staff have very little appetite to learn or adopt new systems, especially for mission-critical work. I also disagree with the idea that your competitors are an ideal partner. They will force you to adopt their processes and live by their rules, severely limiting your upside and will often waste your time with misleading signals of interest.

Has this objection cost you any sales yet? If not, don't over-think this. Is it an objection that you've just been given and you're about to close or lose a sale over? If that's the case, call me or someone and talk through this right now.

Otherwise, focus on ensuring that the client is totally bought-in to using your software (trial or otherwise). If this issue comes up, you have a number of ways to address this:
Generally speaking, even with mission-critical software, the due diligence doesn't include financial analysis of the vendor. So just project the confidence that you *will* be around and you should be fine. If not, there are actual contract-specific language that you could use to address this but you really should avoid that at this stage.

Having built a mission-critical hospital communication system for eight years in my first startup (LiveProcess, which is still going strong) prior to my new startup (Updated.io), I would be remiss if I didn't caution you to go into this space. Convincing execs that you'll be around in a year is but one hurdle you will encounter along the way... there are more stakeholders in the buying process within hospitals' mission-critical communication platforms than you can shake a stick at. Committee after committee, IT obstacle after IT obstacle, entrenched legacy systems that are glued to many stakeholders, nurses, doctors, safety officers, security personnel, and on and on and on... each sets up its own roadblock for you to get into the daily workflow of a hospital. Good luck in this space, but it is NOT for the feint of heart!

How is your product mission critical? What pain does this solve for them? Is it hippa compliant? Is it secure? How is it better than Doximity for secure doc to doc communications( which is free, by the way) how is it better than the 4 or so other secure physician to physician communication platforms out there? Take a look at mobihealth news, several are advertising there. How will your product improve patient outcomes? Once you have answered these questions, Sound like you need a couple of cmo's to interview asking them about their pain points! Keep in mind inbound marketing to show expertise and engage those cmo's even ask which features they'd like to see!

I'm happy to help, let me know!

Here's a few things I've done for B2B engagement with a startup.

1. Engage with their primary IT services/solutions vendor for a three-way deal that commits the vendors support for your product for a 3-5 year timeframe - This will mean a margin erosion, but you'll benefit from having a larger partner and the execs will be comforted by the fact that there's a longer term support vision.
2. Put your code and design in escrow - There are many source code escrow options and you should negotiate the contracts carefully and with good legal advise.
3. Build your pricing mechanism in ways that stagger/cycle payments over a longer period of time - This is tougher when you are starting up, but it maybe a point on the negotiating block that will help the vendor managers/contract teams lean towards you.

Your 'Go To Market' strategy should envision as many scenarios as possible and build a response case around each. There is no single silver bullet that will convince all execs who deal with startups.

Regulations & Certifications - I would suggest trying to link your offering to fill a need a hospital has based on a regulation or certification they are trying to attain. For instance, critical results communication and documentation for test results is an important and necessary duty of hospitals for JCAHO certification. A simple example is if a Head CT demonstrates bleeding in the brain, the ordering provider needs to be alerted by the radiologist interpreting the exam. JCAHO will audit EMRs to ensure this was performed and use this in the certification process. Numerous other examples exist. If your technology could help hospitals address and manage this you could get the attention of the execs.