Product Case Study · Content Security
How I enabled enterprise customers to protect their content through a comprehensive content security framework — combining asset-level restrictions, runtime entitlement checks, and concurrent stream limits.
01 · Problem Statement
Enterprise video customers — media companies, broadcasters, and businesses with internal content — need granular control over who can access their content, from where, and under what conditions. This includes geo-restrictions, domain controls, time-based scheduling, token-based authentication, concurrent stream limits, and device management.
Why it matters: Content protection is not optional for these customers — it's a contractual, regulatory, and business requirement. For paid subscription platforms, it's the mechanism that enforces access. For enterprise customers protecting internal content, it's a compliance need. Without a capable, cost-effective solution, customers either build their own or look elsewhere.
02 · Approach
Joined the project mid-stream and spent time understanding the history: what existed before, why the prior service was being migrated, and what architectural decisions had shaped the current path. Understanding context before making changes meant resisting the urge to optimize prematurely.
Worked closely with engineering to understand current state, remaining work, and technical constraints. Aligned on feature scope based on what was feasible and valuable rather than what sounded good on paper.
Brought Sales, Support, and Customer Success into early conversations. Identified where customer conversations were stalling and what capabilities were table-stakes vs. nice-to-have.
Engaged with enterprise customers directly to validate use cases, understand real workflows, and pressure-test the product vision before committing resources to build.
03 · Root Cause
The core gap wasn't technical — it was a business gap. The market had clearly established that content protection was a standard requirement: paid subscription platforms need to control who streams what, and enterprise customers need to protect internal content from unauthorized access. Brightcove's existing solution did not provide a comprehensive, native answer to this need.
Customers were either working around limitations, relying on incomplete controls, or looking at third-party options that added cost and complexity. The business needed to provide a first-class solution where the market had already established clear demand.
04 · Solution
Brightcove Playback Restrictions is a content security framework that gives customers control over where, when, how, and by whom their content is streamed. It operates at two levels — asset-level restrictions defined upfront, and runtime restrictions enforced dynamically via JWT tokens.
05 · Implementation
The solution supports multiple security tiers (Tier 1–3) covering different combinations of features depending on customer needs — from basic geo and domain controls to full DRM-based concurrent stream enforcement. A key part of the product work was ensuring customers who did not want to encrypt all content still had viable options, and that the solution worked across Brightcove Player, Native SDKs, and customer-built players.
06 · Internal Enablement
One of the most important things I did before launch was ensuring internal teams were ready. I redesigned internal enablement materials, ran training sessions with Sales, Support, and Customer Success, and worked with Marketing to sharpen how the product was positioned — framing it around customer outcomes rather than technical features. This included building practical guides with real use cases so that Sales could have confident conversations and Support could handle questions without escalation.
07 · Rollout Strategy
08 · Outcome & Learnings
The launch landed with internal clarity. Sales understood how to position the product and which tier to recommend for different customer profiles. Support could handle questions without escalating. Customer confusion post-launch was minimal.
Key learnings:
Getting context before acting matters. Joining a project mid-stream means resisting the urge to make changes before understanding why things are built the way they are. The research I did into the prior service and the migration rationale shaped better decisions throughout.
The business gap often precedes the technical one. The market had already validated the need for comprehensive playback restrictions. The work was to build a native, capable solution — not to create demand, but to meet it.
Internal enablement is a product deliverable. A technically complete product that Sales can't position or Support can't explain is commercially incomplete. Treating enablement as part of the product scope — not an afterthought — made a measurable difference in how the launch landed.