Idea Screening in Product Development PDF

**MODULE 2** **IDEA SCREENING IN PRODUCT DEVELOPMENT** **LEARNING OUTCOMES** - **TLO 2** Determining the potential of the concept and whether the idea will lead to a viable product. **Introduc** **Idea Screening in New Product Development** Every new product, service, or solution starts...

**MODULE 2** **IDEA SCREENING IN PRODUCT DEVELOPMENT** **LEARNING OUTCOMES** - **TLO 2** Determining the potential of the concept and whether the idea will lead to a viable product. **Introduc** **Idea Screening in New Product Development** Every new product, service, or solution starts with an idea generation or concept development followed by the idea screening process. Therefore, **idea screening in new product development** is vital to ensure that the development process satisfies company goals and customer expectations. It helps you evaluate each idea to determine if it is worth pursuing. **What is idea screening?** Idea screening is an important step in new product development. When a new product idea is created, it often needs to be screened before development can continue. Screening means determining the potential of the concept and whether the idea will lead to a viable product. At the idea screening stage, you must take into account the needs of your market, competitors, current products, and their flaws. You need to leverage the market research data or feedback to determine the viability and worth of a new idea. It will also answer questions like: - How responsive are the customers to your new product or service? - Is there any market gap in your proposed product idea? - How satisfied are your customers with your products and services? **Why should you always screen ideas?** Although far less talked about than prototyping or beta releases, idea screening is a crucial stage within the new product development process. It acts as the gatekeeper, ensuring only ideas with a high probability of success are advanced for testing. As a result, startups can focus their efforts on building the right product from the beginning, and ultimately, avoid failure. Essentially, idea screening saves time and money in the long run. Even if you do have the manpower or funds to create quick POCs/prototypes and test them among the team, it's still a waste of limited company resources. Screening allows founders and product teams to identify the ideas worthy of testing. It helps us: - Estimate the feasibility of an idea based on research - Think about the practical implications of an idea: do consumers want it, and is there a chance of finding a product-market fit? - Check if an idea aligns with our current goals or product vision - Mitigate the risk of a new project or startup failure And ultimately, allocate resources to the right projects and experiments. As you can see, it's less about separating the good ideas from the bad ones, and more about assessing the potential [value of each solution](https://railsware.com/blog/product-value/). Just because an idea is clever or unique, doesn't mean it's viable. **4 Steps to Idea Screening in New Product Development** 1. **Brainstorm Product or Service Ideas** 2. **Assess the Concepts Against Particular Criteria** 3. **Carry out qualitative and quantitative research** 4. **Concept Development & Testing** Once you've screened ideas and selected one to proceed with, there are generally three main options for the next step. - Create a proof of concept (POC) - Design a prototype - Build a minimum viable product (MVP) Here's a brief rundown of each concept's characteristics and the difference between [POC, prototype, and MVP](https://railsware.com/blog/mvp-prototype-poc/).  **BRIDGeS Framework** - A flexible decision making framework, designed by Railsware, inspired by Pivotal Labs' Inception. It is a solid approach for multi context analysis that leads to a conclusive decision or solution. - BRIDGeS Framework is a game changing tool for C-level executives, product managers and business analysts. Any professional will benefit from this framework, while solving tasks of a different scale. - New problem-solving approach - Multi-purpose tool - Product Strategy Explore strategy directions for complex environments and contexts - Day-to-day Decisions - Operations - Outside of Work **Bridges Follow a 4-step process** The [whole process](https://railsware.com/bridges-framework/process/) is divided into four stages: **\"Uber\" case study** In this case, we observe Uber\'s idea in a time when this service didn't exist. We don't know how actual founders organized the ideation process, but let's see how we would run it with the BRIDGeS framework back then. This approach should help us analyze Benefits, Risks, and Issues for the potential stakeholders to create a new mobility experience on the market. This is a great case to show how BRIDGeS is applied for complex contexts with multiple stakeholders, who have different needs and risks along with those in common. 1 **Problem description** We start describing the problem by mentioning **Subjects **and their **Descriptors **(Benefits, Issues, Risks, Domain Knowledge, Goals). Our team members should have a deep understanding of the context to have a productive session and generate quality content for the right solution. This is how the Problem Space should look after the problem description is done:  First, we define all **Subjects, **which represent stakeholders involved in the context --- those who will benefit from the future Solution. The main stakeholders and users of the Uber service are the Passengers and Drivers. Our key stakeholder is the Uber company, which has the intention to identify the problem and resolve it. We can diversify Subjects and go as deep into segmenting as a particular case requires - by geography, specific features, interests, etc. In this showcase, we will stick to three Subjects: Passengers, Drivers, and Uber Company. According to the required color and shape coding, we denote Subjects as big green rectangles. Descriptors Each Subject is analyzed through Descriptors. We focus on the needs and current experience of the Passengers and Drivers. However, the main goals originate from the business, so we should also add some input about the company itself. Passengers **Issues** Here we mention the existing problems that result in a bad experience for the passengers: - **Clunky ordering experience:** raising one's hand in the street or waiting on the line with a call center is far from being a great experience; - **Price prediction:** some taxis have counters, but you still struggle to guess the total price at the moment of your departure; - **Price negotiation:** you never know what the end price is; - **Call center communications:** staying on the line sometimes seems to last forever; - **Rush hour busyness:** in the rush hour, the prices go up, and a car is hard to find; - **Precise meeting point:** knowing the exact address can be rather challenging and still does not guarantee that a driver finds you. We put this context on red cards and place them on the board next to the Passengers card. Since the card space is limited, messages must be short and readable. **Benefits** Here we look for the potential needs of the passengers. What value can they get from the future Solution? - **Predict time to destination point:** a passenger does not know the route a driver will take or the traffic situation; - **Predict the time of taxi arrival:** operator can tell the approximate time of arrival, but one cannot predict it for sure; - **Simple tip experience:** difficulty finding cash for the tip; weird and outdated card readers; - **Simple cancelation process:** operator is hard to contact; slow operators; - **Driver-Passenger communication:** sometimes the call is not the best option; - **Fair price,** prices may be too high or variable based on distance and trip time; - **Flawless payment process:** need to prevent delays at the destination point. **Risks** Potential issues that passengers may experience in the future are: - **Personal safety:** passengers don\'t know the driver controlling the car, and drivers never know the passenger getting in the car; - **Cash payments:** neither drivers nor passengers know how much the fare will cost until the trip is done, so passengers might not be carrying the right amount of cash and drivers might not have appropriate change. **Domain knowledge** There are things to consider besides Benefits, Risks, and Issues: think about special conditions or additional information about the Subjects involved, as well as the general context. This is called Domain knowledge. For example, 75% of passengers are unhappy with the service - that's a fact worth noting.\ Domain knowledge can be crucial and have a significant influence on the final solution. With that knowledge in mind, we continue moving forward through the process, carefully considering each Subject one by one and noting every Benefit, Risk, and Issue as we go. We note the findings next to the appropriate Subject: Driver or Uber Company. Drivers **Issues** - **Getting a taxi licence:** not all drivers have appropriate licences, especially if being an Uber driver is not their primary job. It takes time and effort to obtain the licence; - **Not enough rides while on duty:** drivers never know how successful a day will be and how much money they\'ll earn in a shift. **Benefits** - **Easy to join the service:** drivers can register with minimal paperwork; - **Quick money:** some people consider ride-sharing as a temporary source of income while searching for a permanent job; - **Car provided by a company:** if drivers don\'t own a car, they can still drive a taxi; - **Additional income source:** drivers can earn extra money in addition to their primary job by working evenings or weekends. Each Subject has its own descriptors. However, some apply to multiple Subjects. In our case, some of the Benefits, Risks, and Issues for Drivers also apply to Passengers. Some of these include driver-passenger communication, fair price, flawless payment process, call center communications, rush hour congestion, precise meeting point, and personal safety. We place cards with common descriptors in between the Driver and Passenger cards. This is another perk when it comes to using cards and the board - you can manipulate the objects in any way, any time, throughout the whole BRIDGeS process. Uber company The Uber company is our key Subject which initiates the changes and has an intention to transform the taxi industry by creating a service with an exceptional user experience. The anticipated results of the future Solution - or Goals - are to serve 75% of the car-sharing market and Change the way taxi services work. Conquering new locations and Minimizing support expenses would be the benefits for the Uber company. In terms of potential risks to the business, authorities will likely Require licences for taxi services. 2 **Prioritization** Now that we have mentioned all Subjects and Descriptors, it's time to set the proper focus for our further steps. We should prioritize all Risks, Issues, and Benefits in the Problem Space and set aside non-essential tasks. Applying [MoSCoW] prioritization technique, we simply go through each Benefit, Risk, and Issue and tag them with the relevant markers, defining what Must, Should, Could, or Won't be done. The descriptor type doesn't influence the priority - a Benefit, for example, can still be of higher importance than an Issue or Risk. What does the "time prediction" feature matter to passengers? Considering the main reason passengers call a taxi is to get to their destination on time, having a feature to predict the length of their trip is a Must. Price negotiation is something that needs to be improved, but it's less critical since it does not influence the choice to get a taxi. We mark the Price negotiation as Could. The same way we mark each Benefit, Risk, and Issue for other Subjects in our Problem Space. 3 **Solution variations**  Now that everything is beautifully set up in the Problem Space, we are ready to head to our **Solution Space** and start brainstorming potential high-level solutions to address all prioritized Benefits, Risks, and Issues. An app might be a solution to the issues, considering the needs of the passengers, drivers, and the business itself. Since these are different platforms, and audiences with different needs and goals, we can make separate mobile applications for passengers and drivers, a universal mobile app for both, or a web app. We place the cards with our high-level Solutions on the board in the Solution Space. According to the BRIDGeS color-coding, these are big blue cards. 4 **Solution breakdown** This is where the magic happens. Now that we have several high-level solutions, we split them into smaller semantical blocks, classified as epics and nested tasks.\ We go through the Benefits, Risks, and Issues for the passengers and drivers in the Problem Space and cover each with \"epics\" or \"tasks\" in the Solution Space. Considering all mentioned descriptors, we define the following epics: "Ride", "Payment", "Communications\", "Security" and "Account". Now color coding is different - each epic and its tasks should have its own color. Then we depict our epics through the small tasks referring to the features an app should have. E.g.: "clunky ordering experience" - "ride request", "precise meeting point - "map" etc. Next, we go through each descriptor and make sure it is covered with a relevant task. A single task can cover several benefits, issues, and risks at a time, and vice versa --- one descriptor can be addressed with multiple tasks. Here is how it looks on the board: It is possible that more Issues, Benefits, and Risks come to mind during the solution ideation process, and we end up adding more cards to the Problem Space. BRIDGeS framework gives flexibility, which allows being more creative. After all of the epics and tasks are mapped on each and every descriptor, we prioritize them using MoSCoW framework. Often the priority level of the tasks is inherited from the descriptors they cover. However, we might have a situation where one task needs to be completed before the team can tackle another, even if the business value of the first task isn't high. In that case, the priority goes up. **Moscow Prioritization** **Moscow Prioritization Definition** Moscow Prioritization, also known as the MoSCoW method or MoSCoW analysis, is an acronym that stands for Must have, Should have, Could have, and Won't have. It is commonly used in agile project management methodologies, such as Scrum and DSDM (Dynamic Systems Development Method). It provides a structured framework for prioritizing requirements and enables teams to adapt and respond to changing project needs. **What is Moscow Prioritization?** Moscow Prioritization is a method used to categorize and prioritize requirements or features in a project. It helps project teams and stakeholders determine what is essential for the project's success and what can be deferred or excluded. By using the Moscow Prioritization method, project managers can make informed decisions about resource allocation and ensure that the most critical elements are addressed first. **Moscow Prioritization Examples** To better understand MoSCoW Prioritization, let's explore some examples: 1. **Must have**: These are the requirements or features that are crucial for the project's success. They are non-negotiable and must be delivered within the specified timeframe. For example, in a software development project, the ability to create user accounts and login functionality would be considered must-have features. 2. **Should have**: These requirements or features are important but not critical. They can be deferred if necessary but should be included in the project if resources allow. For instance, in a website development project, implementing a search functionality would be considered a should-have feature. 3. **Could have**: These requirements or features are desirable but not necessary for the project's core functionality. They can be considered for inclusion if time and resources permit. For example, in a mobile app development project, integrating social media sharing capabilities could be considered a could-have feature. 4. **Won't have**: These are the requirements or features that are explicitly excluded from the project scope. They are not considered essential and will not be implemented. It is important to clearly communicate and manage stakeholders' expectations regarding the exclusion of these features. By using the Moscow Prioritization method, project teams can effectively prioritize their work and focus on delivering the most critical elements first. This approach helps prevent scope creep and ensures that the project's key objectives are met within the given constraints. **How to Implement MoSCoW Prioritization: Best Practices** Using MoSCoW Prioritization effectively requires careful consideration and collaboration among the Agile team and stakeholders. Here are some best practices to ensure the successful implementation of the MoSCoW Rules: 1. **Involve key stakeholders**: Ensure all relevant stakeholders are actively involved in the prioritization process. This includes representatives from the business, development team, product owners, and end-users. Their input and understanding of the project goals and requirements are crucial for making informed decisions. 2. **Clearly define priorities**: Make sure that the team has a shared understanding of what each priority category (Must have, Should have, Could have, Won't have) means. Establish clear criteria for each category to avoid ambiguity and misinterpretation. 3. **Focus on value**: Prioritize features based on their potential value to the end-users and the project's overall objectives. Consider the impact of each requirement on the product's functionality, user experience, and business outcomes. 4. **Revisit priorities regularly**: Priorities can change throughout the project lifecycle due to evolving business needs or market conditions. Regularly review and update the prioritization to stay aligned with the project's current goals. 5. **Collaborative decision-making**: Use collaborative techniques such as group discussions, workshops, and brainstorming sessions to arrive at a consensus on priorities. Encourage open communication and respect different perspectives. 6. **Limit the number of "Must have" items**: Be cautious not to overload the "Must have" category with too many requirements. Limiting the number of Must Have items ensures that they genuinely represent critical features that must be delivered. 7. **Focus on Minimum Viable Product (MVP)**: Use MoSCoW prioritization to identify the Minimum Viable Product--- the set of features that deliver the most value with the least effort. This helps in delivering a usable product early and gathering feedback from users. 8. **Balance stakeholders' needs**: Address conflicts in priorities by having discussions to understand the reasoning behind stakeholders' preferences. Look for opportunities to find common ground and compromise. 9. **Be flexible**: Agile methodologies embrace change, and priorities may shift as the project progresses. Be prepared to adjust priorities based on new information, feedback, or changing market conditions. 10. **Communicate priorities clearly**: Ensure that all team members understand the prioritization and its implications. Transparent communication helps maintain a shared vision and keeps everyone focused on the project's most important goals. **Summary** Moscow Prioritization, also known as the MoSCoW method, is a valuable technique in project management for prioritizing requirements or features. By categorizing them into Must have, Should have, Could have, and Won't have, project teams can effectively allocate resources and ensure the successful delivery of critical elements.  **[Create a Bridges Framework of your product idea. ]**