The Headlines
The analytics were broken, and nobody had noticed. I did.
I built the business's first research function from scratch: a Notion-based hub connecting insight databases, an experimentation roadmap, and strategic discovery work, with AI integration and playbooks written for the people who'd use it after I was gone.
Product, acquisition, and growth teams kept coming back. Five months. Still running.
Fast Growth. Fragile Foundations.
A fast-growing UK fintech lender, 900% growth in four years, £400m funded to more than 8,000 businesses. From the outside, a company firing on all cylinders. From the inside, the product function was thinner than the growth suggested.
I joined as Lead UX Researcher, embedded into the Platform and Engineering team. My remit, as I understood it from the interview process, was to work on the platforms and apps the business was building. Within a week of starting, I discovered that the senior product leader who had shaped that conversation, and whose presence had been a significant factor in my decision to join, had left before my start date. Nobody had told me. I was line-managed, initially, by someone who had no context for what I had been brought in to do.
I've been in that position before. So rather than wait for clarity that wasn't coming, I started looking for where I could have impact quickly.
What I found first was that research wasn't so much absent as misdirected. User interviews had been conducted before my arrival, but without research objectives, discussion guides, or consent processes in place. The instinct to talk to users was right. The framework to do it rigorously wasn't there yet.
That was the foundation I was building on.
Broken Since Day One
The business had GA4 and ThoughtSpot running in parallel, a reasonable setup for a company serious about data. What nobody had checked was whether the two platforms were telling the same story.
They weren't. The discrepancy I found between what GA4 was reporting and what ThoughtSpot showed was significant enough to make any decision based on either platform unreliable. This wasn't a minor rounding difference. The form_start event was firing on page load rather than on user interaction, which meant the business was counting every visitor as having started the loan application, regardless of whether they'd touched it. The result was a 72 percentage point gap between the two platforms, and no reliable read on the most important conversion metric in the business.
I raised it with the data team. They agreed to look into it and didn't follow up. I brought in the front-end developer. We couldn't pin it down together. I kept going. Eventually, in collaboration with the Paid Media Lead, who had deeper familiarity with Google Tag Manager than either of us, we got to the bottom of it. The fix was implemented. Parity was restored.
What struck me wasn't just the fault itself. It was how long it had likely been there. Since the platforms were first configured, every conversion metric, every campaign performance report, every product decision downstream of that data had been built on a broken foundation. Nobody had gone looking, because nobody had reason to think anything was wrong.
I went looking because something felt off. That instinct, to question what the numbers are actually measuring before trusting what they say, is one I'd brought from previous roles, and one I applied here from the first week.
Built to Run Without Me
Before I wrote a single insight, I made a decision about how I wanted to work. Not just for the next few weeks, but for however long I was there, and for whoever came after me.
Previous tools I'd used for research documentation, Google Sheets, Airtable, Confluence, were good enough in isolation but consistently fell short in the same ways. Rigid structures that couldn't grow without being rebuilt. Long-form outputs that sat unread. Poor search and discovery that meant research findings were only ever found by people who already knew they existed. Cross-team engagement that never quite materialised, no matter how well the work was packaged.
I needed something evergreen. Something that wouldn't need restructuring every time the scope of the work expanded. Something that a non-researcher could navigate without training, and that could eventually be interrogated directly by AI, without me in the room.
I settled on Notion. Not because it was the obvious choice, but because after experimenting with it properly for the first time, I could see it had the structural flexibility the other tools lacked. Relational databases. Multiple views filtered for different stakeholders. A block-based editor that made long-form research readable rather than daunting. And a built-in AI capability that, once I understood it, allowed me to build out sophisticated database architecture in hours rather than days.
The result was a UX Research and Optimisation Hub: a dedicated teamspace built around a central insights database, linked to an experimentation roadmap and a set of strategic discovery workspaces. Every database had multiple views, filtered and sorted for different audiences. Every section had a playbook, written in plain English, covering what it contained, how to use it, and how to add to it. The intention was that anyone picking it up after me, researcher or not, could maintain it without asking anyone for help.
I also connected the hub to Claude via MCP, laying the groundwork for stakeholders to query the entire evidence base through natural language prompting, without having to navigate the structure at all. That integration was the beginning of something. Whether the business chose to build on it was up to them.
Unscoped. Unasked For. Necessary.
With the hub in place, I needed work to put into it. The problem was that nobody had scoped any for me. My original remit, working on the platforms and apps the business was building, had effectively dissolved when the senior product leader left. I was sitting between two teams, with no clear owner and no incoming brief.
So I created my own.
I approached the Paid Media Lead, who had joined around the same time as me, with a straightforward proposition. The business was spending heavily on paid acquisition. Once visitors landed on the website, nobody was systematically checking what they did next. That was a problem we could both fix, and fixing it was clearly in both of our interests.
He shared landing page performance data across the full suite of paid campaigns: spend, traffic, form starts, and end-to-end loan application completion rates. I used that data to identify the three pages where the gap between investment and return was widest, and started there.
What followed was a series of UX audits, each combining behavioural data from Hotjar and Microsoft Clarity with event tracking from GA4. Session recordings. Click maps. Scroll depth analysis. Triangulated across three platforms before a single insight was logged. If only one platform surfaced something, I still captured it. Before I arrived, no research was being done at all. The bar for what counted as evidence worth documenting was not set by what three tools agreed on.
Each insight went into the hub as a structured database entry, categorised by touchpoint, impact area, evidence strength, and recommended action. The taxonomy wasn't arbitrary. It was designed so that any stakeholder, regardless of their familiarity with research, could filter to what mattered to them, and so that any AI tool querying the database would have enough context to return something useful.
Beyond the audits, I picked up a 24-participant UserTesting study evaluating a high-fidelity loan application redesign, one of the most complex journeys in the product. It spanned three key sub-flows, from acquisition through to completion. The study generated 63 findings. Twenty-one were classified as act-now priorities, each requiring resolution before the redesign could move forward. The Head of Product Design acted on them, working through the priority stack methodically and not discarding the lower-priority findings either.
I also led structured discovery into a proposed new product before any build commitment had been made, mapping competitive landscape, market demand, technical feasibility, and regulatory risk. The goal was to give the business an evidence base for a go or no-go decision at the earliest possible stage, before sunk cost made the decision harder. The outcome was inconclusive, largely because the decision-maker didn't respond in time, and a competitor launched something similar shortly after. The research had done its job. The decision wasn't mine to make.
A Finding Nobody Acts On Is Just a Document
Producing rigorous research in a company that hadn't asked for it was one challenge. Getting anyone to engage with it was another.
I'd learned this the hard way in a previous role, where long-form Confluence reports sat largely unread outside my immediate team, no matter how carefully structured or how clearly written. The problem wasn't the quality of the research. It was the format, and the assumption that people would seek it out if it was good enough.
They don't. Especially in fast-moving startups, where everyone is already stretched across more than their role technically covers.
So I changed the delivery model. The first thing I tried was Google NotebookLM, a tool I hadn't used before, which I came across while researching AI-assisted synthesis methods. NotebookLM allows you to upload source material and generate a podcast-style audio output, a back-and-forth conversation between two hosts working through the findings. It sounds like a gimmick. It isn't.
For time-poor stakeholders who wouldn't open a written report, an audio summary they could listen to while doing something else was a different proposition entirely. I refined the format over several iterations, eventually producing two versions for each piece of work: a short-form summary of under five minutes, and a longer version running to ten or twenty minutes for more complex projects, occasionally longer. The intention was to meet people where they were, not where I needed them to be.
The second thing I did was find an internal champion. The Head of Product Design was the most consistent consumer of my research output, because my findings directly shaped his design direction. He understood the value of what I was delivering in a way that others in the business hadn't yet. He had also been with the business long enough to have built relationships and credibility with the senior team that I hadn't yet earned. I used that. I got him excited about the work, and he carried it into rooms I wasn't in.
It didn't always land. The honest account is that traction was thinner than I'd hoped beyond the individual contributors who engaged directly: the Paid Media Lead, the SEO and AEO Executive, the Head of Product Design and Product Designer. The business was moving fast and building scrappily, and in that environment, rigorous research was always going to be a harder sell than a shipped feature. I understood that. I kept going anyway.
The Role Ended. The Practice Didn't.
In May 2026, I was made redundant alongside the Product Designer. The stated reason was reduced headcount and cost-cutting. In that context, a research function built on rigour and evidence was always going to be a difficult fit.
The business wanted to move faster and build more scrappily. In that context, a research function built on rigour and evidence was always going to be a difficult fit.
What I left behind was a UX Research and Optimisation Hub that was still live, still structured, and still usable by anyone who chose to engage with it. Every database intact. Every insight logged and categorised. Every section documented with a playbook written in plain English, covering what it contained, how to use it, and how to add to it without prior research experience.
The Head of Product Design, the Paid Media Lead, and the SEO and AEO Executive had all been active users. They knew how it worked. They knew where things lived. Whether the business chose to maintain it, build on it, or let it quietly gather dust was no longer mine to influence.
The MCP connection between the hub and Claude was also still in place. The groundwork for natural language querying of the entire evidence base, without needing to navigate the structure at all, was there for anyone who wanted to use it. That felt like the right note to leave on. Not a finished thing, but a foundation with a clear direction.
Five months is a short time to build something designed to last. I'm aware of that. I'm also aware that the hub is still there, the playbooks are still readable, and the people who engaged with the work kept coming back while I was around. That's not nothing. In a company that hadn't asked for a research function, it's closer to everything I could have done.
What You Learn When Nobody's Watching
Founding a research practice without a mandate is a particular kind of challenge. There's no brief to deliver against, no stakeholder waiting for the output, and no obvious measure of success. You have to decide what good looks like, build toward it, and keep going when nobody around you seems to notice.
What this taught me is to move faster to establish the social infrastructure around the research, not just the technical one. I invested significant time and care in building something structurally sound: the databases, the taxonomy, the playbooks, the AI integration. What I underestimated was how much deliberate relationship-building it takes to create the conditions where research gets pulled rather than pushed. The internal champion approach helped. It wasn't enough on its own.
It also taught me to be more explicit, earlier, about what a research function is and isn't. In environments where research has been done informally, or outsourced, or conflated with other disciplines, the arrival of a dedicated researcher can be misread as validation of what was already happening, rather than a signal that something needs to change. Setting that expectation clearly, and early, is part of the job. I know that now in a way I didn't fully appreciate at the start.
What I'm taking forward is a cleaner model for founding research in resource-constrained environments: start with the infrastructure, find the work nobody has scoped, build the internal champions one relationship at a time, and design every output for the person who won't read it unless you make it impossible to ignore. The hub I built at this business is the most complete version of that model I've produced. The next one will be better.
