As a Product Manager at Collectors I own our web and mobile experience for My Collection & PSA Vault. Our users use the product to manage and delight in their collection, securely store their collectibles with PSA Vault, and list for sale on Goldin. We built this new experience as a greenfield product, which made it important that we could start with clear roles and responsibilities as we took on an ambitious roadmap.
My first day at Collectors I got the customary onboarding packet, answering questions like ‘Who to talk to, who I’d be working with, etc.’ What is less common with onboarding is documentation for how to approach work and successfully run a product development process, but Collectors did this well from day one. I was lucky to be building on what our technology organization had previously established. And, I want to share here how I think that really differentiates the Collectors product & technology organization.
One aspect I found most helpful was a clear definition of my role as product manager/owner. I think for some organizations, PMs become jack-of-all-trade type roles or are working without a directly aligned technology team and product development goals. That was not the case at Collectors. At Collectors you know you will have a team to work with, clarity around business goals, and autonomy in defining the roadmap of what to build to hit those goals & delight customers.
From a product ownership perspective, I’ve appreciated a combination of full ownership and full support; I have the ownership to perform my role well, but also have the support in adjacent areas that help me to stretch and improve. One of the tools we utilize for vision purposes is the product requirements doc (PRD). The PRD covers the product vision and the user stories that comprise that vision. To kickoff the My Collection roadmap, we developed three PRDs describing: collection management, collectible detail, and user profile experiences we wanted to create.
Even with a roadmap defined, many organizations struggle with role definition and swim-lanes, but our product development process provides those. At a high-level it goes something like this– Product owners have to gather requirements from stakeholders, creating a product requirements doc and user stories. They work with a designer to define what the experience should look like to the end user. Then, a tech program manager steps in to organize work cadences and execution. Finally, our engineering team then helps us go from the ‘What’ of the requirements to the ‘How’ of engineering them in software. All groups are involved throughout the process of course, for example, all four roles have a part in defining product requirements, but the approach above guides how we do our work.
So, how did we get a relatively well-defined development process within a fast growing tech organization that more than doubled in size from 2022 to today?
Collectors has hired a team from companies including Amazon, Microsoft, and our CEOs previous company, Flatiron Health. In addition, we’ve acquired five companies since going private in 2021. That has meant we’ve been able to bring together best practices from a wide range of experiences.
Tying together a constellation of different businesses is not easy, however in our development processes I think we have done this well. Best practices from the development team of the collectibles marketplace Goldin(*) are the foundation of our product development and tech sprint p
rocesses. As we expanded, we iterated on these processes to make them scalable across larger engineering teams as well as integrating Product Marketing, Design, and QA into development.
In my experience, the technical program manager (TPMs) and QA roles are strong contributors to how we make our process work! TPMs are responsible for cross-team coordination to make sure roadmaps and dependencies line up with our planned timelines. This is highly important for projects that often involve collaboration of five or more teams. QA does a great job beyond just ensuring the quality of our releases. They ask questions that product or engineering may have overlooked, helping improve the end user experience.
Amongst the good, there have been areas I’ve striven to improve and up-level my product development group. One challenge that we’ve faced is how best to incorporate input from product, design, and engineering. Compounding this, we’ve questioned how granular our requirements should be and what defines whether a project is ready to work on.
It is possible for a product owner to provide insufficient guidance but also possible to be too prescriptive with requirements, straying from defining what should be built into how to build it. For our initial roadmap, we found that as the team built familiarity, we iterated on how granular to make the requirements. Early on, we wrote long user stories that described precise flows and went into detail about how features should work to help kick start the work.
However, that became constraining to design and development teams. So, we shifted to utilize designs as our source of truth for requirements as we built our UX. For UX this worked well enough, however it broke down when we started backend integration and touchpoints with other products, since a UX design doesn’t tell you how the backend is supposed to work.
Through iteration and learning we’re finding a balance between appropriately specific requirements and writing our sources of truth at a level of detail that is realistic to update over time. The touchstone of success we found was making tickets the source of truth for what we build and requiring appropriately detailed acceptance criteria and designs before execution. Getting these inputs together requires input from product, design, and engineering teams, but it’s well worth it because it makes us highly productive when we do the work. And, most importantly, it lets us release a killer product.
While old solutions are very often no longer the best options for today’s problems, it’s imperative to learn from the prior processes and tech products while crafting their replacements. The engineers and product directors of the past probably wrestled with the same problems that today’s will, and old solutions can help inform the new ones. In particular, operations that may seem inscrutable at first might be clues to a costly edge case that would be easy to miss otherwise. Collectibles are a wide world with all kinds of quirks and details that generate all manner of unusual scenarios. It can be tempting to write these off as edge cases that aren’t worth too much investment, but we must remember that collectors are driven by passion over minutia. Sometimes the unusual and quirky parts are the most important ones!
(*) Goldin is a leading online collectibles marketplace that merged with Collectors in 2021.
