THE PROBLEM

Partners were sorted three ways: by region, by product specialty, and by how much money they made for the company. That is market segmentation, and it is a reasonable place to start. It tells you almost nothing about what one of them is trying to get done on a Tuesday morning at nine.

Our partners are their own companies. We hold the relationships with the telecom suppliers, which is what lets us put strong deals and strong commissions in front of a partner, and we pay those commissions out. Partners use the platform to build quotes and contracts, to put solutions together for their own customers, and to track what they have earned. So we were designing inside somebody else's business, not inside ours.

In place of understanding, we had stories. Regional knowledge that did not agree with other regional knowledge, a great deal of well-earned opinion, and almost no quantitative evidence. Underneath the stories, income drove every product decision.

The platform showed it. Tools were bucketed by sales funnel phase, which is how the business thinks about its own process. The connecting task flows between phases were missing, and the phases themselves were generalities that did not match any particular partner's process. Phase by phase, the platform validated the business and not the user. And we could not see how much of a partner's real job happened somewhere else entirely.

We did not know our users. Exposing that was part of what this project was for.

WHAT I DID

I wrote the project initiation request that funded the work, 110 hours with a named executive sponsor and a two-person team alongside me. I built the first survey, seventeen questions, and sent it to a matched sample across segments. I ran and synthesized eleven subject-matter-expert interviews, 993 data points, working with two Directors of Product Management to reach the right people. And I pulled platform analytics underneath all of it, so what partners said could be checked against what they did.

Seventeen questions is a long survey, and long surveys get ignored. The response came back thin. Rather than accept the sample I had, I built a second instrument of ten questions only, chosen out of what the first round's answers had already shown mattered. I structured all of it to test the company's standing beliefs rather than confirm them. Six held up. Five did not. Three findings arrived that nobody had thought to assume.

The five that failed all failed the same way. The company had assumed partners with teams to train, back offices to support, renewal books to manage, and product sets to diversify. Respondents typically had one or two employees, were newer, were still building depth in a single specialty, and had not been around long enough for renewals to be a problem. We had been designing for a partner most of our partners were not yet.

The strongest finding was one nobody had thought to assume. Lead generation and prospecting were what partners needed most. Eleven of twenty-one named it the hardest part of their job, and 76 percent called it extremely important to growing their monthly revenue.

The preliminary patterns also revealed a company-wide bias toward the goals and pain points of the highest-revenue partners. They represented most of the company's profit and a small fraction of the partner base. The product was being built for the minority.

WHAT THE PERSONAS FOUND

Revenue was not the useful axis. Two things were.

Size told you what functionality a partner needed. A one-person broker and a partner with a back office are not doing the same job. The small operator does everything himself, so the platform has to be his back office. Sorting by revenue had been hiding that difference rather than showing it.

Tenure told you how they behaved, and the analytics carried it. New and seasoned partners favored different task flows and prioritized different things. That is two different products wearing the same interface.

Put size and tenure together and you stop having boxes and start having a ladder. A one-person broker can become a small agency, and a small agency can become a large one. The personas were the scaffold for that climb. They were an artifact that could be shared company wide, something to orient strategy against and set priorities by. For product, they were the opinionless justification for which functionality, which task flows, and which tools a partner needs at each stage of growing.

That reframed the money argument instead of fighting it. A partner who grows earns more, and a partner who earns more earns the company more. Revenue tier asked who already deserved our attention. The personas asked who we could help get bigger.

WHERE I WAS WRONG

The part I am proudest of is the part where I was wrong. My first personas still had revenue logic baked into them. I had changed the labels and kept the thinking. When I re-stratified the same population against actual commission data, 18 percent of partners landed in a different persona than the one I had assigned them. I wrote a note to the team that read, in full seriousness, 'remove money as a reference for personas,' and rebuilt them.

THE POWER USER NOBODY HAD STUDIED

Early in this work I identified our own staff as the platform's real power users. It is a high touch business, they were on the platform constantly, and helping partners make money is the job.

Business value was driving product decisions, and what we did not have was a clear account of user value. I argued for a staff persona because they spent their days helping partners work the platform, so they knew where partners got stuck and what they actually needed, and they could say it more clearly than anyone else in the building. Management disagreed at the time. Three personas was one too many, so my triangulation strategy, checking what partners said against what staff saw, was not adopted and the staff never got a persona.

The partner voice went to work as soon as the personas were finished. It shaped strategy and the roadmap from that point on. The staff voice took until 2025, and it did not arrive at the strategy level. It arrived in the design process itself: the SME interview became a validation step, used while a feature was being built to check its functionality and task flows against what staff knew.

What that surfaced was practical. The pain points staff had been quietly absorbing on a partner's behalf. The functionality partners leaned on most. The functionality that was too complicated for a standard user to get through alone. The product got easier to use for it.

WHAT I WOULD DO DIFFERENTLY

I would have argued harder for the staff persona, and I would have argued for a smaller version of it. There was a real reason for caution: much of what staff did ran through an internal system partners had no access to, and a persona built on that could have described an internal tool rather than the partner's product. It was still worth doing. The analytics could have told us which staff to talk to, and their view of the platform's real value sits closest to it. Being early is not the same as being persuasive, and a smaller ask would have got there sooner.

OUTCOMES

Our team used the personas to vet and validate projects, to shape strategy, and to inform the project roadmap. They informed the move toward an opportunity-driven task flow, which was implemented in the dashboard. And they changed how I worked: I could design a solution and argue for it with developers and stakeholders from evidence rather than from preference.