agileHow to Use the Frugal Prototyping Method to Create Effective Release Planning in Entertainment B2B (1/46)
An entertainment B2B multinational running Kanban with multiple teams of fifty plus people has a release planning problem. The company provides a content distribution platform that helps studios and networks deliver video content to streaming services and broadcasters. The company has been around for eighteen years. It has two thousand three hundred employees. The product development organization for the company's new content rights management system has seventy one people (2/46)
. The organization runs Kanban. Eight teams. Each team has nine people. (3/46)
The release planning is broken. Releases are planned too far in advance. That means the plan is based on assumptions. Assumptions mean the plan is wrong. A wrong plan means the team builds features that clients do not want. Unhappy clients leave. Lost clients mean lost revenue. The company lost two hundred and eighteen thousand dollars last quarter. That was thirty five percent of the quarterly revenue from the content rights management system.
The release planning must be effective. (4/46)
Sara Blakely built Spanx on the frugal prototyping method. Her insight was simple. The biggest problem in product development was the tendency to spend too much time and money on planning before testing. Too much planning before testing meant products were based on guesses. Guesses meant products failed. Failed products killed companies. (5/46)
Blakely attacked that tendency. She created the frugal prototyping method. The method was based on one principle: Build the simplest version. Test it fast. Then decide what to do next. (6/46)
Building the simplest version meant creating a prototype. A prototype meant a rough version. A rough version meant little time and money spent. Little time and money meant fast testing. Fast testing meant real feedback. Real feedback meant knowing what worked. Knowing what worked meant being able to decide. Deciding what to do next built Spanx. (7/46)
When Blakely developed the first Spanx product, she did not spend months planning. She built the simplest version. She cut the feet off a pair of pantyhose. That was the prototype. She tested it by wearing it under white pants. She saw the result. She knew it worked. She decided to move forward. That decision built Spanx. (8/46)
Blakely applied the same thinking to every product. When she developed the Spanx bra, she did not spend months planning. She built the simplest version by modifying an existing bra. She tested it. She got feedback. She knew what to change. That built Spanx. (9/46)
For an entertainment B2B multinational, the release planning problem is the same. The company spends too much time planning releases before testing. That means releases are based on assumptions. Assumptions mean releases fail. Failed releases cost two hundred and eighteen thousand dollars. (10/46)
Blakely's frugal prototyping method says: build the simplest version, test it fast, then decide what to do next. That creates effective release planning. Effective release planning saves the company.
The Core Principle (11/46)
Blakely's frugal prototyping method was built on a simple insight. The best way to create effective release planning is to stop spending weeks building detailed release plans based on assumptions about what clients want. Start building the simplest possible version of each release feature as a prototype. Test it with real clients before committing to the full release plan. That way the release plan is based on real feedback instead of guesses (12/46)
. The team only builds features that clients actually need.
Blakely did not build Spanx by spending months planning products and hoping they would work. She built the simplest version, tested it fast, then decided what to do next. The simplest version meant little time and money. Fast testing meant real feedback. Deciding what to do next meant building products that worked. Products that worked built Spanx. (13/46)
For an entertainment B2B multinational, the release planning problem is the same. Too much planning before testing costs two hundred and eighteen thousand dollars. Blakely's method says: build the simplest version, test it fast, then decide what to do next. That creates effective release planning. Effective release planning saves the company.
Four Steps to Apply the Frugal Prototyping Method to Creating Effective Release Planning (14/46)
1. Build the Simplest Version by Creating a Release Prototype for Each Planned Release Feature
Blakely built the simplest version at Spanx. That meant little time and money spent. Little time and money meant fast testing. Fast testing built Spanx.
You should build the simplest version by creating a release prototype for each planned release feature. Make it a minimal working version that can be shown to clients in one week instead of a fully built feature that takes one month. (15/46)
For an entertainment B2B multinational, the release prototype might look like this. The Kanban coach creates a release prototype for a planned feature like the content rights dashboard. The minimal working version has three elements.
Element one is a static mockup. It is a screen that shows the dashboard layout so clients can see what it looks like. It is built in two days. (16/46)
Element two is a clickable prototype. It lets clients click through the dashboard so they can see how it works. It is built in three days.
Element three is a data sample. It is fake data that shows what the dashboard would look like with real data so clients can see the value. It is built in two days.
The total time is one week. The release prototype costs two thousand dollars. That means the team spends little time and money. The team can afford to test. (17/46)
Last quarter, the release prototype was created for every planned release feature. That meant the team spent little time and money. The team could test fast. The team got real feedback. The team built features that clients wanted. That saved the company fifty eight thousand dollars. That was the cost of unwanted features that would have been built without a release prototype. (18/46)
For a Kanban team of fifty plus, the release prototype should have at least three elements: a static mockup, a clickable prototype, and a data sample. The total time should be one week. The total cost should be less than five thousand dollars. For Kanban, the release prototype should be part of the team's release planning. The prototype is a planning artifact.
2. Test It Fast by Showing the Release Prototype to Three Real Clients Within Three Days (19/46)
Blakely tested it fast at Spanx. Fast testing meant real feedback. Real feedback meant knowing what worked. Knowing what worked built Spanx.
You should test it fast by showing the release prototype to three real clients within three days of completing the prototype. Collect their feedback using a structured feedback form. That way the team knows within three days whether the feature is worth building. (20/46)
For an entertainment B2B multinational, the fast testing might look like this. The Kanban coach shows the release prototype to three real clients. Three clients means three perspectives. Three perspectives means a balanced view. (21/46)
Client one is a studio executive from Warner Bros with fifteen years of experience. Client two is a network distribution manager from NBC with twelve years of experience. Client three is a streaming service content lead from Netflix with ten years of experience. (22/46)