Hey folks,
Just wanted to share a recent experience. Our team needed a public-facing roadmap for our SaaS product, and we wanted it to be more dynamic and transparent than a static page or a buried Trello board. We decided to build it using Runway, and I’m honestly pretty impressed with how it turned out.
We used Runway’s video editor to create short, digestible clips for each major feature in the pipeline. Each clip shows a quick prototype or mockup, with text overlays explaining the problem it solves and the expected timeline. We then embedded these into a simple public Notion page, categorized by “Now,” “Next,” and “Later.” The whole thing feels much more alive and engaging than a list of bullet points.
The biggest win was how it changed our internal communication, too. Instead of lengthy written specs, our product team now drafts these quick videos. It cuts down on misinterpretation and gets everyone—engineering, design, marketing—on the same page faster. We’ve also started adding short “behind the scenes” clips for completed items, showing the actual work that went into it, which our users seem to love.
Has anyone else tried using Runway for non-traditional, non-marketing purposes like this? I’m curious about other creative applications for internal or community tools. Also, if you’ve built a public roadmap with other tools, what was your approach? Always looking to learn from this community’s workflows.
— Eric
Keep it civil, keep it real.
That's a fascinating repurposing of a tool. The internal communication benefit you mentioned is the real kicker for me. We've tried using Loom for something similar with API documentation updates, but the editing overhead was too high. Runway's text-to-video and quick editing features seem like they'd cut that down significantly.
Have you considered the data flow implications for scaling this? Right now you're manually embedding into Notion, but if your roadmap grows, you might want to automate it. You could trigger a Zapier or Make workflow when a new Runway video is published, auto-posting it to a designated database in Notion with the correct "Now/Next/Later" tag. It would keep your public page in sync without manual steps.
I'm curious about the lifecycle management, though. When a feature moves from "Later" to "Next," do you update the same video or create a new, more detailed version? Maintaining version control on those video assets could become a hidden cost.
That's a great point about the automation, and I think you're spot on about the need for it as the list grows. I'd probably lean towards building a simple API integration rather than Zapier, just for more control over the metadata that gets pushed to Notion, like the commit hash or the video's last edited date.
Your question on lifecycle management is the real crux of it, though. We faced this exact issue and settled on a rule: the video is updated in place until the feature is in development. Once coding starts, we freeze that video as a record of the "promise" and create a new, more technical one for the "Next" column. It adds a bit of asset overhead, but it prevents confusion about what was originally communicated versus what's being built. Have you seen other teams handle this differently?
buyer beware, but buy smart
Oh that's such a clever idea! Using short videos for feature specs sounds like a game-changer for internal alignment, especially for those tricky UX flows. The "behind the scenes" clips for completed items are pure genius for user engagement.
> non-traditional, non-marketing use
I love experimenting with tools this way. I've actually used Descript's screen recording to do something similar for our marketing automation logic - think "if this lead does X, here's the exact path they take" - but it was purely internal. Taking it public with a roadmap is next level.
I'm really curious about the time investment per video. Do you find your team getting faster at creating them, or does the polish for a public audience still add significant overhead compared to a Loom-style quick-and-dirty recording?
Happy testing!
This approach to internal communication is where I've seen the biggest payoff too. We do something similar for our lead scoring model updates. Instead of a changelog email, the product manager records a quick video walking through the new logic with a mockup of the dashboard. It eliminates the back-and-forth questions from the sales team instantly.
The only caveat I'd add is to be mindful of creating a single point of failure. If your product lead is the only one comfortable making these videos, the process can stall. We made it a rule that any two people from product, design, or engineering can approve and publish a spec video. It keeps things moving.
Have you linked your video roadmap into any analytics yet? We found tagging each video in our CDP and tracking views from known accounts gave our sales team a powerful signal for outreach.
automate everything
You're right about the single point of failure, but creating a committee approval process just trades one bottleneck for another. Getting two people to sign off sounds like a recipe for video spec delays.
> linking your video roadmap into any analytics yet
This is where it can get creepy fast. Tagging videos and tracking views from known accounts? That assumes your CDP is perfectly clean, which is never true. Your sales team will get excited about a "signal" that's just someone from engineering watching it three times to catch a detail. Now they're pinging a lead about a feature that isn't even built based on flawed data. Been there.
been there, migrated that
You're right about the CDP data being a mess. I've seen teams waste months trying to attribute S3 storage cost spikes to "increased engagement" from roadmap views, when it was just the engineering team's daily sync playing the same videos on loop. The attribution noise is real.
I think the approval bottleneck is a process cost, and like any cost, it should be quantified. If a two-person sign-off adds three days to your spec cycle, what's the opportunity cost of that delay in engineer idle time? Sometimes the bottleneck is cheaper than the chaos of uncoordinated commits.
Right-size or die
That's a really good point about measuring the bottleneck cost. I've been trying to track the time from ideation to development start for our smaller tasks, and even small delays add up across a quarter.
It makes me wonder how you'd even start to quantify the "chaos of uncoordinated commits." Is it just more bugs in production, or does it show up somewhere else, like in your sprint velocity metrics?
Tracking uncoordinated commits? Look at your bug backlog churn and your rework rate. It's not a velocity metric, it's the noise in your system. If you're spending more time fixing yesterday's "urgent" feature than building tomorrow's, that's your chaos tax.
Quantify it by the hours your senior devs spend putting out fires that a two minute spec video would have prevented. Sometimes the process bottleneck is cheaper.
CRM is a means, not an end.
Your "freeze the promise" rule is a nice concept, but you're just trading one type of confusion for another. Now you have two videos for one feature - a public "promise" and an internal "technical" one. Which one does support reference when a customer complains the delivered feature doesn't match the roadmap? Which one does sales use?
You've created a version control problem you'll have to manage forever. The asset overhead isn't just storage, it's cognitive load.
Trust but verify.
Exactly. The "promise" video is a liability. Sales will show it, support will get blamed, and legal might get interested if you over-promise.
Your version control problem is now a customer expectation problem. You think a disclaimer in small text fixes it? Good luck with that.
Just link to the commit. One source of truth, always current. Everything else is theater.
Great point about automation scaling. That Zapier/Make workflow could definitely save time, but it introduces a new integration point you need to secure.
> lifecycle management
This is the real gotcha. If you update the same video, you break any existing links or embeds. If you create a new one, you now have multiple assets for the same feature to manage. I've seen teams accidentally leave the old "promise" video up because they forgot which Notion page it was linked to. A naming convention and a tight permission model on that video bucket become crucial.
Maybe tag the video file itself in S3 or GCS with metadata like `feature-name` and `roadmap-status` so your automation can always fetch the latest version? It adds a step, but keeps you from building on broken links.
security by default
Metadata tagging is a nice idea until you have five tags that mean the same thing. Then you're managing a taxonomy instead of a roadmap.
You think automation fetching the "latest version" saves you? Wait until someone tags a video incorrectly. Your entire external roadmap points to a dev's joke commit message.
The real problem isn't broken links, it's needing video at all. Link to the spec doc. It changes, you update it. No promises, no versions.
Your vendor is not your friend.
Interesting approach, but you've just traded static pages for video spec hell. The "misinterpretation" you're avoiding with videos is dwarfed by the new problem of version control and asset sprawl.
What happens when that mockup changes? Do you re-shoot, re-edit, and re-embed? Or do you leave an outdated "promise" video on a public page? The second you update, every embed is a liability. The third you don't, it's misinformation.
And internal alignment is great until you need to search, reference, or link to a specific requirement. A 90-second video is a terrible database.
cg
You're right about the search problem. I once had to audit a legacy video-spec system, and we couldn't even find which features mentioned a specific API endpoint. We had to watch hours of footage. It's not just a terrible database, it's an unindexable black hole.
The asset sprawl multiplies when you consider compliance. A "promise" video for a feature handling PII becomes a record you have to retain, secure, and potentially redact. Good luck doing that at scale with a bucket of MP4s.
The only time video specs worked for us was for a short-lived, high-velocity prototype phase with a tiny team. The moment we needed traceability or scale, it collapsed under its own weight.