The problem
Our award programs recognize more than 8,000 care providers every year: home care agencies, skilled nursing facilities, and independent living communities. Choosing the winners wasn't the hard part. Telling them, and getting them their award assets, was.
The worst step went like this: take a location name inside a PDF hosted on HubSpot and match it to the right email addresses through a merge field. Now do that 8,000 times. It was the most labor-intensive step in the entire awards process and the most error-prone one, and it was only one of six manual steps in notification and delivery. Every year, across our three programs, the process pulled a five-person team off their regular work for about two weeks. Because it only came around once a year, nobody got to do it often enough to get fast at it. On top of that, each of the six steps needed roughly 2.5% rework. At 8,000 winners, that's around 200 records to fix at every step.
Our QA caught the errors before they reached customers, so winners never saw any of it. The cost just landed on us instead, in labor and rework, every single year.
My role
I ran the award cycles as project manager from 2024 through 2026, doing plenty of the hands-on work myself, so I knew exactly where this process hurt. I spotted the opportunity, and as Product Owner I defined the product and owned it through the handoff to engineering.
The big idea: remove the step instead of speeding it up
The tempting fix was a better matching process: cleaner spreadsheets, smarter merge fields, more QA. But a faster way to match names to emails still meant someone matching names to emails. I wanted a process where nobody had to match anything at all.
The data we needed already existed. Customers' applications already told us which locations they had and who belonged to them. So I defined a winner's portal that uses that data directly.
Before
- Collect and clean winner email addresses
- Match location names in HubSpot-hosted PDFs to emails through a merge field
- Send notifications and assets by email
- QA and rework at each of six manual steps
With the portal
- Winners are notified in the portal using data already in their applications
- They log in and see only the assets for the locations they won for
- They download directly
- A public profile directory shows off every winner
What I did
- Defined the product in a working-backwards document and built the roadmap from it.
- Ran engineering sessions to turn the definition into written tickets.
- Ran the open questions through the decision log I'd set up as Program Manager, and closed 95 of its 110 decisions in under six months.
- Set the adoption strategy. Nobody I know is dying for another password, so instead of launching a standalone site, the portal lives inside the existing company portal on Keycloak, where customers already sign in.
Where it stands
The portal is in active development. My part was finding the problem, sizing it, and defining a product that gets rid of it, then handing engineering a clear, ticketed plan. The problem is well measured: two weeks of a five-person team every year, plus rework at six steps across 8,000+ winners. That's a lot of time I'd love to give back to the team.