 Hey everyone, my name is Jack Shabir and today I'll be walking you through a brief overview of what is Discovery and Solutioning in Product Management. I'll be providing an introduction of myself, what is Discovery, the stages to it, what is Solutioning and the stages to Solutioning, writing up a feature and best practices for it, setting your team for success, and then finally, reference and closing. For me, the love of product development started as early as playing my first video game as a child. I was drawn to games that focused on building a journey for the player, creating a process that led to a final goal or major milestone. This love tagged along with me throughout my professional career and allowed me to build products for amazing companies like the Economist, FreshDirect, and today American Express. My goal for this presentation is to discuss two specific starting points of product development that does not get talked about enough, Discovery for the product and Solutioning based off of that Discovery. What is Discovery? Product Discovery is understanding and investigating what your users slash clients problems are and more importantly, what specific needs do they have that are not being met by the current product? What is uncovered during Discovery then gets validated by bringing those same pain points and needs to a Solution that can be executed for development and launch. Product Discovery plays an important role in assisting product teams to decide what capabilities, features to prioritize and to build. Here are some stages to Discovery. Stage one is uncover and understand, use your metrics, competitive analysis, and then stage two is interpret and align. With uncover and understand, the first step of this is to focus on user research. There are plenty of ways to explore and uncover pain points, but the one method I personally find helpful is just speaking directly to your customers. Customer interviews are the best way to understand what is currently happening in the landscape. What are your customers facing with the product or service that are creating challenges and pain points for them? A great way to do this or to expand on this is to identify champions within your customer base. Champions help you organize and collect key insights into the current landscape of your product and allows you to understand those challenges a little bit more in depth. Champions are individuals who have either used your product extensively or daily or have gathered enough insight and information by working or managing with other users who have provided pros and cons of the product. Champions can provide key insights and gaps within the product, which can help you and also utilize in the aid to finding a suitable solution down the line when Discovery evolves into the solutioning. Use your metrics. By delving into data, you can validate what your customers are saying about their pain points and challenges. Data analysis can help draw some conclusions about your customer and user experience. Key points to note here. Data analysis is only helpful if the data is coming directly from your product or is being accurately aggregated by third party tool. Additionally, you must be mindful with the data you're pulling to verify the pain points you're uncovering with your interviews. Be sure to identify if the data is actually geared to focus on those pain points. Is the data showing something differently? What are the discrepancies and where are you seeing them? Finally, in stage one, we have competitor analysis. Are there current solutions in the market that are addressing similar or exact pain points that your customers are facing? What are your competitors implementing to solve the same or fairly similar issues that your customers are facing? Could we implement the same solution? Can we do better? Would those solutions fit within our technological framework? What additional changes would we have to explore from a regulatory or risk standpoint to make those changes fit in our development and our product? Now, we come into stage two, where we are interpreting and aligning our findings of stage one. Once you have been able to gather this information from stage one, you have to now sift through all that information and start aggregating it to making it align with your partners and stakeholders. Diving a little deeper, your customers will provide you new ones insights on specific functionalities of the product and or service. But none of those insights will give you the key to the best solution. This is where your design team comes into play. Your design team will help you sift through the information to begin the process of creating A, documentation, B, process mapping, which you will utilize with your internal stakeholders and partners to start driving alignment on what direction should that solution head into and what to prioritize based off of that direction. Now we fall into solutioning. Solutioning is where the process of identifying problems and cultivating a product to build that will solve those problems. Product Solutioning is required to ensure two critical objectives, increase the chances of success of developing a product that will resolve the problem we are trying to overcome and create maximum value and impact in the shortest amount of time. Solutioning also ensures that internal teams do not build duplicate products or build products that will create no positive impact or unfortunately fail to resolve the problems the product was initially created for. Stages of Solutioning, we have stage three, which is ideate and prioritize, as well as prototype and align. And then finally, stage four, feature creation and development. For ideate and prioritize, when you've gone through stages one and two of discovery and have defined and decided which problem or challenge to prioritize and solve, the next phase falls into Solutioning, which is ideate and prioritize. A part of this is brainstorming, which is an age old tool to get your team's creative juices flowing. A couple of great ways to start that process is starting with the five whys. The concept of the five whys is to take a top level problem and repeatedly dig into it until you arrive at the root cause of the issue and or challenge. An example of this would be why do our sales reps need to re-input all the information that they get from their CRM into our digital application? Why can our sales reps get that information directly pulled via API? Why haven't we prioritized this type of connection in our roadmap sooner? Why are we only now being aware of this problem that our sales reps have to manually input this information? Additional other ways that you can start to get your team thinking a little bit more bigger on what to solution and how to solution it would be to ask some of these other questions. What would you build if you had infinite time and resources to solve this issue? What if we only had one week to solve this issue? Uh-oh, crunch time. What if our product existed only on mobile and not on desktop? Or what would happen if we built the worst possible solution? What would it look like? These are some really, really great questions to start getting your team to think, not just outside the box, but also seeing it from the user's perspective. Once we're completed with ID and prioritized, we now fall into prototyping and align. This stage is to build a prototype that will validate the solution you and your team have created to best solve the issue. In this stage, a simple low-finality sketch could work perfectly and provide a base for your team to easily tweak, iterate, or scrap if needed based on evolving customer feedback. This is where you get to really hone in with your stakeholders and partners to align on if the solution makes sense for not just your customers, but also for your internal teams and anyone that's going to be impacted. This is where you get to start to show what will be MVP, the fast followers to MVP, and then essentially the next phases of the product as you continue down your voila, you guessed it, your roadmap. Now we get into feature creation and development. Once you've achieved alignment on the prototype and the MVP of that product and what the fast followers will be, it's time to work with your team to break down the work into features, which will then get broken down into user stories, and then finally into tasks that your developers can now take up, creating a feature. Now there are many ways to do this, and there are many tools to utilize while doing this. You've got JIRA, you've got Airtable, you've got Mondays, but here are some tips that I would like to add to building a feature. Have a clear title. What exactly is your feature targeting? Provide a description on what you're going to do. What is the purpose of the feature? Providing a problem statement, providing a solution to that problem, and then finally writing out the acceptance criteria on what will render this particular feature a success, setting up your dev team for success. It's extremely important to build relationships. As a product manager, most of your time will be spent working alongside your dev team that will build the product you're gathering business and technical requirements for. Without your development team, nothing gets built, which means no solution is provided to the pain points of your customer. Your relationship with your developers, scrum masters, and other various team members is vital to building a successful product and having a successful launch. Listen to technical advice. Know your strengths and know when you need to listen. Chances are that though your business requirements are rock solid, the actual implementation from a technical sense might be a little bit more complicated than anticipated. Let your dev team provide you confirmations if something can be built and or connected. Or if there is a step you've missed because of another component or another technical hurdle that you just did not anticipate. Let your dev team provide timelines. It is vital to let your dev team provide you estimates on how long a feature and or tasks of that feature will take to develop and be pushed to environments that can be tested by you and your partners. If the feature is too big for the dev team to complete in a certain period of time, consider breaking up that feature even further to provide the highest chance of success the work will be completed. Communicate progress. Communicate what your dev team is accomplishing to your leadership and stakeholders. You are the voice of development when it comes to relaying progress back to your leadership. Be honest and clear about the work that is committed. The roadblocks, the solutions to those roadblocks and any other risks or impediments that may come in the way of development. Additionally, celebrate your dev team when they have completed a major milestone. This goes back to the first bullet point of relationship building. Give credit to where credit is due. In closing, each company has its own way of training its product managers on how to manage and develop products. This process is something that I have cultivated over various product roles and working with both onshore and offshore dev teams. It is vital to take what resonates in this presentation and use it in a way that sets you and your team up for success. If any of you would like to learn more about my process or would like to just chat, please do not hesitate to reach out. My LinkedIn and my email are provided here. Thank you for being a part of this presentation. I really hope you enjoyed it and can't wait to hear your feedback. Thanks.