Mastodawn

# How to Use Brand Extension Method to Create Meaningful User Stories in Retail B2B

A retail B2B startup running DSDM with a team of six to fifteen people has a user story problem. The company builds an inventory forecasting platform for independent retailers. The platform predicts demand, suggests reorder quantities, tracks supplier lead times, and generates purchase orders. (1/47)

The company is two years old with nineteen employees. Nine people work in product development. One feature team. The user stories are weak. They are vague. They do not capture what the user actually needs.

A typical story reads: As a user, I want to see my inventory so that I can manage it. The story does not say what see means. It does not say what manage means. It does not say what data the user needs or what actions the user can take. (2/47)

The developer who picks up the story has to guess. The developer builds something. The product manager reviews it and says it is not what they meant. The developer rebuilds. The rebuild takes three days. Those three days are wasted.

Last month, the team spent forty percent of its development time on rework caused by vague user stories. The rework delayed the launch of the demand prediction module by three weeks. The delay caused two pilot customers to pause their contracts. (3/47)

The user stories must become meaningful.

## The Brand Extension Method

Richard Branson built Virgin on the brand extension method. The model was simple. Branson did not launch new businesses by inventing new categories. He launched them by extending the Virgin brand into adjacent ones.

Virgin Records was music. Virgin Atlantic was travel. Virgin Mobile was telecom. Virgin Cola was beverages. Virgin Galactic was space travel. (4/47)

The brand extension worked because Branson understood one thing. The brand was not a product. The brand was a promise. The promise was: We will give you a better experience than the incumbents. That promise was the same in every category. It was specific. It was testable. It was meaningful. (5/47)

Branson applied the same thinking to product development. When he launched Virgin Atlantic, he did not write vague requirements. He wrote specific promises. We will serve real food on long haul flights. We will offer free drinks in economy. We will have the best in-flight entertainment. We will have the friendliest cabin crew. (6/47)

The promises were specific. They were testable. They were meaningful. The development team knew exactly what to build. They did not guess. They did not rework. They delivered. (7/47)

For a retail B2B startup, the user story problem is the same. The user stories are vague. They do not capture what the user actually needs. Branson's brand extension method says: write user stories as promises. Specific. Testable. Meaningful. The specific promises eliminate guessing. The testable promises eliminate rework. The meaningful promises eliminate waste.

## The Core Principle (8/47)

Branson's brand extension method was built on a simple insight. The best way to communicate what a product should do is to write specific, testable promises instead of vague requirements.

Branson did not tell the Virgin Atlantic team to make flying better. He told them to serve real food on long haul flights and offer free drinks in economy and have the best in-flight entertainment. The promises were specific. They were testable. They were meaningful. (9/47)

For a retail B2B startup, the fix is the same. Write user stories as promises. The promises are specific. The promises are testable. The promises are meaningful. The specific promises eliminate guessing. The testable promises eliminate rework. The meaningful promises eliminate waste.

## Four Steps to Apply Brand Extension Method to Creating Meaningful User Stories

### 1. Rewrite Every User Story as a Specific Promise (10/47)

Branson wrote specific promises for Virgin Atlantic. We will serve real food on long haul flights. The promise said what: real food. The promise said when: on long haul flights. The promise was testable. A passenger could verify whether the food was real. The promise was meaningful. A passenger could feel the difference.

Your team should rewrite every user story as a specific promise that states exactly what the user will experience. (11/47)

For a retail B2B startup, the promise rewrite might look like this. The product manager gathers the team. The team has nine people. The session takes two hours. The session rewrites five user stories.

Story one. Original: As a user, I want to see my inventory so that I can manage it. The story is vague. It does not say what see means or what manage means. (12/47)

The team rewrites. Promise: As a store manager, I want to see a table of all my products with current stock levels, reorder points, and supplier lead times so that I can identify which products need reordering today. (13/47)

The promise is specific. It says what: a table of products with stock levels, reorder points, and lead times. It says who: a store manager. It says why: to identify which products need reordering today. The promise is testable. The developer can verify whether the table shows the three data points. The promise is meaningful. The store manager can act on the information.

Story two. Original: As a user, I want to get alerts so that I know when something is wrong. (14/47)

The team rewrites. Promise: As a store manager, I want to receive a push notification when any product drops below its reorder point so that I can place a purchase order before I run out of stock.

The promise is specific. It says what: a push notification. It says when: when any product drops below its reorder point. It says why: to place a purchase order before running out of stock.

Story three. Original: As a user, I want to forecast demand so that I can plan ahead. (15/47)

The team rewrites. Promise: As a store manager, I want to see a thirty-day demand forecast for each product category based on the last twelve months of sales data so that I can adjust my purchasing plan for the upcoming month.

The promise is specific. It says what: a thirty-day demand forecast. It says how: based on the last twelve months of sales data. It says why: to adjust the purchasing plan for the upcoming month. (16/47)

The five stories are rewritten. The rewriting took two hours. The rewritten stories are specific, testable, and meaningful. The developers know exactly what to build. They do not guess. They do not rework.

For a DSDM team of six to fifteen, the promise rewrite should happen in one session. The session should take no more than two hours. The session should rewrite at least five user stories. For DSDM, the promise rewrite should be part of the user story writing workshop. (17/47)

### 2. Add Acceptance Criteria to Every Promise

Branson added acceptance criteria to every Virgin Atlantic promise. The promise was: We will serve real food on long haul flights. The acceptance criteria were: The food must be prepared fresh on the day of the flight. The food must include at least two hot meal options. The food must be served on ceramic plates with metal cutlery. (18/47)

The acceptance criteria defined what done looked like. The development team knew when the promise was fulfilled. The fulfillment was not subjective. It was measurable.

Your team should add acceptance criteria to every promise that define what done looks like. (19/47)

For a retail B2B startup, the acceptance criteria might look like this. The product manager adds acceptance criteria to every rewritten promise. The acceptance criteria use a simple format: Given [context], when [action], then [outcome].

Promise: As a store manager, I want to see a table of all my products with current stock levels, reorder points, and supplier lead times so that I can identify which products need reordering today. (20/47)

Acceptance criteria one: Given I am on the inventory page, when I load the page, then I see a table with columns for product name, current stock level, reorder point, and supplier lead time.

Acceptance criteria two: Given I am on the inventory page, when a product's current stock level is below its reorder point, then the row is highlighted in red. (21/47)

Acceptance criteria three: Given I am on the inventory page, when I click on a product row, then I see a detail panel with the last three purchase orders for that product.

Acceptance criteria four: Given I am on the inventory page, when I filter by supplier, then I see only the products supplied by that supplier. (22/47)

The acceptance criteria define what done looks like. The developer knows when the story is complete. The product manager knows when to accept the story. The acceptance criteria eliminate subjectivity. The elimination of subjectivity eliminates rework. (23/47)

Last sprint, the developer built the inventory table. The product manager reviewed it. The table had the four columns. It had the red highlighting. It had the detail panel. It had the supplier filter. The product manager accepted the story. No rework. The story was done. (24/47)