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.

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