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 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)
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)
For a Kanban team of fifty plus, the release decision meeting should happen within two days. It should have at least three parts. The team should choose one of three options. For Kanban, the release decision meeting should be part of the team's release planning. The meeting is a planning activity.
4. Iterate by Running a Feedback Loop After Every Release
Blakely iterated at Spanx. Iterating meant Spanx got better. Getting better built Spanx. (33/46)
You should iterate by running a feedback loop after every release. Review the release planning process, the prototype quality, the feedback collection, and the decision making. Base it on what is working and what is not. That way the release planning gets better after every release.
For an entertainment B2B multinational, the feedback loop might look like this. The Kanban coach runs a forty five minute meeting after every release. The meeting has four parts. (34/46)
Part one is fifteen minutes to review the release planning process. The team checks the process and sees if it works. That means the team can adjust it.
Part two is ten minutes to review the prototype quality. The team checks the prototypes and sees if they are good enough. That means the team can improve them.
Part three is ten minutes to review the feedback collection. The team checks the feedback forms and sees if they are useful. That means the team can improve them. (35/46)
Part four is ten minutes to review the decision making. The team checks the decisions and sees if they were right. That means the team can improve them. (36/46)
Last quarter, the feedback loop was run two times. The release planning process was reviewed two times. Three updates were made. Update one added a new step called client pre briefing so clients were briefed before seeing the prototype and understood the context. Update two made the prototypes more realistic so clients could see the value. Update three added a new question: How would you prioritize this feature against other features? That meant the team could prioritize. (37/46)
Three updates meant the release planning was better. Better release planning saved the company fifty four thousand dollars. That was the cost of poor release planning that would have happened without iterating. (38/46)
For a Kanban team of fifty plus, the feedback loop should happen after every release. It should have at least four parts. It should update at least one artifact per release. For Kanban, the feedback loop should be part of the team's release planning. The feedback loop is a planning activity.
Closing on Building the Simplest Version Over Spending Weeks Planning (39/46)
Sara 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.
For an entertainment B2B multinational running Kanban with multiple teams of fifty plus people, creating effective release planning requires the same frugal prototyping method. (40/46)
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. The prototype should have three elements. The total time should be one week. (41/46)