How We Built a Public Product Feedback Loop

Updated: May 2026

Our product roadmap lives on our website. Users can upvote what gets built next, and when a feature ships, the user who asked for it gets an email and their support ticket closes on its own. No one has to remember the follow-up.

We're building OpenFrame as a PLG platform - small deal sizes, broad product surface area, lots of users we'll never speak to one-on-one. That math forces a different kind of product operation. We can't run webinars to announce every shipped feature. We can't track requests in someone's head.

The whole product feedback loop has to run as a system, not a series of human handoffs.

Here's how it works.

Why the roadmap is public

Most companies hide their roadmap because they sell to enterprise buyers who'll hold them to it. We don't have that problem. Our customers aren't signing six-figure contracts with deliverables tied to release dates. They're operators looking at a product, deciding if it's worth using, and asking themselves: are these people actually building?

A public roadmap answers that question without us having to say anything.

It also creates a feedback channel that scales. Every roadmap item has an upvote and downvote button.

We don't have to chase users for feedback - they tell us which direction matters by clicking.

It is the public face of the system. Behind it, every item is a ClickUp task. The two stay in sync automatically.

The voting layer

When someone upvotes a roadmap item, we don't push it to ClickUp immediately. That would hammer the API. The vote drops into a queue, and a job drains the queue once a minute, pushing the batch to ClickUp.

Outbox pattern, basically. The website never waits on ClickUp's API. ClickUp never gets slammed. Either side can be down briefly and nothing breaks.

ClickUp itself runs as multiple boards - one per team, plus a dedicated roadmap board. Each roadmap item carries an icon, sometimes a Figma prototype, sometimes a screenshot of what's shipping. The whole thing mirrors to our database, and from there to the public page.

We also track enhancements and bug fixes as separate object types. The same sync handles all of it, so feature request management runs through one pipeline whether the ask becomes a roadmap item or a small fix.

AI does the release notes

Once a release is ready in ClickUp, we move it to a custom status called "for review." That's my signal to write it up.

But "writing it up" means three inputs: the list of roadmap tasks tied to the release, the bug fixes and enhancements going out, and the semver number. That's it.

From those three fields, an AI agent generates the rest: release summary, changelog, features added, bug fixes, improvements, video script outline, and the OG image. We don't keep a release notes template anyone has to fill in. The template is implicit in what the AI knows to produce.

Then I record the raw release video, walking through what shipped. The AI doesn't write the script - it gives me the structure so I know what to cover.

When the release goes live, the same release page on the website pulls in everything: roadmap items, related fixes, the GitHub release for the open-source side, and the video. One page, one source.

Closing the loop with support tickets

Here's the part most product teams skip.

We use HubSpot for help desk. Every ticket can be tagged with a ClickUp task ID. When a user reports something - a bug, an OS we don't support yet, a missing integration - the support response includes that link.

Then, when the ClickUp task ships in a release, two things happen automatically. The user gets an email saying their ask is now live in production, with a pointer to what changed. Their HubSpot ticket auto-closes.

No one has to remember which user wanted what. No one writes the "hey we shipped this" email. The data was already tied together at the moment the ticket was filed, and the release pipeline knows where to send the notification.

This is the loop:

User reports → ticket linked to task → task ships → user notified → ticket closes.

The whole thing runs as plumbing.

One raw video, six output formats

Every release video gets repurposed automatically. We use Wizado AI's API for the clipping side. The same raw video produces portrait clips for Shorts, square clips for LinkedIn, landscape clips for the website.

For the highlight reel, Claude reads the ElevenLabs transcript and picks scenes. ElevenLabs flags natural cut points - where a sentence ends, where there's a pause - so the highlights don't sound chopped. ShotStack handles the edits. Subtitles are optional, length is configurable.

The video component is unified across the product. The same player renders releases, case studies, and any other long-form video. We didn't want six different video patterns to maintain.

The raw video is the bottleneck. Everything downstream is automated.

What this gives a small team

The point isn't the specific tools. It's that customer feedback loops, the public roadmap, the release pipeline, and the help desk are one connected system instead of six handoffs.

Most product orgs have a roadmap tool, a feedback tool, a release notes tool, a help desk tool, a video editor, and an email platform - and the connection between them is humans copy-pasting. We've made the humans-in-the-loop optional for everything except the actual product decisions.

What we get back is time. No one writes release notes. No one writes "we shipped your fix" emails. No one clips videos for LinkedIn. I think about what to build, record the release video, and the rest happens.

We'll break down a few of the adjacent systems in the next episodes - how we analyze customer interviews to find product gaps, how we build case studies from those interviews, and how documentation runs entirely off GitHub Actions without a technical writer. The full breakdown is on the How We're Building Flamingo podcast.

Build in public works better when the system you're building can carry the weight of being public.

Follow the show on YouTube and our website.