The external compliance requirements are a mess. Each team handles compliance differently, which leads to inconsistency. Inconsistency leads to failed audits. Failed audits lead to lost studio contracts. Last quarter, those lost contracts cost the company $112,000, which was 33% of the quarterly revenue from the royalty tracking system.

Compliance has to be managed consistently across all eight teams. One proven approach comes from Sara Blakely and how she built Spanx. (2/26)

## The Core Insight Behind Frugal Prototyping

Blakely realized that the biggest problem in product development was the tendency to spend too much time and money perfecting a solution before testing it with real users. That made solutions expensive to develop, which left less money for everything else. That fragility is what kills startups.

She attacked the tendency to over-invest in perfection. Her method followed one principle: prototype fast, test cheap, learn quickly, iterate. (3/26)

Blakely did not manage product development at Spanx by letting each team build its own perfect prototype and hoping for consistency. She prototyped fast, tested cheap, learned quickly, and iterated. The entertainment B2B startup should manage compliance the same way.

## Four Steps to Apply the Frugal Prototyping Method

### 1. Prototype Fast: Build a Lightweight Compliance Feature List in One Day (6/26)

Blakely prototyped fast at Spanx, which meant she could test quickly, and testing quickly meant she could learn. Learning built Spanx.

Do the same thing here. Build a lightweight compliance feature list in one day that covers the five most common compliance requirements across all eight teams. Do not let each team build its own compliance process over several months. The chief feature owner creates a one-page document with five features.

The five features might look like this: (7/26)

For an FDD team of fifty plus, the compliance feature list should be a one-page document with at least five features, built in one day, and treated as a standard feature planning artifact.

### 2. Test Cheap: Run the Lightweight Compliance Feature List with One Pilot Team for Two Weeks

Blakely tested cheap at Spanx, which meant she could learn quickly. Learning quickly meant she could iterate. Iterating built Spanx. (11/26)

Do the same thing here. Run the lightweight compliance feature list with one pilot team for two weeks instead of rolling it out to all eight teams at once and hoping it works.

Pick the most compliance-heavy team as the pilot. In this case, that is team three, the royalty calculation team. What works for them will work for everyone else. (12/26)

The two-week pilot follows three steps. First, the pilot team implements the five compliance features and integrates them into their workflow. Second, the pilot team uses the features for two weeks, during which they find problems. Third, the pilot team provides feedback on what worked and what didn't.

Last quarter, a two-week pilot with team three found four problems: (13/26)

Finding those four problems meant the chief feature owner could learn and improve the list before broader rollout. That pilot saved $28,000 in compliance failures that would have occurred without it.

For an FDD team of fifty plus, the pilot should run for two weeks, involve one team, find at least three problems, and be treated as a standard development activity within feature development.

### 3. Learn Quickly: Document the Problems and Update the List Within Three Days (15/26)

Blakely learned quickly at Spanx, which meant she could iterate. Iterating built Spanx.

Do the same thing here. Document the problems found during the pilot and update the lightweight compliance feature list within three days so the other seven teams benefit from the pilot team's experience.

Write down the problems. Then fix them by adding sub-features or updating the existing ones. Based on the pilot results above, the updates would include: (16/26)

When these four sub-features were added and the updated list was shared with the other seven teams, those teams avoided the same mistakes. Compliance became consistent across all eight teams. That saved $24,000.

For an FDD team of fifty plus, quick learning should happen within three days, document at least three problems, update at least one artifact, and be built into the team's feature development process. (18/26)

### 4. Iterate: Roll Out the Updated List to All Eight Teams in Waves of Two Teams per Week

Blakely iterated at Spanx. Iterating made Spanx better. Getting better built Spanx.

Do the same thing here. Roll out the updated lightweight compliance feature list to all eight teams in waves of two teams per week. Collect feedback from each wave so the list gets better with each iteration.

Four waves take four weeks. (19/26)

For an FDD team of fifty plus, the iterative rollout should use waves of two teams per wave, take four weeks to complete, collect feedback after each wave, and be treated as standard feature development activity.

## Closing on Prototyping Fast Over Building Perfect Processes (22/26)