In today’s fast moving e-commerce industry, customers want control and convenience for receiving their deliveries. This key customer need and insight led to the creation and launch of the Wayfair Delivery Network, our very own proprietary large parcel delivery service.
Within a few short years, the WDN has expanded to service customers in dozens of locations across the US. However, as Wayfair continues its fast paced growth trajectory and international expansion, a key question remains:
How do we build and scale a delivery network globally?
This key question laid the foundation for WDN’s vision: to build a global, end-to-end delivery network that provides an excellent delivery experience for our customers. To achieve this vision, WDN was reorganized into three global teams:
- Orchestration - Responsible for the WDN interface to Wayfair and for carton tracking within our network. Based in Boston.
- Transportation - Responsible for over-the-road planning and execution as well as tools for transportation planners, dispatchers, and drivers. Based in Boston.
- Four Walls - Responsible for technology solutions for all WDN buildings including pool points, cross-docks, and depots. Based in Berlin.
For the Berlin WDN product and engineering teams, this reorganization meant that our scope was no longer limited to just Europe, but had expanded to include North America.
The Challenge
Amidst the reorganization, a key problem remained: the technology stack in Europe and North America were completely different. We used different systems, different vendors, and different products to facilitate end to end delivery across two different continents. In order to create a global, scalable delivery network, we had to figure out how to get this done quickly without causing major disruptions in the day to day operations.
Product Discovery
As a senior product manager in WDN, the “Gateway” team was tasked with the responsibility of integrating our new 4 walls sortation software called “Runway” into the North American ecosystem. Following the completion of this integration, Runway will become the 4 walls sortation solution across the global WDN network.
With this task at hand, the team quickly got to work and launched a discovery process to figure out how to integrate and consolidate our various 4 walls tech stack. The initial scoping effort revealed more than 40+ integrations that needed to be evaluated for consideration. As a small team it felt like we would forever be stuck in the discovery phase. To keep us focused on our goal, the Four Walls team and its partners collaborated to develop a set of shared quarterly OKRs. The benefit of using OKRs is that it enables everyone to regularly track progress and communicate confidence levels towards meeting goals and objectives. Regular updates about each team’s progress helped remove blockers while also providing the right level of transparency to make informed decisions about the roadmap.
Product Definition
With so many potential integration points and new platforms in development, it became clear that an integration interface was needed to manage the complexity. The value of an interface is twofold: first, it protects the stability of the underlying application by preventing any system from directly accessing or writing to Runway’s database. Second, by separately implementing Runway and its interface, Gateway, dependencies on external systems are removed. So if the network routing team decides to change how routes are calculated, Runway will still be able to deploy new features and bug fixes without having to worry about making any changes to its codebase.
Our 4 Walls interface is called Gateway. Gateway is the integration interface which all other WDN systems must interact with to communicate information to Runway. Gateway acts as the “gatekeeper” to Runway by only allowing inbound communications through clearly defined data structures and end points. This means that Gateway is responsible for receiving, consolidating, and emitting relevant messages to the Runway application so that warehouse associates have visibility into what trucks and cartons are coming in and out of the building. Furthermore, as an abstraction layer, Gateway hides the underlying complexity of our internal systems. Doing so enables flexibility to plug Runway into different environments as the Four Walls team looks to scale and integrate the Runway software into more and different types of buildings.
Prioritization and Focus
With so many integration options to consider and choose from, we needed to find a way to prioritize the jobs to be done in order to get Runway integrated. What emerged was a way to evaluate each integration option on two criteria:
- Data Availability. Does this product or system have the critical data Gateway needs in order to send messages to Runway? Examples include information about the consignment, the route, and the truck the carton will arrive on.
- System/Platform Readiness. Are the systems/platforms ready for integration? In order to reduce dependencies and risks to Gateway’s development timeline, we wanted a high level of confidence that the systems we integrated with were ready to prevent any delays to the launch Runway.
Based on this prioritization framework, the Gateway team reduced the integration possibilities from 40+ to three!
Product Design
At a high level, Gateway is responsible for implementing three types of scenarios: 1. inbound appointment messages, which provide data about what cartons and trucks are coming into the building. 2. unit movement plan messages, which provide data about network routes and consignment information, and 3. outbound appointment messages, which provides data about what cartons and trucks are leaving the building. Within each scenario are dozens of possible permutations that need to be accounted for within our application to ensure smooth data flows. As we integrate into additional different building types, these permutations will multiply exponentially. Therefore, getting the basics right in our product design is critical to preventing a lot of headaches in the future.
Another key aspect that the Gateway team tackled with our stakeholders and fellow Four Walls team members was how to define success, key performance indicators and mitigate risks. The risks and difficulty of integrating a new sortation software in a warehouse located across the ocean and nine time zones behind while working 100% remotely cannot be understated. Countless hours were spent discussing every possible exception and failure our brains could imagine, and outlining possible solutions and new features. Although the process could sometimes be painful, the increased confidence we had on our ability to identify problems and fixes made it worthwhile. Afterall, the goal of the 4 Walls team is to improve the user experience and operations in our warehouse, not make it worse!
Photo: Some members from the Runway and Gateway Teams (Left to Right from Top: Ariel Yu, Chris Teoh, Vlad Mytsyk, Christine Thach, Matt Howard, Fabian Stelzer, Bruno Filipe Ferreira)
Product Testing
To ensure a smooth launch in North America, the Gateway team and its partners underwent several rounds of testing during the development cycle. Due to COVID-19, all testing was conducted remotely, which added an interesting layer of complexity. We kicked off with integration tests, which aimed to ensure that data flowed from one system to another. Next, we moved into shadow mode testing. The goal of this phase was to ensure that data was being correctly transmitted to Runway in the right sequence. During this phase, heavy data analysis was undertaken to compare expected results with actuals. The final phase before going live in our first building was to conduct a dry run. The goals of the dry run were 1. ensure that all major functionalities are working, and 2. ensure that field operators are sufficiently trained by allowing them to use the Runway application to process selected live orders.
Implementation and Iteration
As a senior product manager, my favorite part in the product development cycle is seeing the product live in action. This past week, the Gateway team reached a major milestone as our application started to receive production data through event streams. But our work doesn’t stop here. With so many dependencies our team is in a constant state of discovery and we continue to uncover new scenarios, risks and gaps everyday. But fast iteration to make your product even better than it was before is part of the fun, and one of the reasons I love product development and management.
Lessons Learned
Gateway and Runway will go live to our first building very soon. As I reflect on the journey thus far, some key lessons come to mind:
- The devil is in the details, especially for exceptions. It is easy to focus on developing your product around happy path scenarios that you expect to happen. However, the real test of your product’s value and success is how it handles exceptions. When things go wrong, consumers/users will either love or hate your product. Therefore, invest adequate time and energy into understanding what exceptions may happen.
- Deploy early to learn about different scenarios in production fast. Fast deployment enabled the team to uncover unexpected bugs and apply fixes quickly.
- Get buy-in and insight from all potentially impacted teams and users as quickly as possible. During one of our early discussions, the team learned about the risks our integration could bring to our financial reporting and inventory management systems. This insight led to the creation of a new workflow to ensure that all outbound events from Runway would continue to provide our partners in finance and warehousing the information required to do their job without disruption.
While the launch of Runway is still pending, I continue this journey with cautious optimism and confidence that we have set ourselves up for success.