Hackworks Innovation Challenge Platform
A configurable platform for running complex innovation programs without rebuilding the operating system for every new client, format, or audience.
Case study at a glance
- Role
- Product strategy and systems lead
- Scope
- A configurable platform spanning registration, participation, submissions, communications, and judging across varied innovation-program formats.
- Outcome
- Increased adoption by 30% and supported approximately $700K in cumulative platform-related revenue—$250K+ in white-label sales and approximately $450K in associated service contracts.
The verified written case study below provides an accessible alternative to the video. Skip to the written story.
01
The challenge
Innovation challenges can look similar from the outside while behaving very differently underneath. Each program can have its own participant model, forms, team rules, submission structure, communications, and judging process.
The existing choice was usually between rigid software that did not fit the program or a heavily manual process that became expensive and fragile as the work scaled.
The opportunity was to turn that repeated complexity into a product: flexible enough for real programs, but coherent enough to operate reliably.
02
The approach
I led the platform design around shared program logic rather than one-off event pages. Admins could configure the rules, while participant and judge experiences consumed the same underlying data through purpose-built interfaces.
That made the platform reusable without pretending every program was identical. The variation moved into configuration, forms, permissions, and workflow states instead of custom rebuilds.
03
How the system works
Participation models
Programs could support individuals or teams, including free-agent recruitment, join requests, private teams, and open formation.
Dynamic forms
Admins could define registration and submission requirements, including vetting, waitlists, and structured data capture.
Flexible judging
Multiple criteria sets, judge types, and phases worked with manual assignment or automated distribution rules.
Shared architecture
Admin, participant, and judge products used the same API and program logic while presenting different experiences.
Video case study
See the complete product story.
A deeper walkthrough of the problem, product decisions, and finished experience.
04
Key decisions
Configure the system instead of customizing every event
Reusable building blocks reduced repeated development while preserving the differences that mattered to each program.
Treat forms as product infrastructure
Registration and submission data powered the rest of the workflow, so forms became a flexible system rather than static screens.
Separate experiences without fragmenting the product
Judges, admins, and participants needed different tools, but a shared logic layer kept the program consistent end to end.
05
What changed
- Increased platform adoption by 30%.
- Supported approximately $700K in cumulative platform-related revenue, including $250K+ in white-label sales and approximately $450K in associated service contracts.
- Reduced operational overhead by moving recurring variation into configuration.
- Unified admin, participant, and judge workflows around one program model.
Reflection
The platform reflects how I like to work: start with the real complexity, find the reusable logic inside it, and build a system that stays flexible without becoming chaotic.
The next layer I would deepen is operational visibility—especially form performance, judging throughput, and participant drop-off—so teams can improve programs using evidence from the platform itself.