The problem
Live streaming had been growing for years, and a clear gap in InPlayer's platform was that customers had no native way to engage their viewers during a stream. Some had built their own chat solutions. Most had nothing. Customers were starting to ask for it, especially those running concerts, sports events and ticketed live experiences where viewer interaction was the whole point.
LiveLike was a clear partner choice: an audience engagement specialist, video-player agnostic, working across web and mobile, with a chat product broadcasters were already using elsewhere. Integrating their chat into our paywall would let customers offer real-time interaction without us having to build a chat system from scratch.
The initial framing was simple: chat as MVP. Moderation, polls, reactions and other engagement widgets as post-MVP work. We ran the project through RICE prioritization against the Integrations team's OKRs and committed.
Discovery
The product designer and I ran qualitative discovery with two customers from different segments. One was a music-industry production company running large concerts, up to 15,000 concurrent viewers, and actively asking for engagement features. The other was a platform-apps company whose customers were more focused on content navigation than live interaction, so their feedback was more measured.
Discovery confirmed our direction. Both customers wanted chat. The music-industry customer was unambiguous; the platform-apps customer was more cautious but still saw the value for the right kind of broadcaster. The hypothesis held. We moved into building.
Prototype and validation
With discovery signal validated, we built a clickable prototype in Figma and XD covering both the dashboard flow and the paywall experience. The goal was to get something concrete in front of customers before we shipped to test the actual experience, not just the idea.
Validation was structured: two broadcaster customers, both running live events. We handed them the prototype, gave them a script of tasks to complete, asked them to think aloud, and rated each flow on a 1–5 scale. The product designer and I ran the sessions together.
What validation found
What we heard surprised us.
The customers were excited about chat, that part matched. But a different signal kept showing up across both sessions, and it wasn't about chat itself.
"If the chat is not moderated it can turn into a disaster."
"I would expect to have a feature where you could censor comments to block profanities. The artist would have to have someone administering all of that."
That second customer went further. They walked us through how their artists actually work: some have a single manager running both the stream and the chat simultaneously; others have a team of ten. That level of detail moved the conversation from "moderation is a feature" to "moderation is a workflow that fits into how the customer's customers run their day."
Either way, the conclusion was the same: an unmoderated chat wasn't an incomplete feature to fix later. It was a reason they wouldn't activate the feature at all. A chat that could be flooded with profanity or spam wasn't a less-complete product for them, it was a liability they couldn't put in front of their viewers.
This was the moment that changed how I thought about MVP scope.
Moderation had been in the design doc as post-MVP. Validation made clear that framing wasn't going to work. So I made the call to extend the MVP scope to include basic moderation from day one.
The risk was real: we were adding scope to a project on a fixed timeline, which meant either pushing the launch or cutting something else. I judged it was the right risk to take because shipping a feature customers wouldn't activate was a worse outcome than shipping later. We integrated LiveLike's automatic content filter so customers could turn AI-driven moderation on or off per chat room, documented it, surfaced it in the dashboard UI and made it part of the chat setup flow.
Go-live
The prototype sessions gave us specific UX changes to make before launch. The integration shipped on schedule.
We'd set an activation target of 8% of customers turning chat on in the quarter after launch, based on the innovation adoption lifecycle, where innovators plus early adopters typically make up around 16% of a market, and we'd planned conservatively for half of that. We hit it.
The work was paused when InPlayer was acquired by JWX. The integration was working in production at the time of the acquisition.
Discovery and validation are different jobs
Going into LiveLike, my mental model of validation was that it was a confirmation step — you'd build a prototype, walk customers through it, get a thumbs-up and ship. Discovery had already told us we were building the right thing. Validation was supposed to be the safety check.
What this project showed me was that validation does something else too. Sometimes it doesn't confirm what you're shipping, bit it changes what counts as usable. Chat was the right thing to build. But what we'd framed as a fast-follow (moderation) turned out to be the thing that determined whether the feature was usable at all.
The lesson I've carried forward: whenever it's possible to put a working prototype in front of real customers before shipping, it's worth the time. Discovery tells you whether to build the thing. Validation tells you what makes the thing actually usable. They're different jobs and you need both.