The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

“I’ve had team members spend time in ambulances to learn about the job.”

What does it take to master product discovery? Mark Rearden, speaking from his experience in healthcare software, believes that it’s founded on understanding the customer. And doing that goes far beyond writing analysis and diagrams. You need to go out there and witness your users in action.

Mark joined us to discuss:

• the unique challenges of building and selling healthcare software products,
• the role of a tech leader in product discovery,
• the top priority for tech leaders in any industry.

Keep reading and you’ll enrich your product discovery toolbox with ideas and practices born out of hands-on experience in the healthcare industry.

About Mark & Dedalus

Dedalus’ vision

Eric Ignasik: Hello Mark. Dedalus is wrapping up a busy year – just recently, you announced the launch of a new data search and export service for NHS England. Could you tell us a little more about it?

12 months ago, NHS England asked us if there was anything we could do to combine two of their existing products.

The first product was Organization Data Search (ODS). Every healthcare organization in the UK has an ODS code, and this product was used to search for this code and accompanying reference data. For instance, to sign up for an NHS service like GP Connect you’d have to submit your ODS code as part of the onboarding.

The second product was called ODS Datapoint which contains the same data as ODS, but allows a user to export the data to CSV or Excel so there was overlap of functionality.

We spent a day with the team at NHS England to understand their existing products, who their users were and how they currently interact. We then took that understanding away, examined the existing market in terms of UI/UX, came up with a design and pitched an idea. They really liked it, so we moved to define the scope of what they wanted to pull together for that first release. We launched the beta around May 2024, after about seven months of collaboration. They ran it for three months. It went live in October. Now, we consistently launch new versions. This will be an ongoing thing as they keep refining.

I think I read in your new State of Frontend that people are working towards the WCAG 2.1 AA standard. WCAG is in our mind for whatever product we build, but when you build anything for the NHS, there are very strict guidelines. For them, we have to do triple A sometimes, and still use specific fonts compatible with screen readers.

I heard something about it. I learned  during my work with UK companies that projects for the NHS are challenging and require the highest standards. How did you overcome these challenges and go from ideation to beta in six months?

The team at the NHS is fantastic. I’m not taking all the credit here. We work collaboratively with a Scrum agile approach. Usually with a weekly cadence, but sometimes, for example in the early stages of a product, we might have a daily cadence. My development team has access to the NHS user acceptance team, making sure we’re hitting requirements.

We also introduced some new technologies. The original product we were shown was a standard React app, but we felt that using server-side rendering would increase performance, so we switched to Next.js.

What other milestones were important to you this year?

We’ve had an outstanding year, marked by significant industry recognition and achievements. My team won two out of five awards for which it was nominated. One was the HTN Award (Health Tech News) for Frontline Digitization Project of the Year for our OneResponse Ambulance EPR solution.

I’m also proud of our apprentices’ accomplishments. About two and a half years ago, we collaborated with the Coders Guild, a software development boot camp in Leeds. We brought around 30 apprentices into my team, a combination of devs and testers. 

They were all at the beginning of their careers – people who used to work as police officers, veterinarians, pharmacists, kitchen porters, chefs, or warehouse workers. This year, three of them were nominated for the British Computer Society Apprentice of the Year.

For product milestones, we took our OneResponse product fully live over at Northwest Ambulance in the UK. Used in over 700 ambulances, we run 4,000 iPads that capture patient data, handling around 3,000 patients a day in a fully cloud-native system. 

We also took OneResponse live for a private ambulance service, Spark Medical. It’s the first organisation of its kind in the UK to start using its own Electronic Patient Records (EPR) solution, and the first to use GP Connect to give paramedics access to a patient’s past medical history at the scene.

OneResponse solves the “blind medicine” problem – when paramedics have to make decisions without any knowledge about the patient. GP Connect takes a patient’s NHS number from their demographics and looks up their allergies, medications, and other information that can improve the quality of care.

Finally, I’m proud of the PatientAide app, a patient engagement platform at North Staffordshire Combined NHS Trust. They’re using it for appointments, messaging, questionnaires, and follow-up treatment. We’ve had some excellent feedback on that.

Product discovery in healthcare software

Looking at how Dedalus communicates, it’s immediately clear that you have a lot of knowledge about the healthcare sector. Among other things, you talk about moving from isolated incidents to the “continuum of care” paradigm. Is this something that you figured out during your product discovery process?

From my own product perspective on the continuum of care, there’s a big shift we’re seeing in the ambulance sector. When we built the first solution, it was incident-based – every incident created a new record, with no patient history. There was no Master Patient Index (MPI).

Now, the trend is patient-centered care. We know that you, Eric, exist. Each time we see you, we record it. Whether you’re picked up by an ambulance, receiving inpatient care, or managing your outpatient appointments, we have an ecosystem of products connected to our large EPR that support the quality of care that you receive at every step.

Is this the biggest pain point of clients in the healthcare industry?

The patient is at the forefront of everything we develop so in my opinion clinical safety is paramount in all the products that we build. When developing healthcare software, in addition to quality assurance, our clinical safety team assesses everything we build. They create a hazard log against every one of the development items or features and mark whether the item is clinically safe.

Missing or incorrect data can really impact patient care, too. Speak to anyone in healthcare, and you’ll find that patient care and safety are very important to people in this industry. It’s not about the money, there are lives at stake.

Then, there’s system availability. During the CrowdStrike outage in the summer of 2024, being able to bring up our systems quickly was crucial. Luckily, my apps were unaffected however, high availability of systems is extremely important – at least three nines (99,9%) if not better than that.

Finally, the quality of support matters greatly. We’re building products for frontline emergency service and clinical use cases, so our support service has major incident management availability to tackle even the most severe issues.

That’s a lot to cover. It seems that healthcare organizations may be particularly difficult to sell to. Are they more demanding than in other industries? What do they look for in products like yours?

Selling to public sector healthcare organizations is challenging because of the number of decision-makers involved, the environment they work within and the governance.

They’ll do a full tender process. They’ll release a capability assessment or a tender to the market, and then we submit our response. These decisions can take forever, we wouldn’t survive it as a small company. Sometimes, you’ll spend a lot of money to successfully jump through all of the hoops in the tender process and still get rejected at the last minute. It’s extremely difficult to sell to the NHS for the larger items.

Below a certain value, say £100k-150k, the decision making can come down to people further down the chain. In the NHS, they write a business case for absolutely every piece of spending. 

We’re doing some work with Northwest Ambulance at the moment. They want to introduce some new functionality which will allow a paramedic to leave the patient in the waiting room and get back on the road, releasing an ambulance quicker.

First, they send us some high level requirements to give us a basic understanding of the task. To sell to them, we can’t just say, “Yeah, we’ll do it.” Like many other Public Sector and NHS Organisations, we have to write a statement of work defining the deliverables and full scope. We put together a Rough Order of Magnitude (ROM) and provide a quotation.

These things slow you down, and decision-making can be protracted in the NHS. Right now, we’re 12 months into the process of waiting for a hospital’s decision on whether to progress some development.

So, the sales cycle is very long due to the complexity – how long does it get?

It could be years. And the implementation timelines can be years as well. You might start a project and it could be years in the delivery. Oftentimes, this can be because of pressures within the clients organisation whose primary function is to provide care. Digital programmes and projects have to take a back seat sometimes.

Not like your standard playbook of quick ideation and quick shipping – you’re in it for the long run.

Right, but when you can deliver agile, it makes a world of difference and stands out. If you can promise a feature in six weeks and actually deliver on that, then change can happen much quicker than usual. This agility is a critical factor for success when working with the NHS compared to, say, the private financial sector.

Tech leader’s role in product discovery

Let’s talk about the role of a tech leader in the product discovery process. From your unique perspective in healthcare, what does the ideation process look like? Do you listen to the market and get ideas from potential clients, or do you innovate on your own?

It’s a combination of approaches.

I get feedback from customers about their pain points and desired tweaks. I also get it from the team who know the product better than anyone else or might see a cool solution out in the wild. We do hybrid working, working at the office two days a week which gives everybody the opportunity to talk about what they saw in other apps or in health tech news.

From my own point of view, I’m always following innovation and not just in healthcare. For example, I heard about a holiday experience with a digital concierge on WhatsApp. You look at things like that and think, “Oh, that might be quite useful for us.”

I’ll float these ideas with the team. Sometimes they might have already dismissed it, other times we refine it and take it forward. For example, Northwest Ambulance wanted to improve their Ambulance Care Quality Indicators (ACQI) – how well they provide care on a specific type of cardiac arrest. We helped them go from 65% compliance with best practice to 95% compliance by applying a sort of checkout process with clear steps.

And how diverse is that product team at Dedalus? In this series, we’ve talked a lot about the benefits of cross-functional teams. What’s your take on cross-departmental collaboration and product development?

We encourage everyone to come up with ideas, even people outside of our team. We promote that so people talk amongst themselves, start dismissing bad ideas, and refine the good ones.

We’ve been asked to implement concurrent working in OneResponse so that two people could write into the same record at the same time. We brought the entire team together to solve this problem. I gave my thoughts on solving it, then we walked through it and picked it apart. Allowing collaboration across multiple teams, rather than a single product owner deciding, promotes ownership and helps everybody see the full picture.

I think it’s great that you’re able to make work on the product more fun while making the end product better at the same time.

We often hear that tech leaders keep expanding outside the engineering department, even doing things like leading sales efforts for demanding customers. How often do you venture into other spaces, like sales?

Everyone’s a salesperson. I go out and spend time with customers, explaining the vision behind the technology. I understand the value proposition and the proof of value.

I did a customer session a few months ago, and their CIO had very specific technology questions. Because I was there, we were able to have an easy back-and-forth. Bringing in someone technical can definitely help expedite those conversations.

There are some other changes happening that intersect with cross-functional collaboration. We hear that software engineers and developers are becoming increasingly versatile and turning to full stack. Engineers from our State of Frontend report are doing more on the backend to be self-sufficient. Are you seeing this as well? Anything else that caught your eye in our report?

There’s lots in your report which I found interesting. My team’s young and I’m seeing that ambition to be full stack. They don’t want to be confined to UI or frontend.

It’s “I want to learn full stack. I want to learn every single new technology that ever gets mentioned.” Everybody wants to know more. It’s not driven by the company but by the developers themselves and their eagerness to understand and learn more. That ambition is really nice, and I think, going forward, having full-stack skills will be extremely important because it’ll just become an expectation.

Your comments about developers testing and doing their own quality assurance and adding that skill – I’m seeing that as well. Developers should be doing some of their own testing. If you don’t capture it, you’re just passing a bug to the next person, and they’re going to find it, and it’s going to slow you down.

Your comments on cross-platform development are also interesting. Our products are PWAs. We decided to go down that route about three years ago to expedite what we develop – only build one code base and work across it. We chose React because of how quickly we could upskill people and start to deliver.

Now, I notice in your latest set of metrics React Native is your top cross-platform. Apple has been threatening to remove support for PWAs in Europe, so I’m at a decision point now – do I start to move the team towards React Native? If we don’t, we could suddenly have a huge amount of technical debt if Apple makes that one decision.

There are so many technologies to keep up with, so when you make your report, it really puts a line in the sand for us. You’ve given me food for thought with React Native, and also convinced me to forget about Flutter, which was low in the ranking.

This is really important for teams like mine. It gives you a decent barometer on the market to where you can direct resources. It costs a lot of money to develop software, so when you make a bad decision early on, it can really cost you.

To summarize the topic of product, how do you measure the success of a product initiative in your field?

Success can be measured through various metrics, but the most consistent indicators are the number of customers who actively use your product and the volume of issues they report – but that would be the same for any industry.

Industry reports, such as the KLAS report, are useful. It’s a global survey where people rate EPRs and their functionality. Our Orbis product was named number one in Europe.

User feedback is always good. We evaluate NPS (Net Promoter Score) for everybody who uses our apps across everything. That’s always useful, and shows what our customers feel about us. 

Everyone loves the products because we collaborate so closely with our customers. We’re nearby, so they can come and spend time with us as well. If you constantly talk to the people using your product, you can’t go wrong. We also get feedback through ServiceNow, with a survey after a support instance.

General advice

If you were to apply your healthcare software experience more broadly, what would you tell others, maybe younger or aspiring tech leaders, about how to understand the needs of their customers? How can they be more customer-centric based on your experiences in your industry?

I’ve always found that having a strong relationship with the customer is key. You don’t need to have an “us and them” mentality, and that’s what I promote with every customer I work with.

I know our customers and how they work. I’ll go and spend time at their location to see their working practices, so when they’re talking about pain points or things they could improve, it’s not just verbal – I actually witnessed it. I’ve spent time with them. I’ve had developers spend time in ambulances to learn about the job. There’s a lot to understand – the entire environment, anything that can impact how you’re interacting with the product.

That’s my advice: no matter what industry, understanding your customer and spending time with your customer is the top priority.

Resources

Could you recommend some resources, such as books, podcasts or newsletters, that could help tech leaders learn even more about the challenges of software product discovery today?

I’ll focus on health-related technology resources. Some of my favourites include HTN, HSJ, Emergency Services Times, and MobiHealthNews. The last one is US focussed, but it’s useful for finding out where the sentiment for investment is in the sector.

What’s next? 5 actions for CTOs to take

Coming from the tough environment of healthcare, Mark offers this advice for product discovery:

• No matter your industry, understanding and spending time with your customer is the top priority – in healthcare, that means being ready to ride in an ambulance to see how paramedics use your software solutions, or to join a sales session with a customer to answer technical questions.
• Source ideas for products from customers, your team, and the market – don’t be shy to ask people outside of the tech department for ideas, and look at innovative companies beyond your industry for inspiration.
• Figure out if your company can wait out the sales process for your product – for example, selling large products to major healthcare providers involves many decision makers, might take years, and you can still get rejected at the last minute. If you’re a smaller company, you won’t be able to withstand the financial pressure of this uncertainty.
• To stand out in a complex industry, learn to be agile – if you can implement your product quickly and painlessly, you gain a significant advantage.
• If you’re not doing it yet, start expanding into full stack development – if the trend holds up, full stack skills will be extremely important soon because most developers will have them. Particularly younger developers are ambitious, eager to learn, and don’t want to be confined to either the front or the back end.

If these pieces of advice work in healthcare, there’s a good chance they’ll work just about anywhere!