HP 1CPQ Product Design Team

In 2020 I joined HP Inc. as Principal Experience Designer on the 1CPQ (Configure, Price, Quote) team inside the Commercial organisation. The workload was manageable at first. But as CPQ set out to deliver more products and more features for HP partners, the need for more designers stopped being a matter of opinion.

The team serves external users (HP resellers and distributors) and internal ones, HP sales representatives among them. The objective is that every market adopts the tools successfully, with a shorter turnaround time behind them, so business runs smoother for HP partners.

This study is about the part that was never drawn in Figma: making the case for a design team with the evidence to carry it, and then building one from the ground up, global and remote.

I raised it in a 1:1 first. I told the program director I wanted to hire, and my reason was not that the team was unhappy or that quality was slipping. It was that I could see myself becoming the bottleneck. He did not say no. He said bring me evidence.

So I started clocking what design work actually took. My own hours and my design partner’s, the two of us on Config and Quote, project by project, from September 2020 through February 2021.

Six months came to 2,856 hours against the 1,440 that two people can hold — 3.97 times what one designer should carry in that window, where HP’s own ceiling was 3.0. The team was not stretched in the way people usually mean when they say it. It was carrying close to a second team’s worth of work, and now there was a number for that.

The hours on their own only described the past. To argue about the increments ahead I had to size the work, so I sorted every project into three tiers by what it cost over six months, then priced the upcoming ones at the floor of their tier. That is where the ~4,500 came from, and it is the number the ask rested on.

I took three options rather than one: three junior designers, or two seniors, or one staff-level designer. Same problem, three different shapes, and I wanted the decision to be about which shape the program needed rather than whether I deserved help.

Management approved the first option, and chose to hire step by step rather than all at once. What gave way in the meantime was UI/UX governance. It was in the forecast as large-scale work, it never sat on a PI, and so it became day-to-day work absorbed around everything else rather than work anyone was resourced to do. That is the same reason it had been invisible before I started counting: the tracking only saw what had an epic number attached, and governance never did.

The bottleneck resolved, and the team kept growing alongside what the epics needed. That was the part that mattered more than the headcount itself. Once the work could be sized, adding people stopped being an argument and became a calculation.