The strategy and processes behind “Project Element”; our integration with one of the most powerful selling platforms in the world
Background
At Collectors, one of our main areas of focus is giving customers the best, most frictionless path to liquidity. We feel the best way to do that is by working on the features that can make collecting, grading, and selling fun and easy to do. And related to this world of buying and selling, there are certain companies that don’t need an introduction. They have become ingrained in the day-to-day of our lives and probably lead to an unhealthy amount of screen time. For collectors and non-collectors alike, eBay is one of those companies.
In late 2023, our Product and Technology (P&T) organization began to pursue a potential partnership between Collectors and eBay. Integrating the PSA Vault and Grading experiences with the eBay Marketplace, it would give users the ability to directly list their vaulted and graded cards on eBay’s platform, without having to worry about the hassle of shipping and fulfillment. In short, a game changer in the hobby.
Now, after the hard work of more than eight different P&T teams and numerous cross-functional partners, along with the completion of too many Jira tickets to count, I’m happy to say (spoiler alert) we successfully launched our MVP in June 2024. But how’d we go from an idea to going live with a full-fledged MVP?
The Lead Up
To take a step back, I work on our Technical Program Management team at Collectors. Our job is to bring alignment and clarity to different cross-functional and cross-team P&T initiatives. This is done in many ways. Whether it’s establishing and driving different processes, helping define scope, track and manage timelines, or just generally tackling impediments day-to-day, we try our best to keep things moving in the right direction.
As it relates to our integration with eBay, there was one item that we needed alignment on before anything else could even kick off; the scope of our MVP. We knew there was interest from leadership in understanding the level of effort for different features and functionality related to building a proper selling experience. We also knew there was a premium being placed on speed-to-market. To help answer those points, we implemented one of our first scaled cross-team processes.
Imagine having a Product Requirements Document (or PRD) review but, instead of reviewing more defined, smaller, user stories, we were reviewing epic-level requirements. We gathered leads across all pertinent teams to start our first Initiative Review at Collectors. We had 3 main goals in mind for these sessions: 1. An understanding of what teams would be involved to meet “epic-level” criteria, 2. Early callouts on potential dependencies, and 3. Rough T-shirt sizing of all workstreams. This would then give us the information we’d need to present to leadership our “menu” of options for MVP.
The meetings ended up being extremely useful. A huge shoutout to our product leads across PSA, especially My Collection, who gathered a lot of the initial requirements needed for this discussion. Because of this, each team was given visibility at the earliest of stages for work coming down the pipeline, and were able to provide input to ensure we were accounting for all dependencies to run an efficient project and launch. I then broke down the work into 5 distinct workstreams, from the user experience, to payout, fulfillment, etc, with a rough dev week estimate for each. After presenting our “menu” (with a little bit of horse trading and fast-follow agreements tucked in), we had our MVP scope!
Kickoff
Although we now had an agreement on our MVP, we were far from being in a position of heads down development. There were still questions around UX design, product requirements, and general technical architecture. Because this project was going to touch so many different areas and services, we knew we had to apply some level of cadence and predictability to our processes. We didn’t want to run the risk of getting too far down a path of no return without having scheduled checkpoints, both during, and even before, actual development started. This is when we decided to spin up a Scrum of Scrums.
For those unaware, a Scrum of Scrums is a technique used to coordinate separate teams to deliver features or functionality. Plainly put, in a SoS meeting, we share updates on work. This includes progress, impediments, and what the team plans to accomplish before the next meeting. By having this, we can better coordinate output from all teams, provide transparency into when dependencies exist, and have all the right players in the room if there’s anything blocking progress.
Because of our earlier Initiative Review, we already had a high-level understanding of ownership, and who needed to work on what. That gave us the opportunity to outline roles and responsibilities to share during SoS, so everyone knew who our lead product and tech partners were to direct questions. It also helped us prioritize what to tackle first, which was system architecture. As our team leads began to do their research spikes, everyone had line of sight as to how progress was being made, and when we’d be able to have more formal, focused discussions around the cross-team architecture.
A similar process was done from a UX design perspective, too. In collaboration with our User Research team, our Design team was able to provide visibility into what the experience would look like on My Collection. After reviewals with the P&T teams to discuss feasibility, and reviewals with our business facing stakeholders, we were able to show how our MVP would look and feel. Below are some early (not implemented) explorations from our design team for the “Selling” and “Sold” Tabs within the My Collection experience.
In Progress
So at this point, our weekly SoS meeting is in place, we’re checking in on status and blockers, our designs and technical architecture have been reviewed and signed off on, and teams are actively coding against requirements. No changes or concerns the rest of the way, right? As with most projects, that’s always easier said than done.
From the earlier discussions we had around speed-to-market, we knew our guidance was to have a lean MVP, and iterate from there. That doesn’t mean we didn’t have a couple bouts of scope creep, whether if it was due to technical deep-dives unearthing new needs, or an ask to accommodate a change in product requirements. The main point we tried to make when having to take this work on, is making it explicitly clear what this would mean to the larger picture and timeline. We wanted to be as transparent as we could, as early as we could, if taking on additional work could balloon scope. Fortunately, our tech leads across our customer-facing experiences, shared services, and internal systems did an amazing job being agile and rolling with the punches as they came about.
As we continued to make progress (slight changes notwithstanding), we were able to get more crisp on our milestones. This helped paint that picture of, if we had to take something on, what that meant for getting to dev completion, E2E testing, etc. So not only were we able to identify what those were, but also showcase the process so everyone knew how well we were tracking towards completing them.
At Collectors, we use Jira as our source of truth for tracking and documenting what teams are working on sprint to sprint. It’s one thing to provide estimates early in the process, but another to feel confident in the work to actually get done on time. By being able to leverage Jira through the use of different labels, I was able to create filters and dashboards around different flows which gave us additional validation in knowing we were on track, or knowing that we had to flag a risk to completion. Below is an example of one of those dashboards used to track tickets needed across all teams to consider our Listing Flow (Happy Path) complete.
Launch
For launching a product of this scale (both in the amount of work and in the publicity that would surround go-live) we knew we wanted to have a phased approach. For larger features at Collectors, we like to segment our launches to smaller “Alpha” and “Beta” cohorts. This helps us gather and address feedback from more focused groups, making sure functionality is working as expected before just flipping a switch and opening the floodgates. In addition to the technical considerations, segmenting our launches help derisk from an operational perspective as well. If we were to immediately start with a public launch, there’s potential we would’ve had to deal with a level of volume we might not have been ready to fulfill within our SLAs. We split this up into “Alpha” meaning Internal Collectors Stakeholders, and “Beta” being different subsets of users outside the company (I.E users who we consider Vault power sellers, users who had items at the eBay Vault which were heading to the PSA Vault, and Collectors Club members with vaulted items).
Each phase would involve its own set of steps and signoffs needed to make sure we felt comfortable in moving forward. We knew from the beginning that this would need coordination across not only our P&T teams, but representation from our partners in Operations, Marketing, Finance, etc. To help with this, we would set up 2 coordination meetings in advance of each phase; one of them was done 1-2 weeks in advance of that phase’s launch so we could talk through and document everything that needed to be completed. This included tactical items such as flipping of feature flags, turning on Optimizely audiences, and marketing comms (see image to the right for what “Beta” users received at go-live); sign-offs from teams like QA, Operations, etc to make sure they validated functionality is working as intended; and tracking of any development that was done strictly during the “Alpha” or “Beta” phases. Each item was outlined and reviewed with this group, with an owner attached and a date/time for execution. This made it easier for anyone, regardless of team or functional area, to know what the plan was and who they could reach out to for questions or concerns. The second coordination meeting was held a few days before that phase go-live, and this was essentially a Go/No-Go call. We would review all the line items associated with that phase, make sure they were either complete or on track to be done, and confirm there were no additional items we were missing. Whether it was time for Alpha Launch, Beta Launch, or our General Availability (GA) Launch, we already knew what needed to be done and by whom, which helped ease any potential nerves.
Throughout this process, a huge shoutout needs to be given to all of our different team leads. They were available, responsive, and collaborative throughout each phase of the project, making it that much easier to make sure we weren’t missing steps. By the time June 24th rolled around (when we opened up to 100% of the public and all GA marketing comms were released), we had over 15,000 listings already created during our Alpha and Beta periods, and a large portion of those fulfilled and gone through our post-sale flows. This gave us the confidence needed in moving forward with opening to 100% GA.
Retro / What’s Next
Since our MVP go-live, we’ve received a lot of positive feedback and adoption. The volume of listings and GMV has exceeded initial projections, and we’re hoping with continued enhancements to the experience, we’ll see those numbers grow. We’ve already been able to address several fast-follow enhancements like bulk listing items, enabling multi-item checkout and fulfillment from eBay into our downstream systems, and being able to choose the start date for your item going live.
As we wrapped up Phase 1 of our work, we held a retrospective across all teams that played a role in launching Project Element. We were able to take stock in what went well and should be carried forward for future initiatives, along with things that may not have gone so well and can be seen as areas of opportunity. Things like better visibility into the testing strategy from the beginning, and more robust monitoring and alerting at MVP were helpful takeaways that will continue to serve us well as we improve and scale our processes as a P&T organization, and our products as a whole. Especially as we turn our sights to the next exciting feature for our marketplace integration – Buy Now Listings!
