Building a startup in the UX Research space? Consider this.
Since EnjoyHQ was acquired in 2021, many founders in the space have reached out to learn about our experience; through this, I’ve met very talented people building impressive startups. Today, I’m hoping that by sharing more publicly some of the things I learned building a startup in the UX research space, I can contribute to your journey or perhaps add a different perspective to some of the challenges you may be facing.
Every company is unique, and the industry continues to change rapidly, so please take this advice just as an additional data point to consider.
The following are six different insights I wish I had known before I started building EnjoyHQ.
Technical considerations
Your data model is even more important than you may think.
If you’ve been running your company for a while, this advice will feel like it is a little too late, but it is not. When you decide to build a product that helps others gather, analyze, or share data, how you structure your data model will determine the flexibility you’ll have for developing powerful features in the future.
A rigid data model can slow you down and prohibit you from shipping as fast as you would like. It will force you to spend time untangling that rigidity before making progress. This type of technical debt will haunt you. Therefore, spending enough time mapping out real-world concepts (reports, IDs, documents, transcripts, participants, etc) so the system has more in-built flexibility will help you in the long run, especially now that every product is trying to incorporate AI.
For example, being able to surface metadata for any data point, being able to search across all workflows, or being able to export a decent file format are some of the things that a flexible data model should let you do. You can’t anticipate all the features and workflows you will need, but you can build your data product with a more systemic mindset.
Helping people with their data problems means adding a lot of flexibility to the system, even if that flexibility is not exposed to users through the UI right away.
Work on your APIs
When we started building integrations for EnjoyHQ, I was always shocked at the lack of APIs in the market. Most companies we wanted to integrate with didn’t have a public API.
It’s understandable that when you launch your company, you may not prioritize public APIs from the beginning; product market fit is the priority. However, remember that tools can’t exist in isolation anymore.
Your customers are using perhaps way too many tools to get their jobs done, and when it comes to data products, you don’t have a choice. People want their data to flow in and out of whatever systems they are using. They want the freedom to export data and customize workflows with their internal tools. This is no longer an enterprise feature. This is now table stakes.
A good public API opens opportunities for partnerships, for discovering new use cases, and for genuinely embedding yourself within your customer’s workflows by adding real value and not by forcing customers to stay because they can’t get their data out of the system.
In a world where everybody wants to be the system of record, if you listen closely to your customers, you will realize that what they want is to learn from their own customers, not to be trapped in a disconnected workflow. Help them do that.
You don’t become a system of record by saying on your website that you are. You do that by understanding the ecosystem of tools your customers use, the data those tools handle, and how you work with that data.
Customer Understanding
Streamline your procurement process
Understanding how you can help your users get your tool through their procurement process is one of the most underrated tactics to be able to sell to enterprises when you are still a small company.
Most of your users have never bought a tool for their team; most will learn to do that with yours. Support them with all the materials and research they need to do to build the business case.
Be patient when things are slow, and be so responsive that they feel they are your only customer.
Even though every company buys tools slightly differently, you will recognize patterns that will help you create the supporting documents that will benefit most customers. This will save you time and make your champions fall in love with you.
Consider providing your potential customers with things like in-depth competitor analysis, detailed case studies explaining step-by-step implementation, and neatly organized SOC2, security, and policy documentation.
Ask to be introduced to the procurement team and make them your partners.
Most founders do not realize that even if your users love your product, if you don’t help them go through the procurement process successfully, you will make them remember you as that complicated and annoying thing they had to do just to get the tool. Procurement is also part of your customer experience.
Invest in product marketing
In a crowded market, everybody is fighting for leads, and when you get one through the door, you may assume that the product, a demo, or services should do the heavy lifting to get the conversion. Do not assume that.
When people buy UX tools, they are not thinking about one tool at a time; they are thinking about the ecosystem of tools they already have and how yours will fit within that stack.
Forget about your use cases and what your product does. Think about the overall picture.
The overall picture involves understanding the tools they use and their reasons for using them. Your tool is just another one in their ecosystem; it’s not the center of the universe. Intimately knowing this context will give you insights that will drive your product marketing, how you position your tool, the content you develop for people, especially those in the middle of your funnel, and the integrations you may need to build.
Product Strategy
Understand what insights and data mean for different groups of users.
The thing about building for UX researchers is that you are never just building for UX researchers. It may sound obvious that researchers work as part of a team and have many stakeholders. However, what is less apparent is how fragmented and different the definition of an insight can be for each stakeholder.
Product managers often search for quantitative insights. They want stories that have numbers to back things up. They look at customer feedback from the original source (support tickets, surveys, etc) for insights. Researchers want depth; they also want the numbers, but depth is the game. Marketers, designers, and other stakeholders have a particular idea of what is a valid insight or at least one they feel comfortable making decisions on. The bigger the company, the harder it is to agree on what insights are worth acting on.
I had so many discussions about this topic with my co-founder that one day, he told me jokingly: “When I grow up, I want to be an actionable insight.” Anyway…..🤌
The thing is that, in some ways, an insight is a mythical creature, even though it shouldn’t be. I often would advise my customers to ask around their team for a definition of actionable insight. Many would be surprised about how different those definitions would be depending on who you asked.
All of that is to say:
- Do not base your prices on “numbers of insights”; you will never be able to measure that. I’ve seen many companies tempted to do something like this. It sounds amazing and very customer-driven in theory, but that’s not how reality works.
- Don’t charge for data volume. More data does not mean more insights, and customers know this.
- Do not assume that just because multiple people in the organization use your product and they are all interested in customer insights, they will value the same things about your product. It sounds obvious, but trust me, it will be less obvious when you are trying to prioritize your roadmap based on multiple personas.
You’re solving 3 different problems, not one.
Whether you are building a testing platform, a panel management, a research repository, a survey tool, or a combination of these products, you are never working on just one particular problem. People will always have to do 3 things: Access data, analyze data, and share data.
Whatever your product does, you have to address these three areas one way or another.
Practically, it may mean building features, APIs, or integrations. Inevitably, some products will be better than yours in some of those 3 areas, but that doesn’t mean you can let that go. If you help customers gather data, you have to help them analyze it or give them the data in a format they can analyze themselves or build an integration with one or several tools that help them do the analysis.
The same applies to a product that does analysis; you most likely will have to build features, integrations, or APIs to help customers share the analysis. In my experience, there is no way around this.
I could go on and on about this problem space. I will always be grateful for the opportunity to serve thousands of researchers through my journey with EnjoyHQ. If you are a founder in this space, I salute you!🫡 It is a complex yet wonderful ecosystem.
