5 lessons learned while assisting Healthcare #startups by Shailesh Gogate @sgogate
18 months ago Faichi Solutions, http://www.faichi.com/ an offshore product engineering partner, decided to focus on two verticals: Healthcare and Media/ Publishing.
To scale a company, one should pick one or two verticals to focus on (especially when you have limited budget 🙂 ). These two verticals were identified based on the number of clients we had in those 2 verticals and customer references :).
In the first 4 years of operations, we had worked with a Population health product which was pivoted from a Wellness product, a Patient Management product, and a Health Management platform. In the last 18 months, we have worked/ working on two TeleHealth products, another Population health, a Behavioral Health, and two Health Management products.
While assisting different Healthcare ISVs (product companies a.k.a Independent Software Vendors), Faichi Solutions was initially a product engineering partner. Having that said, we learned a lot (and continue to learn) of business and operational issues (and are now an integral part of the development and release lifecycle). Listing 5 learnings (amongst many) below:
1. Add a product owner even if the Client has one: Core members of a startup end up wearing different hats. It’s hard to manage/ explain (and document – the biggest challenge) user stories, workflows, questions of the developers/ testers (should be accessible). Solution: Have another product owner who mimics client’s product owner. It removes a lot of roadblocks. This is very helpful to finish the number of user stories planned during a sprint.
2. Be ready to educate your Client and be educated: When your key point of contact is a domain expert and not a tech expert (although she thinks she understands technology), you end up educating the Client on technology and its processes. One has to communicate in a way which is politically correct (without hurting the ego of the entrepreneur, requires a different kind of skill). In the same breath, would like to point out, engineering partner needs to understand the nuances of client’s business. Sometimes a simple step in a use-case could be nerve-wracking, keep an open mind to learn.
3. Incorporate business dependencies while estimating a task: While estimating development effort for a user story, e.g. integration with EHR, one may estimate 4 to 5 weeks. However, there are a lot of business dependencies which have to be considered. For e.g. To get a buy-in from the CIO of a hospital / large clinic (particularly if it’s an on-premise EHR) to integrate with a product can take up to six months or more (or none). There are tons of such examples.
4. Have a domain expert on the project: Even if you are engaging with client’s VP/ Dir of Engineering, there are a lot of user stories which need clarification before and during the designing or coding process. For e.g. while moving from ICD 9 to ICD 10 codes, there is an architecture and UI change. The domain expert should point this out early in the process. There are changes being incorporated in US Healthcare, which is going to affect the revenue of a product. One should be able to filter out key implementations from the list of buzz words floating around (e.g. MACRA).
5. Build accelerators to reduce time to market: Anticipate what features are likely to be added to multiple products. For e.g. for telehealth clients, “Patient Intake forms” will be needed in a few months time. For a different set of clients and prospects, Chronic care management workflow will be required. In the initial years, we could not anticipate these needs. However, in the last 18 months, we added a few accelerators which add significant value for our clients. Not only these accelerators are helpful in reducing time to market of our clients, they were also helping in reducing clients’ cost.
There are a lot of best practices which have to be followed while working with offshore teams e.g. Good / Open communication, Tools and Processes, Daily standups, SCRUM masters on both sides, and much more. All of these are implemented and optimized as the relationship with Clients mature. However, the ones which come to mind at the top the head for Healthcare startups are listed above. Am sure engineering/ operation managers will have a lot to share. Feel free to add your learnings in the comments section below.
To scale a company, one should pick one or two verticals to focus on (especially when you have limited budget 🙂 ). These two verticals were identified based on the number of clients we had in those 2 verticals and customer references :).
In the first 4 years of operations, we had worked with a Population health product which was pivoted from a Wellness product, a Patient Management product, and a Health Management platform. In the last 18 months, we have worked/ working on two TeleHealth products, another Population health, a Behavioral Health, and two Health Management products.
While assisting different Healthcare ISVs (product companies a.k.a Independent Software Vendors), Faichi Solutions was initially a product engineering partner. Having that said, we learned a lot (and continue to learn) of business and operational issues (and are now an integral part of the development and release lifecycle). Listing 5 learnings (amongst many) below:
1. Add a product owner even if the Client has one: Core members of a startup end up wearing different hats. It’s hard to manage/ explain (and document – the biggest challenge) user stories, workflows, questions of the developers/ testers (should be accessible). Solution: Have another product owner who mimics client’s product owner. It removes a lot of roadblocks. This is very helpful to finish the number of user stories planned during a sprint.
2. Be ready to educate your Client and be educated: When your key point of contact is a domain expert and not a tech expert (although she thinks she understands technology), you end up educating the Client on technology and its processes. One has to communicate in a way which is politically correct (without hurting the ego of the entrepreneur, requires a different kind of skill). In the same breath, would like to point out, engineering partner needs to understand the nuances of client’s business. Sometimes a simple step in a use-case could be nerve-wracking, keep an open mind to learn.
3. Incorporate business dependencies while estimating a task: While estimating development effort for a user story, e.g. integration with EHR, one may estimate 4 to 5 weeks. However, there are a lot of business dependencies which have to be considered. For e.g. To get a buy-in from the CIO of a hospital / large clinic (particularly if it’s an on-premise EHR) to integrate with a product can take up to six months or more (or none). There are tons of such examples.
4. Have a domain expert on the project: Even if you are engaging with client’s VP/ Dir of Engineering, there are a lot of user stories which need clarification before and during the designing or coding process. For e.g. while moving from ICD 9 to ICD 10 codes, there is an architecture and UI change. The domain expert should point this out early in the process. There are changes being incorporated in US Healthcare, which is going to affect the revenue of a product. One should be able to filter out key implementations from the list of buzz words floating around (e.g. MACRA).
5. Build accelerators to reduce time to market: Anticipate what features are likely to be added to multiple products. For e.g. for telehealth clients, “Patient Intake forms” will be needed in a few months time. For a different set of clients and prospects, Chronic care management workflow will be required. In the initial years, we could not anticipate these needs. However, in the last 18 months, we added a few accelerators which add significant value for our clients. Not only these accelerators are helpful in reducing time to market of our clients, they were also helping in reducing clients’ cost.
There are a lot of best practices which have to be followed while working with offshore teams e.g. Good / Open communication, Tools and Processes, Daily standups, SCRUM masters on both sides, and much more. All of these are implemented and optimized as the relationship with Clients mature. However, the ones which come to mind at the top the head for Healthcare startups are listed above. Am sure engineering/ operation managers will have a lot to share. Feel free to add your learnings in the comments section below.
Author
Shailesh Gogate
Shailesh Gogate is an entrepreneurial business development leader with deep expertise across Product Engineering services. Shailesh holds more than 20 years of IT industry experience working with companies across the world. He has a strong interest in product management and adds value to healthcare product companies to make them successful.
JP Pattanaik
Akanksha Rajeev
This list is not exhaustive. I don’t need to look at statistics to confront the horrid truth. News stories of women from all over India being raped, beaten, killed are flashed across us day after day – and we all are aware of it. The fatal Nirbhaya gang-rape saw an outpouring on the streets of Delhi – protests decrying the fragile status of women in India. Candle light marches, editorials examining the patriarchal and sexist traditions of our country, an awakening on social media – even conversations on streets revolve around the night they cannot forget: the night that took Nirbhaya. We need to do something about women safety. Devices, trackers, processes, helplines- whatever little or more we can do.
For elderly even small accidents can be deadly. While simple falls, such as slipping while walking off a curb, may seem relatively harmless, they can actually lead to severe injury and death in elderly individuals, according to a new study published in The Journal of Trauma: Injury, Infection, and Critical Care. As the population continues to age, it is important for physicians and caregivers to be aware of and prepared to deal with this issue, which could significantly impact the overall health and wellbeing of older adults. 
Article By: Dr. Ruchi Dass
You must be logged in to post a comment.