AMA: Realtor.com Sr. Director, Product Operations, Casey Flinn on Product Operations

I look at this question as more "when is my org ready for Product Ops" vs "what size should it be" :) Here are some signals for "ready" that I would use: * You are probably struggling to scale the org. You have great people on the team but it’s gotten so big and complex that it’s just getting harder and harder to work and impacting the team. * Your org structure might be more vertically aligned and working well in those structures, but there is nobody looking at the horizontal aspects of the org with enough focus to make an impact. Also, vice versa in this case too. * You see some operationally minded people on the team who are already leaning into this role. Typically, there is someone who already showing you what you need by taking on the work in addition to their day job * You write out a job description with clear statements to what they are accountable for, AND you can show that to everyone in the Product org and they won’t get confused/concerned about their role. For some context, at realtor.com we were at about ~120 people in the product org when we started Product Ops. We also had very well established and defined Product Manager, Product Designer, Product Marketing Manager roles.

This is such a new field I think we are all still trying to figure it out together. However ... * Product Ops should be a feeder role into other product roles like Product Manager. There are so many barriers to entry into PM roles, If done right Product Ops can be a great bridge into Associate PMs. Product ops can help people develop the right mindset, learn through observation, apply product thinking (e.g., forming and testing hypotheses based on data) to Product Ops work, and show off their potential to hiring managers * I personally want to hire mid/senior Product Ops people who have been a Product Manager, Product Designer, etc. role before. This is because if you don’t know the work, pain, joy, methodologies of the roles you are helping to scale, then there is going to be a steep learning curve. I see Product Ops as a great way to pivot your career where you have a Product Mindset, but you want to use that in a different way with different customers. * Your company should support dual track career ladders where your contribution can scale with your compensation. This means you can have Principal level roles as well as leadership roles for Product Ops. An inconvenient truth is that there are a lot more individual contributor roles out there today than there are people leadership ones. * Another aspect here is that Product Ops shouldn’t be seen as a one-way door. If you are really great and loving the ops part, you could parley those skills in to other ops roles in the company. If you love the product part you could always go back to a PM role (if you came from one), or if your manager is really focused on developing you into a PM (or other product role) then you could go that route.

I love this question because I have been asking people this same one for ever since I started in Product roles :) It’s also an exhausting question because roadmaps and their processes are so highly tuned to the org/company itself that when we share these with each other it’s hard to not get lost in the "how will this work for me/us?" Here is what’s important in this area IMHO: Process: Think, plan, and tell the story around outcomes not features * I’m currently working to drive proficiency and skill development around the Opportunity Mapping approach that Teresa Torres teaches in her book Continuous Discovery. Of all the "process" things to focus on, this one is powerful because it shifts thinking from features to outcomes and gives a pretty easy way to map those out. I highlight this because this leads a product team to create an outcome based roadmap vs. a feature based roadmap. * Also, our CPO has really pushed us to start our work with a written narrative about the consumer problems, why they matter, and put them in the context of the insights we gleaned via discovery. We often forget that the roadmap is the visual representation of the story we are trying to sell, and putting things on a side isn’t the same cognitive process of putting a written story together. I think that in order to be efficient, product teams around the world have become so hyper focused on the output of the roadmap itself, we lost sight of the "why" behind it, and the written narrative has been a great way to rebuild that muscle * I call these out as key process upgrades because the purpose of the roadmap is not to make sure a roadmap gets produced, but it’s to make sure we are creating the right outcomes. Tools: Spoiler alert... Google sheets and slides. * I have evaluated a lot of road mapping tools, and I will still evaluate more, but it seems to come down to two things: * The actual slides / deck of the roadmap (whether for customers, the exec team, the board) always require us to make visual / storytelling choices where we can’t use the out of the box views etc. from the tools. So, no matter what tool we are using, we are always creating a roadmap in slides :) * Team adoption. I think it’s important to make sure individual teams are bought in to whatever tool we want to roll out. My common experience here is that a lot of these road mapping tools are interesting and a curiosity to teams, but they have something that is "good enough" in place. Long way of saying that its low on the priority list. * Don’t get me wrong, I think the tools in the Product Stack are critical. However, I think tool selection needs to be aligned to where the teams can get the most value. As an example, right now, I/we are more focused on tools that help product teams conduct discovery and interact with more consumers/customers. I could see opening up the road mapping tools conversation in a future horizon.

I’m going to sound like a broken record, but we should really be looking at Product Ops as a way to force multiply the work of our teams vs. carving out responsibilities from other roles and giving them to Product Ops. If you don’t have any Product Marketing Managers (PMM), maybe you would ask Product Ops to take on some PMM functions (like GTM), but you should be asking why we aren’t hiring PMMs if that’s the case :) Ok so then what does PMM "generally" do: * Go-to-market (GTM) / Sales Enablement: You need to be binary here: Product Ops owns GTM 100% or Product Marketing does. And I mean end-to end ownership of GTM. Don’t cut in half. Its already complex enough to manage GTM activities between a PM and PMM, so if you insert a 3rd role/person in that relationship you are just going to set up Product Ops to be the "runner" of probably the least glamourous parts of GTM, and create a lot of waste and frustration. * Competitive Research: I think that if you have a lot of PMMs doing this you could make this a force multiplier, but it can’t just be doing the research and saying "here are my notes from the earnings call." The bar should be higher and Product Ops should be briefing "everyone" on what this means, and delivering actionable insights in the context of your work/roadmaps to help PMMs, PMs, etc. move faster. * Market Strategies and Monetization: This is a huge value that great PMMs bring and they spend years learning and mastering these aspects of the PMM role. Product Ops should not touch this IMHO I love this question because it speaks to an anti-pattern, I see with Product Ops where some orgs see it as a way to scale by splitting a role to create more capacity / put 2-3 people in the "same box." Might sound great on paper, probably not so much for the people in those roles.

Ideally, I would like to hire a Senior Product Manager/Designer/Marketer etc. who is looking to take their skills and do something new/different with their career. I say this because these roles nurture things like: * Design Thinking * Using data to build and test hypotheses * Ability to break big things into simple, lovable, complete solutions where we can ship small and learn along the way * Desire and track record to deliver outcomes * Appreciates process, but understands that not every problem needs a new process 

When I started Product Ops here at realtor.com I started with mission, principles, and northstar metric: Mission: Help level and clear the field on which our people and teams play, so you can do the best work of your career, in a community you love, and positively impact the lives of our users Principles People are our foundation Create the conditions for you to do your best work, grow and find success in your role, and build an enduringly great community of Products People Raise as many boats as possible Drive continuous improvement in those areas where we need to scale as an organization; communications, planning, hiring, onboarding, tools, etc. Amplify best practices Look horizontally across communities, squads, individuals to identify and standardize on the right things (not standardize everything) Northstar Metric Employee engagement (NOTE: our CPO and I landed on this as the northstar metric because we saw Product Ops as there not to do the work of a Product Manager, Product Designer, Product Marteter, but rather make the system in which we work in easier to get sh!t done and more rewardingfor our teams)

I strongly recommend you join groups, reach out to other Product Ops folks in LinkedIn and ask to learn more. Nobody really has this role canonized, in fact there are multiple versions of what Product Ops could be. We are kind of in this "norming" phase of Product Ops so its important that you form a clear point of view of your own of what your company needs (or thinks they need :) ) so that you can craft the right flavor of Product Ops. I have found some quality conversations / ideas via interactions in the PLA slack community. Also, Marty Cagan with Silicon Valley Product Group has started sharing some of his thoughts on Product Ops.