agileA technology hardware company running SAFe with sixteen to fifty people has a disconnection problem. The company makes enterprise networking hardware: routers, switches, access points, and network management software. It has been around for fourteen years with three thousand two hundred employees. The product development organization has forty-two people across five agile release train teams, with seven to nine people per team. (1/34)
The teams are disconnected from user needs. The disconnection happened gradually. Two years ago, the company reorganized into platform teams. Team one owns routing firmware. Team two owns switching firmware. Team three owns access point firmware. Team four owns network management software. Team five owns the cloud dashboard. The split made sense architecturally, with each team owning a clear domain. But the split created a problem (2/34)
. The teams stopped thinking about users and started thinking about components.
Team one thinks about routing tables. Team two thinks about packet forwarding. Team three thinks about radio frequency management. Team four thinks about SNMP traps. Team five thinks about dashboard widgets. Nobody thinks about the network administrator who has to configure and manage all of these components. (3/34)
Last quarter, team five redesigned the cloud dashboard. The redesign took eight weeks. Fonts were cleaner, colors more consistent, the layout more spacious. But the redesign did not address the network administrator's actual problem. Configuring a new access point still required navigating through seven screens. The network administrators complained. The complaints went to support, then escalated to product. The product team was surprised (4/34)
Steve Jobs built Apple using the reality distortion field, a term coined by Atari colleague Bill Atkinson. It described Jobs's ability to convince himself and others that the impossible was possible. But it was not just about ambition. It was about focus. Jobs used it to keep Apple's teams focused on one thing: the user experience. He did not let teams focus on components, technology, or specs. He forced teams to focus on what the user would feel. (6/34)
When Jobs returned to Apple in 1997, Apple had over three hundred products. Jobs cut the product line to ten. The cut was brutal and necessary. It forced every team to focus on a small number of products. That focus produced the iMac, then the iPod, then the iPhone, then the iPad. Each product was a result of the reality distortion field and of focus. (7/34)
Jobs applied the same thinking internally. When launching the original iPhone, the engineering team wanted a physical keyboard. They had data showing physical keyboards had higher typing speeds. Jobs rejected the data. He said the user does not care about typing speed. The user cares about having a bigger screen. He made the team believe a virtual keyboard was possible. They built it. It worked. The iPhone succeeded. (8/34)
For a technology hardware enterprise, the disconnection problem is the same. Teams are focused on components, not users. Jobs's reality distortion field says: force every team to focus on the user experience. That focus eliminates component thinking and reconnects team tasks to user needs. (9/34)
The core principle is simple. The best way to reconnect team tasks to user needs is to force every team to focus on the user experience instead of the component they own. Jobs did not let the iPhone team focus on the keyboard. He forced them to focus on the screen. That produced a better user experience. (10/34)
For a technology hardware enterprise, the teams are focused on components. The reality distortion field says: force every team to focus on the user experience. The focus eliminates component thinking and reconnects team tasks to user needs.
Step 1: Map Every Team's Current Tasks to the User Journey and Identify the Gaps (11/34)
Jobs mapped Apple's three hundred products to the user journey in 1997. The mapping revealed most products did not serve a clear user need. They served internal engineering interests. Those products were cut. (12/34)
Your team should do the same. The product manager leads a three-hour mapping session with all five team leads. The session maps every team's current tasks to the network administrator's user journey. The journey has six stages. Stage one is unbox and mount the hardware. Stage two is power on and connect to the network. Stage three is configure the device. Stage four is monitor the network. Stage five is troubleshoot issues. Stage six is upgrade firmware. (13/34)
The mapping reveals the gaps. Team one owns routing firmware. Their tasks are optimizing routing table lookup speed, adding support for a new routing protocol, and fixing a memory leak. These map only to stage six. Team two owns switching firmware. Their tasks are improving packet forwarding latency, adding VLAN support, and fixing a spanning tree bug. These also map only to stage six. Team three owns access point firmware (14/34)
. Their tasks are improving radio frequency management, adding Wi-Fi 7 support, and fixing a channel selection bug. These map only to stage six. (15/34)
Team four owns network management software. Their tasks are adding a new SNMP trap type, improving event log search speed, and fixing an alerting bug. These map to stages four and five. Team five owns the cloud dashboard. Their tasks are redesigning the visual design, adding a bandwidth usage widget, and fixing a user management bug. These map to stage four. (16/34)
The mapping reveals three gaps. No team owns stage one, unbox and mount the hardware. No team owns stage two, power on and connect to the network. No team owns stage three, configure the device. These three gaps are the stages that matter most to the network administrator. They are where the user experiences the most friction. The seven-screen access point configuration workflow lives here. The forty-five-minute initial setup time lives here (17/34)
. The lack of a guided setup wizard lives here.
For a SAFe team of sixteen to fifty, this mapping should happen in one three-hour session during program increment planning. The mapping is a planning input.
Step 2: Assign Every Team a User Journey Stage in Addition to Their Component Ownership (18/34)
Jobs assigned every Apple team a user experience goal alongside their engineering goal. The engineering goal was to build the component. The user experience goal was to make the component invisible. The iPhone team's engineering goal was to build a virtual keyboard. The user experience goal was to make it feel natural. The dual assignment forced the team to think about the user. (19/34)
Your team should do the same. The product manager assigns every team a user journey stage in addition to their component ownership. Team one owns routing firmware and is assigned stage two, power on and connect to the network. Team two owns switching firmware and is assigned stage three, configure the device. Team three owns access point firmware and is assigned stage one, unbox and mount the hardware (20/34)
. Team four owns network management software and is assigned stage five, troubleshoot issues. Team five owns the cloud dashboard and is assigned stage four, monitor the network. (21/34)
Every team now has two responsibilities: component ownership and user journey stage ownership. This forces every team to think about the user. Team three is assigned stage one. Their current tasks are all about radio frequency management and Wi-Fi 7. None address unboxing. The dual assignment forces them to add a new task: create a quick start guide that reduces unboxing-to-mounting time from twenty minutes to five minutes. That task reconnects team three to the user. (22/34)
For a SAFe team of sixteen to fifty, this assignment should be made during program increment planning. It is a planning decision.
Step 3: Require Every Team to Spend Twenty Percent of Each Sprint on User Journey Tasks
Jobs required every Apple team to spend time on user experience tasks. It was not optional. The requirement forced teams to think about the user and produced better products. (23/34)
Your team should do the same. The product manager sets the rule. Every team must spend twenty percent of each sprint on user journey tasks. Twenty percent of a two-week sprint is two days. Team three is assigned stage one. Their sprint backlog has ten tasks. Eight are component tasks. Two are user journey tasks: create a quick start guide and design a mounting template that fits standard rack sizes. (24/34)
The quick start guide is tested with five network administrators. Average unboxing-to-mounting time drops from twenty minutes to six minutes. The mounting template fits standard rack sizes. Installation is faster. The user journey tasks produced a measurable improvement. The network administrator spends less time on unboxing and more time on configuration. (25/34)
For a SAFe team of sixteen to fifty, the twenty percent rule should be enforced during sprint planning and measured during sprint review. It is a planning constraint.
Step 4: Run a User Journey Feedback Loop Every Sprint with Real Network Administrators
Jobs ran a user experience feedback loop every week at Apple. It tested the experience with real users. It was not optional. It forced teams to validate their assumptions and produced better products. (26/34)
Your team should do the same. At the end of every sprint, the product manager runs a one-hour user journey test with three network administrators from the customer advisory board. The test focuses on the user journey stages addressed during that sprint. (27/34)
In sprint one, team two worked on stage three, configure the device. They added a guided setup wizard that reduces access point configuration from seven screens to three. Three network administrators test the wizard. The test reveals two issues. The wizard does not explain what a VLAN is. The wizard does not allow the administrator to go back to a previous step. (28/34)
Both issues are documented and added to the next sprint backlog. In sprint two, team two fixes both issues. The wizard now includes a VLAN explanation tooltip and a back button. The three network administrators test the updated wizard. Configuration time drops from fifteen minutes to four minutes.
The feedback loop caught both issues early and cheap. It prevented complaints, support tickets, escalations, and delays. (29/34)