eBay Stores Platform Migration

Setting the stage

This is a blog post that follows up on my writing about migrating eBay’s Top Level Category Pages.

The tl;dr is that eBay was moving to unify all the ways a user could browse inventory on the site into a consistent shopping experience.  The way to do this was put all the different “browsable” experiences onto one platform, which internally was called Lexington. My post linked above dives into the reasons for moving these different experiences onto Lexington and the business value that would come from this.  My original post linked above details one of my projects which was to migrate top level category pages to Lexington and what I learned from that experience. While I was executing on that project I simultaneously was tasked with migrating eBay Stores to Lexington.

What are eBay Stores?

eBay Stores were pages that featured a seller’s inventory. A seller can pay eBay a monthly fee for this type of page that in theory would get them more traffic.  A seller technically will have a Seller Profile page that will feature his or her inventory, but an eBay Store was supposed to be an elevated version of this experience.

The value add for a seller to pay for an eBay Store was to get more traffic through SEO, to get more traffic through organic promotion throughout eBay’s site, to have cheaper listing fees, and to have a way to represent his or her brand.  More information can be found on eBay’s information page: Why Get an eBay Store.


There were 3 target customers for eBay Stores:

  1. The buyer browsing on eBay

  2. Sellers that were paying an additional fee to have a storefront

  3. eBay’s SEO (Search Engine Optimization) Presence

Customer problems

As the end user browsing eBay:

  • I need to be able to find relevant inventory that I want to browse from this seller

  • I need to be able to find a seller whose inventory I want to browse

  • I should be able to access an eBay Store on all devices

  • I need to understand what an eBay Store is and the value it provides

As an eBay Seller:

  • I need buyers to be able to navigate my inventory properly

  • I need to be able to represent my brand on eBay

  • I need to be able to showcase any promotions/coupons that I am offering through eBay

  • I need to have shoppers find and discover my eBay Store

As eBay’s SEO Presence:

  • I need links into eBay Stores to maintain and build SEO visibility

  • I need eBay Stores to use the correct links to listings and other eBay pages

  • I need eBay Stores URLs to follow SEO best practices


There were a TON of hurdles in order to do this project.  

Multiple owners

The first major hurdle was that eBay Stores were not just a storefront or page for buyers to browse, it also was an entire Content Management System (CMS) within eBay’s Selling platform.  

This meant that this single product was owned partially by eBay’s Buyer Experience and partially by eBay’s Seller Experience.  This meant a lot of negotiation and alignment on timelines which ultimately has led to this product’s inability to move forward. (I will detail this more later in the post.)

Incomplete migrations

The second hurdle for this project was that there had been a previous project to migrate eBay Stores to an updated codebase and platform, and it was not completed due to shifting priorities.  This left eBay Stores buyer experience on 3 platforms:

  1. An archaic version from the mid 2000s (referred to as Legacy Stores)

  2. A version from the mid 2000s that allowed custom HTML/CSS/JavaScript on the storefront (referred to as Custom Stores)

  3. The 80% complete version from the early 2010s (referred to as NextGen Stores)

It also left the eBay Stores Seller Experience on 2 platforms:

  1. An archaic version from the mid 2000s that powered the Legacy Stores and Custom Stores (referred to as Legacy Stores tool)

  2. The 80% complete version from the early 2010s that powered the NextGen Stores (referred to as NextGen Stores tool)

This migration had to take into account 3 storefronts and 2 CMS’s and build a solution that could move all of them into a single storefront and a single CMS.

Lack of resources

When I originally took this project, I was supposed to have 7 engineers working on this for the storefront, and the seller tools were supposed to have a dedicated product manager and 5 engineers working on it.

Due to attrition, my team shrank to 4 engineers.

Additionally, due to priority shifts from the Seller Experience team, stores tools were down to 1 engineer and 0 product managers.

A project that was scoped to take an entire year with 12 engineers and 2 PMs shrank to 5 engineers and 1 PM.  This is largely attributed to organizational dysfunction discussed below.

Organizational dysfunction

For some context, when eBay does planning, they come up with timelines to do a project based on how many engineers are needed and how long it will take them. The projects are then “funded” with a funny-money that is internally referred to as “product developer (PD) months” or “engineering heads”.

In order to get projects done at eBay, you must be “funded” with enough engineering heads and time to do the project.  For eBay Stores to see meaningful progress, it meant that both the Buyer Experience and Seller Experience teams had to commit enough PD months to their respective pieces of the product.  Neither side could make meaningful progress without the other.

The year that I took this project, both organizations had committed the proper resources to get this done...until a month into the year, the Seller Experience team shuffled priorities and “delayed” its headcount into the project until later in the year (and the date kept rolling later and later).  The engineers allocated for the project were also folks that were to be hired, so that did not account for not only making a hire, but also getting the engineer on-boarded.

(Ultimately, the Seller Experience team never got the resources to hold its end of the bargain.)

Aside from the Seller Experience team removing resources from the project, the Buyer Experience team lost 2 months from its own organizational dysfunction.  For a total of 3 months of the year, the leads of the eBay Stores team and 2 other partner teams (the Browse team and the Events team) met regularly for architecture discussions, and at the end of 2 months, leadership blew up the architecture plans and proposed a new one, which meant 2 months of wasted time.

The Plan

Despite the hurdles ahead, the team and I moved forward with the goal of delivering the best possible product for our users. We went through several prioritization exercises to figure out how we could deliver meaningful results with fewer resources and less time.

We had a north star for what we wanted to deliver for the experience.  We compromised several times and settled on delivering a 1:1 feature parity with the latest NextGen Stores with some fixes that addressed top customer pain points collected from customer support.  We did this because with limited Seller Experience resources, we could only access data that already existed in the selling experience services because we did not have support to build out the service support for additional features.  The goal was that when Seller Experience eventually staffed-up, we would achieve our north-star.

The slimmed-down migration plan aimed to build feature parity from eBay Stores NextGen, address SEO problems with linking, fix top seller-reported issues, and finally release the previously desktop-only product onto mobile web and eBay's native applications.

What happened

As the year progressed and the team worked, ultimately our progress to deliver this new version of Stores was very slow.  There were a number of reasons for this aside from the hurdles described above.

One of these reasons is the team lost both its lead engineer and its engineering manager early in the project. This left a gap in leadership.

Another reason progress was slow is because normally as the product manager, I would have stepped in to fill some of the leadership void; however, I recognize in retrospect that I was spread too thin across 3 projects and 3 engineering teams, so I was not able to dive in and dedicate the attention needed to one particular team and project because I was constantly having to bounce around the 3 teams and projects.

A third reason progress was slow was due to the constant rotation of frontend engineers due to lack of resources. This meant repeatedly ramping an engineer up on the codebase and product, which is time consuming.

Lastly, progress was slow because of several miscommunications internally in the team and externally between partner teams that led to wasted effort and missed requirements. This was a fundamental breakdown for myself, the team, and our partners.

Ultimately at the end of the year, we had a new Storefront that delivered on the plan detailed above with the exception of a native application.  The team was gunning to wrap up progress and deliver the product in time for our annual moratorium for holiday shopping, but as our deadline approached and I took a step back to look at the product we were delivering, I realized that the product was not at the quality that we should deliver for our customers, and I had to make a hard call with the team.

We decided to not launch our product at the end of the year, and wait until the beginning of the next year.  There were many reasons for this that include the following:

First, parts of the UI were a little bit wonky. We were iterating to fix them, but ultimately they needed time, which we lacked due to the impending moratorium.  Launching the product with these UI issues would show a lack of attention to detail and lack of quality for our customers.

Second, a last minute requirement from legal in Europe required eBay Stores to show an Impressum, and there was not a service in place to display this properly. Legacy and Custom storefronts allowed custom HTML from sellers who could manually add this information. This feature miss meant that we would not be able to migrate many Storefronts in the EU.

Lastly, the driving force for this migration was not just addressing the customer problems detailed above, but also to simplify the underlying tech and curation tools.

Some history is needed to explain this problem: Due to the incomplete migration of Legacy and Custom stores to NextGen Stores, sellers would have to switch between the version of stores they were using in order to access certain features. If a seller wanted to adjust their categories or URL, they had to use the Legacy store, but if they wanted to change their photo, they had to use the NextGen store. Ultimately customer support would have to guide sellers in this ass-backwards process of upgrading and downgrading their storefronts in order to access certain features.  

When I took a step back and looked at what we were delivering for sellers, I realized that the product we were about to roll-out actually made the existing problem of working between store tools worse.  Some sellers would be migrated and others wouldn’t. 2 different store tools would access the same storefront, but they could not access all of the features they needed.

In the end, it was a very tough decision, because the team had worked so hard to wrap the product up for an initial launch, but ultimately when I sat everyone down and explained the issues, we all agreed that we needed to delay the launch until we would work these problems out.  

Ultimately, I ended up switching teams (for reasons unrelated to this project’s success) and another PM wrapped up the work and launched the product once it was in a better place.

What I learned

I alluded to many of my learnings throughout this post, but this section will detail them explicitly.

Immovable forces

There were certain immovable forces such as the lack of resources and alignment for the selling experience team that severely limited our ability to execute. These were signs my manager and I saw very early on, but we decided to pursue this project anyways. In retrospect, we probably should have cut bait and reprioritized our own resources into a project where we could deliver more value without being blocked.

I have learned to better assess hurdles ahead of me. For something like what I experienced for eBay Stores (where we had a dependent team that reneged its support and resources and we could not fix this), it would have been a better use of our time and resources to pivot and deliver on something where we were not blocked.  (I leveraged my learning on this for a later project of mine that I will write about in my next post.)

Time commitments

I was extremely excited and passionate to build and work on many products at eBay that had high visibility and a lot of love from customers. I kept asking for more work and more ownership, but I later learned that my eyes were bigger than my stomach.  I had originally asked to have more responsibility than my 1 team and product. I had imagined I would get 2 teams and 2 products, but I was instead given 3 teams and 3 products. I liked each of the teams and products and did not want to give anything up, but by the end of the year I realized that although I touched a lot of pieces of eBay and worked with a lot of great people, I was spread too thin and could not dive in as much as needed.

My previous year when I had 1 team and 1 product, I was able to dive in and help steer the team when there was a lack of leadership and resources.  When I had 3 teams and 3 products, I was not able to dive in and steer when one of my teams was struggling. I detailed this with the eBay Stores team in this post, and one of my other teams also needed more guidance during the year as well.

I learned that although it’s great to do a lot of things and do them well, it’s actually better to do fewer things and excel at them.  It helps me to focus and deliver more value and learnings, and it allows my team(s) to move faster and stronger.

Product quality

I learned the value of spending the right amount of time to ensure a quality product launch.

Delivering a lot of things is great, it’s shiny and easy to talk about, but in the end the number one priority of a product manager is not the number of notches on your belt from product and feature launches.  In fact, the number one priority of a product manager should be the users and delivering the best customer experience.

Product management entails a lot of assessing trade-offs and figuring out the best way to deliver a product in a resource-constrained environment on a time-crunch.  In situations when these barriers and limitations do exist, it is still not worth launching a half-baked product for the sake of saying you did it. A broken product and bad user experience is worse than maintaining something that is not ideal.

Moreover, it takes a lot of time and energy for a product manager to work with the team to deliver quality products. There are design iterations, engineering iterations, data exploration, and much more in order to deliver quality products.  Working on tons of products takes away time and energy from working with any one individual product or team.

Product managers have to find the balance of quality and scale when working on products.  During my time at eBay, I personally could deliver much higher quality with one team and product, but my scale was much lower.  I was also able to deliver much higher scale with three teams and three products, but my quality was sacrificed.

The mix of scale and quality varies between PMs and companies.  I now have a much better idea of my capacity to scale based on my experience with eBay Stores.

Vision and Strategy

The last major learning from this project was the importance of buy-in from leadership for the vision and strategy for a product.  

eBay Stores was a great idea and product when it first launched because the concept of a seller having his or her own page and storefront was unheard of.

In today’s world, Shopify, Wordpress, Etsy, TicTail and countless other competitors offer a seller his or her own storefront.  The value of eBay Stores is diminished when you compare what it was back in the day and what it is today with the onslaught of competitors.

I developed a plan and strategy that aimed to marry the offerings of eBay’s past, eBay’s present, and what competitors offered for similar product offerings into a long-term roadmap for eBay Stores.  In its current format, it could not compete with the likes of Shopify or Wordpress in customizations. Shopify and Wordpress could not compete at an individual level with the scale of eBay’s marketplace (without intense investment in SEO and traffic).

Leadership liked my vision and strategy, but their priority was migrating Stores off of the old software stack so that it would cost less to maintain.  They were not focused on building it into a cutting-edge product offering relative to the numerous competitors on the market.

Since leadership was not invested in my vision and strategy, they were not going to invest as much in funding the number of engineers necessary to achieve this.  For previous projects, I had been able to push my vision and strategy with fewer resources and with less leadership buy-in; however, in this instance, I was not able to.

I have learned to place higher value on getting leadership’s buy-in on the vision and strategy for the product, because when it comes time to make trade-offs in where they invest, they are going to move resources away from projects with less buy-ins and more into projects where there is higher buy-in.  I took this lesson to heart and applied it to my next project that I will write about in my next post.


Large corporations can have a lot of moving pieces that are unbelievably tough to get moving.

My biggest insights from this project were:

  1. Getting a better sense of which projects will deliver value and which are not setup for success

  2. The value of how to focus your time in order to get the most bang for your buck

  3. Learning how to balance scale of deliverables with quality of products

  4. Emphasizing leadership buy-in for a vision and strategy early in the project

Top Level Category Pages Platform Migration

Setting the stage

I’m over a year late in posting this, but I wanted to take some time to document the launch of my biggest project of 2017. This was a project of migrating eBay’s top level category pages onto it’s new technology stack called Lexington, which was used for a variety of shopping experiences at the company.

I previously wrote about Top Level Category Pages in an older blog post about eBay’s Flexible Pages (called Flexihub). The Top Level Category Pages Platform Migration was the process of moving the biggest use case for eBay’s Flexible Pages (Flexihub) from the old Flexihub platform onto the new Lexington Platform that hosted eBay’s lower level categories.

These are the links to the original launch announcements for the first wave of the migration and then followed a few months later with the second wave of the migration.

Rather than recount the specifics of the launch announcements and the details of each feature, I want to use the rest of this post to dive into what the problem was, what the barriers were, why the team approached this a certain way, what went well, and what I would do differently.

Customer Problems

There were 3 different types of customers that we had to take into consideration for this project that all had varying problems that sometimes conflicted with one another, which made this a very tricky project and product launch.


  1. The end user browsing on eBay

  2. The internal site merchandiser that curates content on the pages

  3. eBay’s SEO (Search Engine Optimization) Presence

Customer Problems

As the end user browsing eBay:

  • I need to be able to find relevant categories that I want to browse.

  • I want to see relevant promotions for the category.

  • I don’t want to land on broken pages or see expired promotions.

As the internal site merchandiser that curates content on the pages:

  • I need to be able to direct customers towards seasonally relevant categories.

  • I need to be able to feature promotions that are running for my category.

  • I need to be able to style the page differently for each season and holiday (e.g. winter has a cold-theme whereas July 4 has a beach theme).

  • I need to have flexibility to customize photos, colors, text-content, and links for the varying seasons, promotions, content, etc.

  • I need a curation tool that does not crash, scales across thousands of pages, and is inuitive to use.

As eBay’s SEO Presence:

  • I need to link to the correct URLs for categories in the taxonomy, promotions, and listings for Google to crawl (I can’t have extra parameters that create duplicate URLs for the same content).

  • I need fresh content that encourages Google to continue to crawl my pages regularly.

  • I need to link to Categories, Product Pages, and Listings for Google to crawl.

Flexihub problems

Flexihub was never designed to support category browse pages. It was meant for flash sales on eBay. It was repurposed for flexible pages that could be spun up in a moment’s notice with flexible content.

The flexibility in the pages resulted in broken links, stale content, duplicate pages, poor image quality, hacky JavaScript plugins, and many other problems. We needed to make sure we could ensure flexibility for the business partners curating the pages, but also guide the business user towards quality curations. This came at the cost of some flexibility.

eBay Shopping Experience problems

eBay is a giant marketplace with millions upon millions of listings. eBay also grew into a giant that had many different ways for shoppers to navigate eBay’s inventory. Shoppers could browse by a seller, a category, a holiday, and more. These different types of ways to shop resulted in a fragmented shopping experience depending on the curation type. The grand vision for Lexington was to unify the shopping experience into a homogenous user interface.

Lexington Platform

The Lexington Platform was ideated as a way to solve eBay’s problem of varying shopping experiences that looked nothing alike as well as Flexihub’s problem of stale content with broken links. Lexington was designed with the vision of surfacing the best inventory for the eBay shopper. For each category, Lexington aimed to:

  • Feature the most engaging categories that were lower in the taxonomy.

  • Show fresh inventory using algorithms that found the best listings.

  • Surface listings and products that were trending on eBay and other sites.

  • Highlight listings that were at lower prices on eBay than other sites.

  • Expose deals and promotional events.

  • Make it easy to refine and filter.

  • Be SEO-friendly in order to drive more traffic from Google.

The Lexington Platform started with the lower level category pages. The next step to furthering the new shopping experience for eBay was to migrate the top level category pages onto the Lexington Platform.

Curation Tools

Flexihub pages were originally curated by a tool called Kiosk. This tool was built during a hackathon and was never intended for the use-cases it evolved into supporting. This was painfully obvious in both the visual design and the information architecture of the platform. Kiosk was so tough to use that the company literally hired a team to support the business partners in curating their pages.

A new tool called Spotlight (aka Regional Customizations aka RC) was built as the successor to Kiosk. It was designed from its core to support the initial lower level category pages and was built with the intention of expanding its use-cases to top level category pages and other curation types on eBay. Spotlight/Regional Customizations was designed not only as a tool for curating pages but also as a page templating engine that defined how curated pages would order and place different features and pieces of content on the page.

Spotlight/Regional Customizations addressed the business partner pain points of having a modern and usable tool for customzing pages, and it also addressed the eBay SEO pain points of forcing clean links when business partners curated the pages. It also was forward-thinking in being built as a framework that could take on additional business use-cases for the product team to support.


There were a lot of different issues that created many hurdles for myself and my team to overcome in order to accomplish this project. Off the top of my head, some of the most challenging issues were:

  • The team was spread across the entire world. I was based in New York City, some of the engineers were in San Jose, CA while others were in Israel. One partner PM was in San Jose, another partner PM was in Israel. The business partners were spread across San Jose, New York City, Israel, Florida, the United Kingdom, Germany, France, Italy, Spain, Australia, and Canada.

  • The business partners wanted tons of flexibility, but Flexihub’s history showed that when the business had too much flexibility in what they could curate on the category pages, it led to broken links, poor image quality, varying layouts and overall a poor shopping experience.

  • Pure algorithmic content did not allow for curating business promotions or styling for seasonality for the year and for current events.

  • Some business partners had conflicting opinions and wanted to prioritize building features that had low engagement and little to no business impact based on a hunch as opposed to raw data.

  • The previous platform (Flexihub) had a module called RTM which basically acted as a free-for-all where partners could “hack” the page and inject any HTML/CSS/JavaScript. At some points this provided modules the business partners liked and were permitted to keep, and at other times it created poor user experience and broke pieces of the page that forced product to remove the module. The business partners had to be weaned off of this type of functionality in order to prevent pages from breaking at random times.

  • The business partners used to create fake layouts with image maps: a feature that allowed an internal user to upload an image of any size and lay out links on top of the image. This allowed the business partners to mimic user experiences that they liked but had not vetted. This feature also had to be killed but left with a structured yet flexible replacement.

  • Business partners generally had little to no SEO knowledge, so the curation tool had to have guard rails in place to make sure content and link quality maintained eBay SEO best-practices.

  • Although eBay had a category taxonomy, the top-level category pages had evolved under the unstructured Flexihub platform to include high-traffic pages that were not a part of the eBay category taxonomy. The Lexington platform originally required that each page be a part of the eBay taxonomy, and due to complications of the eBay taxonomy, we could not just create Category IDs for the pages that were not apart of the taxonomy, so there were engineering solutions that had to be created around the lack of flexibility surrounding the structured data.

  • There was a ton of politics associated with these pages. They were critical for the beginning of the browse path for our shoppers who liked browsing. They served as the entry-way to the taxonomy. They also served as key landing experiences for SEO traffic. Lastly, they were the forefront of how the business promoted its deals, events, and other promotions. It was not just about the data or the end-user, but it was a lot about managing different stakeholders’ opinions and making sure we met the needs to the different stakeholders and their use-cases; this meant a lot of trade-offs in how we designed and deployed this experience.


The top level categories were broken down into 2 parts, dividing them into L0s (the top-most categories) and L1s (the second from the top-most categories). The L1s were migrated first, and the L0s were migrated second. This was done for the following reasons:

  1. The requirements were generated based on understanding the patterns the business followed with it’s super flexible curations on Flexihub and designing a way to support the general types of curations in a more structured format on Lexington. The features built covered 95% of the flexible curation types, and left some flexibility for the 5% that were too infrequently used to warrant engineering work. These requirements were based on my previous years of experience with the platforms and partner teams, then they were road-showed to the business partners globally as well as the partner teams that were helping to execute on this project.

  2. L2-L7 pages (levels below L0s and L1s) were already migrated to Lexington. In order to maintain continuity, it made more sense to continue the flow of migrating pages bottom-to-top.

  3. The business partners were more particular about how they curated the L0 pages and wanted to have more curation options available for them. Rather than wait and migrate all pages at once, we built the first half of the product needs to start, and upon phase 1 completion, we migrated the L1s. Then we finished the rest of the product features for phase 2 and migrated the L0s in the second wave.

  4. There was the potential for negative SEO impact with a massive change in these top level category pages that served as the starting point for Google’s crawling. We had to do URL masks and migrate the pages in 2 parts. First, maintain the URL but change the content to the new platform. Second, maintain the content of the new platform but finally flip the URL to it’s new permanent format and 301 redirect the old URLs. Doing all pages at once would have been a more serious SEO risk than doing them in parts.

  5. We had to coordinate the business partners curating an entirely new set of pages while still maintaining the old set of pages. This meant temporarily doubling their workload. Doubling the business partners’s workload for L0s and L1s at the same time was not going to be manageable for the them; however, we worked together to find a way for the business partners to be able to manage the old pages and new pages at the same time for just the L1s, and then again for just the L0s.

  6. We had to modify the Lexington Platform to support pages without a Category ID and hack together a Buyer Taxonomy that created structure for these previously random floating pages. This was required for the L0s but not the L1s, and this work needed additional time. This further supported migrating the L1s before the L0s.

Now that I have had some time to reflect on this project, I want to use this blog post to focus on what went well, what was tough, and what didn’t go well.

What went well

Despite the complex customer problems and the barriers for this project, there were a number of successes.

The new Lexington platform was a huge improvement for the shopping user experience. The pages loaded faster, the images were crisper, and the UI overall looked way better relative to Flexihub.

The curation platform Spotlight was also a huge improvement for the business partners. The curation process was much simpler and streamlined relative to Kiosk. The internal business users were more satisfied with the new toolset.

SEO cleanliness also improved due to the guardrails in place from Spotlight. There were [almost] no broken links and more of the eBay taxonomy was exposed on the new Lexington pages than previously were on Flexihub.

What did not go well

The rollout process was extremely chaotic. We had to schedule the release time with each region to make sure there was no breakage. The business partners in all of the regions had to maintain 2 curations for each page until the rollout was complete - this was stressful for all parties involved. There were also miscommunications within the business partner teams that led to last minute fire drills to collect all of the content and assets together in time for the launch.

Furthermore, switching the experience was not simply a code rollout, but it also involved URL masks from the old pages to the new ones, and there were a number of complications with this process that were not discovered until the launch date.

Finally, coordinating teams across 9 countries was extremely complicated and resulted in some sleepless nights.

In the end, the pages went live, and the business did not break!

What I would do differently

After having some time to reflect on this project, there were a number of things that I would have done differently.

At this time, I was on too many projects, so I did not have enough time on my hands to dedicate hours to a mock rollout to test all of the changeovers. I relied on my engineering partners for the sign-off, which was OK, but we should have coordinated doing 1 page in each region to start as a test, then migrated the rest of the pages.

Additionally, I did not have a clear way of measuring success. We could not run a true A/B test because the business partners could not afford to maintain all of the pages on both platforms, but in retrospect we should have tried to do this in some capacity.

Moreover, I did not have enough tools at my disposal to measure the performance of the pages. I was using some internal dashboards that were no longer maintained to check for any major breakage, but I was not diligent enough in checking the numbers daily, and I did not plan enough in advance to have support at hand to easily measure engagement with statistical accuracy. I was having to hack things together to make sure we were not in the red. I also could have done a better job setting up clearly defined metrics of success, metrics of failure, and counter metrics. I only looked very surface level at CTR and Bounce rate, but I did not look enough at the origin source traffic or the implications toward the bottom of the funnel with purchases or other conversion metrics.


In the end, I am grateful for the opportunity to have been the lead for a massive project at eBay. It touched an unprecedented number of teams and required an enormous amount of coordination, communication, requirements gathering and execution. It also required having a good sense of humor for when everything seemed to be going wrong.

All in all, it was a great experience learning how to coordinate so many different groups of people with competing interests, differing expertise, and broad geographic ranges. This experience gave me a greater appreciation for the work that leaders in large organizations undertake to get things done.