Rebuilding a Team, Refocusing a Product

My role


Scope	Cross-platform mobile product (iOS and Android) inherited mid-cycle with significant team and product health challenges
Team	Multi-disciplinary mobile group across two platforms; prior to my involvement the teams were operating largely in isolation from each other
What I owned	Full UX leadership for the mobile group: diagnosing and rebuilding team health; setting and driving the product strategy; making the call to halt new feature work; leading the research and vision work that redefined who the product was for and what it needed to do for them

Where I came in

The mobile group was not doing well. App ratings were poor on both platforms. The teams working on iOS and Android were disconnected from each other and from the product vision. There was no clear sense of who they were building for or why certain decisions were being made. The result was exactly what you’d expect: low ownership, reactive work, and a product that was trying to serve everyone and doing it badly.

When I was asked to take on the mobile group as UX lead, it was clear that the problems were running in parallel. The team needed help. And the product needed a fundamentally different approach. I decided to run both workstreams at once rather than wait for one to resolve before addressing the other.

Fixing the team before fixing the product

There is a version of this story where I go straight to the product problems. That would have been a mistake.

The team was struggling for reasons that were worth understanding before trying to fix output. Designers and PMs were disconnected from the end users. There was no shared sense of what good looked like. Accountability was murky. And there was a general feeling of being stuck, ground down by a backlog of known issues with no clear path through them.

I brought the teams together for a series of workshops. The goal was not to produce artefacts. It was to rebuild some trust and establish a shared picture of how things were going and how we wanted them to go. We talked honestly about what wasn’t working. We set things that had gone badly to the past and turned attention toward how the team wanted to operate going forward.

From those sessions we developed a set of team principles: concrete commitments about how we’d work together, how we’d make decisions, and what we owed each other. Not values on a wall. Specific agreements about ways of working that people had a hand in shaping.

The shift in the team was noticeable. Not immediate, but real. People started moving with more confidence. Ownership started to show up in the work.

[ Placeholder — team workshop artefacts ]

The product health decision

While the team was finding its footing, I was working through the product. The picture was not good.

There was a long backlog of known UX issues on both platforms. The team was aware of them. Users were reporting them. But new feature work kept arriving, which meant the known issues stayed known and unfixed. The product was accumulating debt faster than it was repaying it.

I made the call, in agreement with product and engineering, to halt new feature development entirely. The focus would shift to relieving customer pain as quickly as we could work through it. New features could wait until we had earned the right to build them.

This is not always an easy argument to make. The instinct is usually to keep shipping. But the data was clear: ratings were poor, users were frustrated with basics, and adding features to a broken foundation was not going to change either of those things. We needed to get the product to a state where it was trustworthy before we could make it more capable.

To move through the issues systematically rather than reactively, I introduced cognitive walkthroughs as a core practice for the team. We listed the primary use cases for the app and mapped all known issues against them, graded by severity. Then we stepped through each flow as a team, decomposing every sub-step and asking the same diagnostic questions at each stage. It moved the team from responding to what users reported to anticipating what they hadn’t yet.

The sessions were useful on two levels. The problems got catalogued and prioritised properly. And the team started building a shared language for quality: a common sense of what we were aiming at and why.

[ Placeholder — cognitive walkthrough documentation ]

Understanding who the product was actually for

Running parallel to the team and product health work was the question that sat underneath everything else: who were we building for?

The existing vision was broad. The app was meant to serve the full range of HubSpot users, across every role and use case. In practice, this meant no one was served particularly well. Every decision involved implicit trade-offs between incompatible user needs, and without a clear answer to who mattered most, those trade-offs were being resolved inconsistently.

The data told a more useful story than the stated vision did.

Of CRM weekly active users, 80% were desktop-only. Only 16% used both desktop and mobile, and 4% used mobile exclusively. On the surface this might look like mobile is niche. But the downstream numbers told the opposite story. Users who engaged with the mobile app retained at four times the rate of non-app users. CRM users who used the mobile app touchlessly upgraded at seven times the rate of those who didn’t. Users of the HubSpot app were three times more likely to close a deal. Paid Sales Hub reps who used the app consistently had higher NPS than those who didn’t.

Mobile was not small. It was underserved. And among the people for whom it would matter most, the commercial upside was significant.

The user base split into two broad groups: Generalists (47%) who were typically early-stage startup founders or multi-hat wearers, and Specialists (53%) in defined roles like sales, service, or marketing, typically at scaleup or enterprise companies. The Generalist was more likely to be a free user who happened to have HubSpot. The Specialist was the paid user who had been put onto it and whose job depended on using it well.

The focus needed to be on the Specialist. And within that, the Sales Specialist was the sharpest target: a user who was often not at a desk, whose relationship with their phone was professional rather than casual, and for whom the gap between the HubSpot app and what they actually needed in their working day was largest.

[ Placeholder — user segmentation research ]

The vision: frictionless selling

With a clear user in focus, the product direction became significantly easier to articulate.

The Sales Specialist’s working day organised itself around three things: planning their time and priorities, communicating with leads and contacts, and capturing the outcomes of those interactions back into the CRM. Plan, Communicate, Capture. Everything else in the app was either in service of one of those or it wasn’t important enough to prioritise.

This gave us the “frictionless selling” vision. Not a tagline. A design principle with teeth. Every feature proposal, every design decision, could be tested against whether it made planning, communicating, or capturing meaningfully faster and easier for someone who was mobile-first by necessity.

The framing also surfaced how much friction existed in the product that we hadn’t yet named properly. Contacts couldn’t be saved to a user’s phone, so an incoming call from a known lead showed up as an unknown number. Email wasn’t integrated with Gmail or Outlook, so reps couldn’t access their templates from the app. There was no offline mode, so the app was useless on a plane. There was no way to sort contacts by date last contacted, which sounds trivial until you’re a sales rep trying to manage follow-up cadences on the move.

Users had developed workarounds. They were adding a contact’s phone number into a task description so the number would be tappable when the reminder appeared. These kinds of hacks are a reliable signal: the need is real and the product hasn’t met it.

The three pillars of the vision each had a corresponding set of improvements:

Frictionless planning brought on-device calendar context into the app, introduced location and time-based reminders that were immediately actionable, and created automatic follow-up prompts tied to completed engagements.

Frictionless communication addressed the contact recognition problem with HubSpot CallerID, integrated Gmail and Outlook into the app, and built toward a centralised inbox that brought third-party messaging into the same space as HubSpot communications.

Frictionless capturing used the phone’s own hardware to do work that previously required sitting at a desktop: camera-based business card scanning, microphone dictation with optional transcription, contextual prompts based on time and location, and a stronger offline capability so the app functioned when it needed to most.

[ Placeholder — frictionless selling vision diagram ]

What the work delivered

Turning around a product team is slow work, and most of the results don’t announce themselves on a single date. But by the time the vision was in place, the change was visible at every level.

The team had a clear picture of who they were building for and what success looked like for that person. The cognitive walkthrough process had given them a repeatable way to move through quality problems rather than just responding to what surfaced in app reviews. Feature work had restarted, but now against a strategy that could be defended, rather than a general directive to build more things.

The product had a vision that was specific enough to actually constrain decisions. Frictionless selling for the Sales Specialist is a different brief than “make the app better for HubSpot users.” It tells you what to prioritise and what to decline. That specificity was the point.

The commercial case for mobile was never in doubt once the data was properly surfaced. The question had always been whether the product could live up to it. The work here was about making that possible.

HubSpot Mobile