Our New York Tech Week event “Breakfast Bytes: Building a Scalable HealthTech Startup” with Perkins Coie LLP and SemperVirens VC was a blast.
It was great to listen to our panelists LaDale George from Perkins Coie LLP, Ion Feldman from Rightway, and our own Head of Product Iggy Moliver discussing the best tools, protocols, and approaches for getting a healthtech startup off the ground.
If you missed the event, we pulled together some of the most memorable soundbytes from the panel, so you don’t have to miss out on their advice.
LaDale George
Partner, Perkins Coie LLP
“When it comes to figuring out regulations as a new company, first focus on two things – your offering, and your revenue model. What you are offering – a product or service? If it’s a product, is it going to be a medical device or not? If it’s a service, does it have a space for clinical care, or is it a service that’s more technological and deals with logistical data or operational issues? After you define your offering, you next have to define what your revenue model is. How do you intend to get paid? These two things will determine which regulations apply to you.
One mistake I see companies make is that they define their company around regulations. Define your company, and then navigate the regulations that apply to you. This navigation is something we refer to as business yoga. You may have to bend certain parts of your company’s model to meet certain regulatory requirements. You have to think of regulations as not a barrier to your business, but requirements to support good healthcare that you need to navigate around.
As you scale, try to comply with regulation. It might be that you don’t comply, but if your intent is to comply, it’s a much better position to be in with regulators when you’re talking to them and asking for forgiveness. As you move forward, if there are issues that come up, then you can have discussions with regulators in good faith.”
Iggy Moliver
Head of Product and Strategy, Remedy Product Studio
“I think of three core areas for any product we build, but particularly in healthcare. It boils down to the process, the documentation, and the user considerations.
From a process standpoint – please be using an agile process. That’s true for any early stage startup, but in healthcare, you’re going to be met with considerations you learn about during the process build. You have to be flexible in how you define your roadmap. What’s also unique to healthcare is that your agile process will need some outside expert voices. When you do your roadmapping, you should be running ideas by the clinical voice in the room, or you may need to run things by your attorney more. Making sure you have the right voice in the room at every step can help you avoid a lot of headaches and rebuilds which are too expensive to handle at the early stage.
For documentation, well documented processes are particularly important in healthcare. When I talk about documentation, I mean your roadmap, your user stories, any outward-facing documentation about APIs.
User stories in particular are an area where we see companies fall short all the time. When we look at their backlog, it will say something like “integrate payments.” That’s not a user story. It’s a wish. We look for a user story to be really defined and have a description and an acceptance criteria, etc. In healthcare this is particularly important where you might have non-functional requirements or data requirements that need to be explicitly written into the story for two reasons:
The engineer who builds this today might not be the engineer who extends this in two years. They need to understand exactly what the intended use cases were.
You have a lot of steps between your clinical voice or your attorney before it gets translated to the person who is actually going to build. You don’t want to expose sensitive healthcare data.
The last part is user considerations. Your users for a healthcare product may not be digital natives. They may be an older population that doesn’t primarily interact through a smartphone. You either need to try and change these behaviors – which never works – or work through their existing behaviors and work with a users’ existing flow.”
Ion Feldman
Chief Technology Officer, Rightway
“When I think of scaling, my attention really comes down to security and compliance. I think it’s important for two reasons. First, any responsible customer is going to be asking if you’ve ever had any sort of incident or breach, and answering yes to that early on can really prevent you from reaching customer acquisition goals. It’s important to take it seriously from the beginning.
Secondly, people purchasing healthcare products and services aren’t always the most risk tolerant. They want to go with the big guy. They want to find a reason not to pick you as a young startup, and security is often their out. If you don’t check all the boxes when they stick their security team on you, that gives them a reason to move on. It’s important to focus on a zero trust infrastructure from the ground up. It’s very difficult to add on later. It’s very tempting when you’re a small team, and you want to move super fast to avoid that, but when you start to scale it gets out of hand pretty quickly.
One thing I would recommend looking into is Aptible. Aptible is a service layer on top of AWS that does a lot of the compliance for you. You pay a premium for it, but my company was able to reach a considerable scale, and I didn’t have to hire my first security person for about three and a half years. I’ve seen that saying you use Aptible provides a lot of comfort to prospective customers.”
Never want to miss another panel again? Sign up here to stay in the loop about all our future events and happenings.
In the meantime, check out our other insights about the healthtech landscape in our blogs “Eight Winning Characteristics of a Successful Health Tech Company” and “Leading and Building in the HealthTech Space.”
Comments