agile# How to Use the Global Delivery Model to Pivot Strategy Based on User Data in Entertainment B2B (1/34)
An entertainment B2B SME running FDD with a small team of two to five people has a strategy pivot problem. The company provides a ticketing and audience analytics platform to small and mid-sized music venues. It has been around for six years and has thirty-one employees. The product development organization for the company's new dynamic pricing engine has four people. One small team. The strategy is not based on user data. (2/34)
That means the team builds features based on assumptions. Those assumptions lead to features users don't want. Low adoption follows. Venues don't renew subscriptions. The company loses recurring revenue. That loss cost the company seventy-four thousand dollars last quarter. That was forty-one percent of the quarterly revenue from the dynamic pricing engine.
The strategy must pivot based on user data. (3/34)
Narayana Murthy built Infosys on the Global Delivery Model. His insight was simple. The biggest problem in delivering value across distances was making decisions centrally without understanding local needs. That led to the wrong work being prioritized. Delivery slowed. Clients were unhappy. Contracts were lost. Companies died. (4/34)
Murthy attacked the tendency to make decisions centrally without local data. He created the Global Delivery Model based on one principle: Distribute the sensing. Centralize the response.
Distributing the sensing meant putting data collectors close to the customer. That gave the company a real understanding of local needs. The right work got prioritized. Centralizing the response meant coordinating action from the center. The company could pivot quickly. That speed built Infosys. (5/34)
When Murthy set up the model, he didn't centralize all decision-making in India. He put project managers on site with clients. That gave Infosys direct insight into what clients actually needed. The right work got prioritized. Delivery was fast. That built Infosys. (6/34)
Murthy applied the same thinking to strategy decisions. When Infosys decided which markets to enter, he didn't make the call from a boardroom. He sent people to the markets. They collected data. The company understood the market. Strategy pivoted based on evidence. That built Infosys. (7/34)
For an entertainment B2B SME, the problem is the same. The team builds features based on assumptions. No user data gets collected. The company can't pivot. That inability costs seventy-four thousand dollars.
Murthy's model says: distribute the sensing, centralize the response. That combination enables data-driven pivots. Those pivots save time and money.
## The Core Principle (8/34)
Murthy's Global Delivery Model was built on a straightforward insight. The best way to pivot strategy based on user data is to stop making feature decisions in a vacuum. Stop guessing what venues need. Start distributing the sensing by embedding data collection into every feature. Centralize the response by reviewing all collected user data in a weekly thirty-minute strategy session. (9/34)
That approach builds a complete picture of what venues actually do. The team uses that picture to pivot product strategy every two weeks instead of every six months. (10/34)
Murthy didn't pivot strategy at Infosys by making decisions centrally without local data and hoping the assumptions were right. He pivoted by distributing the sensing, putting project managers on site with clients, and centralizing the response. Infosys understood client needs. It could pivot quickly. That speed built the company. (11/34)
For an entertainment B2B SME, the problem is the same. Building features based on assumptions costs seventy-four thousand dollars. Murthy's model says: distribute the sensing, centralize the response. That enables data-driven pivots. Those pivots save time and money.
## Four Steps to Apply the Global Delivery Model
1. Distribute the Sensing by Embedding Three Data Collection Points into Every Feature (12/34)
Murthy distributed the sensing at Infosys. That meant the company understood client needs. The right work got prioritized. That built Infosys.
You should do the same. Embed three data collection points into every feature. User behavior gets captured at every interaction. The team gets a complete picture of what venues actually do.
For an entertainment B2B SME, the three data collection points look like this. (13/34)
Data collection point one: Feature usage tracking. This tracks how often a feature is used. The team knows which features are popular. That tells the team what venues value. Implementation is simple. The developer adds an event to the code. Every time a venue uses the feature, the event fires and gets logged. The team can see usage frequency. That's data. (14/34)
Data collection point two: Drop-off point tracking. This tracks where users stop using a feature. The team knows where the feature is confusing. That tells the team what to fix. Implementation is simple. The developer adds a step tracker to the code. Every time a venue completes a step, it gets logged. The team can see where venues drop off. That's data. (15/34)
Data collection point three: Time on task tracking. This tracks how long users spend on each task. The team knows which tasks are slow. That tells the team what to optimize. Implementation is simple. The developer adds a timer to the code. The timer starts when a venue begins a task and stops when they finish. The team can see how long tasks take. That's data. (16/34)
Last quarter, embedding these three data collection points into every feature meant user behavior was captured at every interaction. The team had a complete picture. They knew what venues actually did. They stopped making assumptions. That saved the company twenty-six thousand dollars. That was the cost of features that would have been built on wrong assumptions. (17/34)
For an FDD team of two to five, embed three data collection points into every feature. Track usage, drop-off, and time on task. The developer implements them. Make them part of the team's feature development workflow.
2. Centralize the Response by Running a Weekly Thirty-Minute Strategy Session
Murthy centralized the response at Infosys. That meant the company could pivot quickly. That speed built Infosys. (18/34)
You should do the same. Run a weekly thirty-minute strategy session. The team reviews all collected user data. They decide whether to pivot the product strategy or continue on the current path.
For an entertainment B2B SME, the session has three parts.
Part one: Review feature usage data. Ten minutes. The team looks at the data. They see which features are popular and which are not. They decide whether to invest more in popular features or cut unpopular ones. (19/34)
Part two: Review drop-off data. Ten minutes. The team looks at the data. They see where venues drop off. They decide whether to fix confusing steps or remove them.
Part three: Make a pivot decision. Ten minutes. The team decides. They either pivot or continue. Pivoting means changing direction. Continuing means staying on the current path. Making this decision every week means the team can pivot quickly. They don't waste time on the wrong strategy. (20/34)
Last quarter, the team ran the session twelve times. They reviewed user data twelve times. They made four pivot decisions.
Pivot decision one: the team pivoted away from a feature with low usage. Venues didn't want it. Building it was a waste. The pivot saved three weeks of development time.
Pivot decision two: the team pivoted toward a feature with high usage. Venues loved it. Investing in it was smart. The pivot increased adoption by fifteen percent. (21/34)
Pivot decision three: the team pivoted away from a step with high drop-off. Venues found it confusing. They abandoned the feature. The pivot reduced drop-off by twenty-two percent.
Pivot decision four: the team pivoted toward a task with low time on task. Venues found it fast. They liked it. The pivot increased satisfaction by eleven percent. (22/34)
Those four decisions saved the company twenty-nine thousand dollars. That was the cost of the wrong strategy that would have continued without the weekly session.
For an FDD team of two to five, keep the session to thirty minutes. Use the three-part structure. Make at least one pivot decision per month. Make it part of the team's feature planning.
3. Build an MVP for Every Pivot Decision and Ship It to Five Venues Within One Week (23/34)
Murthy built MVPs at Infosys. That meant the company could test quickly. It could validate. That built Infosys.
You should do the same. For every pivot decision, build the smallest possible feature that tests the new direction. Ship it to five venues within one week. Validate the pivot before committing. (24/34)
For an entertainment B2B SME, the process looks like this. The team lead builds an MVP for every pivot decision. The feature is minimal. It takes one week to build. The team ships it quickly. They test it with real venues. They validate the pivot. They know if it's right. Then they commit or pivot again.
The MVP goes to five venues. Those five venues test it and provide feedback. The team learns. They decide whether to commit to the pivot or try something else. (25/34)