At a glance
- Role
- Product Lead and Lead Developer
- Team
- Me plus a senior engineer, and a Sales partner for the second act
- Timeline
- Q3 2025, kickoff to conference launch
- Users
- Rare disease researchers, with global patient advocacy groups as the clients: one at launch, then two more
- Metrics
- Shipped on time, 3 clients, part of $800K in new contracts and $75K upsell ARR
Problem and stakes
Lumiio's flagship product was built for patients. A client, a global patient advocacy group, needed their researchers to access and work with that data directly, which the product had never done. Their previous vendor could talk the talk but could not walk the walk, so they arrived skeptical and with little patience for surprises.
The launch date was fixed to an international conference where the client would present the portal on stage. Missing it would have cost the contract and the relationship. It mattered to Lumiio too: this was our first researcher-facing product, and a test of whether we could serve that segment at all.
I owned requirements, client communication, scope decisions, the build and launch readiness. Partway through, it became clear the original scope would not fit the deadline. The client was asking for a full research workbench. What they needed on stage was a working portal that a researcher could log into, find a cohort, and show real data moving.
-
KickoffRequirements, client communication and the build, with a senior engineer
-
Scope cutLaunch list and deferred list agreed in writing
-
Conference launchShipped on time, presented on stage
-
Repackaged with SalesConfiguration replaces custom code, and the portal goes to two more clients
- Scope cut
- Launch
- New client
What I did
-
01
Cut to what the conference demo needed, and wrote down what "done" meant
I separated what the client had asked for from what the presenter needed on stage, then put the shipped list and the deferred list in writing and got the client to sign off on both before the cut.
Tradeoff. The client gave up the custom report builder for launch. In return, nothing on the launch list was allowed to slip, and the deferred list had dates attached.
-
02
Deferred study collaboration and sharing to a post-conference release
Sharing needed a permissions model for people outside the client's own team, which meant a data model change that would have put the launch at risk, and nobody would see it in a 20 minute presentation.
Tradeoff. It cost us a feature the client cared about. I explained the reasoning to the client and to leadership before the conference, not after, so nobody was surprised.
-
03
Kept data correctness and access control non-negotiable
A researcher portal that showed the wrong patient's data on stage would have ended the relationship. I protected the time for permissions, audit and data checks even when other things were being cut.
Tradeoff. Less polish in the UI at launch. The client agreed that correct and plain beat pretty and wrong.
-
04
Gained a new client's trust by delivering everything we talked about
The client's previous vendor could talk the talk but could not walk the walk. It mattered to me that everything we discussed was something I could act on and deliver, so I ran a demo every week, sent honest written status updates, raised risks early with options attached, and kept the written scope agreement current.
Tradeoff. The cadence cost me build time every week. It was worth it: by launch the client was forwarding my updates to their own leadership.
The second act: from one client to three
After launch I worked with Sales and Product to redefine the portal as a platform rather than a one-client build. That meant replacing custom code with configuration, deciding which features became standard, and agreeing how to package and price it. It went to two more clients.
- Custom code
- Per-client configuration for data fields, cohort definitions, export formats and branding
- One-off features
- A standard feature set every client gets, with the custom report builder as a paid add-on
- Bespoke pricing
- A packaged offer Sales could quote without engineering in the room: a platform fee, a per-study fee, and the add-on priced separately
- Researcher login with role-based access
- Cohort views of patient-reported data
- Export of study data
- Custom report builder
- Study collaboration and sharing
- Researcher login with role-based access
- Cohort views of patient-reported data
- Export of study data
- Custom report builder
- Study collaboration and sharing
- Per-client configuration (the platform work)
What went wrong
I locked the scope agreement later than I should have. For the first five weeks the client and I were working from a shared understanding rather than a written one, and when the deadline pressure arrived, the cut was harder to explain than it needed to be. I also built the first version for one client rather than for reuse, which meant the second act cost more engineering than it would have if I had designed for configuration from day one. Both are things I now do at kickoff.
Results
- Shipped on time for the conference, and the client presented it on stage using the live portal rather than slides.
- Went from one client to three after the portal was repackaged as a platform.
- Part of the $800K in new contracts, and the source of the $75K in upsell ARR from the add-on and configuration sold to clients two and three.
- Fourteen researchers onboarded across the three clients, supporting five studies.
What I'd do next
- Write the scope agreement and the definition of done in the first week, before the first line of code.
- Start every 0 to 1 build with the question of who the second customer is, so configuration is designed in rather than retrofitted.
Why this matters
Growth and self-serve roles are about turning one good experience into a repeatable one. The second act here, one client to three and custom to configurable, is that work. It also shows the Sales and CX partnership most PM roles ask for: I repackaged the portal with Sales and built the enablement that let CS support it.
Next case study
Questionnaire builder refactor
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.
- Refactor
- Discovery
- Admin tooling
- Support partnership