When changing customer behaviour is not an option

co-authored with Alexandre Huckert, Head of Product @ Lifen

In a previous article, we discussed the nature of the love-hate relationship between healthcare professionals and their IT systems. In a short summary, the best description is: “it’s complicated”. Despite all the advances in technology in the last 30 years, IT Systems in the medical field are not always as reliable as desired (“the system is down” is a running joke in many healthcare institutions), have bugs and issues that don’t get fixed fast enough and are not focused enough on customer needs (UX, efficiency, etc).

There is a common saying about new product introductions: “the product needs to be at least 10 times better than the existing state of the art on the market, for people to switch massively”. While every startup aspires for massive adoption of its products, very few have a 10x improvement along one or more dimensions from Day 1.

Lifen identified rightfully and relatively quickly that communication and information exchange between healthcare professionals (or lack thereof) was a key pain point to solve. The most widespread workflow for exchanging healthcare records was to:

1. Print the health record on paper
2. If the doctor is not in the manually maintained local address book, figure out (somehow) the address of the doctor by either calling them (somehow) or finding an address on a public directory
3. Put a label and a stamp on an envelope and then insert the printed health record
4. Hope for the best that it won’t come back in 3 weeks as “cannot be delivered, recipient doesn’t live at the indicated address”
5. Some level of adoption of secure email for health data exchange (MSSanté and APICrypt) was already in place in 2016 but it was in its infancy. The shortcomings were similar except for the envelope and the letter, the rest holds.
6. Scan the received paper health records to add them into health record Software.

Our first iteration in 2016 offered the following features:

1. A web interface where any healthcare professional could chat with a fellow healthcare professional (see subsequent point about authentication)
2. Easy drag and drop document sharing in the chat window, and a simple form for patient information.
3. Interactive Patient history search
4. Strong, 2-factor authentication with their professional card (i.e “carte CPS”, a smart card provided by the government to identify electronically each doctor) and a personal username/password.

Lifen Chat View

At a first glance, how can such a product miss the mark? It brought great UX, allowed data access on the go, structured patient data and the data exchange itself (sender and recipient), improved security and discoverability (through search). Despite all this, it failed to gain traction in the market.

At the end of 2016, after a year of trying to convince people to use the product (and failing), it became clear that there were key aspects of the daily routine of a doctor that were not taken into account. Let’s go through these learnings:

1. While the web has taken over the world in the last 25 years, certain professions have not caught up and are still in the “packaged software” paradigm.
2. The health record that is exchanged is originated from the existing Electronic Health Records (EHR) Software and in order to drag’n’drop it into the web browser, it needs to be exported, saved and then dragged into the browser window — that’s a (major) hassle in general, but even more so when people have metrics like : average number of clicks per day.
3. When the document is dropped into the web interface, the user is asked to fill the patient information by hand — this was seen as another major hassle, and a redundant task since the health records software already had the information in the first place …
4. Search in the web interface was interesting but since it was limited to the documents exchanged on the new service, it was almost useless unless the doctor/institution committed to all data exchange to be on Lifen (typical chicken and egg problem in new service adoption)
5. While the CPS card (see above) added a strong layer of security to the process, it was unreliable and turned out to be a massive dropoff factor in the conversion funnel for our saas service. We had to figure out a better way to maintain security high but reduce the friction.
6. Many introductory calls with doctors and their healthcare assistants, who do most of the administrative work we were trying to address, ended prematurely when we explained the change in workflow, we were advocating. We were being “rejected” before people even tried the product. This is the worst case scenario if you’re trying to be customer centric and to design your product iteratively based on customer feedback (we just didn’t have enough feedback at the beginning).

With this in mind and in search of Product-Market fit (the market need was clear, we needed the right product), we started rethinking the whole product offering and the go-to-market and by Feb’2017, we started experimenting with a “Virtual Printer” product.

The analysis went as follows:

1. Let’s keep the existing workflow of printing as the way to “send” a health record
2. Let’s avoid asking the user to enter data that is already included in the health record (the patient information, the type of health record, the recipient, the sender) and find a way to extract it from the document itself
3. Let’s incentivise users to use our service for all health record exchanges by supporting any channel used to deliver them (digital or paper)
4. Let’s abstract from the sender the recipient’s preferred delivery method
5. Let’s switch to more transparent and flexible authentication (IP whitelisting, One-time code (OTP) by SMS or Google Authenticator-like apps) instead of CPS but let’s verify the doctor’s identity by calling them to on-board them when they sign-up
6. Let’s package our service as an application that can be installed cross-platform the way other products in this ecosystem are distributed

The last point merits special attention from a technical stand point. Native applications have multiple pros and cons from a deployment stand point that are well documented but from our stand point, we wanted to maintain a couple of key things:

• Include a virtual printer functionality into our application which can only be done with a native app
• Comply with the IT departments standard procedures for deployment (.MSI installer + Registry Keys for configuration through GPOs in Active Directory)
• Stick with web-technologies to be able to (largely) share our “native” application implementation with our web one (React/Redux-based)
• Have the widest OS compatibility matrix possible on the windows side (and be able to offer MacOS and possibly Linux versions too)
• Be able to keep a homogenous installed base (basically be in an iOS-like world vs an Android-like world from a fragmentation stand point)

To meet these requirements, we chose NW.js (aka NodeWebkit) as opposed to Electron for a very simple reason: Windows XP compatibility (Yes, at 17 years-old, WinXP still drives Software design decision unfortunately).

Surprisingly, Windows XP was still (somewhat of) a thing in the healthcare space in early 2017. One of our major early customers still had a large installed base of WinXP desktops. Electron has many advantages over NodeWebkit such as build-in auto-update mechanisms and a larger user-base (which helps clear bugs and add support for newer versions of MacOS faster for example). True to our fanatical customer commitment, we accepted to live without these features and to create them on our own.

So, we shipped a first version of this application for Windows and MacOS in Mars 2017. This application included 4 components:

• A “Virtual Printer” called “Send to Lifen”, which consisted of a simple “Print to PDF” functionality through either native OS functionality (on Windows 10 or MacOS) or through a bundled free solution, on older versions of windows, that met our needs.
• A sync engine that detected PDF files which were created as described above and pushed them to our API
• A Dashboard component that allowed the user to view medical documents, follow their status and search through them. This was a lightweight webmail-like solution.
• An infrastructure component for authentication, security, configuration and diagnostics.

The application allowed the user to stick with his/her existing workflow (Printing) while offloading the “routing” function (detecting where to send the document and how) to Lifen and gaining better insight into the quality of the service that is delivered (including detecting bad deliveries and dead inboxes and rerouting the document through another channel, something almost nobody did in their previous workflow). This is well illustrated on our “How does it work?” page here. But here’s our main Dashboard view :

Lifen Desktop App Dashboard

This pivot triggered a fundamental change in our technical stack. We had to build a Native Application now :)

We feel that our current toolset, NW.js + Typescript + ReactJS / Redux (+ our own boilerplate homegrown libraries) + Bootstrap + WIX Tools + Microsoft VSTS (aka Azure Devops as of Sep’18), has been a winning formula for developing our native application while maintaining a fast iteration cycle and developer efficiency.

Take VSTS as an example. Besides standard CI tool capabilities, it offers build agents for Linux, MacOS and Windows (many flavours) which allows us to build all versions of our native app using a single CI pipeline (including Windows installers). Great!

Also, we have put in place a streamlined multi-stage release process, that is geared for fast iteration. Each application-build is a potential candidate to go to Production and be released to customers if it “graduates” through our release process. The steps it needs to go through, are :

Development -> Beta -> Production.

At each transition, the product owner (who is responsible for the product validation) can signal that the build meets his/her expectations by acknowledging a notification from VSTS for the build. This results into moving the build forward along the process. The “Beta” stage is used extensively to validate builds with our most loyal users, who opt-in to join our Beta program. Think of this as the Beta channel in Google Chrome. Every new feature or non-trivial UX change goes through an extensive Beta phase and the learnings have been always worth it, through capturing customer feedback or catching bugs before they are exposed to the wider installed base. Having such confidence in the release process allowed us to introduce new functionality fast but also to sunset certain features in a controlled manner (an often overlooked part of the product lifecycle). Needless to say, our Product Managers aren’t gun-shy with releases :)

Finding Product-Market fit is the ultimate goal of every new venture. One key aspect that is always mentioned is : “listen to the customer”. But despite the common wisdom that quite often, the customers don’t know what they want, sometimes, they actually do and what they want is to do things the way they always did!

Technology and agile processes have to step up and be able to meet customer requirements while enabling fast iteration and efficient development.