How to Find Market Fit for Data Products

By the time I entered the bar on that rainy spring afternoon, Justin had already started on his cocktail. It had been a few months since I saw him last; after his product design firm ended their work with my previous healthcare technology employer, he had taken on some new projects and
it was tough to find time to connect. I had recently left that employer myself to take on a new job that ticked all the boxes- pay raise, prestigious company, work from home, great boss. Plenty of changes to catch up on.

After the usual pleasantries were exchanged, we started talking about how he felt there was such a missed opportunity with that last project. He had been working with one of the other product managers to modernize a clinical analytics platform. The original product was a perfect example of how software was conceived and built for healthcare organizations- it started in the early 2000s as an incredibly advanced data query platform, purpose-built for a large hospital in a time before electronic medical records and cloud databases. The hospital thought the product was unique enough to sell to other hospitals, but couldn’t figure out a way to commercialize it, so they sold the technology and team to this growing healthcare technology company.

The healthcare technology company had put a little bit of money into developing out the product further- adding new integrations to different clinical systems, expanding the natural language querying capabilities, etc. They invested in marketing the product- trade shows, enterprise salespeople, the works. Nothing seemed to work. The final shot was bringing in a design firm to completely update the user interface and backend architecture. That’s where I met Justin- he was running the product overhaul. Spoiler alert- the product updates still didn’t help the product sell, and the company mothballed it.

Justin, and the product manager he was working with at the company, decided to try to build a similar product on their own. At first, I thought that it was pride that led Justin to try for the second time. It wasn’t.

He had been in a bad motorcycle accident a couple of years before, and almost died from his injuries. During the many weeks of recovery, he got to know his surgeon very well, and being someone naturally interested in
software design, wanted to know a bit more about how she used technology in her job. She wasn’t a big fan of the electronic medical record because she couldn’t find the data she needed to do her job at scale. She could only view one record at a time, which limited her ability to look at what all of her patients needed. Justin saw how frustrating this was for her, and how much impact it would have if this problem was solved for medical professionals like her.

So, when Justin started on this clinical analytics product update for the company, it was personal. When that didn’t go as planned, he still felt the need to solve the problem. He brought in Carmine as the technical co-founder to build out a cloud-based version of the tool with natural language search. Carmine also had a connection to healthcare- his mom had worked in a doctor’s office and experienced some of the same problems that Justin’s surgeon had. He had also been doing a lot of freelance development work for data engineering and data science teams at large corporations. They seemed to be having the same problems- how could they make it easier for non-technical colleagues to access the right data that they needed, without too much strain on the department?

The team was assembled, and they started building out the product. They had been working on the Phiona product for six months or so by the time I met Justin for drinks.

I asked how it was going, and Justin seemed pretty positive about the progress. They started demonstrating Phiona to different organizations- incubators, accelerators, hospitals and insurance companies. Carmine
had solved some of the difficult technical issues around integrating with
electronic medical record systems and building out the natural language search capabilities. People really liked the product and thought it had promise. But no one wanted to trust a motley crew of folks without a lot of healthcare-specific technology experience with a massive enterprise deal.

Since I had been in healthcare product management and marketing roles my entire career, Justin asked whether there were any shortcuts to revenue in this space. I couldn’t really think of any- most hospitals were very conservative about bringing on new technology, especially with data
products. If you had good connections, you might be able to get a pilot program with someone, but after that you generally needed 6-12 months to show your value. Once you had your first customer, you could then start using that to get others, but that could take another 12-18 months.

That wouldn’t work without taking on a lot of venture capital. And without an experienced healthcare operator, that was quite unlikely to happen. It seemed like a predicament. We finished up our drinks and left the bar.

A few months passed. Justin and Carmine continued working with the third co-founder to get meetings and build out Phiona further. They never seemed to be able to get past the first meeting- everyone wanted to talk
about natural language analytics, but no one wanted to be the first to try it.
Patient lives were on the line, and that meant sticking with tried and true
methods.

When I next met Justin for coffee a few months later, we both were at inflection points in our professional lives. It turns out the third co-founder was offered a promotion at her full-time job, so she felt she couldn’t dedicate the time anymore to help with Phiona. Justin was frustrated with the perpetual meeting song and dance. My boss had left my company and the department was on the verge of being disbanded, leaving me in corporate purgatory.

We vented about our respective issues for a few minutes before planning how to move forward. Justin asked if I’d be willing to do work on the side for Phiona. He couldn’t pay me, but it would at least give me something to do while all of the corporate issues were being sorted out.

I agreed, but only if we started thinking about ways to move out of healthcare. I was burnt out on healthcare technology- it seemed like there was no real way to innovate outside of the major electronic medical record providers, and the constant fight between insurance companies and hospitals led to software that was more focused on maximizing profits rather than helping patients receive care. This shift in focus certainly wasn’t what Justin wanted, but he realized that there was no way to move further in the healthcare market.

So Phiona was no longer a healthcare product. Over the next couple of months, we pared back capabilities to what was essential- remove the integrations to healthcare systems, focus on the search capabilities, and make it so that Phiona could be accessed from different messaging applications.

We got to minimum viability, and started sending Phiona to people we knew professionally in the data analytics space. Again, people loved it, but they couldn’t really figure out what they’d use it for. We could only search uploaded spreadsheets, and results were very much dependent on how clean the data was going into the spreadsheet. We onboarded many people who used the product for an hour or so, only to never use it again. We seemed to have a major product-market fit problem.

Since we kept in pretty close contact with our initial users, we were able to have pretty candid conversations about the shortcomings in the product.

Everyone said that the natural language search feature on its own was easy to use and much easier than either figuring out how to write a SQL
query or manually filter multiple columns in Excel. It just wasn’t very valuable yet on its own. Our users told us that they could already mostly get by with Excel or Google Sheets’ ways to filter and search their spreadsheets. But, where Phiona had the advantage was very large datasets where Excel would generally hang or crash. Maybe we could integrate with databases, where tables could be millions or billions of rows.

The other issues had to do with the data results themselves. Users would want to combine multiple datasets together to make the search more comprehensive. Data was inevitably dirty and so searching for a particular date would only return results in a certain format. Maybe data transformation would be required to split columns, or group certain results into another column. And after all of that was done, if there was an update to the spreadsheet or data table, you’d have to do it all over again.

Essentially, what made the search valuable was all of the intermediate steps it took to prepare for search. And most non-technical users weren’t fluent in SQL or Python to be able to do these things, so they relied on data engineers or analysts, who were always inundated with existing work.

Existing tools didn’t really solve the problem- they were either too expensive and made for large enterprise data teams, or they were
desktop tools that were limited by the computer’s memory. Moreover, these tools still required a level of manual work- you had to know what the issues were and how to find them, which took a lot of time and trial and error.

Since then, we’ve been refining what it means to organize, prepare and automate data for analytics and/or data science without requiring coding knowledge.

1. Market-Distribution Fit Matters. While searching for product-market fit, it’s essential to keep in mind how you plan to finance and sell your product. Many markets require incredibly high amounts of capital to access customers, for a variety of reasons. Many people think of companies like Uber (two-sided marketplace, requires significant marketing spend) or SpaceX (space travel, requires significant technology innovation).

Healthcare and other heavily regulated industries are capital intensive because of the length of time and trust required in the sales cycle. If you haven’t raised enough money to take this into account, it will be difficult to stay alive long enough to close your first few deals. There’s a reason why there are very few bootstrapped insurance startups.

2. With Flashy Technology Features, Move Beyond the Hype. People like to talk about new technology. They’ll even take meetings to see and talk about the possibilities. But they’ll rarely buy because the required work to get to what that flashy feature needs either requires significant implementation (which you’ll have to do) or massive culture change (which you generally can’t do).

3. Nothing Compares to User Feedback. I feel this lesson comes up in every early startup post, but don’t neglect user feedback. The twist on this lesson is that I’d recommend bringing someone with a design and/or product management background to these user feedback sessions- it helps to be able to map the required use cases to user interface development, as well as to understand what are the areas where pursuing a feature may break an existing interface or broader value proposition.