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.
Customers
There were 3 target customers for eBay Stores:
The buyer browsing on eBay
Sellers that were paying an additional fee to have a storefront
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
Hurdles
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:
An archaic version from the mid 2000s (referred to as Legacy Stores)
A version from the mid 2000s that allowed custom HTML/CSS/JavaScript on the storefront (referred to as Custom Stores)
The 80% complete version from the early 2010s (referred to as NextGen Stores)
It also left the eBay Stores Seller Experience on 2 platforms:
An archaic version from the mid 2000s that powered the Legacy Stores and Custom Stores (referred to as Legacy Stores tool)
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.
Conclusion
Large corporations can have a lot of moving pieces that are unbelievably tough to get moving.
My biggest insights from this project were:
Getting a better sense of which projects will deliver value and which are not setup for success
The value of how to focus your time in order to get the most bang for your buck
Learning how to balance scale of deliverables with quality of products
Emphasizing leadership buy-in for a vision and strategy early in the project