Casey Flinn

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’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.

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.

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 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.

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.

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 

Ah yes, I remember this article :) I think the key point Marty makes is "Things go wrong when these two roles are not clearly defined." There are two aspects of "defined" to work out here. From a management and org structure perspective, there needs to be definition of who is accountable for what and how these roles should work with each other written down somewhere to serve as a starting point. The next level of definition occurs between the matrixed individuals when you look at these management definitions and define your own working agreements that help you both succeed in the context of the shared portfolio of work, your individual strengths, and all the undocumented expectations that you discover along the way. The uncomfortable truth is that you can't just produce a RACI and expect everything to work out fine. This is because RACIs try to separate out work under the idea to make things clear and clean, but product work is highly collaborative which creates the conditions to blur the lines. My best advice here would be to think about what makes a Product Trio/Triad successful, and apply that same mindset to your matrixed partners: 1. Have shared OKRs 2. Work together (collaborate) vs. create handoffs (coordinate) 3. Align early on your decision making process 4. Create the conditions where its ok to have conflict and mechanisms to resolve it

Lts flip this around - what are the questions our new partners are thinking of, but probably will not ask us? I can gaurantee there are at least four: * Will I like working with this person? * Can I trust this person? * What change is this person going to create? * Do we have the same expectations about how we work together? I am framing things this way for two reasons. First, the primary objective when meeting new partners is always to lay down a foundation of trust. A great way to start building that trust is to be genuinely curious about your partner's perspective and offer up answers vs. making them dig around. Second, it's far too common that we start with trying to understand that person's role ahead of understanding the person themselves. Remember, we work with people, not roles. There will be plenty of time to talk about the work in front of you, your roles and responsibilities, and OKRs. A few finer points: I encourage everyone to take on a mindset of having partners vs. stakeholders. Personally, having stakeholders feels adversarial to me. I know it's semantics, but consider if you would rather be considered a partner or stakeholder :) There are specific questions you should answer together in order to set healthy boundaries and clear expectations. All too often unclear boundaries and expectations are the fuel for discord and drama 1. Who is the decision maker for X, Y, and Z? 2. How do you like to receive feedback? 3. What does it look like for us to disagree and commit? 4. If we feel the need to escalate something where we are at an impasse, how do we do that together in a way that preserves our partnership?

If you believe that your partners are there to help you build the best experiences/products possible, then you should have continuous feedback loops with them not just at the start and finish. The most effective teams include their internal partners in their sprint cadences which look something like this: * You are involving them early in the discovery process to see the opportunities you are exploring and the outcomes you are trying to achieve. This is how you can make sure you are aligned from the beginning and get everyone committed to the path forward. * You have a continuous cadence and are inviting them to sprint reviews and/or making recordings available so you can prevent surprises about how the solution is evolving based on what you are learning. This process here is probably most critical because if your internal partners are there for the whole journey, then launching a product is that much easier as 1) they have context and details of what is being built and 2) they can start their work in parallel and iterate with you along the journey vs. making it a "handoff" to them at the end. * You are creating a culture of mutual accountability by creating space for them to share how their work is progressing alongside yours. The norm seems to be that the product team needs to be transparent and show their work and ask for feedback, but is this reciprocated by your internal partners? I don't think this all fits into a sprint demo, but I have used GTM demos as a place for partners like sales, operations, product marketing, etc. to show the progress they are making and for the product team to give feedback. Having these conversations and feedback loops is a way to ensure that the whole experience works well and has high quality. * Lastly, consider inviting your internal partners to your retrospectives or holding a separate one.