AMA: realtor.com Sr. Director, Product Operations, Casey Flinn on Product Management Skills

Not Understanding and/or Aligning OKRs If you are operating against different and even competing OKRs then your roadmap will never get buy in. This issue creates the conditions where no matter what you have on there, there will not be alignment because everyone is chasing a different outcome. This is why OKR creation with stakeholders is critical - everyone needs to be bought into the direction before you can cuss and discuss the details and the how to get there Not Framing the Story with Data Your roadmap should not start with the actual details of the delivery items. You need to start with the consumer/customer/user opportunities (aka problems) that you have discovered through copious conversation, looking at your product metrics, and competitive analysis. Then you can talk about what outcomes you can drive by addressing these opportunities, THEN show what you intend to go discover or deliver. When you omit the opportunities and outcomes that are informed by your first hand data, then you make all your decisions subjective. This doesn't remove disagreement, but it changes the nature of the conversation to be "ok, lets take a step back and see what data best supports these differing opinions." Just Saying No To be clear, you need to say no a lot, but you just cant say "no" and move on. The best approach here is to always refer to the roadmap and ask the question "is this new thing more important than the direction we are already aligned on?" You have to remember that you probably can see the roadmap in your dreams at night, but your stakeholders don't, even if you publish it and you are transparent, the reality is that its not front and center each and every day for them like it is to you. Creating the habit of asking questions like the one above is real important to giving you the credibility to say no to low priority stuff, because you are saying yes to high priority stuff

Great question. I would frame this as more "Product skills and mindsets" vs. just Product Management as I see these skills and mindsets across the community of Product roles. Also, I'm going to do what a good Product Person would do and prioritize for what I think would have an outsized impact on the whole company. Accountability to Outcomes over Outputs A product trio cannot survive long if they don't deliver outcomes and they just keep touting "look what we shipped." A sales person cannot survive long touting all the demos they made without posting actual sales. There are certain parts of the org that operate like this naturally because its high visibility and it gets measured, so the opportunity is to get the whole org operating like this. A great example is that in my recent history an internal team rolled out a new tool for employees. There was a ton of fanfare about the launch, but months and months later adoption was abysmal. If this was a Product team that launched this it would have been a huge miss in terms of product market fit, yet this was generally seen as a success because the narrative only focused on delivery, not outcomes. What happens here is that you are doing your org culture a disservice. When some teams are accountable to outcomes and others outputs, you cant "be all in this together." Demo Your Work First, note that this can be an enabler to helping achieve the point above. In general modern Product teams follow some sort of Agile, and in there should be the aspect of doing sprint demos. As a reminder we demo work to get feedback and keep the shared understanding train on the tracks. My experience is that the outcomes are always better when you show your work early and often to customers - you learn more and get more access to signals to increase your odds of hitting that outcome you are driving for. The odd thing here is that this feels a uniquely "Product" behavior, which it doesn't need to be. Imagine the impact of the Sales Engineer demoing the new demo system to their customers (sales team) as they are working? Imaging the FP&A team demoing the new process to do annual budgets to their customers (department heads) as they are working? Test Your Assumptions I observe that people make lists and talk about assumptions all the time, but don't really know what to do other than curate the list and reference it at the RCA meeting :) Product has to constantly balance speed with risk, and this is a real solid technique to help a Trio out. The core concept here is use assumption mapping to get a clear view on assumptions, then do simple quick tests (not research projects) to reduce your high risk assumptions. The reason I think this is valuable to the whole org is because 1) we all could use a better way to de-risk our work 2) most people don't know what to do after they create the list of assumptions. Either people slow down to assess everything or get overwhelmed and just YOLO it.

Creating new opportunities. This is really what will differentiate yourself as a Product Manager and really expand your own career opportunities. Its also the hardest thing to achieve because it requires high levels of proficiency, a strong "product sense," and being in a company that creates the conditions for you to do this. Imagine two PMs both focusing on driving a KR of improving NPS by 30pts... PM 1 achieves that goal by revising pricing and packaging, addressing feature gaps with the nearest competitor, and rolling out a some features that are truly customer inspired. PM 1 clearly had impact, and they and the teams around them have something they can point to as a real accomplishment that made the business better. PM 2 however has been spending a lot of time with their Trio practicing continuous discovery habits, and they discovered an opportunity that nobody in the business even considered around a problem that their competitions are not solving either. PM 2 works to bring early iterations of this product to life and customers buy and adopt this new product which increases NPS because they are getting value they never expected. Both of these types of PMs are needed in a Product org as they are clearly able to deliver impact. The distinction here is that eventually optimization work starts to run dry and companies need to produce new things in order to grow and retain competitive differentiation, this is where the PM 2 is going to have outsized impact on a company. Lastly, I do observe this is a learnable skill that we can all develop. As I observe "opportunity creators" today, the most salient things they have in common is that 1) they talk to a lot of different people (customers, prospects, stakeholders), 2) with high frequency, and 3) not to validate their own ideas / prioritize problems but to just understand what their experiences are. This allows them to "paint with more colors" when they are thinking about how to drive outcomes and what opportunities they should pursue.

I get the gist of the question, yet want to call out that "impressing" team mates is not the path I would take. Rather its all about how one can show up authentically and build a collaborative working relationship. It also set ups a paradigm where one party gets to define what is valued and the other just has to respond / adapt. So I would recommend something like this (note: this applies not just to your engineering partners but also everyone in your Trio+ sphere). Essentially I want to consistently demonstrate three things. I'm real... * I do what I say and keep my commitments. * I'm going to act the same whether its just us, in a big group, or with our bosses. * I'm going to make mistakes and have to apologize for stuff I'm safe... * I wont throw your or the team under the bus * I wont grab all the credit / not acknowledge our team efforts * Mistakes happen, lets face it as a team I care... * I will be present for and engaged with the team * I will own my responsibilities as a PM * I will get to the right level of technical knowledge that fits the needs of our work * My Trio partners are equals When all three of these factors are healthy, we are going to be in the high trust / high collaboration zone and mutually influencing each other to achieve great outcomes.

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