 Welcome, everyone, to today's product school webinar, How to Prioritize Your Product. For me, prioritization is a product manager's and a product owner's primary responsibility. Making decisions regarding the sequence in which to develop and implement features is one of the main keys to a product success. Feature prioritization is the ongoing process of deciding what should be built and when that maximizes value with limited time and resources. I'm Marie Uyesho, a product manager at American Express for credit risk and fraud capabilities and have over 10 years of experience in the financial services industry. I've been a safe Agile practitioner for four years and previously been doing business and data analysis and also management consulting. At American Express, we practice Agile Framework Code Safe. It is short for Scaled Agile Framework. This framework is a customer-centric approach to define, build, and ensure there is a continuous release of products and services for our customers. Majority of my Agile experience are on managing large enterprise solution portfolios. However, I believe core fundamental activities like feature prioritization applies to all business sizes. Our agenda for today will focus on three topics. Defining your MVP, distinguishing reality versus perception, and tech debt. When is it worth it? There are numerous techniques in approaching feature prioritization like wishchef, Moscow, Rice, and Canon model. This webinar is not a deep dive on these approaches, but rather taking different aspects of these techniques and using them in a more practical and agile manner. Defining your MVP, the minimum viable product. This allows the team to collect the maximum returns with the least amount of effort, with a functioning, releasable, and more importantly, a usable product. Ask yourself and your stakeholders these questions that are often overlooked. Is there a market need for it? What is truly minimum? Is this the right solution? There is a market need for it when designing a product. You must know your customer. We have heard this term before and I'd like to stress the importance of it. Do your due diligence and analysis. Identify and study your market, industry, target segment, and customer needs. It is not enough to make assumptions and just use in-house data and studies. Actually take the courage to go beyond your circle and seek out external inputs and, if possible, actually talk to your customers. Engage with them directly to understand them better. I myself took the initiative and made extra steps to learn about people spending habits by getting a retail job as a cashier outside of American Express. I got the opportunity to observe and inquire about customers' credit card use and also got the experience firsthand in selling the store's private label credit card. I've also had the opportunity to sit down with Amix's servicing teams and actually listen to customer calls. So these direct invaluable feedback gave me further insight in knowing my customer that I've definitely applied in defining my product. Ultimately, prioritize features that build the product that has a market use for it. If no one buys or uses it, then what is the point and purpose of your product? What is truly minimum? For all of my features, I typically calculate the wish shift, which means wait at shortest job first and assign a Moscow prioritization category of must-have, should-have, could-have, and more-have. Wish shift is calculated by adding user business value, time criticality, and written reduction or opportunity enablement, which will be the feature's cost of delay and then divide that by job size or job duration. Please reference scaled-agile-framework.com if you'd like to learn more about how to calculate your feature's wish shift. Both activities make up my first task of prioritization. Next step is to ensure that the prioritized features are actually building towards an achievable working product within a given program increment. Consider breaking down a feature scope into smaller increments and have several points of next so that there is a product that can be quickly delivered to market instead of building a complex, large, almost unattainable point of arrival as your first release, because this will take more time, thus delaying any market launches, which means delay in introducing your product to your customers, which will definitely drive up your cost of delay. So, to illustrate my point, here is an example of product features broken down into increments for a new mobile game. I have four features listed. Storyline, Gameplay, Graphics, and Sound Effects. For the first increment, you can see that the prioritized features are covering basic or minimal functionality, but it will still deliver a working product that can be released. As the increments progresses, more and more improvements to the features are undertaken. Its customer will be continuously engaged and they are experiencing more of what your product is about several times throughout a given period. Defining the MVP actually decreases costs and brings maximum added value at the end of each increment. Is this the right solution? All initiatives will have limited time and resources, regardless the size of your company or your team. This is an absolute given. Assess a feature and see if there are alternative solutions that will not eat into these resources, which will allow you to prioritize more, thus maximizing your returns. The correct solution might not always involve new technology builds or enhancements. And in my experience, I have found solutions that are already in place in production that was built by another team that I was simply unaware of. But these existing products can be leveraged by my product. They might require some configuration or retrofitting, but the fact is it already exists. And in itself is a huge win. And definitely will be a cost saver and a time saver. Looking to a solution that might also be either procedural or operational changes, or maybe simply reinforcing user training, especially when you're dealing with products or is for customer servicing. What is seen as an issue might actually just be an opportunity to refresh user memos or mammals. Another possibility to explore is cross-sell opportunities. Can you offer alternative products that already exist? That's something that is already built. That is already in your arsenal. Offer these features to your customers and see if it works for them. And without using another product existing core function by creating more customized features on it it could become more and more problematic in the long run because they will be difficult to maintain. And thus, being more causing more to be usable and viable. Next is reality versus perception. When determining a feature's value or the opportunity it enables, data analysis is an absolute must. As it exposes the reality as opposed to just perceived perception. Opinions are pitfalls in prioritizing features that will prevent you to deliver the most customer value. Data has become assault after commodity. It is in fact the oil of the new digital age. Used correctly, data exposes the need of your customer base supporting the notion of knowing your customer. Data has become so important over the past few years that five of the most valuable listed companies in the world are in the business of selling data. It has to be quantifiable. Beware of the HIPAA effect. Know your velocity and dependencies. Value has to be quantifiable. Your feature value has to be quantifiable. Data is an accurate measure of features valuable of features value value. It will provide the true cost of opportunity to market need and trends and the true cost of delay. It improves decision making significantly and helps strengthen your prioritization decisions to deliver a true relevant product. You would want to always be supported by data. Be alert in spotting the HIPAA effect. HIPAA means highest paid person's opinion. And in this case, this might be your boss or your business stakeholders or even a given client or even a client or customer. As a product manager or product owner, it is my responsibility to challenge their opinions. Respectfully challenge them though. I am fortunate enough to work for a company that encourages to speak up and that my expertise and knowledge are respected. I do ask the HIPAAs to refer back to the data, to tangible data and help them recognize the opinions might not be the best financial or customer choice. Although sometimes the loudest voice might persist, show them how their feature fax against others and go back to the data. Opinions are subjective, so don't allow them to be presented as fax. Always go by the numbers. If they had success in the past, that does not mean another success is guaranteed. I take ownership of my features and have the in-depth knowledge that someone in leadership might not have. So I see it as my responsibility to share it. But I recognize that some people do have very strong and good business instincts. However, don't rely on that alone. In fact, data analytics would support those intuitions and minimize the potential risk that a wrong decision might cause. Consider your Scrum team's velocity and dependencies. Velocity is a measure of the speed at which an agile Scrum team completes work items. These measurements are calculated by counting the units of work completed within a sprint. Estimate the job duration based on upon how quickly they've completed work in the past. Because this determines how far to push specific features and position them to be achievable by the end of the sprint. So be realistic, and if necessary, replant the feature increments to maximize the value delivered based on velocity. We definitely would like to assume everything will go right, but that is simply not the case, and definitely not reality. Always add in contingencies when prioritizing work. I engage at least 15 different Scrum teams during prioritization or a given PI. And I definitely take into account each team's velocity and performances in the past. And add in contingencies accordingly. I know when to push for stretch goals and what not to. So identify features with dependencies on other teams. So although agile assumes the team has everything it needs to deliver an increment of work, that is simply not the case or not the reality. Definitely not my reality working as a PM over the years. Prioritize features based on these dependencies and when it will be resolved. Since your Scrum team cannot start their work to start building or deploying any new features, if these dependencies remain unresolved open, because your Scrum team's work will definitely be disrupted. So remember part of prioritization is managing the flow of work. Thus, I ensure that there is continuous flow to make the best use of the team's time and eliminate any idle time. Third on our agenda is tech debt. When is it worth it? Should you move these features to your team's backlog? Technical debt represents the extra development work that stems from features or code built to expedite the delivery of a piece of functionality or a project which later needs to be refactored or possibly rebuilt. So you would like to assess first if speed over write code is the gain greater than the cost? Are there hard exceptions? You might have what we call low-hanging fruit features that will be a quick win for your customers. However, these short-term wins must still fit overall product strategy that is incurring tech debt or any tech debt. Prioritized features that is not focused solely on creating more and more features for any given demo because the number of features in a demo does not equate to number of value provided to the customer. So again, you would want to focus on customer value. Note this simple formula. Tech debt, is it less than your opportunity gains, customer retention gains, or possibly averted fines? Is the debt returns greater than if you had remained debt-free? For example, getting your competitor to market in order to capture a larger market share or capture a majority of a market share. But however, a big however, is the cognizance of the cumulative tech debt as this will lead to your product to become unsustainable in the long run and that's causing more cost to maintain and might cost you to either decommission your product or rebuild it entirely new from scratch. So at American Express, we have exceptions to these tech debt goals. I call them unavoidables. These are the type of features that need to be prioritized immediately regardless of the tech debt incurred. Two examples. First, government regulatory fines and compliance mandates. This is kind of self-explanatory. As a financial company, we are heavily, extremely heavily regulated and monitored since any crisis to our company or to any of our products has direct impact to cause huge economic harm. We also have our own compliance mandates as we do hold ourselves accountable above and beyond what the regulation dictates. Second example is fixes to product bugs that has a huge adverse effect on company's reputation or a product's reputation, which will result in immediate customer loss and huge damage to the brand. For example, what I can think of that falls under this, these exceptions are bone-up crashes, cloud crashes, data security leaks, or hardware blowing up caused by a recent software release. These definitely have huge impact to your brand. Although remember that not all bugs need immediate attention. Ask your stakeholders to set a loss threshold and if that bug exceeds it, when that bug exceeds it, then the feature containing that fix can be prioritized under this exception. In summary, I'd like to leave you with these closing points. Seek a minimum viable product that is needed by market and your customers. Prioritize based on reality that is grounded by data and contributes to an overall product strategy. Minimize tech debt by prioritizing features that build a viable, feasible, and sustainable product. Give more weight to features that bring efficiency and effectiveness. Make the most of your resources to collect the maximum return and continuously bring value to your customers. And remember, you are the product manager or the product owner. We are responsible for what gets built. However, remember to also remain flexible to reprioritize. One of the things that this pandemic has definitely taught us is that market and customer needs can change and turn on a dime. We have to remain adoptable, accept change, and more importantly, respond to it. For lack of a better term, be agile. And with that, I'd like to close this webinar by thanking everyone who attended. And also, I would also like to thank the product school for inviting me to speak on this topic, how to prioritize your product. And if you have any questions, please feel free to reach out to me on LinkedIn. Thank you again and have a nice day.