Insight Pipeline & Facilitation

Building a Shared Pain-Point Pipeline Inside F-Secure Sense Engineering-Led Team

The Challenges

• The team behind them was engineering-driven, technically strong, and short on structured ways to bring the user's perspective into decisions that crossed both products.

• There was no dedicated tool for customer journey mapping in place.

• And as it became clear more than once — no shared, prioritized view of where users were actually struggling.

Two pieces of work, about six months apart, tackled that gap from different angles: one for a specific cross-product feature, one for the whole Sense app.

Workstream 1: Making a cross-product feature's pain points visible

United Family Rules (UFR) let users control devices and security settings across both Sense and Total — a feature that only existed because the two products had to function as one from the user's side. In practice, the integration had real technical limitations, inconsistent functionality between the two apps, and no clear model for how device and user management were supposed to work together.

I led the UX analysis of UFR: identifying where the pain actually was, and making a technical, cross-product problem legible from the user's side.

The approach:

Storytelling first:

Rather than starting from the technical spec, I built a scenario: a family of three — an admin, a teenager, and a young child — purchasing both Sense and Total through a service provider and setting up profiles and family rules for the first time. I didn't get to validate this scenario with real users afterward, but as a starting assumption it gave the team a concrete, shared reference point for reasoning about where the flow would break down, rather than debating it in the abstract.

Journey mapping, product by product and combined

I mapped the user journey through Sense and Total individually, then their interaction, documenting thoughts, feelings, activities, and needs at each step. With no dedicated journey-mapping tool available at the org, Figma was the shared canvas everyone could actually open and use.

Cataloging pains, gains, and what already existed

Every pain point surfaced through the journey maps got flagged and categorized, along with which team was actually responsible for it — essential given UFR touched more than one product area.

Adding impact, not just a list

After the first round of workshops, stakeholders asked for more than a pain-point list — they wanted to know which ones mattered most. I added impact analysis to help prioritize.

The reaction in the room was telling: presenting the journey from the user's actual standpoint was, for many stakeholders, the first time they'd considered it that way at all. That reaction — surprise that this view hadn't existed yet — was itself a sign of the gap this work was closing.

Workstream 2: A reality check across the whole Sense team

Roughly six months later, a different but related gap needed closing: not a single feature this time, but the app as a whole. I designed and facilitated a Rose, Bud, Thorn workshop — a structured method for surfacing what's working, what isn't, and where the opportunities are — as a reality check on the current state of Sense, seen through the user's eyes.

This wasn't a small, siloed exercise. Fifteen people joined, spanning design, mobile engineering, QE, and other R&D functions. Rather than debate the product in the abstract, I had participants split into four groups and each adopt one of two real target personas — an tech-savvy "Idea Hunter" or a less technical "Relationship Builder" — and evaluate seven concrete focus areas (home network status, device state, device lists, threats and events, people and devices, profiles, and family rules) from that persona's point of view.

The Output

The output was a structured catalog: pain points, usability issues, visual issues, and copy issues, organized by focus area rather than left as a loose pile of complaints — with clear next steps to prioritize the opportunities against the product's actual roadmap.

This is the same underlying discipline as the UFR work, just at a different altitude: instead of one feature's pain points, this created a shared, cross-functional, prioritizable view of an entire product's UX health — something the team could act on together rather than each function holding its own partial picture.

Why it matters

Neither of these was a research project in the traditional sense — one relied on an unvalidated scenario because real user access wasn't available, the other relied on internal stakeholders role-playing personas rather than actual users. Working within engineering-first teams often means the insight pipeline doesn't come pre-built and user access isn't guaranteed; the job is to build a working version anyway, one that's honest about its own limits, and to make it structured and prioritizable rather than anecdotal.

That's the same problem I still help organizations solve: they have customer insight somewhere — research, support tickets, workshops, tribal knowledge — but it isn't captured, structured, or routed anywhere that shapes actual decisions. The fix isn't always more research. Sometimes it's building the pipeline that turns what's already known into something a cross-functional team can actually prioritize against.