Preqin~5 min read
What if the data found the insight before an analyst did?
An insights feed for institutional investors, built despite a backend that could not deliver anything in real time.
- Role: Research and product design
- Timeline: Zero to one
- Team: Cross-functional
- Impact: 90% faster time-to-insight
- Platform: Web
Impact
Time to insight
Weekly active users
Upsell
Held to 2021, when I left Preqin. The 90% is measured against the weeks investment professionals were spending to surface an insight by hand. Two gaps I should close: how time-to-insight was instrumented (logged task time versus estimated from interviews), and the user base the 20% is 20% of.
The short version
Investment professionals at Preqin spent weeks finding insights their data already contained. Leadership wanted that fixed but did not believe a project could do it, so nothing was staffed. The PM agreed.
I got it moving by asking for something smaller than agreement, then designed an insights experience: a templated feed of machine-generated findings ranked by actionability. Time-to-insight fell 90%.
The constraint behind every decision was simple: the backend could not deliver in real time, and it would not before we shipped.
What I owned
I owned
- Design end to end
- Discovery: 12 interviews with asset managers, and the journey map from them
- The Insights Feed: the template model and the ranking
- Pressure-testing every concept against what the models could actually deliver
Shared
- The delivery model, which the backend’s real-time limits decided as much as I did
- Which findings counted as actionable: the data science side set what was computable, I set what was legible
Problem
Why were people spending weeks answering questions the data already held?
Investment professionals worked through scattered dashboards to assemble a picture the platform could in principle have assembled for them. Decisions came slowly and adoption suffered.
Interviews with 12 asset managers found three things. Volume and noise made insights impossible to prioritize. Contextual metrics sat across separate dashboards, so patterns were only visible to someone already looking for them. And peripheral signals (alerts, comparisons, portfolio anomalies) were ignored almost entirely.
On the other side, the models could generate hundreds of findings a day, and the backend could not deliver any of them in real time.
Ask for a question, not belief
Could I ask for a question instead of a commitment?
The project was unstaffed because leadership had stated the need but separately concluded it was not viable enough to staff; the PM agreed. There was no advocate on either side of the product and design line, and no evidence to offer because producing it required staffing. The alternatives were a roadmap commitment, dropping it, or a time-boxed experiment with a defined question.
I reframed it as a learning experiment: permission to establish whether the belief was correct, not a commitment to the outcome. An experiment without commitment can be under-resourced, and a negative result can kill the idea for years, so the question was narrow enough to answer cheaply either way. It was taken on on those terms; everything below happened inside that framing.
Worth being exact about what moved here, because it was not persuasion. No evidence changed anyone’s position: there was none. What changed was the size of the ask. A committed bet requires belief; a bounded question requires only that the question be worth answering.
One structure for every finding
Could one template make hundreds of findings readable?
The options were dynamic real-time visualizations, a bespoke layout for each insight type, or one template with slots. The backend could not deliver in real time, dynamic visualization was constrained by the same limits, and neither would change before ship.
We chose one template: findings arrive pre-composed and the interface renders them without computing anything. Uniformity makes a feed scannable and ignorable; a templated insight arriving daily can stop registering at the rate a good one does. Ranking countered that risk, because without it the decision would worsen the original problem. Hundreds of findings a day could be delivered and read without anyone learning a new tool.
Let the feed choose what matters
Who should decide what comes first?
A chronological feed, user-configured filters and saved views, or system ranking by actionability were all possible. Volume had made prioritization impossible; chronology would reproduce that problem, while filters require users to know what they are looking for, which research said they did not.
We ranked on the system side and showed the reasoning on the card. Hidden ranking logic would not be trusted and an untrusted feed would be scrolled past, so each insight unfolds from a single metric into the narrative behind it, making its rank checkable. That directly addressed the research finding that peripheral signals, including alerts and anomalies, were being ignored.
What we shipped
We shipped the Insights Feed: templated findings from the generative models, ranked by actionability, each expanding from a headline metric into the narrative behind it. It fit existing workflows and required no training.
The feed could succeed by being new
The uncomfortable truth is that templating may have made the feed easier to ignore as well as easier to read. The same structure that let hundreds of findings arrive without new interface work made them look alike, so ranking had to keep the useful ones from becoming background noise.
What actually happened is that the template solved the delivery constraint and the system ranked by actionability. I left before slow ranking decay could show up, and the recorded timeline does not establish how long the 90% improvement held or whether the feed was still benefiting from novelty. A ranked feed needs evidence that it stays interesting, not just evidence that it works at launch.
