Collaboration in Product Management

Watch my talk on Collaboration in Product Management that I gave at Product School.

Product management is a weird discipline. It’s so much fun because you are at the center of every piece of the puzzle for launching a product, yet, you don’t have any tangible deliverables.  

A PM is responsible to deliver a Product Requirements Document (PRD), and maybe some Engineering tickets in JIRA.  Some PMs are also responsible for data analysis, others are involved in wire-framing designs as well. Ultimately the end deliverable for every product manager is simply the product itself.

The irony is, the product manager owns no one piece of the product, yet is responsible for every part of it.  Designers make and deliver the designs, engineers write and deliver the code, but all a PM has to show for is some documents, emails, and meetings.

So what makes a product manager successful at his or her job? Ultimately there are a lot of different skills that a PM must bring to the table, but one of the most important strengths that a product manager must leverage is collaboration.

Collaboration: the action of working with someone to produce or create something


The focus of this post will be on variety of viewpoints a product manager can take on when he or she is facilitating collaboration. I have learned to embody the topics below through my time as a product manager at eBay.

Team player

Successful collaboration in product management at a large company requires being a team player; but what exactly does that mean?  In my eyes, being a team player as a product manager is like being the captain of the soccer team.

The soccer captain

The soccer captain does not get to decide who is playing where, that’s the coach’s choice.  The captain is seen as a leader for the team and has the responsibility of rallying the team around the goal of winning the game.  In the end, the captain is not the person who wins the game by him or herself, and the soccer captain is not telling everyone what to do.  The entire team is on the field playing together and having to coordinate together to score and win the game. The goalie, the defense, and the offense all have slightly different roles but are expected to help contribute to all parts of the game.

Being a team player with the Squad

Being a team player in product management to facilitate collaboration is very similar.  The product manager is not a football quarterback calling the shots, but rather he or she is the leader that is helping guide the team towards accomplishing goals.  Engineers and designers have different roles, but they all need to work together to deliver a quality product. Everyone on the team ends up collaborating on the designs, the product requirements, the engineering quality, and the release.  Engineers should weigh in on designs giving feedback on what is feasible and what tweaks can be made based on technical limitations; designers should help check the final code to check for quality representation of the designs and ensuring a quality user experience.  All parties should be giving feedback to the product manager’s requirements.

The product manager, engineers, and designers each own their own piece of the pie but also collaborate on the other parts of the product.  No one person is dictating what everyone else is doing, but all three parties are supporting each other in their responsibilities and deliverables.  

At the core of each team, the product manager is the leading front to help facilitate the collaboration across design, engineering, research, data, and any other needs of the product.

Being a team player with partners

In large companies, it is rare for a team to operate in isolation; generally, the team either has a dependency on a partner team or is a dependency for a partner team.  Despite not being on the same team, it is still super critical for the product manager to maintain the team player mentality when collaborating with partners.

Sometimes different teams have competing priorities, this can lead to friction when deciding how to prioritize resources and deliverables.  One thing to keep in mind is that despite being on different teams in the company, everyone is still working at the same company. The company, in essence, is one giant team of people who are working towards furthering the company to achieve its goals and be amazing.  This is a critical mentality when managing partnerships across teams.

In situations where I have partnered with teams with competing priorities, I have found it helpful to remind everyone that we all have the same common goal of making great products that further the company; this sets a great base for collaboration.  It’s helpful to manage these potential conflicts by finding common ground. Sometimes it comes in the form of finding shared goals for our products, other times it’s about aligning on shared values and objectives.

Ultimately, finding the shared common ground is the first step to getting larger buy-in from partners on your collective goals and furthering the teams to win their respective games.  This helps everyone to align and get results.

Aside from garnering buy-in with partner teams, being a good team player for collaboration also requires simply being friendly.  Over time it is easy to sniff out people who are only out for themselves, and it catches up to them later. In a larger company, you’re never truly independent and in control of your own destiny.  If you only ask for favors but never help others, or if you only return favors for partners who have helped you before, you may struggle to succeed long term.

Moreover, compromise is also a big component for great collaboration in companies.  There will be times when you and another team partner on a project and do not see eye-to-eye on everything.  When faced with these situations, it is best to seek a middle ground and make compromises. Attempting to bulldoze a partnership to get 100% of your asks without any compromise does not lead to productive team partnerships.  There are times when it happens and it is out of your control, but generally speaking, compromising on the project fosters positive collaboration and shared success.

When it comes time to make compromises with a partner team, it is best to lay out your top priorities on both sides and what elements you cannot compromise on but also identity pieces that you can make compromises on. This helps both teams to accomplish their top priorities and succeed in collaborating.

Being a team player across squads is not just about how you can work with partners to achieve your goals, but also how you work with partners to help them achieve their goals.   Partnerships across teams are most successful when it is not an exchange, but when it's genuinely trying to see everyone succeed and do well. The good energy flows and helps you later when you need help from someone.  The product manager who is working to be a team player for both his or her sprint team and for the broader organization is the product manager who sees the most success.


Successful collaboration in product management in larger companies requires a deep understanding of emotions.  Product management is a people-oriented job that requires you to have a grasp on your own emotions and be able to understand and work with others’ emotions.


The first and most important aspect of fostering collaboration in product management from an emotional standpoint is empathy.

Empathy is defined as the ability to understand and share the feelings of another


A lot of product management books and experts will discuss empathy in terms of being empathetic to user needs; however, empathy is also critically important to understandings your team and your partners.

In relation to your specific team, empathy is understanding the parts of software development that your engineers love (e.g. like building a brand new experience) and knowing what they dislike (e.g. such as fixing business-critical bugs on the weekend).  Empathy for your team might also be less directly associated with the product and more about understanding things that make them feel appreciated and valued.

Empathy towards your partner teams is understanding more than just what product they own or what their roadmap is, but also understanding their attachments to certain projects or the underlying struggles that may be involved with addressing competing priorities.  

Nonetheless, empathy for your team and your partners’ emotional experience can give you an edge in fostering great collaboration because you understand what makes them tick.


A key emotional experience in fostering collaboration at a large company is excitement.

In true product management, it is rare for a team to be directed to execute on a specific task or forced to partner on a project.  Great product-led companies operate bottom-up in their directives. In a bottom-up organization, collaboration stems from excitement towards a common goal.  

As a product manager facilitating collaboration, it is key to get your team, and your partner teams excited about the project you are working on.  Maybe the excitement is about a new game-changing feature or an amazing design improvement. Other times excitement comes from using data to show performance or an opportunity.

Regardless, excitement is an extremely powerful emotion for motivating individual teams and partner teams to collaborate.

Calm and composed

Building products rarely goes exactly as planned; sometimes in collaborating with partner teams where certain things are out of your control, mishaps such as a missed deadline or a sudden change in resources can occur.  In these instances, it is critical to exercise being calm and composed.

The surest way for a collaboration to go downhill both within a squad or amongst partner teams is for an individual to lose his or her cool.  As a product manager, keeping calm and helping the various folks to remain composed ends up being one of those skills that is not written in the job description but ends up being extremely vital during hard times.

Remaining calm in a tough situation is easier said than done, but there are techniques that you can employ to let cooler heads prevail.  These include:

  1. Practicing mindfulness

  2. Turning a hair-pulling moment into a moment of laughter

  3. Maintaining perspective of the big picture beyond the difficult moment

  4. Taking deep breaths

Frustration is inevitable, but how you handle that is critical. Lashing out or being passive aggressive due to an aggravating situation will only backfire. When it is beneficial, have an open and non-accusatory conversation about whatever has happened.  Regardless of what happens, the best thing you can do is learn from it, adapt and laugh it off.

Having fun

An extremely underrated emotional experience that helps fuel great collaboration is having fun.

Work takes up at least 40 hours a week (generally more). This means as a product manager, you are spending a large chunk of your life with the folks on your squad and with folks on partner teams executing product roadmaps.  People naturally tend toward situations that are more enjoyable and fun.

In product management, there are ways to make sure you and your respective teams are having fun with what you are doing.  Not everyone is lucky enough to work in technology and build the future, that in itself is fun.

Moreover, having fun can be more than just the work in front of you, but it is also the environment and attitude set forth every day.  Just because you are at work does not mean everything discussed has to be purely work-related. It goes a long way asking your team and your partners how their weekend was, or understanding and talking about hobbies they might have.  This blending of topics can bring more interesting and fun conversations to the work environment. When folks are having more fun collaborating because of the tone of the environment, the collaboration improves tenfold.

Being upbeat and light-hearted makes collaboration in product management a pleasure.


Collaborating effectively in product management requires great relationships.  Relationships matter. You'll hear entrepreneurs talk all the time about how important relationships are to growing and succeeding, the same applies to product collaboration (as alluded to in the section on being a Team Player).


A critical component of building great relationships for collaboration includes building trust with teams and partners. Trust in these folks and their expertise. If you second-guess them or override their work, it breaks trust.  On the flip side, if there is an expectation for you to provide something, honor your word and deliver results; this builds the team’s trust in you.

Managerial relationship

Your relationship with your manager is also critical in furthering collaboration in product management.  

Manage up; not in a way that makes you a sycophant, but in ways that further your team. Try to avoid being in a passive relationship with your manager waiting for him or her to tell you what to do.

Push yourself and your manager to help you grow and execute. Use your manager to facilitate conversations and decision making across the organization. You won't win every negotiation, sometimes you have to escalate and partner with your manager to move the needle. Having a great relationship with your manager will allow to move faster and collaborate better around the company.

Positive reinforcement

A key part of building great relationships for collaboration is positive reinforcement with your team and your partners.

Explicitly letting your team or your partner know when they have done a great job or have gone above and beyond is extremely rewarding on both sides.  It encourages great work and fuels positivity for future collaboration.

In special situations, it is also great to send emails to a team member or partner’s manager commending the individual on their efforts.  This type of impromptu positive feedback is rarer, but it leaves a great impression on all parties. Helping your partners and team further their career is a sure way to build a strong relationship and further your abilities to have positive collaboration.

Never burn bridges

Product management involves working with a lot of different parties over time, so it is key to remember to never burn bridges.

In large tech companies, people switch teams a lot and priorities shift over time.  Sometimes you end up working with someone and you do not have the best time or relationship.  It is easy to want to blow someone off that you have not had a great experience within the past; however, the world is smaller than it seems, and you might end up working with that person again in the future.

Even when a collaboration with someone is hard, it is still better to preserve the positive parts of the relationship than to write the individual off.


In my experience, one of the most common points of failure when collaborating in product management is a failure in communication.

Productive communication for facilitating collaboration across teams and partners is not trivial.  Not everyone interprets information the same way, and conveying knowledge differs from person-to-person.

Source of truth

I find it helpful to have a central document that acts as a living record of what the project is and how it evolves.  This generally is my PRD (or spec) that details the customer, the problem, the objectives, any dependencies/limitations as well as relevant resources and people.  Some companies have a specific format that everyone uses, a lot of others do not. In a situation that does not have a specific format, I find it helpful to detail the core pieces mentioned above, but I also add sections and content that my team and partners ask for or find relevant.  In the end, the document format should fit the team and its needs.

I also find it helpful to have a centralized shared folder where I store everything relevant to the project.  This includes the PRD, other relevant PRDs, research, data, designs, you name it, it’s all in the shared folder.  This way I can share out a single document and folder that enables all team members and partners to explore what they need on their own time, and it also keeps a central source of truth.

Establishing deliverables

Moreover, when there are meetings and discussions surrounding a collaborative project, it is helpful to make sure there is a clear agenda, but it is critical to make sure that at the end of any meetings or discussions, it is explicitly communicated what deliverables are expected from folks and on what timeline.  It is all too easy to have a breakdown in communication surrounding what is to be done after a meeting and who is doing it. Meeting notes and summaries help mitigate this risk, but it is best to recap in-person and establish these expectations.

Managing expectations and updates

Lastly, in certain situations, status emails help with communication across broader collaborations.  In a massive company, it is impossible to make every meeting and keep up-to-date on the happenings of a project daily.  A weekly or bi-weekly status email helps keep all stakeholders informed, manage expectations of the team and partners, and maintain a paper trail for when things go awry.

Not all of these pieces are necessary for strong communication to facilitate collaboration.  It is best to figure out which methods work for the team and partners rather than force a method onto the group.


Additional aspects of furthering collaboration in product management include taking time for reflection, showing humility, and getting feedback throughout the product journey.


An underrated quality in a product manager that helps build collaborative efforts is humility.  

Over time, every product manager messes up, and that's OK. It might be a missed requirement, forgetting to include a key stakeholder, or a mistake in a number of other ways.

The best way to maintain trust from your collaborative partners is to acknowledge when you have messed up, be open about what happened, and learn from it.  Collaboration is not just about what works well, but also about what does not work well.

Your partners will respect you more for recognizing a point of failure as opposed to sweeping it under the rug or casting blame elsewhere.  The acknowledgement and openness of your mistakes conveys strength and courage, both of which put you in a better position for future collaboration.


Sometimes things go well and other times they fall flat on their face.  Ultimately you will be able to build relationships and trust for collaboration through reflecting on your experiences building products.

As a product manager, your collaboration skill sets will grow if you take time to reflect on how your working relationships are in practice.  

Furthermore, your partnerships grow stronger within a team and with partner teams when you take the time to reflect with the respective members as a group.


The best way to build your collaboration skills and encourage folks to collaborate in the future is to ask for honest feedback.

It can be hard to hear negative qualities about yourself, but you have the potential to learn so much more at a faster rate when you let your guard down and ask your team and partners to identify areas of strength and more importantly areas for improvement.

Not everyone is comfortable hearing tough feedback, and many are uncomfortable giving blunt feedback.  It is critical to not be defensive and to simply listen and understand feedback when it is given. These moments are difficult for a lot of people, but they can be the biggest opportunities for growth as an individual and as a collaborator.

Leadership as a service

Last but not least, one of the most impactful perspectives a product manager can lean-in on as a collaborator is practicing “leadership as a service”.

[Leadership as a service is] the job to develop collective capability with a sense of shared endeavor. Leadership as a service is not about extracting work or anything from teams but it’s about serving them and inspiring them by service. Leadership as a service is a philosophy and set of practices.

Abhishek Tiwari

This idea of leadership as a service is meant to flip the roles and tasks of a leader upside-down.  Traditionally, a leader is telling everyone what to do and setting the direction.

As mentioned in the Team Player section, collaboration in product management is less like that of a quarterback and more of a soccer team captain.  The team has to execute as one, and no one person is calling the shots.

A great way to collaborate with a team and with partners is rather than asking someone to do something, instead ask “How can I help you to accomplish X? What are ways that I can help make this easier/faster/better?”.  

This inverts the entire model and truly reflects the nature of a product manager’s role, the facilitator of everything in order to launch great products.  This nuanced approach to viewing collaboration and leadership makes a HUGE difference in how the team and partners execute. Not only does it send a positive tone, but it also helps you as the product manager know exactly where to lean in and support the team in executing their tasks.

Leadership as a service is the icing on the cake for great collaboration in product management.


In summary, collaboration in product management is not a trivial feat.  Many ideas and practices go into fostering great collaboration, including:

  1. Being a team player

  2. An emotionally sound environment

  3. Strong relationships

  4. Great communication

  5. Self-inquiry

  6. Leadership as a service

Product management requires a mixed bag of skills.  Collaboration is one of the hardest yet most important ones to hone in your product career.

There is no single right way of collaborating. The best thing you can do is be open, be honest, and always work to further the team, product, and company.

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.