My GitHub bio describes me as a product manager with an impatience for boring. That is fairly accurate.
When a process is repetitive, unclear or difficult to explain, my instinct is often to build something small. The purpose is not always to create a startup or a polished product. A prototype is a way to make the problem concrete enough to test.
Start with the awkward moment
The most useful ideas usually begin with a specific frustration.
Testing an NHS form requires a realistic identifier, but using a real patient’s NHS number would be inappropriate. That became a small generator which deliberately produces numbers that fail the official checksum. It preserves the shape needed for validation while making accidental use of a real identifier far less likely.
Choosing accessible colours can become a slow sequence of manual contrast checks. That became a palette generator which creates distinct colour sets and adjusts lightness towards AA or AAA targets.
Finding current board papers across NHS organisations involves repeating the same search across sites with very different structures. That began as a scraper and grew into a broader evidence platform spanning mental health trusts, ICBs and national datasets.
The scale is different, but the starting question is the same: what is the smallest useful thing that would remove this friction?
A prototype is a question
Building exposes assumptions that are easy to hide in a document.
An NHS evidence scraper has to confront inconsistent naming, broken links, rate limits, JavaScript-rendered pages and organisations that move their publications without warning. A group game picker has to define what a “good” recommendation means when friends own different games, have different amounts of time and do not agree on a genre.
Those are not only engineering problems. They are product and operational questions. The code forces a decision about edge cases, ownership and what information a user actually needs.
That is why I find prototyping useful in delivery roles. It creates an artefact people can react to. A working screen, an automated report or a rough calculation invites more specific feedback than a description of what the eventual solution might do.
Build for the real workflow
The prototype needs to respect the environment around it.
The invalid NHS number generator explains which digit was changed and why the result fails validation. The accessible palette tool lets someone inspect existing hex colours rather than requiring them to start again. The NHS evidence scraper keeps a failure log and allows manual correction because public websites will never remain perfectly predictable.
The same principle applies to personal projects. What Should We Play? is not simply a random game picker. The real problem includes finding a date, comparing libraries, working around private Steam profiles, agreeing a budget and sharing the result with a group. The interesting work is in the joins between those steps.
Sometimes the interface is physical
Electronics projects provide a useful change of pace because they make constraints impossible to ignore.
Adapting a desktop companion to a round ESP32-S3 touch display meant working with the safe area of a circular screen, physical buttons, a latching side switch, Bluetooth pairing and sleep behaviour. A design that works in a browser is not automatically useful on a 1.85-inch device.
That kind of making reinforces the same habit I value in healthtech: understand the context, prototype around the constraint and test the experience where it will actually be used.
Know when to stop and when to scale
Some prototypes should remain single-page utilities. Their value is that they solve one task clearly.
Others reveal a larger workflow and earn more investment. The NHS scraper accumulated organisation configuration, caching, parallel jobs and evidence extraction because each real run exposed the next limitation. The game-night tool grew into a full-stack product because planning and choosing were connected problems for the same group.
I do not mind a prototype growing. I mind it growing before the extra work answers a real question.
I understand an idea faster once I can click it, break it and put it in front of someone else. More often than not, that is when I discover the original problem was slightly wrong.