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 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 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)
The release prototype is shown in a thirty minute meeting. The meeting has two parts. Part one is a fifteen minute prototype walkthrough so clients see the feature and understand it. Part two is fifteen minutes for collecting feedback using a structured feedback form. (23/46)
The structured feedback form has five questions. Question one: Does this feature solve a real problem for you? Question two: What is the most valuable part of this feature? Question three: What is missing from this feature? Question four: Would you use this feature in your daily work? Question five: What would make this feature better? (24/46)
Each client answers the five questions. That gives the team structured feedback. Structured feedback means the team can compare answers. Comparing answers means seeing patterns. Seeing patterns means knowing what to change.
The testing is completed within three days. That means the team knows quickly. Knowing quickly means deciding quickly. (25/46)
Last quarter, fast testing was done for every release prototype. The team got real feedback within three days. The team knew whether the feature was worth building. The team only built features that clients wanted. That saved the company fifty four thousand dollars. That was the cost of unwanted features that would have been built without fast testing. (26/46)
For a Kanban team of fifty plus, fast testing should involve at least three clients. It should be completed within three days. The structured feedback form should have at least five questions. For Kanban, fast testing should be part of the team's release planning. The testing is a planning activity.
3. Decide What to Do Next by Holding a Release Decision Meeting Within Two Days of Collecting Feedback (27/46)
Blakely decided what to do next at Spanx. Deciding what to do next meant building products that worked. Products that worked built Spanx.
You should decide what to do next by holding a release decision meeting within two days of collecting feedback. The team reviews the feedback and decides whether to build the feature, pivot, or drop it. That way the release plan is based on real feedback instead of assumptions. (28/46)
For an entertainment B2B multinational, the release decision meeting might look like this. The Kanban coach holds a thirty minute release decision meeting within two days. Two days means the feedback is fresh. Fresh feedback means an informed decision.
The meeting has three parts. Part one is ten minutes to review feedback. The team reads the structured feedback forms and sees what clients said. That means the team knows what clients want. (29/46)
Part two is fifteen minutes to decide. The team chooses one of three options. Option one is to build the feature. That means the feedback was positive and clients want the feature. Option two is to pivot. That means the feedback was mixed and clients want some parts. The team changes the feature. Option three is to drop the feature. That means the feedback was negative and clients do not want it. (30/46)
Part three is five minutes to update the release plan. The team changes the plan to reflect the decision. That means the plan is based on real feedback. (31/46)
Last quarter, the release decision meeting was held for every release prototype. The team decided what to do next. The release plan was based on real feedback. The team only built features that clients wanted. That saved the company fifty two thousand dollars. That was the cost of unwanted features that would have been built without a release decision meeting. (32/46)