Before I go into how we built a product operations team, I want to describe what product operations is since it’s still relatively new for a lot of folks and specific to different companies.
PS: I have new Yotuube channel where I build things without code. You can check it out here — https://tinyurl.com/ycvdpoqt
When we started out building the Visually marketplace we took a different approach than simply defining the MVP and iterating on it with a core group of engineers (For context at Visually we were striving to build the world’s largest marketplace for premium design content — we started out with infographics). We divided the product in two parts — one is what we built technically with the engineering team and the other less talked part is the operations backend which helped support and validate what the engineering team built and was about to build. The operations backend is what I call as product operations.
Building a product is continuous validation and a big part of that validation is what we did with the product operations team at Visually. Currently we have a marketplace of thousands of designers, hundreds of paying clients and millions of dollars in transactions every year which the product operations team supports.
Core responsibilities of product operations:
- Help validate and test ideas quickly so they can be “productized”: The product operations team validates the product behind the scenes — often manually. Over time, when product operations determines that something is working well, we automate it.
- Ownership of revenue being delivered through the product: Making sure projects go through to the product successfully and identifying what needs to be automated to do so
Recruiting the right people
The thought process behind the team structure
When building the Visually marketplace, one of the first things we did was identify what falls in what bucket, one is what we are going to develop vs. what we are going to support manually — we knew we had to iterate quickly and building an MVP was key. It was important to determine the right team structure, define responsibilities appropriately across the product development and product operations teams, and finally, hire the right kind of people who were able to take ownership.
The way we structured the operations team was to give project assignments and oversight of each new vertical (Static infographics, videos, interactives) to a different person.
Product operations had to be small — if the team exceeded a critical size, it would mean that either we weren’t automating fast enough or the things we were doing weren’t scalable. It’s great to initially build things that don’t scale but in our case we had a risk of becoming more of a design agency which we had to avoid. Keeping a balance of service, not going overboard, was very important for us.
The people we hired for the product operations team were unicorns — people with a good operations sense, strong sense of ownership, a good bent of product and building companies, and finally passion for the product or knowledge of a specific vertical. We have maintained a team of about 5 to take on all the different verticals in our SF office.
Hiring the right people is critical, especially because the product operations team owns revenue. Validations, feedback and iterations on the product features are all important, but ensuring that what’s already existing is functioning smoothly in order to see clients through to the successful completion of their projects is imperative.
Defining ownership for the team
Initially, as part of the validation process, the product operations team took on a lot of responsibility that we eventually removed or automated:
- Project observation: Monitoring all projects in the project center to see what was needed proactively, give feedback and help clients where needed.
- Assignment of talent: We eventually evolved a fairly sophisticated algorithm which did the assigning and that knowledge was gained initially from manual assignments. Sending invitations was automated.
- Designing the project kick-off process: The creative briefs for each project were developed over time based on team’s suggestions.
- Supply sourcing: The sourcing supply was manual in the beginning, we focused entirely on the customer
- Miscellaneous activity behind the scenes: Any other activity which is not visible to the customer — rush projects were sourced manually, for instance; custom projects were scoped, new verticals and offerings were tested
A strong customer support team also contributed throughout this process to provide feedback to the product and meet client needs. That team is distinct from the product operations team, however. The customer support team’s size linearly scales with the business growth while the product operations team core doesn’t change that much.
Product operations is a new area
It comes with all the challenges of a new area
It’s different than pure operations in a company. It’s tightly coupled and integrated with the product team. A product operations team is not an absolutely necessity in every company, but in certain areas like marketplaces it’s a must-have in order to move quickly and make informed improvements to the product.
The challenges of it being new is communicating its value to the rest of the company internally — new roles, new titles and the way we overcame this challenge was to communicate the core responsibilities very clearly to the rest of the company. The other continuing challenge is ensuring that the coupling with product is solid. This means ensuring that product releases move at a comparable speed to feedback from product operations — if not, it leads to frustration.
It depends on your product team structure and nature of your startup but every product team usually has folks who are at least partially involved in product operations (even if they don’t use that terminology). In our case, it helped immensely to clearly separate the two.
