Smarter Product Discovery

A discoverability problem in disguise.

Users weren't finding or engaging with the full range of hiring services available to them, which meant lower engagement and revenue left on the table. When I joined, there was no defined solution: only behavioural data pointing at a problem, and a team that couldn't agree on what the problem actually was.

From navigation problem to personalization problem.

I ran two product discovery workshops with developers, stakeholders and designers using the Idea Napkin method, a framework that forces teams to define a feature's value, target user and strategic fit before anyone proposes solutions. With teams arriving with different definitions of the problem, we needed a shared starting point first.

I also ran a competitor analysis of Upwork and Fiverr: not to copy their patterns, but to find where they created discovery moments and where they fell short.

We came in thinking this was a navigation and IA problem. We left discovery knowing it was a personalization problem.

Alignment before solutions.

1. Discovery workshop

   The Idea Napkin method aligned everyone on the problem, so we didn't design in four directions at once.

2. Competitor analysis

   How Upwork and Fiverr surface services to users who don't know what to search for, and where that falls short.

3. Wireframing

   Structure first, then interactive prototypes for stakeholder feedback, with copy refined by the writing team.

4. Usability testing

   User interviews with the research team, then A/B testing to pressure-test the interaction model.

5. Synthesis

   Not a list of findings, but a prioritised set of design decisions.

6. Components

   A component library merged into the existing design system, documented and handed off.

Holding the line on a feature worth shipping.

Midway through the project, stakeholders pushed to cut the feature entirely. Their position was that it wouldn't drive meaningful value and the engineering investment wasn't worth it.

The PM and I disagreed. The research pointed clearly at a real unmet need, and the competitor analysis showed that platforms solving this problem saw real engagement gains. We made the case to continue, not by arguing for the design, but by arguing for what the data said.

That decision to hold the line and ship is what the $850K outcome is built on.

The core design bet: a three-question quiz.

The quiz matches users to the right hiring model (Individual Candidates, Teams or Managed Delivery) based on their project needs. It sits as a persistent entry point on the Hiring Hub, and the recommendation gives users a clear next action.

Filters require users to know what they're looking for. Our research showed they didn't. A quiz inverts the model: it asks about their situation, then surfaces what's relevant.

Numbers that made the case.

The gap between the quiz cohort (55%) and the overall rate (23%) is the clearest signal in the data. Users guided to the right service converted at more than double the rate of those who weren't: the recommendation system working exactly as designed.

Evidence over opinion.

I was the primary design voice on a cross-functional team with genuinely conflicting views about whether this feature should exist. My job was to structure discovery so alignment came before design, advocate for a research-led direction when stakeholders wanted to cut scope, and build components that merged cleanly with the existing design system.

Making the case, alongside the PM, to continue a feature stakeholders wanted to kill, and being accountable to that call when the data came back.