I made the case for and led a refactor of the questionnaire builder, the tool every study on the platform depends on, after bug tickets, admin interviews and a slow, clunky experience all pointed at it. Builder support tickets fell 100% in the six months after launch.

Role

Product Manager, owned the case for the refactor, the discovery with admins, scope and delivery

Team

Me, as product manager, designer and engineer, with the three admins I interviewed as the first users

Timeline

Over four months making the case, then built and launched in Q1 2026

Users

Platform admins and study coordinators, on our own team and at client research groups, who build and maintain the questionnaires patients answer

Metrics

Builder support tickets down 100% six months after launch, time to build a questionnaire from two days to half a day

1. 01

   Built the case on dev hours, not on complaints

   Tickets alone looked like noise, and admin complaints alone looked like preference. The case landed when I led with how much dev team time was going into patching the builder, then put the admins' experience next to it in the same short document.

   Tradeoff. Building the case took months before any engineering started. In return, senior leadership approved a refactor rather than another round of patches, and nobody questioned the scope later.

2. 02

   Shipped the builder first, and the rest of the building experience after it

   Every admin had a list. I put the builder itself, where the tickets and the slowness were, in the first release, and sequenced the other parts of the building experience into the releases that followed.

   Tradeoff. Admins waited longer for the lower-priority improvements. In return, their highest-priority items shipped as soon as possible instead of everything arriving late together.

3. 03

   Made speed and clicks requirements with a number, not a hope

   Slowness and the number of clicks to reach one outcome were why admins did not trust the tool. I set a load-time target on the largest real questionnaire and a click budget for the most common tasks, and tested every release against that questionnaire, not a sample one.

   Tradeoff. A large share of the time went into loading and saving, which nobody sees. It was the right call: a prettier builder that was still slow would have changed nothing.

4. 04

   Shipped to a few admins first and watched the tickets

   We released the new builder to the three admins I had interviewed before everyone, and I checked two things each week: ticket volume about the builder, and whether those admins were still hand-making their print previews.

   Tradeoff. Being sure of the result took weeks of watching rather than one launch announcement. It also meant Support saw the drop before I reported it, which made the number easy to believe.

• Builder support tickets fell 100% in the six months after launch.
• Time to build a new questionnaire fell from about two days to half a day.
• Ethics submissions use a print preview from inside the builder instead of a hand-made one.

Tickets tell you where it hurts. The dev hours going into patches tell leadership why it matters.

• →Instrument the builder (time to publish, saves per questionnaire, errors) so the next regression shows up on a dashboard before it shows up in tickets.
• →Run the same tickets-plus-dev-hours review on the patient enrolment flow, now that the method has paid for itself once.

Most PM roles involve more inherited features than new ones. This is the work of noticing that a core tool is quietly failing, proving it with evidence a leadership team will fund, and refactoring it without breaking the people who depend on it every day. It also shows the Support and CX partnership PM roles ask for: the ticket queue was my first source, and Support saw the drop first.