From reactive requests to a company priority: a design vision for CRM data

HubSpot is software that companies use to keep track of their customers, which is called a CRM. Every day, salespeople, marketers and support teams open pages that list their customers, companies, deals and tasks, then work through that list. Each customer or deal is a "record." My team owned those list pages.

Almost every HubSpot user used these pages, for very different jobs, and it showed. The top theme in customer satisfaction feedback was that people could not see their data the way they needed to. One internal comment summed up the mood: it's better than spreadsheets, but what is this page for?

Three things made it urgent:

1. We had no shared answer to what the product was or who it was for. Each request pulled the pages in a different direction.
2. Another team had a product with a similar name. It was unclear whether we should merge with them or stay distinct.
3. The company was shifting to a platform model, where other teams build experiences on top of our pages. That meant a growing stream of requests from inside the company, and no point of view of our own to judge them against.

The question underneath all of it: what is this product, and what future should we work toward?

Not every problem needs a vision. This one did, because the issue was not a single broken screen. It was that many teams were making reasonable decisions in different directions.

A design vision is a way for a group to reach collective agreement about strategic direction. It is a clear, vivid picture of the ideal future for the people using the product, and it does the work of disambiguation: it digs into a space just enough to give teams the confidence to get going in what looks like the best direction. It is not a spec, and it is not a commitment to build anything in particular.

I set three goals for mine:

1. Communicate and inspire with a clear picture of users in context, in an ideal future.
2. Set a north star for how we would solve customer and business problems, so teams could pull in the same direction.
3. Establish a 2–3 year strategy to guide everyday decisions and connect the work between teams.

A vision is only as good as the evidence under it, and I did not want it to rest on design taste. I used a four-part method: the company, the competition, the customer and the technology. For each, I went looking for what was true.

Company. I traced the vision to where the company was headed: making the CRM flexible enough to support more complex businesses and to serve as a platform for other teams to build on. That gave me two big opportunities to design toward: solving for more sophisticated use cases, and solving for specific jobs people need to get done in a much more targeted way.

Competition. I scanned CRMs and sales tools and sorted what I saw into four themes: make data visual so it is easy to prioritize, focus on activities and actions over end goals, bring everything into one place, and use AI and insights to guide decisions.

The key insight was that users do not think in pages. A single customer record can show up as a full page, a side panel, a row in a table or a card on a board, and people pick whichever fits the moment. So I proposed a new way to describe the product: these pages are records in aggregate, the one place every user goes to see their records and act on them. That gave the team a clear identity: a productivity tool that lets people do their work their own way.

The idea was a small set of standard building blocks that internal teams and customers could arrange into the view they need, for a sales rep's deals, a marketer's campaigns or a custom type of record. I grouped the opportunities into two themes: pages that help you act (tasks and activities on each row, color-coded priorities, reporting in context) and pages you can customize (navigation, more ways to visualize, summaries, and well-designed starting views for common jobs).

A vision only matters if other teams adopt it, and it touched many of them. I took it on a roadshow to about a dozen teams before asking anyone to commit.

The pushback was mostly about scale. The change was broad, and it would take many teams working together to deliver. That is a fair concern, and I treated it as one. I framed the vision as a direction to agree on, not a plan every team had to sign up for at once. The shared building blocks meant teams could adopt it piece by piece, and I kept the next steps staged.

I laid out those next steps: align the wider group, align across product areas, test the concept with customers, and define the metrics that would tell us it worked.

The vision gave my team and the teams around it a shared answer to what the product is, a north star, and a 2–3 year strategy to guide everyday decisions and connect work across teams.

After I left HubSpot, it became one of the company's top priorities the following year.

Test the idea with customers sooner. I laid out concept tests as a next step, but agreement came first from inside the company. If I did this again, I would run customer tests alongside the roadshow, so internal buy-in rested on customer evidence as well as a good argument.

Define success before the pitch. Measuring the vision was also left as a next step. I would agree on what "working" looks like up front, so the vision could be judged on results and not only on how persuasive it was.