Getting to Know Users for the First Time
How a newly acquired tech org got its first shared picture of who its users were, and what it took to make that picture stick.
The Challenge
Product teams across 11 apps in three continents were making roadmap decisions without having spoken directly to a single user.
There was no research function, no insights culture, and no appetite for one. Nobody was asking for this work. That was the starting point.
Proactively Introducing Research
When the company I worked at acquired this European company, my team's mandate expanded overnight. What we found was a product organisation building without any user evidence in the room.
I initiated this project proactively - not because anyone asked for it, but because there was a clear case for it and someone had to make the first move.
The goal wasn't just to run research. It was to demonstrate what research could do, in an environment that had never seen it work.
The Research Approach
I designed a mixed-method approach around the constraints. With no existing research channels and unstructured user metrics, the priority was triangulating patterns from multiple sources so findings wouldn't rest on any single method.
Focus on the 3 core markets: >90% of user engagement was in Italy, Spain and Portugal.
Qualitative interviews formed the backbone: 20 per market, 60 total - to define behaviours, motivations, and the structure of the user types without false precision.
Survey data tested whether patterns held at scale.
App analytics acted as a reality check: did the patterns we saw in the research data match the user metrics?
In a low-maturity environment, research alone wouldn't have been enough to get traction. Connecting findings back to their own app analytics gave the work credibility it needed to land.
60 1:1 Interviews
To manage interviews across language barriers, I created the Discussion Guide and handled all analysis across translated transcripts, and engaged an agency to conduct the interviews.
In-app user survey
I worked with the app teams to build a new in-app survey channel, rather than relying on an existing email subscriber list which would have skewed heavily towards power users. This produced a more representative sample than any existing channel could have.
What We Found
Four user types emerged, defined by behaviour and motivation rather than demographics. They held consistently across countries - despite cultural differences in how people shop - which suggested the patterns were grounded in something more fundamental than market-level habit.
The artefacts were designed around one principle: keep teams focused on what users are trying to do. Each asset was built for immediate use; clear enough to reference in a meeting or async discussion, and distinct enough to guide decisions.
Segment overview cards designed for fast recall. Succinct behavioural labels, related imagery, and consistent colour-coding created a shared shorthand teams could use immediately in discussions.
One-page user type artefacts. Combined motivations, behaviours, and pain points across the full shopper journey, and outlined how app usage fits into broader routines.
Opportunity thought-starters. Linking the user type to specific features or messaging, to show how distinct user behaviour requires different product needs.
Detailed side-by-side comparison of key behaviours and drivers. For a deeper view.
The Harder Problem: Making It Stick
Delivering the research was the straightforward part. The harder question was whether it would change how teams worked - in an organisation with no prior research culture and no existing habit of referencing user evidence in decisions.
I treated adoption as part of the research problem, not something to hand off once the findings were shared. That meant designing the rollout in phases, with a clear logic to the sequence.
Phase 1 - Prove the value before asking for buy-in
Rather than launching org-wide with a presentation, I embedded the user types into a live feature redesign first. Teams could see them working in a real product context before being asked to adopt them more broadly. The goal was evidence of usefulness: decisions were documented and team feedback was captured.
Phase 2 - Build familiarity, not just awareness
The org-wide introduction came second - a lunch-and-learn, followed by team-specific workshops focused on each team's own decision streams. The reference guide produced at this stage ended up embedded in company onboarding, which meant every new employee encountered the user types before they'd been in a single product meeting.
Phase 3 - Integrating into workflows
The final phase was about embedding the user types into the systems teams already used: discovery briefs, PRDs, Analytics dashboards with behavioural proxies mapped to each type. Within two months, they were referenced in 100% of new briefs. Executives began referencing them in Town Halls. Roadmap planning sessions were grounded in “who is the customer?” The signal I was most pleased by wasn't the adoption metric - it was the shorthand names and Slack emojis teams had created for their day-to-day conversations. That's when I knew a shared language has landed.
Impact
Immediately: PMs and designers reported stronger confidence using user evidence in decisions and faster alignment with engineering — measured via pre/post surveys.
Within two months: User types referenced in 100% of new discovery briefs across the portfolio.
Long-term: Embedded into company onboarding, Analytics dashboards, and product planning cycles. New joiners encountered the user types before their first product meeting. Leadership built them into how they talked about the business. The research created a shared language that teams reached for on their own. That, more than any individual finding, is what made it worth doing.
This project reinforced that the methodology matters, but infrastructure, sequencing, and trust are what determine whether research changes anything.