Navigating the First 90 Days in Product Operations: A Roadmap to Success

In this Product Ops HQ Meetup, Maria Van Wambeke, a seasoned expert with over 20 years of experience in product management and operations, shares a comprehensive framework for new product operations professionals navigating their first 90 days in the role. Hosted by Ana Andrade, the session breaks down the journey into three stages—Curiosity, Inventory, and Prioritization & Quick Wins—providing actionable insights for early-stage product ops professionals to build credibility, align with teams, and start driving impactful changes within their organizations.

Maria emphasizes the importance of curiosity and active listening in the first stage, where new hires should immerse themselves in understanding the existing processes and relationships within the company. The second stage, Inventory, involves assessing work streams, data strategies, and tool usage to uncover areas of improvement. Finally, in the Prioritization & Quick Wins stage, product ops professionals are guided on how to prioritize initiatives effectively and create early wins that align with organizational goals.

With practical examples and real-world scenarios, Maria provides a valuable roadmap for new product operations leaders to make an immediate and lasting impact.

Key Takeaways

• Stage 1: Curiosity – The first 30 days should be dedicated to active listening, meeting with functional leads, and understanding the company’s existing processes. Build political capital early by empathizing with colleagues and learning their pain points.
• Stage 2: Inventory – Once you have a broad understanding of the organization’s structure, focus on identifying inefficiencies and roadblocks within existing processes, tools, and data. Mapping out the day-to-day experience of product managers helps in streamlining operations and improving team effectiveness.
• Stage 3: Prioritization & Quick Wins – Use the insights from the first two stages to identify high-impact, low-effort initiatives. Implement quick wins that demonstrate value early on and build momentum for larger changes. Prioritize based on impact to the organization and technical feasibility.
• Collaboration & Empathy – Building relationships across departments and gaining buy-in from leadership is essential for long-term success. Show the value of proposed changes through data and evidence to overcome resistance.
• Continuous Improvement – Product ops is about iterating on processes and continuously improving. Don’t over-engineer systems; focus on incremental, manageable changes that lead to lasting improvements.

Transcript

Introduction

Ana Andrade: Hello, hello everyone. Welcome. Welcome to the February edition of the ProductOps HQ Meetup. For those who don’t know me yet, I’m Ana and I’m tuning in from Portugal. I’m glad to be your host today, along with my friend Alisa, who’s going to be my co-host. Welcome, Alisa.

Alisa: Hi Ana! Excited for today’s session.

Ana Andrade: Thank you all. Thank you. So thank you all for joining us today. If you are here with us, please drop a quick “Hi” in the chat and let us know where you are tuning in from. So I will wait a bit. In the meantime, I want to share with you a couple of housekeeping notes. This live session is around one hour long and it will be recorded and available on demand later. We will start with the presentation, but we want it to be as much engaging as possible. So if you have a question for our speaker, you can drop it in the chat and I will ask her to answer. And after the presentation, we will have enough time to do a live Q&A. So during the live Q&A, I will ask you to turn on your mic and camera so you can ask directly the questions to our guest speaker.

So without further ado, we are here today to discover the roadmap to success in your first 90 days as a new product ops professional. We will start soon, but before introducing our lovely speaker, let’s kick things off with a quick icebreaker. So what’s one word you would use to describe your first 90 days in a new product ops role? Or if you are just starting, let us know which word you hope defines it. Drop your answer in the chat. And if someone wants to tell out loud, feel free to tell us. Okay, I’ll wait. Firehouse. Unclear. Listening tour. That’s great. Chaos. Yeah. Chaotic. Intense. Wow, that’s so awesome, guys. Thanks for sharing. I believe we have so much here to discuss with our speaker.

So without further ado, I want to introduce our amazing speaker, Maria Van Wambeke. Maria has over 20 years of experience leading product management, product operations, and program management teams for both private and public companies. Her power skills are scaling operations and cross-functional teams using agile methodologies, driving alignment and efficiencies across teams to ensure delivery and delivery of the best products for their customers, and deep engaging communication and facilitation that gets to the core of issues and introducing solutions that create sustainable change for organizations and teams. Maria is also an avid outdoors woman who loves to unplug while solo backpacking throughout the world. Who doesn’t, right? So welcome, Maria. Thank you so much for joining us today and for sharing your helpful advice with our community.

All right. So we will start right after a short word from our sponsor, Dragonboat. So Dragonboat helps teams deliver products that accelerate business outcomes. Its award-winning responsive product portfolio management platform adopted by more than 4000 teams in over 60 countries allows teams to strategize, prioritize, plan, deliver, measure, and improve their products. To learn more about the suite of products for roadmapping, portfolio management, and strategic planning that Dragonbot has to offer, check out dragonboat.io and my brilliant co-host will drop the link in the chat for you.

Are you able to see my deck now? Yeah? Okay. So Maria, let’s go to it. Passing the mic over to you now.

Maria Van Wambeke: Thanks, Ana. All right, team. I’m really excited to be here as a member of the growing product ops community. And I wanted to just shout out special thanks to Dragonboat for providing a space for us to collaborate, share ideas, and support one another as we navigate this product ops journey. And from some of the responses in the chat, it’s a tumultuous journey, but we’re on it together. So I know that much of the content that I’ve put together in the presentation is based on a poll that we ran, which is asking, you know, some of the things that you came across in your first 90 days on the job. So we’ve built much of the content around answering some of those pain points. So thank you all for being a part of this presentation. It’s really a true testament of the power of our community. Next slide, please. So before we dive into tactical content, I like to set the stage for a general kind of fits most definition of what product ops is. So we put it in context. And as you look at this slide, you’re thinking, wow, that’s a really robust charter, right? And that’s the intent, again, based on the comments in the chat. We are asked to do so much, often as a one-person shop. And that makes creating effective, repeatable processes that make an impact even more crucial. So let’s quickly describe each area.

Stage 1: The Curiosity Stage

Maria Van Wambeke: Product ops is the glue between functions and teams, ensuring that cross-functional communication and alignment are proactively built into processes. Product ops is aligning product priorities to what matters most to the organization, with global prioritization across multiple teams and roadmaps. OKRs, KPIs, and value streams are some of the methodologies that I’ve used to enable this. Product ops is streamlining routine tasks for product managers through ownership and management of the product data strategy, tech stack, frameworks, templates, again, just to name a few. This result is often giving back time to PMs so they can focus on creating customer value. And this, in my experience, has been one of the delights of product ops, having a PM come to me and say, “Wow, you made my life easier, or you freed me up to work on more requirements,” right? So this is a very, very key function. Product ops is product manager optimization and excellence through onboarding, empowerment, and coaching so that PMs can be their most effective in their roles. Product ops is creating value for the organization through continuous process improvements and standard operating procedures that scale.

 Product ops is promoting a discipline of continuous discovery and learning. This includes user, customer, and competitive research, as well as testing and experimentation, again, built into the day in the life of a product manager. Product ops is celebrating and communicating with the development and execution of a communication strategy that has documentation and presentation. And this is all collaborated and executed through a product ops calendar. And finally, if that wasn’t enough, product ops is ownership of the PM tech stack, including tool selection, implementation, and management. So the product ops charter varies greatly across organizations. Every role I’ve been in, it’s different. So this is just the general, again, fits most definition before we dive into the actual tactical content. And I’m also really interested in hearing from some of you offline or in the chat about areas that you are responsible for that may have been missed in this rough-cut definition. So now we’ve set up our contextual space, so we can dive into the first 90 days of the product ops role and that framework.

Stage 2: The Inventory Stage

Maria Van Wambeke: So I wanted to give you an aerial view just of this, again, the theme of the journey, navigating the product ops journey in your first 90 days. So congratulations. Amazing. You just landed a new role and you’re very excited about diving in, but you don’t know where to start. So the framework is actually broken down into three stages. Some stages may take longer than a month. Some stages may take less than a month. You might interchange actually when you execute on these things and when you act.

So this is really a framework for you to take pieces from and to build your own entry into an organization. So stage one is the curiosity stage. You’re on a mission. Previous slide, please. Stage one is the curiosity stage. You’re on a learning tour and this is your map. You’re going to navigate a new landscape by meeting with functional leads and stakeholders and each of the direct product team members. And generally, when I refer to the product team, I mean product management, design, and engineering, which is especially valuable in those teams working together in agile, of course. And your aim in speaking to each of these individuals is to really understand the lay of the land. You’re going to ask a ton of questions, be inquisitive, and take a passenger seat in the conversations. As I said previously, you don’t have any political capital at this point. So you’re building relationships that are going to mature into alliances as you progress through your role. You want to connect. Right. And learn. You’re an advocate for change, but you don’t have all the answers yet. Right. So the slow and graceful entry shows that you respect and honor that there is a reason behind why things are done a certain way.

And you’re on a mission to understand that. Why? And just a few tips here. As you’re meeting one on one with individuals, functional leads, stakeholders, team members, take a ton of notes. I mean, copious notes. You’re looking for any sort of identification of those areas that we’re going to inventory in a later stage. Right. So where are work streams being documented? What processes are in place? What tools are being used? You’re likely going to revisit many of the conversations again in follow-up discussions and in other stages of the process.

Stage 2: The Inventory Stage (Continued)

Maria Van Wambeke: So you want to make sure you know where you might want to follow up. So listen intently and empathetically, of course, to identify pain points and jobs to be done that can be improved. And again, make lists of work streams, processes, and data sets. Again, this is your own cheat sheet. So you can go back to it and refer in subsequent stages. So before I go on, are there any questions or clarifications needed?

All right. Coolio. Next slide, please. All right. So diving into stage two, which is, you know, around month two, it’s the inventory stage. You’re approaching this stage again with a big picture or an aerial view of the organization, how things are done and why they are done a certain way. In this stage, you’re going to get in the weeds and you’re going to inventory everything and baseline as much as possible. So, again, these are the work streams or the roadmaps, processes, standard operating procedures, data sets and all the information you can find. And you really want to try to piece together a day in the life of a product manager and other members of that product team. Right. Your role is to streamline and reduce friction in a day in the life of those roles. So you likely discovered key areas or pain points in your learning tour that you should highlight. Again, with what matters most of the organization, I’m going to share just a few key areas that I’ve discovered. And again, I’m curious to see what others have identified in these early stages of a new role. So one is the full product portfolio, and this is a true holistic understanding of where resources are being utilized so that in the near future, right, you can gauge the capacity of a specific team and then prioritize apples to apples.

I’ve always been astounded that all I discover that roadmaps aren’t the only output where resources are being used, but there’s tech debt and technical projects. And what we, you know, in a previous role, funny called skunk works projects. Right. Those things that you don’t know that are being worked on behind the scenes. And it’s imperative to understand they exist because, again, they’re taking away velocity and capacity from a team and what they can work on for customer value. The second is how the team is aligning discovery and output to the company vision, strategy and planning. What methodology is being used? I referred to this previously as like, OKRs, KPIs, value streams. But again, we are here to make an impact. And unless the work we’re doing aligns to a high-level strategy, then it is actually out of alignment with the company mission. The third thing that I’ve discovered is the data strategy for the team. Right. And depending on the role, you might also include business metrics. I was also responsible for business operations in my previous role. So it was quite a robust data strategy. So you want to understand what data the team is using, what disparate data sets. And also, is there a framework, you know, like the Google HEART framework? Right.

Maria Van Wambeke: So the fourth is the product manager tool set or product dev tech stack. And it’s best to learn about these tools by shadowing the product manager to see not only what tools they’re using, but how they’re using them and how frequently. Right. How much are they actually being leveraged? And it’s surprising again to me how often Excel is used as the go-to or Google sheets or smart sheets when a more sophisticated solution like Dragonboat isn’t being used.

Maria Van Wambeke: So fifth is frameworks and prioritization methodologies. How do PMs prioritize features and are they all using the same set of frameworks? In my experience, I’ve seen a plethora of frameworks being used for prioritization. And again, this reduces the normalization of the output. Right. And does not create standard operating procedures for a team. And finally, looking at recurring meetings and events. And this isn’t always something that people think of, but it’s the biggest drain on time for a product manager. And if we’re going back to one of the goals in our role, it’s giving time back to the product manager. So imagine if you could decrease the amount of meetings that they’re spending their time in to work on excelling in the role and again, providing value back to customers. So these are some key areas that I’ve encountered, but we’ll go over a full inventory list on the next slide. I know that was already a lot. But in closing, as you’re working to identify the who, what, why and how for product teams, really start to build your own narrative or hypothesis about the day in the life of a product manager. And again, other members of the product team. Right. You want to start to gain a deep level of empathy and understanding of the main pain points, which will then translate into the initiatives that you’re going to work on later on. All right. Thank you, Anna. And I know this is a very robust slide and it’s not meant for me to talk through. It’s meant to be a resource. And the way this is laid out is a full inventory list of all those areas where, again, you’re going to look at to really deeply understand a day in the life of a product manager and other members of teams. It’s organized into two dimensions. The first dimension is the who, what, why and how. And then it’s categorically organized based on your product ops charter, which maps somewhat loosely to the slide of the massive charter we went through when we are adding context. So you’ll see that there is a plethora of items here. And the reality is you may or may not be responsible for all of these areas, but I wanted to give you a robust list to at least cross reference and say, oh, Wow, did I think of that? Did I think of that? There might be some low hanging fruit too. So again, just for reference, and you’ll have this in the slide deck at the end of the presentation. And if there are any questions about any of this, again, drop it in the chat or if we want to go back to it in Q&A, happy to do so.

Stage 3: Prioritization & Quick Wins

Ana Andrade:  Sorry, Maria. We are actually having one question in the chat. So C Wedwell, I’m sorry if I’m saying it wrong, asks if you do you think product ops is responsible for defining reg definitions, t-shirt sizes, etc?

Maria Van Wambeke: So the reason that I bring this up is that a lot of roles in product operations include release management, capacity planning, because you’re working in alliance with the engineering team or the engineering operations team. So the reason this is fundamental is that if you have two teams that are working on different roadmaps, right, for the same organization or same business unit, but their methodology is being defined in a different way, the data is disparate and inconsistent. And what you have is that you’re not able to size things across the entire portfolio effectively. So that really is the goal, is normalizing the way things are calculated across the entire portfolio so we can get to a point to compare apples to apples.

Ana Andrade: I hope that answers. Thank you, Maria.

Maria Van Wambeke: Okay, so you’re welcome. So the next slide is just showing the implementation. Anna, next slide, pretty please. Thanks. All right, so this is a metrics inventory implementation that I put together. And there are a few things that I wanted to show. This, again, can be very rough cut done in Excel or any other spreadsheet. And this is one inventory example of how I would approach running inventory analysis for metrics, or what are the metrics and data points that a PM leverages and accesses, again, a day in the life to make informed decisions. So you’ll see the table headings are incredibly important because there’s some things we’re calling out. What is the source of the data? What is the entity? How it’s calculated? How often it’s calculated and how reliable it is? Again, when we run these inventory, the key is what we want to get to is what will be the data point that we end up selecting to be used as a universal data set for a PM. So another thing I wanted to call out is you’ll look at time on task. And I purposefully duplicated this because in my experience, as you talk to PMs and you’re running inventory, you’ll see that PMs will be using the exact same measurement, time on track, from five different sources.

So that, again, does not normalize or create a reliable universal data set. So this is a prime example of why we want to run inventory. Not only what are people doing, what are people using, but where are there disparities in data and where might we throw a PM off track? So this is a good example of that. And again, you’ll have this in the PowerPoint. And I also have versions of these things in Excel if you guys want a quick template to start off. So next slide, please, Ana.

Prioritization & Quick Wins (Continued)

Maria Van Wambeke: Next slide, thanks. Alright, so now that you’ve identified a healthy number of initiatives for your product ops backlog, it’s time to develop your own weighted prioritization framework. Again, tying always back to what matters most to the organization. You should have gained some deep insight into these areas during your learning tour, and also in studying vision and strategy documentation, whatever you could get your hands on, right? And if you’re hesitant or lack confidence in deciding on these variables, or you want just really reinforcement that your selection is accurate, you can re-engage your roster. This is the list of people that you spoke to in stages one and two. This is also a great way to re-engage this group to continue to build that political capital and to begin building your alliance in cross-functional team. So now to dive into how you’re going to build the framework. It’s broken into two key measurement areas, and they align with the action priority matrix.

Maria Van Wambeke: The action priority matrix, that’s just a fancy name for that quick wins chart that was on the previous slide. So what we want to do is generate an aggregate score for impact, which is on the left, and then one for effort, which is on the right. And again, this ties back to that action priority matrix. High impact, low effort equals quick win. This is what we want to identify, and this is what we want to work on first. So to design the framework, you should have a pretty strong understanding of what matters most to the organization. Areas that I’ve measured in the past are customer, and again, these are all based on impact. Customer impact, financial impact, competitive, strategic alignment, market. And again, market usually applies to first mover, second mover, speed to market, time to market, if there’s expediency that’s tied to it or needed. And then also competitive.

So under effort, the simplest measurement is time, right? So this would be resource, capacity, velocity. But I also like to add complexity, and this addresses technical feasibility. Technical feasibility is your engineering team, if you need assistance from them. Is there friction in them developing something for your needs? Is it a technology that’s used before? Is it a tool that’s already in use? What is the learning curve?

Those all apply to, again, the complexity. So once your impact and effort variables are identified, you’re going to determine a scale. I use a 10-point scale for more granularity, but you can also use a 5-point scale with 10 and 5 having the most impact. So now you’ve got these things laid out. You’re going to create a spreadsheet or use whatever method you want to build this out. You’re going to add these variables as column headers across the top. And Smartsheet, Google Sheets, Excel, they all work. And then you’re going to add each of your initiatives to the sheet and begin assigning scores.

So just to dive into a little bit of detail so this is clear. So you build a spreadsheet with each of these variables as your column headers. And then you’re going to have the first column, of course, for the initiatives that you created in Step 2.

So I have an example spreadsheet with all of these details that we can show in a couple of slides.

And just to demystify this. So before we do that, slide 16, please. We want to assess. And again, this goes back to one of the questions about T-shirt sizing. This is T-shirt sizing for us in product ops and not necessarily for the engineering team. But in order for us to assess the time component, again, for our effort that’s going to feed into this template, I like to use T-shirt sizing since it’s simple and easy to understand. But it’s really important that you define methodology for sizing before diving in. You want to always normalize your output. So first you need to decide on the sizes you’ll use. If you have a lot of initiatives, it’s better to be more granular. Next, you’ll decide on what each size represents in terms of time. Does a numeric value equal a calendar week or a sprint or a release? You’ll have to define that. And then since it’s the product ops backlog, I suggest that you are the person that sizes initiatives. And then if you want to phone a friend, you can always talk to somebody that’s on your roster to help define things if you aren’t sure how to size.

Conclusion

Maria Van Wambeke: So now that you’ve understood and built your methodology for sizing, you’re going to assign the weights for effort and add them for each of your initiatives to your sheet. Effort is made up of time from the T-shirt sizing value and then complexity, which again, it’s subjective, but it’s that assessment of technical feasibility. If you find that that is difficult to obtain, you can simplify your T-shirt sizing or simplify and just use T-shirt sizing and reduce your matrix for effort equals time.

Maria Van Wambeke: And if you need me to clarify that, let me know. But just to reiterate, you can always simplify and omit trying to gather a score for complexity. So let’s go to the next slide and see how we’ve pulled all of this stuff together. All right. So you can see this is pretty small, but this is a spreadsheet that I put together and I’ve added the weight for all the variables into the framework. And I have added the initiatives. I have across the top, you can see each of my column headers are directly tying back to the framework. I have a 10-point score that I use for all variables except for time, which equals the T-shirt sizing. And you’ll see the end result is I have a total score for impact. And again, what we’re trying to identify is highest impact, lowest effort equals quick win. And you can see that we’ve actually been able to chart that on the X and Y axis with impact and effort to identify the quick wins.

Maria Van Wambeke: So unfortunately, Google Sheets isn’t able to build out this sort of charting, but Excel is. And it’s just a quick and easy way to pull together and see a visual. If not, you can sort and do a visual by impact and effort to identify. But this is actually a sheet that I’m happy to share with you that I have in Google Sheets. So now that we’ve added the weight for all the variables, you can see that you’ve got your quick wins.

Maria Van Wambeke: And again, the goal is that you want to make an impact as expeditiously as possible to show your value. You can always iterate once your MVP is out.

Maria Van Wambeke: Next slide, thanks. So I wanted, again, this is, you know, doing a lot of quick work in Excel or Google Sheets. But on the next slide, I wanted to show you an example of the framework in Dragonboat. All right. So here’s an example of the framework in action. And I implemented it in Dragonboat, again, to create that single source of truth, which is essential for building standard operating procedures for a day in the life of PM. This really helps to encourage adoption, right? Having that ease of use and low friction.

Maria Van Wambeke: So finally, I know this is a lot of content. Next slide, please, Anna. I wanted to put myself back in your shoes and answer the poll myself about, you know, what I wish I had known being a bit retrospective. And two things come to mind. And the first is to take the time and energy to build political capital before implementing changes. And I think I’ve given some good guidance on how to approach that. But what I’ve witnessed in my own career is that the level of collaboration and buy-in has a direct correlation to the success of rolling out a new process. Change is really hard. And change is even harder without others being invested in the success. So stage one of the first 90 days is really about gaining that success and a graceful approach into introducing change so that you bring people along on your journey.

Maria Van Wambeke: The second is processes do not need to be heavy and account for every use case. It’s better to roll out incremental changes and practice continuous improvement and adapt processes and systems to the people that actually use them most. I am a very operational thinker.

Maria Van Wambeke: So I tend to, if I over-engineer a process and try to roll it out, I found that that really reduces the adoption. So this was a learning insight for me throughout my career. So you can use experiential metrics and user data to make incremental improvements that are actually based on user behavior instead of our assumptions about how things should work. So now, you know, in my day in the life and my role, I remind myself to always view change through the lens of making a day in the life better. Again, for the product team or one of the auxiliary team members. And I really can rarely, rarely go astray. So I know a lot of me, a lot of content. I hope that it was clear in being described. If anything was unclear, let’s go ahead, kick off some Q&A and dive into the nitty-gritty. I’m super excited to hear from all of you.

Audience Q&A

Ana Andrade: Thank you, Maria. This is really helpful and insightful. And we really have some questions to answer. But before we dive in the Q&A, I just want to share some helpful resources from our sponsor. So you don’t worry that Alisa is going to share those links in the chat for you. So we have the product ops playbook. If you have not your copy yet, you should definitely download it and get certified in responsive BPM framework. And last but not least, you can sign up for the upcoming webinar around how to choose the right road mapping tool for your product team. All right. So let’s go to the audience Q&A and I will stop sharing so we can have more engagement. So let’s see through the chat. What do we have here? Okay, so we have one question from Siv. Are you online? Do you want to put your mic on and ask your question directly?

Siv: Sure. Hi. Yeah. Hi. It rhymes with five. And yeah, I guess my question is pretty simple, I think. So when you talked about this prioritization framework, right? When you need to score, like the impact, right? And the effort. So the question is, do you prioritize? Do you put those scores individually as product ops manager? Or do you kind of have, or do you, is it like collective effort, right? So when different people, they put scores and then you just average those scores? So basically, that’s the first question I have.

Maria Van Wambeke: Okay, so super good question. And it, like, made me remember, I forgot to say something. So to answer the first question is, what I did was I introduced a framework, right? There’s a prioritization framework that you are building for yourself as the product ops guru. You’re going to leverage that to prioritize your own backlog. Like so much of what we do in product ops is acting as a product manager, right, for the team. So if that’s the case, you can definitely score your own initiatives. But one thing that is really valuable is you can take that. So again, that would be your input, you own it. But if you need to, again, I said phone a friend, ask for some feedback and collaborate a little on the metrics. That’s fine. But that is your backlog. What you could also do is you can leverage that same framework that you’ve built. And you can iterate on it, right? Once you try it out, and you realize that the methodology is actually sound, you can apply that framework to your actual product portfolio, and begin using it to weight things and prioritize things. In that case, you would, of course, want to bring others in because there’s, you know, technical impact, design impact, you generally would size things among your cohort or among that team. So that’s a really good question. And also, thank you for reminding me to call out that you can leverage these frameworks that you’ve built for your teams, not just for yourself.

Siv: Thank you. I have another one. But yeah, if I may. So the second question I have is, so kind of your opinion or your proposal, how to navigate or how to address a situation when the leadership, right, your direct manager, they imply you to do certain things, so certain changes or, you know, certain processes to build certain processes, the way they see it. But on the other hand, you have the feedback and pain points from product managers, right? You surveyed, you talked to, and they have different pain points, and they have different needs, right? So basically, how do you, and often, right, those things, they conflict. Yeah. Right. So how do you basically navigate between those or in this situation?

Maria Van Wambeke: I love this. It reminds me of a behavioral question, like for interviewing, how do you deal with conflict in your organization? So I use data. And again, proving value, but I ask permission, like through some like diplomacy, right? And let me give you an example. So I, you know, say my boss says, you’re going to use software development lifecycle, they already use it hands down. And you say, well, actually, I have a much better experience using agile, right? And so you ask your boss, or you ask whomever you’re reporting to, wherever this conflict is, can I get 30 minutes of your time to show you the value, right, of what this solution will provide? And you can either do it in an email, whatever the medium is that this individual, again, you want to respect their time. But you ask permission, you can give them a presentation, show them the value, prove the value. Another way that I’ve approached this is pilot programs, which have been really impactful, again, asking for permission and saying, look, I don’t want to overhaul everything until I’m able to show you the evidence of what I’m suggesting. Can I take teams A and B, and run agile with them and run a pilot surface the findings and give you enough data to make again, an informed decision. You can’t fault leadership for pushing back if you’re not showing evidence of a better future. So your job is to show that evidence. So there’s a comfort and a calculated risk, and a data informed decision that they can make. So those are approaches that I have used.

Siv: Awesome. Thank you. Thank you. Really helpful.

Ana Andrade: All right, so I think we are almost on time. Maybe we will put the other questions in our Slack, and probably you can answer them there, Maria. That’s okay for you?

Maria Van Wambeke: Yeah, I probably have time for one. You want one more?

Ana Andrade: Yeah. Okay, so let’s check. So C Waddle asked about what would you look at for financial when you were talking about your prioritization framework?

Maria Van Wambeke: Yeah, so again, you can define your matrix in terms of impact, but for financial there for me was ROI. Margins, ROI, profitability. So again, an example would be if I had plotted an initiative that 12 customers have asked for, that’s going to have a high financial impact and a high ROI. Whereas if I have an initiative, right, that is simply for internal tech debt, that will likely have a low financial impact.

Ana Andrade: Okay, so thank you. Thank you, Maria. And thank you all for joining us today. This was fantastic. Amazing conversation and so engaging. So I will just want to share one last slide. I know that we are on time, but I will share your screen. So someone was asking if Dragonboat can do some of the spreadsheets that you mentioned before. So if you are ready to see Dragonboat in action, join the next group demo on Feb 29. You can scan this QR code to save your spot. And if you are not on yours yet, please join us up on board and keep the conversation ongoing there. So I think that’s all for now. Thank you all for joining. Thank you, Maria. Thank you so much. This was really helpful. And I hope to see you all next time. Take care. Thank you. Bye bye.

Maria Van Wambeke: See you next time.

Reference

• Dragonboat: https://dragonboat.io
• Google HEART Framework: https://uxdesign.cc/googles-heart-framework-choosing-the-right-metrics-for-your-product-112bd7300d55 
• Product OKR: https://quantive.com/resources/articles/product-management-okrs 
• Product Ops HQ: https://responsiveppm.org/product-ops-hq/
• Maria Van Wambeke: https://www.linkedin.com/in/mariavanwambeke/
• Ana Andrade: https://www.linkedin.com/in/ana-raquel-andrade/