Making of the DreamWorks Case Study

Writing case studies about completed projects is hard. Writing about ongoing work is harder. Writing about ongoing work at a major entertainment studio while maintaining client confidentiality is the boss level.

The DreamWorks case study taught me as much about communication constraints as it did about product strategy. Here's how I navigated it.

The core tension

I wanted to show my best work. But my best work was happening in real-time, with sensitive information, at a client who hadn't agreed to be a reference.

The constraints:

• Active engagement - The project was ongoing, with shifting scope and evolving relationships
• Confidential details - Specific metrics, internal politics, and unreleased product plans
• Recognizable people - Quotes from colleagues and stakeholders who might not want to be named
• Prototype access - Live systems I couldn't screenshot without permission

I could have waited. Written it after the engagement ended, got formal approval, sanitized everything. But by then, the details would have faded. The texture of decisions-in-progress would be lost.

So I wrote it live and solved each constraint individually.

Anonymization over omission

My first instinct was to remove sensitive details. But that created a different problem: the case study felt generic. "Improved efficiency" means nothing. "15-30 minutes reduced to 60 seconds" means something.

The better approach: anonymize people, keep specifics.

• Quotes from stakeholders became attributed to roles: "VP of Engineering," "the DigiMatte lead"
• I kept exact metrics but removed context that would identify individuals
• The client name stayed - DreamWorks is publicly known as a technology-forward studio, and the work itself isn't secret

I also got explicit approval from my primary contact before publishing. The content was framed carefully: this is my analysis, my synthesis, my perspective on the work. Not an official DreamWorks statement.

The sidenote system

Case studies need context. But footnotes interrupt flow, and inline explanations bloat the prose.

Sidenotes[tufte] solved this elegantly. Technical terms get definitions in the margin. Methodology explanations live alongside the narrative without derailing it. Readers who know the domain skip them; readers who don't can learn without context-switching.

The technical implementation went through three iterations. First, I tried imperative DOM positioning - measuring element positions and setting CSS transforms. This broke on React re-renders because the measurements became stale.

Then I tried pure CSS with position: sticky and margin placement. This worked for simple cases but couldn't handle collision detection when multiple sidenotes were close together.

The final system uses React context:

1. Sidenote components register with a provider, passing their content and a ref to the inline marker
2. The provider calculates all positions after refs are available
3. SidenoteColumn renders the sidenotes with collision avoidance
4. On mobile, sidenotes become tap-to-reveal popovers

Simple concept, surprisingly complex execution.

Embedded prototypes

Telling people you built something is less convincing than showing them.

I embedded live prototypes directly in the case study using password-protected iframes. Readers can interact with actual functionality, not static screenshots. The prototype loads when you expand it, so it doesn't slow down initial page load[defer].

The decision to use live embeds over screenshots was intentional:

• Credibility - You can verify the work exists and functions
• Context - Seeing how interactions feel conveys more than describing them
• Evolution - As prototypes improve, the case study automatically shows the latest version

Password protection handled the confidentiality issue. Approved viewers get access; random visitors see a prompt explaining why access is restricted.

Eventually, I removed password protection for the DreamWorks prototype when the scope of work became more public. But having the infrastructure in place let me share selectively during the sensitive period.

The WIP overlay pattern

Not everything was ready to show. Some sections were drafted but incomplete. Some prototypes existed but weren't polished.

Rather than hide unfinished work entirely, I added a "Work in Progress" overlay system. Readers see that content exists, that I'm actively developing it, but can't access the raw material yet.

This turned a limitation into a feature. The case study signals ongoing engagement rather than completed archive. It says: this work is happening now.

Structure decisions

The hardest part was narrative structure. Product work doesn't have a clean beginning, middle, end. It's iterative, parallel, sometimes contradictory.

I settled on this flow:

1. Hook - The pencil test story. Animators digitizing their own studio's DVD because the original assets were inaccessible.
2. Context - How animated films get made. Without this, readers can't evaluate whether the problem is real.
3. Problem - The five manifestations of the root issue: no shared language, artists as archivists, globalization pressure, the incumbent's AI advantage, file-by-file workflows.
4. Approach - What we tried, what failed, what worked. Including the political dynamics of earning trust.
5. Solution - The specific artifacts and outcomes.
6. Impact - Quantified results and stakeholder quotes.

Each section could standalone. Readers can skim headings, dive into what interests them, skip what doesn't. The table of contents with scroll-spy makes navigation explicit.

What I'd do differently

More visuals, earlier. I front-loaded prose and back-loaded screenshots. Should have been the reverse. People scan.

Shorter sections. Some sections are 800+ words. Web readers don't have that patience. I should have broken them up further.

Explicit timestamps. The case study spans November 2024 to present. I mention this in passing but should have made the timeline more visible - it affects how readers interpret "in progress" statements.

The meta-lesson

Writing this case study was product work. I had users (hiring managers, potential clients), constraints (confidentiality, time), and needed to ship something useful while iterating.

The decisions - sidenotes vs. footnotes, live prototypes vs. screenshots, anonymization vs. omission - were product decisions. Each involved tradeoffs. Each required understanding user needs.

Which is maybe the real point of the exercise. The case study demonstrates the thing it describes.

---

The DreamWorks case study is at /work/enterprise-asset-platform.