ManageXR

managexr

What Do Product Managers Do? I get this question several times. From aspiring Product Managers, professionals who want to make a move to product management, students, friends, and even my mom (as she struggles to explain to others what her daughter does). As glorified as it may sound, and as most definitions would describe a Product Manager as being the ‘CEO of the product!’, I think it is the most misunderstood interpretation of the level of direct authority this role possesses. Of course, as a PM, you get to shape the product vision and strategy to drive it toward success, but as they say, it takes a village, and as I like to put it, a product manager is like a shepherd, who will drive the herd toward taking products to greener pastures. And although the role varies in different organizations, In simple terms, A product manager helps develop product strategy, partners with executives/stakeholders on how to deliver and take it to market and manages people/resources to execute on that vision. I can understand why it has taken so long for people to get familiar with this new role, as the title ‘Product Manager’ did not exist until perhaps a decade ago. It is basically a ‘jack of all trades’ kind of a role, which varies according to the company size, the user audience, the industry, and the stage at which the product is in its lifecycle. More than the roles and responsibilities, I would like to elaborate on some of the core competencies that a PM possesses and skills he or she applies, in their day-to-day jobs. Core Competencies for a PM These are the skills that differentiate a good PM from a stellar PM: Ability to Define a Vision: Any product starts with setting a vision, that is in line with the overall vision for the company. A mission statement about what you want your product to be. A product manager sets the direction for where the product is going and what it will deliver in the future. For example, Google’s vision is “to organize the world’s information and make it universally accessible and useful.” Slack’s product vision is “transforming work, building better communication, and creating greater transparency.” This is not simply a tagline or a marketing statement; it is a culture that every person working at these companies abides by. Setting a strategic vision requires a solid understanding of the business, the company goals, and the customer’s needs. Understanding Product-Market Fit: This is one of the most critical pieces in terms of knowledge areas for a PM, as it involves understanding the market, defining the problem statement, and then building a product that solves this problem. ‘Achieving product-market fit’ from the beginning and iterating on it throughout the product development process is key to being a successful product manager. Business Modeling: While the vision tells you why the product should be made, the business case tells you how the product will create value, monetize on that value, and be a sustainable growing business. For this, a PM sets short-term and long-term goals, defines the growth path, and the revenue streams, and identifies the resources to achieve the product vision. I like Alex Osterwalder’s Business Model Canvas as a template to put together some of these details. Experimentation and Hypothesis Testing: You must have heard of taking a ‘data-driven approach’ to making decisions. Well, there is no dearth today of tools and mechanisms for product managers to gather data and feedback. The main issue is to sift through this data and identify the metrics that really matter. One of the skills of a PM is to frame a hypothesis for a particular observation, run experiments to test the hypothesis, and then effectively measure the outcome by deriving KPIs that objectively validate the assumptions and will eventually help drive decisions. Taking the example of Slack in their early days, they were trying to prove its utility to users. One of the hypotheses was ‘eliminating the use of email’. The team started asking prospective clients to spend an entire day without email, only using Slack for all communications. The experiment was a success and the Slack team was able to demonstrate how effective the tool was in breaking people away from their email and enabling productivity. Prioritization Ask any PM what is that one competency that he or she is forever trying to master, and the answer most often will be prioritization skills! You have a great set of ideas and requests gathered from users, sales, product support, developers, etc. Evaluating these against the right set of criteria to know what to work on first, is according to me the most important skill that needs to be developed and honed over time. There are many prioritization frameworks and techniques, including the RICE method, ICE scoring, and the KANO method, to name a few. As a good prioritization example, Slack focused on a few things that were most important to their product vision: Search: The team knew that users needed to not worry about labeling and storing documents and had to focus their roadmap to build this capability, one that Gmail and Google, had set high standards for. Synchronization: The problem with every other enterprise productivity tool was the need for the user to be able to pick up from where he left off after switching devices. This is what became one of Slack’s biggest differentiators. Simple file-sharing: Slack wanted to make it super easy to drag-drop files and paste images which was in line with its focus on building an intuitive UI.
Although these features may seem rudimentary, Slack identified and prioritized these, as an attempt to build something that would be an important change for the audience who were used to cumbersome experiences through other competitive tools. Design Thinking A PM typically works very closely with a product designer to ensure the features presented to the user, serve the functionality in the way they are designed for. In order to design experiences and user interfaces, a PM should have a thorough understanding of the user journey and how users will consume the product capabilities. As a good resource, I found the Lean UX helpful in sharing techniques to incorporate design into agile product development. Metrics and Measurement More often than not, PMs are faced with the challenge of weighing the information assimilated from a variety of sources in order to make product decisions. As you build your hypothesis and begin to test, you will need to understand the opportunities for feedback, what to measure, and how to measure. Being proficient in these metrics measurement methodologies is a core skill to develop as a PM. This includes qualitative testing (e.g., usability testing or session monitoring) or quantitative (traffic analysis or user engagement tracking). There are also other forms of comparative measurement such as A/B testing, multi-variate testing, etc. Sticking to the same example of Slack, when they were tackling their next set of goals, performed a bunch of qualitative interviews with their largest accounts to test the hypothesis that they weren’t serving those larger teams as well as they could. Some of the questions asked were — How do you use Slack? Who uses it within the organization? What do they use it for? What other tools do you use, and how does Slack fit into that? Using the feedback gathered, Slack then made several changes to its feature set for larger teams (e.g., creating a different set of default notifications to avoid ping fatigue) Besides these core skills, there are other personal or as I call them, fundamental proficiencies that truly differentiate a good PM from an expert, seasoned product person. These include leadership, planning, cross-functional collaboration, stakeholder management, and relationship building which are as vital to becoming a successful product manager as the core competencies covered above. What Do Product Managers Do? I get this question several times. From aspiring Product Managers, professionals who want to make a move to product management, students, friends, and even my mom (as she struggles to explain to others what her daughter does). As glorified as it may sound, and as most definitions would describe a Product Manager as being the ‘CEO of the product!’, I think it is the most misunderstood interpretation of the level of direct authority this role possesses. Of course, as a PM, you get to shape the product vision and strategy to drive it toward success, but as they say, it takes a village, and as I like to put it, a product manager is like a shepherd, who will drive the herd toward taking products to greener pastures. And although the role varies in different organizations, In simple terms, A product manager helps develop product strategy, partners with executives/stakeholders on how to deliver and take it to market and manages people/resources to execute on that vision. A product manager helps develop product strategy, partners with executives/stakeholders on how to deliver and take it to market and manages people/resources to execute on that vision. I can understand why it has taken so long for people to get familiar with this new role, as the title ‘Product Manager’ did not exist until perhaps a decade ago. It is basically a ‘jack of all trades’ kind of a role, which varies according to the company size, the user audience, the industry, and the stage at which the product is in its lifecycle. More than the roles and responsibilities, I would like to elaborate on some of the core competencies that a PM possesses and skills he or she applies, in their day-to-day jobs. Core Competencies for a PM These are the skills that differentiate a good PM from a stellar PM: Ability to Define a Vision: Ability to Define a Vision: Any product starts with setting a vision, that is in line with the overall vision for the company. A mission statement about what you want your product to be. A product manager sets the direction for where the product is going and what it will deliver in the future. For example, Google’s vision is “to organize the world’s information and make it universally accessible and useful.” Slack’s product vision is “transforming work, building better communication, and creating greater transparency.” This is not simply a tagline or a marketing statement; it is a culture that every person working at these companies abides by. Setting a strategic vision requires a solid understanding of the business, the company goals, and the customer’s needs. Understanding Product-Market Fit : Understanding Product-Market Fit This is one of the most critical pieces in terms of knowledge areas for a PM, as it involves understanding the market, defining the problem statement, and then building a product that solves this problem. ‘Achieving product-market fit’ from the beginning and iterating on it throughout the product development process is key to being a successful product manager. Business Modeling : Business Modeling While the vision tells you why the product should be made, the business case tells you how the product will create value, monetize on that value, and be a sustainable growing business. For this, a PM sets short-term and long-term goals, defines the growth path, and the revenue streams, and identifies the resources to achieve the product vision. I like Alex Osterwalder’s Business Model Canvas as a template to put together some of these details. Business Model Canvas Experimentation and Hypothesis Testing: Experimentation and Hypothesis Testing: You must have heard of taking a ‘data-driven approach’ to making decisions. Well, there is no dearth today of tools and mechanisms for product managers to gather data and feedback. The main issue is to sift through this data and identify the metrics that really matter. One of the skills of a PM is to frame a hypothesis for a particular observation, run experiments to test the hypothesis, and then effectively measure the outcome by deriving KPIs that objectively validate the assumptions and will eventually help drive decisions. Taking the example of Slack in their early days, they were trying to prove its utility to users. One of the hypotheses was ‘eliminating the use of email’. The team started asking prospective clients to spend an entire day without email, only using Slack for all communications. The experiment was a success and the Slack team was able to demonstrate how effective the tool was in breaking people away from their email and enabling productivity. Prioritization Prioritization Ask any PM what is that one competency that he or she is forever trying to master, and the answer most often will be prioritization skills! You have a great set of ideas and requests gathered from users, sales, product support, developers, etc. Evaluating these against the right set of criteria to know what to work on first, is according to me the most important skill that needs to be developed and honed over time. There are many prioritization frameworks and techniques, including the RICE method , ICE scoring , and the KANO method , to name a few. RICE method ICE scoring KANO method As a good prioritization example, Slack focused on a few things that were most important to their product vision: Search: The team knew that users needed to not worry about labeling and storing documents and had to focus their roadmap to build this capability, one that Gmail and Google, had set high standards for. Search: The team knew that users needed to not worry about labeling and storing documents and had to focus their roadmap to build this capability, one that Gmail and Google, had set high standards for. Search: Synchronization: The problem with every other enterprise productivity tool was the need for the user to be able to pick up from where he left off after switching devices. This is what became one of Slack’s biggest differentiators. Synchronization: The problem with every other enterprise productivity tool was the need for the user to be able to pick up from where he left off after switching devices. This is what became one of Slack’s biggest differentiators. Synchronization: Simple file-sharing: Slack wanted to make it super easy to drag-drop files and paste images which was in line with its focus on building an intuitive UI.
Although these features may seem rudimentary, Slack identified and prioritized these, as an attempt to build something that would be an important change for the audience who were used to cumbersome experiences through other competitive tools. Simple file-sharing: Slack wanted to make it super easy to drag-drop files and paste images which was in line with its focus on building an intuitive UI. Although these features may seem rudimentary, Slack identified and prioritized these, as an attempt to build something that would be an important change for the audience who were used to cumbersome experiences through other competitive tools. Simple file-sharing: Slack wanted to make it super easy to drag-drop files and paste images which was in line with its focus on building an intuitive UI. Simple file-sharing: Although these features may seem rudimentary, Slack identified and prioritized these, as an attempt to build something that would be an important change for the audience who were used to cumbersome experiences through other competitive tools. Design Thinking Design Thinking A PM typically works very closely with a product designer to ensure the features presented to the user, serve the functionality in the way they are designed for. In order to design experiences and user interfaces, a PM should have a thorough understanding of the user journey and how users will consume the product capabilities. As a good resource, I found the Lean UX helpful in sharing techniques to incorporate design into agile product development. Metrics and Measurement Metrics and Measurement More often than not, PMs are faced with the challenge of weighing the information assimilated from a variety of sources in order to make product decisions. As you build your hypothesis and begin to test, you will need to understand the opportunities for feedback, what to measure, and how to measure. Being proficient in these metrics measurement methodologies is a core skill to develop as a PM. This includes qualitative testing (e.g., usability testing or session monitoring) or quantitative (traffic analysis or user engagement tracking). There are also other forms of comparative measurement such as A/B testing, multi-variate testing, etc. Sticking to the same example of Slack, when they were tackling their next set of goals, performed a bunch of qualitative interviews with their largest accounts to test the hypothesis that they weren’t serving those larger teams as well as they could. Some of the questions asked were — How do you use Slack? Who uses it within the organization? What do they use it for? What other tools do you use, and how does Slack fit into that? Using the feedback gathered, Slack then made several changes to its feature set for larger teams (e.g., creating a different set of default notifications to avoid ping fatigue) Besides these core skills, there are other personal or as I call them, fundamental proficiencies that truly differentiate a good PM from an expert, seasoned product person. These include leadership, planning, cross-functional collaboration, stakeholder management, and relationship building which are as vital to becoming a successful product manager as the core competencies covered above.

Demystifying the Role of a Product Manager: Beyond the 'CEO of the Product' Perception

At HackerNoon, we value stories about building groundbreaking tech. These questions aren’t just about AI mechanics—they’re about the innovation, challenges, and creativity of bringing cutting-edge tools to life, a perfect fit for our community of tech leaders, builders, and future-minded readers. Would you like to take a stab at answering some of these questions? The link for the template is HERE. Interested in reading the content from all of our writing prompts? Click HERE. What’s the main problem your AI product is designed to solve, and what is effective about your approach to solving it? What criteria did you use to select the specific AI models for this product, and how does your company make decisions like this? How do you ensure your product delivers accurate and unbiased results to users? What is your day in the life like as a product manager? What’s the next big breakthrough in AI that everyone should be watching for? What’s been the biggest challenge you’ve faced in bringing this AI product to market, from concept to launch? How do you envision AI evolving to better understand and respond to human emotions, and what challenges or opportunities do you see in that area? What performance metrics or KPIs do you track to gauge the success of this AI product? How do you approach designing a product experience that’s not only functional but also engaging and memorable for users? In the long-term, how do you think AI will help the individual reach one’s full potential? Where do you see the product evolving in the next few years, and what features are you most excited to add? What’s your perspective on AI’s impact on jobs, and how do you address those concerns in your product strategy? What user feedback surprised you and led to changes in your roadmap, strategy or product experience? Would you like to take a stab at answering some of these questions? The link for the template is HERE. Interested in reading the content from all of our writing prompts? Click HERE. Learn more about AI on HackerNoon. At HackerNoon, we value stories about building groundbreaking tech. These questions aren’t just about AI mechanics—they’re about the innovation, challenges, and creativity of bringing cutting-edge tools to life, a perfect fit for our community of tech leaders, builders, and future-minded readers. At HackerNoon, we value stories about building groundbreaking tech. These questions aren’t just about AI mechanics—they’re about the innovation, challenges, and creativity of bringing cutting-edge tools to life, a perfect fit for our community of tech leaders, builders, and future-minded readers. Would you like to take a stab at answering some of these questions? The link for the template is HERE. Interested in reading the content from all of our writing prompts? Click HERE. Would you like to take a stab at answering some of these questions? The link for the template is HERE . Interested in reading the content from all of our writing prompts? Click HERE . The link for the template is HERE HERE . HERE HERE . What’s the main problem your AI product is designed to solve, and what is effective about your approach to solving it? What’s the main problem your AI product is designed to solve, and what is effective about your approach to solving it? What criteria did you use to select the specific AI models for this product, and how does your company make decisions like this? What criteria did you use to select the specific AI models for this product, and how does your company make decisions like this? How do you ensure your product delivers accurate and unbiased results to users? How do you ensure your product delivers accurate and unbiased results to users? What is your day in the life like as a product manager? What is your day in the life like as a product manager? What’s the next big breakthrough in AI that everyone should be watching for? What’s the next big breakthrough in AI that everyone should be watching for? What’s been the biggest challenge you’ve faced in bringing this AI product to market, from concept to launch? What’s been the biggest challenge you’ve faced in bringing this AI product to market, from concept to launch? How do you envision AI evolving to better understand and respond to human emotions, and what challenges or opportunities do you see in that area? How do you envision AI evolving to better understand and respond to human emotions, and what challenges or opportunities do you see in that area? What performance metrics or KPIs do you track to gauge the success of this AI product? What performance metrics or KPIs do you track to gauge the success of this AI product? How do you approach designing a product experience that’s not only functional but also engaging and memorable for users? How do you approach designing a product experience that’s not only functional but also engaging and memorable for users? In the long-term, how do you think AI will help the individual reach one’s full potential? In the long-term, how do you think AI will help the individual reach one’s full potential? Where do you see the product evolving in the next few years, and what features are you most excited to add? Where do you see the product evolving in the next few years, and what features are you most excited to add? What’s your perspective on AI’s impact on jobs, and how do you address those concerns in your product strategy? What’s your perspective on AI’s impact on jobs, and how do you address those concerns in your product strategy? What user feedback surprised you and led to changes in your roadmap, strategy or product experience? What user feedback surprised you and led to changes in your roadmap, strategy or product experience? Would you like to take a stab at answering some of these questions? The link for the template is HERE. Interested in reading the content from all of our writing prompts? Click HERE. Would you like to take a stab at answering some of these questions? The link for the template is HERE . Interested in reading the content from all of our writing prompts? Click HERE . The link for the template is HERE HERE . HERE HERE . Learn more about AI on HackerNoon. Learn more about AI on HackerNoon . Learn more about AI on HackerNoon

Baker's Dozen AI: 13 Questions with a Product Manager Who Makes an AI Product 

The HackerNoon Newsletter: The Product Manager’s Decision Making Dilemma (11/7/2024)

The number one challenge a product manager faces is prioritization. You make choices every day. How many times have you heard PMs say “data-driven” when asked about making roadmap decisions? This data-driven approach is easier said than done. More often than usual, the problem is not a dearth of great ideas. Prioritization is all about how to choose ‘what’ to build ‘when’ and ‘why’. Shouldn’t it be as simple as sifting through customer feedback, picking the most innovative and ‘seemingly cool’ ideas and start implementing? What makes this process so difficult? Why is prioritization difficult? Every product has a feedback loop, some more mature than others. Your customers provide you their ‘wish-list’ of features, your sales team has a set of requirements, they wished the product fulfilled in order to make better sales, you engineering team comes up with a list of tasks that are needed to make the product more resilient and your designers have these great ideas for a better, more intuitive UX/UI. It is these branches of feedback loop and the emerging competing opportunities that make it extremely difficult to decide what to build next. You wish you could build anything and everything from the above list, however, capacity in terms of resources (people, time, budget) to deliver is always limited. In addition, once you release a product, you inherently promise incremental predictable value, release after release and being able live up to that promise is extremely important in order to sustain customer trust. What does a PM need to prioritize? Prioritization happens at different levels. On a goals level, one has to prioritize on the metrics, the OKRs (objectives-key-result) and the KPIs (key performance indicators to evaluate and track progress toward the objectives.
At the strategy level, one has to prioritize on the high- level initiatives for the product.
On an architectural level, one has to prioritize on the platform technologies, scalability considerations, interoperability challenges etc.
At the release level, one has to prioritize on the sprints, features, user stories, epics and bugs. At all these levels, prioritization is performed using a combination of data, instinct and a consensus amongst stakeholders, which makes it even harder to define that standard magic formula that can be applied to all prioritization exercises. So how do you approach this? Before we dive into the best model to approach prioritization, there are a few non-prescriptive the techniques that I personally incorporate into my product planning. Product Vision As clichéd as it may sound, everything begins with the product vision. Once you have your product strategy defined, you plan a series of events that need to happen in order to achieve it. This plan is basically a detailed description of what has to happen within the product and what capabilities you hope to build. All prioritization decisions should then reflect that plan and be in constant check with your product vision. Every roadmap review and planning session should track progress toward achieving this vision and what would be the next steps or milestones to get you closer to the vision. In Marie Kondo’s words, When the ultimate goal is “Joy”, constantly ask yourself “Does it spark joy?”. Similarly, everything on the backlog should drive your product strategy forward and hence we need to ask, “Does this support the product strategy?” Customer Mindset Everyone is aware of Amazon’s 14 leadership Principles, the first of which is ‘customer obsession’. “The number one thing that has made us successful by far is obsessive compulsive focus on the customer as opposed to obsession over the competitor” — Bezos Now, I am not saying, what worked for Amazon, will or should work for your product. But keeping the customer at the center of every planning and prioritization exercise is key to ensure you are building things in the right direction. Also, beware as you do this, because customers will always want more, always ask for a new shiny feature the competitive product may have launched, however, it is your job to go beyond this ask into uncovering the actual need to solve a problem. You really need to go deep into revealing the real vs perceived value. What is a required vs a good to have capability? Does developing this new feature or set of features benefit a significant addressable customer segment? Impact What are the drivers for your business objectives and what impact does this feature have on moving the needle on those. Your eventual goal is to be profitable, however, for any company the typical business objectives are one of the following, depending on the stage of the product: New customer acquisition
Increase product engagement
Increase revenue from existing customers (up-sell)
Expand product into other markets/regions/parts of the customer org.
Customer retention In each roadmap planning session (however often you may perform it — quarterly or bi-annually), evaluate how you are doing on each of the above business objectives. Risk As a PM, you are responsible for every aspect of the product, not just shipping features out the door. Awareness of competitors, legal adherences, compliance, technical feasibilities, security, privacy etc. are crucial considerations while prioritization. You need to ask the tough questions, once released, can it be supported and maintained? If it fails, can we handle the consequences?
It is also important to have a common understanding amongst stakeholders of what is non-negotiable. For example, a social media product has to prioritize features that de-risk user privacy over say, working toward a new video chatting feature. A healthcare product has to prioritize efforts that make the product adhere to HIPAA guidelines vs building a new chatbot for customer service. Thus, it is important to incorporate a risk measurement exercise into your roadmap planning process.
In addition, as you think more about the execution phase, identifying dependency risks and mechanism to unblock them should be considered in prioritization and estimation. What techniques can I use to prioritize? There are several frameworks that can be applied to prioritization: The MoSCoW (must, should, could, won’t) method allows you to categorize your list of requirements or ideas into the sets of critical, high-priority, desirable and future. The KANO model, helps to understand the customer’s perspective on product features by assessing their satisfaction by identifying the basic, expected and attractive attributes of the product. The RICE scoring model combines factors of Reach, Impact, Confidence and Efforts. I am a very visual person and what I personally use for prioritizing roadmap initiative is the ‘Story Mapping’ method. This allows me to map features and user stories against ‘time’ and ‘necessity’ and cutting off the list to plan the MVP and subsequent releases. First you lay out the activity buckets (which are major attributes) for your product along the horizontal axis. The vertical axis represents the criticality in terms of how important the user stories are. Groups of user stories qualify as one activity. In order to define releases, you then mark a cut-off horizontal line, selecting stories that have fall into the same criticality level. This visualization technique provides a clear picture of incremental product iterations and provides stakeholders a visual map of an end-to-end product version in each release. Below is an example from Jeff Patton’s User Story Mapping. Of course there are many more frameworks out there, depending on the maturity stage and complexity of the product. No framework is perfect and the best way to create your own secret sauce for prioritization is to adopt, modify, test and test again to ultimately get to what works for you. And lastly, always remember to keep the key principles of product vision, customer mindset, impact and risk measurement as you plan your product roadmap. The number one challenge a product manager faces is prioritization. You make choices every day. How many times have you heard PMs say “data-driven” when asked about making roadmap decisions? This data-driven approach is easier said than done. More often than usual, the problem is not a dearth of great ideas. Prioritization is all about how to choose ‘what’ to build ‘when’ and ‘why’. Prioritization is all about how to choose ‘what’ to build ‘when’ and ‘why’. Shouldn’t it be as simple as sifting through customer feedback, picking the most innovative and ‘seemingly cool’ ideas and start implementing? What makes this process so difficult? Why is prioritization difficult? Why is prioritization difficult? Every product has a feedback loop, some more mature than others. Your customers provide you their ‘wish-list’ of features, your sales team has a set of requirements, they wished the product fulfilled in order to make better sales, you engineering team comes up with a list of tasks that are needed to make the product more resilient and your designers have these great ideas for a better, more intuitive UX/UI. It is these branches of feedback loop and the emerging competing opportunities that make it extremely difficult to decide what to build next. You wish you could build anything and everything from the above list, however, capacity in terms of resources (people, time, budget) to deliver is always limited. In addition, once you release a product, you inherently promise incremental predictable value, release after release and being able live up to that promise is extremely important in order to sustain customer trust. What does a PM need to prioritize? What does a PM need to prioritize? Prioritization happens at different levels. On a goals level, one has to prioritize on the metrics, the OKRs (objectives-key-result) and the KPIs (key performance indicators to evaluate and track progress toward the objectives. At the strategy level, one has to prioritize on the high- level initiatives for the product. On an architectural level, one has to prioritize on the platform technologies, scalability considerations, interoperability challenges etc. At the release level, one has to prioritize on the sprints, features, user stories, epics and bugs. On a goals level, one has to prioritize on the metrics, the OKRs (objectives-key-result) and the KPIs (key performance indicators to evaluate and track progress toward the objectives. OKRs At the strategy level, one has to prioritize on the high- level initiatives for the product. On an architectural level, one has to prioritize on the platform technologies, scalability considerations, interoperability challenges etc. At the release level, one has to prioritize on the sprints, features, user stories, epics and bugs. At all these levels, prioritization is performed using a combination of data, instinct and a consensus amongst stakeholders, which makes it even harder to define that standard magic formula that can be applied to all prioritization exercises. So how do you approach this? So how do you approach this? Before we dive into the best model to approach prioritization, there are a few non-prescriptive the techniques that I personally incorporate into my product planning. Product Vision Product Vision As clichéd as it may sound, everything begins with the product vision. Once you have your product strategy defined, you plan a series of events that need to happen in order to achieve it. This plan is basically a detailed description of what has to happen within the product and what capabilities you hope to build. All prioritization decisions should then reflect that plan and be in constant check with your product vision. Every roadmap review and planning session should track progress toward achieving this vision and what would be the next steps or milestones to get you closer to the vision. In Marie Kondo’s words, When the ultimate goal is “Joy”, constantly ask yourself “Does it spark joy?”. Similarly, everything on the backlog should drive your product strategy forward and hence we need to ask, “Does this support the product strategy?” product strategy Marie Kondo’s Customer Mindset Customer Mindset Everyone is aware of Amazon’s 14 leadership Principles , the first of which is ‘customer obsession’. 14 leadership Principles “The number one thing that has made us successful by far is obsessive compulsive focus on the customer as opposed to obsession over the competitor” — Bezos “The number one thing that has made us successful by far is obsessive compulsive focus on the customer as opposed to obsession over the competitor” — Bezos Now, I am not saying, what worked for Amazon, will or should work for your product. But keeping the customer at the center of every planning and prioritization exercise is key to ensure you are building things in the right direction. Also, beware as you do this, because customers will always want more, always ask for a new shiny feature the competitive product may have launched, however, it is your job to go beyond this ask into uncovering the actual need to solve a problem. You really need to go deep into revealing the real vs perceived value. What is a required vs a good to have capability? Does developing this new feature or set of features benefit a significant addressable customer segment? Impact Impact What are the drivers for your business objectives and what impact does this feature have on moving the needle on those. Your eventual goal is to be profitable, however, for any company the typical business objectives are one of the following, depending on the stage of the product: New customer acquisition Increase product engagement Increase revenue from existing customers (up-sell) Expand product into other markets/regions/parts of the customer org. Customer retention New customer acquisition Increase product engagement Increase revenue from existing customers (up-sell) Expand product into other markets/regions/parts of the customer org. Customer retention In each roadmap planning session (however often you may perform it — quarterly or bi-annually), evaluate how you are doing on each of the above business objectives. Risk Risk As a PM, you are responsible for every aspect of the product, not just shipping features out the door. Awareness of competitors, legal adherences, compliance, technical feasibilities, security, privacy etc. are crucial considerations while prioritization. You need to ask the tough questions, once released, can it be supported and maintained? If it fails, can we handle the consequences? It is also important to have a common understanding amongst stakeholders of what is non-negotiable. For example, a social media product has to prioritize features that de-risk user privacy over say, working toward a new video chatting feature. A healthcare product has to prioritize efforts that make the product adhere to HIPAA guidelines vs building a new chatbot for customer service. Thus, it is important to incorporate a risk measurement exercise into your roadmap planning process. In addition, as you think more about the execution phase, identifying dependency risks and mechanism to unblock them should be considered in prioritization and estimation. Awareness of competitors, legal adherences, compliance, technical feasibilities, security, privacy etc. are crucial considerations while prioritization. You need to ask the tough questions, once released, can it be supported and maintained? If it fails, can we handle the consequences? It is also important to have a common understanding amongst stakeholders of what is non-negotiable. For example, a social media product has to prioritize features that de-risk user privacy over say, working toward a new video chatting feature. A healthcare product has to prioritize efforts that make the product adhere to HIPAA guidelines vs building a new chatbot for customer service. Thus, it is important to incorporate a risk measurement exercise into your roadmap planning process. In addition, as you think more about the execution phase, identifying dependency risks and mechanism to unblock them should be considered in prioritization and estimation. What techniques can I use to prioritize? There are several frameworks that can be applied to prioritization: The MoSCoW (must, should, could, won’t) method allows you to categorize your list of requirements or ideas into the sets of critical, high-priority, desirable and future. MoSCoW The KANO model , helps to understand the customer’s perspective on product features by assessing their satisfaction by identifying the basic, expected and attractive attributes of the product. KANO model The RICE scoring model combines factors of Reach, Impact, Confidence and Efforts. I am a very visual person and what I personally use for prioritizing roadmap initiative is the ‘Story Mapping’ method. This allows me to map features and user stories against ‘time’ and ‘necessity’ and cutting off the list to plan the MVP and subsequent releases. ‘Story Mapping’ First you lay out the activity buckets (which are major attributes) for your product along the horizontal axis. The vertical axis represents the criticality in terms of how important the user stories are. Groups of user stories qualify as one activity. In order to define releases, you then mark a cut-off horizontal line, selecting stories that have fall into the same criticality level. This visualization technique provides a clear picture of incremental product iterations and provides stakeholders a visual map of an end-to-end product version in each release. Below is an example from Jeff Patton’s User Story Mapping . User Story Mapping Of course there are many more frameworks out there, depending on the maturity stage and complexity of the product. No framework is perfect and the best way to create your own secret sauce for prioritization is to adopt, modify, test and test again to ultimately get to what works for you. And lastly, always remember to keep the key principles of product vision, customer mindset, impact and risk measurement as you plan your product roadmap.

The Product Manager’s Decision Making Dilemma

Дылема прыняцця рашэнняў менеджэрам па прадуктах

Dilema rozhodování produktového manažera

Das Entscheidungsdilemma des Produktmanagers

El dilema de la toma de decisiones del gerente de producto

معضل تصمیم گیری مدیر محصول

O dilema da toma de decisións do xestor de produto

Dilema pri donošenju odluka voditelja proizvoda

プロダクトマネージャーの意思決定のジレンマ

Icyemezo cyumuyobozi wibicuruzwa Gufata Dilemma

தயாரிப்பு மேலாளரின் முடிவெடுக்கும் குழப்பம்

Önüm dolandyryjysynyň karary Dilemma

پروڈکٹ مینیجر کا فیصلہ سازی مشکوک

One of the most important tasks of an Engineering Manager is to enable others to do bigger, better things. The usual analogy which often gets used is to think of yourself as a multiplier. Imagine having 5 developers in your team. If all of them do 1 unit of work a day and you do nothing to help them, as a team, you will get 5 units of work done at the end of the day. However if you find a way for them to do their work twice as more efficient, you would become a multiplier to all of your engineers and therefore allowing them to achieve 2 × 5 = 10 units of work. The higher the multiplier you are, the more you’ll be able to achieve with your team. In this article, we will recommend a homegrown method which we have devised (by simply combining various concepts that we have collected along the way) to help one understand the best way to amplify this multiplier. The method consists of 4 steps: See
Observe
Prioritize
Act Let’s look into these components to better understand how it can be applied. See It is important for one to understand where you stand in the grand scheme of things. This helps you in knowing what your sphere of influence is which will help you prioritize which problems to tackle first vs those which require more effort to do so. The exercise is quite simple. It will feel very familiar when you see it although it also has a small twist. In this tree, Dunya is in the center. She has 1 direct report and her peer (Michael) has two direct reports. Both Dunya and Michael report to Allan whom himself manages 3 other engineering managers. Those managers manage many other Individual Contributors (IC). We use a color code to express the degree at which you can exercise influence. Those people to whom you have a single line to are L1. Those people are the ones you can influence the most. Afterall it is easier to talk to your peers for help or your team members than it is to ask the CEO of the company. Those people who are two lines away from you are L2. It is also possible to influence them however it would require more effort to do so. In the above example, Dunya would be able to influence Ivan however that would require more work since there is no way for her to enforce what she would like to see differently. She would have to convince Ivan (using persuasion, data, or similar) to be able to influence him do what she would like. Similarly, those who are three lines away are a L3. L3 is still influenceable however it would require significantly more work than it would take to convince L2. In my humble opinion it is not worth spending a lot of effort on these levels as the return on investment would be lowered significantly. So far, what we have seen is no different than an organizational chart. The only difference is the circle marked project. Quite often, people in companies interact with each other through projects instead of reporting lines. There will be many projects, migrations, crafts, workforces, etc. where people from different teams will be collaborating on. We represent such initiatives using the ellipse (in the above graph) where we connect different members through that bubble. This allows us to see what the sphere of influence of an individual is across teams. In the above example we can see that Bruno is a L2 to Dunya since they cooperate on the same project. So again, we’re just counting the number of lines connecting the two. This way of thinking also helps us understand the effect someone has had on their peers. Think Performance, where someone who has managed to move metrics for their L1, L2 and L3 has apparently had a great impact on a larger sphere. Someone who has only managed to help their L3 might be focused on the wrong things (since they’re actually not helping their own team but rather helping others). And someone who has only affected their L1 might still be a mid level engineer and would have to increase their sphere of influence to have greater impact. Observe Now that we understand where we are positioned in the organization and how are interactions look like, it is time to collect data and try to understand the pain-points that could leverage your expertise. Collect Whenever I join a new company or when I switch teams, I always start by doing 1:1s with everyone in the team (not only engineers) where I ask them a single question: What are the things that annoy you the most or that slow you down? This question allows me to understand the biggest challenges that the team is facing, which for sure is important for me to address as an Engineering Manager. Doing so will help me resolve those issues so that I can multiply my team's output. Once I’ve collected all the issues I put them in a database. There will be many issues which you’ll be hearing again and again from different engineers and that’s OK. Then we add three columns to this database called category, reporter and level. The category column helps us start grouping the issues under logical categories. An issue can fall under multiple categories. Once all issues have been categorized, we can sort the categories based on the number of times we’ve heard issues in that category. The Level column shows us from which level of sphere of influence we have heard this problem from. The reporter column helps us remember who gave us the issue. This gives us a basic understanding of the frequency of issues, and the level which they come from. Understand The next step in Observe is to write down the categories and start doing a Root Cause Analysis (RCA) on each and every one of them. You can use any method to help do the RCA however I would strongly recommend to use something simple such as the 5 Whys. The idea with the 5 Whys is to ask “Why” 5 times (rather as many times as needed to find the root cause) to understand what the root cause of an issue might be. It would be better if you do this exercise with those people from your database. Luckily we kept this in our reporter column. Having done this exercise you should obtain something that resembles this: This map will allow us to see the root causes of some of the issues. Those would be the leaves of the tree which are marked red. It will also sometimes help uncover dependencies across different root causes. Not only will this visualization help us understand the issues, their root causes but it will also help us understand the interactions between the issues. In the above example we can see that the “Excessive Use of Integration or End-to-End Tests” are affecting two different branches of the tree. Meaning that, removing this root cause will remedy quite some symptoms. Prioritize Now that we have understood our sphere of influence and that we’ve collected several root causes, we can get started with picking the problems to work on. In order to do so we will be plotting all of the root cause on the well known, Impact vs Effort matrix. Which would look like this: This will help us understand what to prioritize. We also should not forget to use color coding we had in the See exercise, we would basically be enriching the matrix with a 3rd dimension. Looking at the resulting matrix, one could conclude to start with the two leftmost tickets since they are very low effort, have some impact but also do affect a mid-level sphere of influence instead of starting with the rightmost one. Act At this point in time, we know what we can do to help our engineers. We also know how, solving those issue would impact the company. Lastly, we also get a clear understanding of who will be impacting by such an improvement. Now that all pieces are in place, there is only one thing left to do: Act! One of the most important tasks of an Engineering Manager is to enable others to do bigger, better things. Engineering Manager The usual analogy which often gets used is to think of yourself as a multiplier . Imagine having 5 developers in your team. If all of them do 1 unit of work a day and you do nothing to help them, as a team, you will get 5 units of work done at the end of the day. multiplier However if you find a way for them to do their work twice as more efficient, you would become a multiplier to all of your engineers and therefore allowing them to achieve 2 × 5 = 10 units of work. The higher the multiplier you are, the more you’ll be able to achieve with your team. In this article, we will recommend a homegrown method which we have devised (by simply combining various concepts that we have collected along the way) to help one understand the best way to amplify this multiplier. The method consists of 4 steps: See Observe Prioritize Act See See Observe Observe Prioritize Prioritize Act Act Let’s look into these components to better understand how it can be applied. See It is important for one to understand where you stand in the grand scheme of things. This helps you in knowing what your sphere of influence is which will help you prioritize which problems to tackle first vs those which require more effort to do so. The exercise is quite simple. It will feel very familiar when you see it although it also has a small twist. In this tree, Dunya is in the center. She has 1 direct report and her peer ( Michael ) has two direct reports. Both Dunya and Michael report to Allan whom himself manages 3 other engineering managers. Those managers manage many other Individual Contributors ( IC ). Dunya Michael Dunya Michael Allan Individual Contributors IC We use a color code to express the degree at which you can exercise influence. Those people to whom you have a single line to are L1 . Those people are the ones you can influence the most. Afterall it is easier to talk to your peers for help or your team members than it is to ask the CEO of the company. L1 Those people who are two lines away from you are L2 . It is also possible to influence them however it would require more effort to do so. In the above example, Dunya would be able to influence Ivan however that would require more work since there is no way for her to enforce what she would like to see differently. She would have to convince Ivan (using persuasion, data, or similar) to be able to influence him do what she would like. L2 Dunya Ivan Ivan Similarly, those who are three lines away are a L3 . L3 is still influenceable however it would require significantly more work than it would take to convince L2 . In my humble opinion it is not worth spending a lot of effort on these levels as the return on investment would be lowered significantly. L3 L3 L2 So far, what we have seen is no different than an organizational chart . The only difference is the circle marked project. Quite often, people in companies interact with each other through projects instead of reporting lines. There will be many projects, migrations, crafts, workforces, etc. where people from different teams will be collaborating on. We represent such initiatives using the ellipse (in the above graph) where we connect different members through that bubble. This allows us to see what the sphere of influence of an individual is across teams. In the above example we can see that Bruno is a L2 to Dunya since they cooperate on the same project. So again, we’re just counting the number of lines connecting the two. organizational chart organizational chart Bruno L2 Dunya This way of thinking also helps us understand the effect someone has had on their peers. Think Performance, where someone who has managed to move metrics for their L1 , L2 and L3 has apparently had a great impact on a larger sphere. Someone who has only managed to help their L3 might be focused on the wrong things (since they’re actually not helping their own team but rather helping others). And someone who has only affected their L1 might still be a mid level engineer and would have to increase their sphere of influence to have greater impact. L1 L2 L3 L3 L1 Observe Now that we understand where we are positioned in the organization and how are interactions look like, it is time to collect data and try to understand the pain-points that could leverage your expertise. collect understand Collect Whenever I join a new company or when I switch teams, I always start by doing 1:1s with everyone in the team (not only engineers) where I ask them a single question: What are the things that annoy you the most or that slow you down? What are the things that annoy you the most or that slow you down? This question allows me to understand the biggest challenges that the team is facing, which for sure is important for me to address as an Engineering Manager. Doing so will help me resolve those issues so that I can multiply my team's output. Once I’ve collected all the issues I put them in a database . There will be many issues which you’ll be hearing again and again from different engineers and that’s OK. Then we add three columns to this database called category , reporter and level . The category column helps us start grouping the issues under logical categories. An issue can fall under multiple categories. Once all issues have been categorized, we can sort the categories based on the number of times we’ve heard issues in that category. The Level column shows us from which level of sphere of influence we have heard this problem from. The reporter column helps us remember who gave us the issue. database category reporter level This gives us a basic understanding of the frequency of issues, and the level which they come from. Understand The next step in Observe is to write down the categories and start doing a Root Cause Analysis ( RCA ) on each and every one of them. You can use any method to help do the RCA however I would strongly recommend to use something simple such as the 5 Whys. The idea with the 5 Whys is to ask “Why” 5 times (rather as many times as needed to find the root cause) to understand what the root cause of an issue might be. It would be better if you do this exercise with those people from your database. Luckily we kept this in our reporter column. Observe Root Cause Analysis Root Cause Analysis RCA RCA reporter Having done this exercise you should obtain something that resembles this: This map will allow us to see the root causes of some of the issues. Those would be the leaves of the tree which are marked red. It will also sometimes help uncover dependencies across different root causes. Not only will this visualization help us understand the issues, their root causes but it will also help us understand the interactions between the issues. In the above example we can see that the “ Excessive Use of Integration or End-to-End Tests ” are affecting two different branches of the tree. Meaning that, removing this root cause will remedy quite some symptoms. Excessive Use of Integration or End-to-End Tests Prioritize Now that we have understood our sphere of influence and that we’ve collected several root causes, we can get started with picking the problems to work on. In order to do so we will be plotting all of the root cause on the well known, Impact vs Effort matrix. Which would look like this: Impact vs Effort Impact vs Effort This will help us understand what to prioritize. We also should not forget to use color coding we had in the See exercise, we would basically be enriching the matrix with a 3rd dimension. See Looking at the resulting matrix, one could conclude to start with the two leftmost tickets since they are very low effort, have some impact but also do affect a mid-level sphere of influence instead of starting with the rightmost one. start with the two leftmost tickets Act At this point in time, we know what we can do to help our engineers. We also know how , solving those issue would impact the company. Lastly, we also get a clear understanding of who will be impacting by such an improvement. what how who Now that all pieces are in place, there is only one thing left to do: Act ! Act

From Manager to Multiplier: Elevate Your Team With SOPA

ম্যানেজার থেকে গুণক পর্যন্ত: SOPA দিয়ে আপনার দলকে উন্নত করুন

Od menadžera do multiplikatora: Podignite svoj tim uz SOPA

Vom Manager zum Multiplikator: Bringen Sie Ihr Team mit SOPA auf die nächste Stufe

De gerente a multiplicador: eleve a su equipo con SOPA

Soti nan Manadjè a miltiplikatè: Elve ekip ou a ak SOPA

マネージャーからマルチプライヤーへ: SOPA でチームをレベルアップ

Kobanda na Mokambi kino na Multiplicateur: Tombola Equipe Na Yo Na SOPA

ຈາກຜູ້ຈັດການໄປຫາຕົວຄູນ: ຍົກທີມຂອງເຈົ້າດ້ວຍ SOPA

Nuo vadovo iki daugiklio: padidinkite savo komandą naudodami SOPA

Од менаџер до мултипликатор: Подигнете го вашиот тим со SOPA

Аз менеҷер то мултипликатор: Дастаи худро бо SOPA баланд бардоред

ካብ ኣካያዲ ናብ መባዛሒ: ጋንታኻ ብሶፓ ኣዕብያ

Introduction As a Technical Product Manager specializing in document processing solutions, I've led a team of technologists to achieve significant efficiency gains in digital products. My focus has been on leveraging cutting-edge technologies to streamline document extraction, transformation, and loading processes, resulting in substantial cost savings and automation. The Challenge Our team was tasked with developing a solution to process a high volume of unstructured documents, extracting relevant information, and integrating it into our digital product ecosystem. The existing manual process was time-consuming, error-prone, and costly, processing only 800 documents per day with an accuracy rate of 45%. Product Management Process Discovery and Research (2 weeks) Conducted stakeholder interviews across 3 departments (Case Intake, Document Processors, Reviewers)
Analyzed 8,000 historical documents to understand content patterns
Identified key pain points:


Slow processing (6 minutes per document)


Low accuracy rates (55% error rate)


Scalability issues Strategy and Planning (3 weeks) Defined key objectives of the project:

Increase processing speed by 4x
Improve accuracy to over 80%
Reduce operational costs by 40%



Created a product roadmap with 3 major milestones over 6 months


Prioritized features using the MoSCoW method Design and Prototyping (4 weeks) Collaborated with UX designers to create wireframes for the user interface
Developed a technical architecture leveraging AWS services
Created a proof of concept using AWS Textract and basic NLP models Development and Testing (16 weeks) Implemented Agile methodology with 2-week sprints


Integrated AWS Textract for initial document processing


Helped development of custom NLP models using John Snow Labs' NLP library by translating Business need to Tech need


Helped the Tech Team Built an API using AWS API Gateway for seamless integration Conducted weekly demos with stakeholders for continuous feedback Launch and Iteration (8 weeks) Performed phased rollout, starting with 10% of document volume


Monitored key metrics daily and made rapid adjustments Gradually increased processing volume, reaching 100% after 6 weeks Key Technologies Used and Interactions AWS Textract: For efficient extraction of text, forms, and tables from documents


AWS API Gateway: To create a scalable and secure API for our document processing pipeline


John Snow Labs NLP: Utilized for NLP pre-training and processing of unstructured text Efficiency Gains and Results Processing Speed Before: 800 documents per day (6 minutes per document)
After: 4,000 documents per day (72 seconds per document) Speed Improvement 4x increase in processing speed Accuracy Before: 45% accuracy in information extraction
After: 83% accuracy in information extraction Improvement: 84% increase in accuracy Scalability Before: Linear scaling (more documents = more staff)


After: Improved scaling (can handle 5x volume with 2x cost increase) Lessons Learned and Best Practices Stakeholder Engagement: Regular demos and feedback sessions were crucial for alignment and buy-in.


Iterative Development: Starting with a MVP and iterating based on real-world usage led to a more robust final product.


Data-Driven Decision-Making: Continuous monitoring of key metrics allowed for rapid adjustments and optimizations.


Technology Selection: Careful evaluation of AWS services and NLP libraries ensured we chose the right tools for our specific needs.


Change Management: Implementing a phased rollout and providing comprehensive training minimized disruption and maximized adoption. Conclusion
By following a structured product management process and leveraging cutting-edge technologies, we transformed a manual, inefficient document processing system into a highly automated, more accurate, and scalable solution. The significant improvements in processing speed, accuracy, and cost-efficiency demonstrate the power of combining strategic product management with innovative technology. This project not only solved an immediate business need but also positioned the company for future growth and adaptability in handling increasing document volumes. Introduction Introduction As a Technical Product Manager specializing in document processing solutions, I've led a team of technologists to achieve significant efficiency gains in digital products. My focus has been on leveraging cutting-edge technologies to streamline document extraction, transformation, and loading processes, resulting in substantial cost savings and automation. The Challenge The Challenge Our team was tasked with developing a solution to process a high volume of unstructured documents, extracting relevant information, and integrating it into our digital product ecosystem. The existing manual process was time-consuming, error-prone, and costly, processing only 800 documents per day with an accuracy rate of 45%. Product Management Process Product Management Process Discovery and Research (2 weeks) Discovery and Research (2 weeks) Discovery and Research (2 weeks) Conducted stakeholder interviews across 3 departments (Case Intake, Document Processors, Reviewers) Analyzed 8,000 historical documents to understand content patterns Identified key pain points:


Slow processing (6 minutes per document)


Low accuracy rates (55% error rate)


Scalability issues Conducted stakeholder interviews across 3 departments (Case Intake, Document Processors, Reviewers) Analyzed 8,000 historical documents to understand content patterns Identified key pain points: Slow processing (6 minutes per document)


Low accuracy rates (55% error rate)


Scalability issues Slow processing (6 minutes per document) Low accuracy rates (55% error rate) Scalability issues Slow processing (6 minutes per document) Slow processing (6 minutes per document) Low accuracy rates (55% error rate) Low accuracy rates (55% error rate) Scalability issues Scalability issues Strategy and Planning (3 weeks) Strategy and Planning (3 weeks) Strategy and Planning (3 weeks) Defined key objectives of the project:

Increase processing speed by 4x
Improve accuracy to over 80%
Reduce operational costs by 40% Created a product roadmap with 3 major milestones over 6 months Prioritized features using the MoSCoW method Defined key objectives of the project: Increase processing speed by 4x
Improve accuracy to over 80%
Reduce operational costs by 40% Defined key objectives of the project: Increase processing speed by 4x Improve accuracy to over 80% Reduce operational costs by 40% Increase processing speed by 4x Improve accuracy to over 80% Reduce operational costs by 40% Created a product roadmap with 3 major milestones over 6 months Created a product roadmap with 3 major milestones over 6 months Prioritized features using the MoSCoW method Prioritized features using the MoSCoW method Design and Prototyping (4 weeks) Design and Prototyping (4 weeks) Design and Prototyping (4 weeks) Collaborated with UX designers to create wireframes for the user interface Developed a technical architecture leveraging AWS services Created a proof of concept using AWS Textract and basic NLP models Collaborated with UX designers to create wireframes for the user interface Developed a technical architecture leveraging AWS services Created a proof of concept using AWS Textract and basic NLP models Development and Testing (16 weeks) Development and Testing (16 weeks) Development and Testing (16 weeks) Implemented Agile methodology with 2-week sprints Integrated AWS Textract for initial document processing Helped development of custom NLP models using John Snow Labs' NLP library by translating Business need to Tech need Helped the Tech Team Built an API using AWS API Gateway for seamless integration Conducted weekly demos with stakeholders for continuous feedback Implemented Agile methodology with 2-week sprints Implemented Agile methodology with 2-week sprints Integrated AWS Textract for initial document processing Integrated AWS Textract for initial document processing Helped development of custom NLP models using John Snow Labs' NLP library by translating Business need to Tech need Helped development of custom NLP models using John Snow Labs' NLP library by translating Business need to Tech need Helped the Tech Team Built an API using AWS API Gateway for seamless integration Conducted weekly demos with stakeholders for continuous feedback Helped the Tech Team Built an API using AWS API Gateway for seamless integration Conducted weekly demos with stakeholders for continuous feedback Launch and Iteration (8 weeks) Launch and Iteration (8 weeks) Launch and Iteration (8 weeks) Performed phased rollout, starting with 10% of document volume Monitored key metrics daily and made rapid adjustments Gradually increased processing volume, reaching 100% after 6 weeks Performed phased rollout, starting with 10% of document volume Performed phased rollout, starting with 10% of document volume Monitored key metrics daily and made rapid adjustments Gradually increased processing volume, reaching 100% after 6 weeks Monitored key metrics daily and made rapid adjustments Gradually increased processing volume, reaching 100% after 6 weeks Key Technologies Used and Interactions Key Technologies Used and Interactions AWS Textract: For efficient extraction of text, forms, and tables from documents AWS API Gateway: To create a scalable and secure API for our document processing pipeline John Snow Labs NLP: Utilized for NLP pre-training and processing of unstructured text AWS Textract: For efficient extraction of text, forms, and tables from documents AWS Textract: For efficient extraction of text, forms, and tables from documents AWS Textract: AWS API Gateway: To create a scalable and secure API for our document processing pipeline AWS API Gateway: To create a scalable and secure API for our document processing pipeline AWS API Gateway: John Snow Labs NLP: Utilized for NLP pre-training and processing of unstructured text John Snow Labs NLP: Utilized for NLP pre-training and processing of unstructured text John Snow Labs NLP: Efficiency Gains and Results Efficiency Gains and Results Processing Speed Processing Speed Before: 800 documents per day (6 minutes per document) After: 4,000 documents per day (72 seconds per document) Before: 800 documents per day (6 minutes per document) After: 4,000 documents per day (72 seconds per document) Speed Improvement Speed Improvement 4x increase in processing speed 4x increase in processing speed 4x increase in processing speed Accuracy Accuracy Before: 45% accuracy in information extraction After: 83% accuracy in information extraction Improvement: 84% increase in accuracy Before: 45% accuracy in information extraction After: 83% accuracy in information extraction Improvement: 84% increase in accuracy Scalability Scalability Before: Linear scaling (more documents = more staff) After: Improved scaling (can handle 5x volume with 2x cost increase) Before: Linear scaling (more documents = more staff) Before: Linear scaling (more documents = more staff) After: Improved scaling (can handle 5x volume with 2x cost increase) After: Improved scaling (can handle 5x volume with 2x cost increase) Lessons Learned and Best Practices Lessons Learned and Best Practices Stakeholder Engagement: Regular demos and feedback sessions were crucial for alignment and buy-in. Iterative Development: Starting with a MVP and iterating based on real-world usage led to a more robust final product. Data-Driven Decision-Making: Continuous monitoring of key metrics allowed for rapid adjustments and optimizations. Technology Selection: Careful evaluation of AWS services and NLP libraries ensured we chose the right tools for our specific needs. Change Management: Implementing a phased rollout and providing comprehensive training minimized disruption and maximized adoption. Stakeholder Engagement: Regular demos and feedback sessions were crucial for alignment and buy-in. Stakeholder Engagement: Regular demos and feedback sessions were crucial for alignment and buy-in. Iterative Development: Starting with a MVP and iterating based on real-world usage led to a more robust final product. Iterative Development: Starting with a MVP and iterating based on real-world usage led to a more robust final product. Data-Driven Decision-Making: Continuous monitoring of key metrics allowed for rapid adjustments and optimizations. Data-Driven Decision-Making: Continuous monitoring of key metrics allowed for rapid adjustments and optimizations. Technology Selection: Careful evaluation of AWS services and NLP libraries ensured we chose the right tools for our specific needs. Technology Selection: Careful evaluation of AWS services and NLP libraries ensured we chose the right tools for our specific needs. Change Management: Implementing a phased rollout and providing comprehensive training minimized disruption and maximized adoption. Change Management: Implementing a phased rollout and providing comprehensive training minimized disruption and maximized adoption. Conclusion By following a structured product management process and leveraging cutting-edge technologies, we transformed a manual, inefficient document processing system into a highly automated, more accurate, and scalable solution. The significant improvements in processing speed, accuracy, and cost-efficiency demonstrate the power of combining strategic product management with innovative technology. This project not only solved an immediate business need but also positioned the company for future growth and adaptability in handling increasing document volumes. Conclusion

Driving Efficiency in Document Processing: A Technical Product Manager's Journey

Building a Device Manager App on Android: Lessons from Managing 300K+ Terminals

NPM vs Bun: Comparison of Package Managers for JavaScript Developers

The Noonification: Good Managers Know to Not Make These Mistakes (8/31/2024)

Good Managers Know to Not Make These Mistakes

ভাল পরিচালকরা এই ভুলগুলি করতে জানেন না

Dobri menadžeri znaju da ne prave ove greške

Los buenos gerentes saben que no deben cometer estos errores

Kudeatzaile onek badakite akats hauek ez dituztela egiten

I buoni manager sanno che non devono commettere questi errori

優秀なマネージャーはこれらのミスをしないことを知っています

კარგმა მენეჯერებმა იციან, რომ არ დაუშვან ეს შეცდომები

ښه مدیران پوهیږي چې دا غلطۍ نه کوي

Bons gerentes sabem que não devem cometer esses erros

Allin Kamachiqkunam Yachanku Mana Kay Pantaykunata

ንፉዓት ኣካየድቲ ነዚ ጌጋታት ከምዘይፍጽሙ ይፈልጡ እዮም።

Abaphathi Abahle Bayazi Ukungawenzi Lawa Maphutha

Stories, News & Mentions about MANAGEXR

Managexr’s Stories on HackerNoon