What's your process for scoping product requirements?

Problem framing is also crucial. E.g. at Schiphol Airport, people have to wait for their bags after landing. This is frustrating. They could have framed the problem as get the bags there sooner. But the problem was that waiting for their bags is boring. How could they reduce the boredom of the time spent waiting? At Schiphol, you have to walk 15 mins to be able to claim your bags. So by the time you arrive, they may already are on the conveyor belt. How you frame the problem limits or expands the possible solutions.

I would like to point out that collaboration with Customer Service (Member Support) team as a Product Manager is key, as they can provide very useful insights on key user problems from CS tickets or general queries. During one of the discoveries I've done, we had an indication from several interviews about a user problem. In order to collect more data, I collaborated with our CS team to review tickets. This way I actually identified two main specific problems and was able to prioritise better which one I will then go with to defining a solution.

Focusing on understanding the problem before jumping to solutions is crucial for effective product thinking. Our natural inclination towards our own ideas can sometimes lead us away from the real issue at hand.

To scope the requirements, first is to identify the problem that we are tending to solve. Thhe problem can be identified from multiple sources like user interviews, user feedback, interval teams dogfooding ideas. Second is to prioritize the problem we want to solve, and brainstorm solutions for that problem. We then prioritize the solution which gives most impact with lowest effort. The solution once stakeholders approved is then built into detailed requirements which is required by the engineering and design teams. This requires us to scope the requirements which can turn into a successful minimum lovable product (MLP) for execution and delivery. This is done based on the value and the effort required to be delivered within a timeline.

Defining the root problem is deceptively tricky - symptoms masquerade as causes.??? Use a problem framing tool to dig deeper and expose the true issue: ? 5 Whys - iteratively ask "why" to get the root ? Fishbone diagram - visually map contributing factors ? Problem vision - describe the ideal future state Well-framed problems invite creative solutions. ??Bad framings limit ideas.

I would recommend including wider team (engineers and other stakeholders) to ideation workshop. This proven to gather a more versatile solutions to a problem. It also brings more visibility to what Product Manager is working on during the discovery phase. This also allows to check viability of certain solutions as engineers are involved as well. It should be optional to attend, but encouraged.

One of the best approaches in my career is to try to write 20 hypotheses for the solution. Usually, the first 5 are obvious, and the next 5 are easily identifiable as well. After generating 10 ideas, you begin to think outside the box, activating your imagination and creativity. As a result, genuine insights start to emerge around the 16th or 17th idea. These hidden gems can prove to be invaluable.

Collaborate with multiple teams while defining a solution, put your thoughts and solution identified and then allow them to do below actions without bias- 1. Brainstorm 2. Brain writing 3. Sketching 4. Allow them to throw 10 bad solution 5. Allow them to ask you as much as why (min 5) 6. Ask them to write hmw statement before they conclude even And could be many based on the practice but in every solution defining session there should be a flow of open thoughts and bias need to be discarded.

This is the second battle! ?? Defining the solution is where the magic happens. ?? In this step, I've found brainstorming, sketching, and prototyping to be invaluable. They help transform ideas into tangible solutions that resonate with users. But the journey doesn't end here! It's crucial to stay in close contact with the customer and ensure all teams are aligned with the solution. ????

From my experience, the sooner I involved engineers in the conversation, the faster and more robust our solutions turned out to be. Engineers don't just think in code; they often have a keen understanding of system architectures and can provide insights into design that can be both elegant and efficient. Moreover, early involvement fosters a sense of ownership among engineers. They're no longer just 'building to spec'; they're part of the problem-solving process. This heightened sense of investment often translates into higher-quality output and quicker development cycles.

Certainly, defining the scope is where it all comes together! ?? I've discovered that breaking information into bite-sized pieces and collaborating with cross-functional teams are pivotal. ?? It's akin to solving a puzzle where each piece plays a role in the grand scheme. Prioritization is my guiding star during this phase. By sorting through ideas and options, we ensure our MVP delivers maximum value with minimal effort and risk. ????

First of all, decompose the feature. You should select the components that are vitally important for the first version of the product. For instance, if you are creating a new fitness app, you must create a workout screen. However, for the first version of the product, you could deprioritize audio instructions because they are valuable but not necessary features. The best way to prioritize is by using one of the popular frameworks, such as ICE. You can estimate each part of the new product together with your team and compare it with the available velocity of your team. This allows you to select the most valuable features and hypotheses.

Or, build on the user journey you've built in previous steps and prioritize based on a User Story Map, a great tool to help with slicing out a potential first release that continues to tie it back to the user and the problem you're trying to solve.

1. Prioritize MoSCoW: segregate features into Must-haves and nice-to-haves. RICE: use Reach, Impact, Confidence, and Effort to add data-driven nuance. 2. Collaborate on Estimation Team Insights: engineers and designers can flag hurdles or suggest efficiencies. Smart Sizing: use Fibonacci or t-shirt sizes to gauge effort. 3. Validate Externally Feedback Loops: run scoped features past users and stakeholders for a reality check. Expert Opinions: consult industry experts to avoid pitfalls. 4. Leverage Tools Roadmaps: direct all stakeholders towards a common destination. Backlogs & Specs: not just lists but your project’s source of truth.

You can use statement of Assumptions: sum it all up in a well-documented assumption statement. This serves as both a checklist and a discussion starter for the team.

These are some ways to get started. Capture requirements: This involves documenting the requirements of the product, which includes analyzing, prioritizing, tracking, and collaborating with stakeholders to agree on work to be performed. -Analyze and prioritize requirements: This step involves analyzing the requirements to determine their feasibility and prioritizing them based on their importance. -Group and organize requirements: This step involves grouping the requirements into categories and organizing them in a way that makes sense. -Implement Kanban or Scrum: This step involves implementing either Kanban or Scrum methodology to manage the project. -Define and track status of requirements -Manage dependencies

Customer insights and stakeholder feedback play a critical role in defining requirements. When defining the problem and strategizing around the solution, our team has made it a habit to try validating our hypothesis and getting feedback on our solution PRIOR to building. This helps to make sure we are meeting customer needs and delivering value.

One way to approach this is to use the concept of diverging and converging.. Diverging: be open to all ideas that solve the problem Converging: then sit down with your team to analyze the best approach and shortlist the priorities. It is highly essential to clearly write down and document the scope, limitations, risks involved in the product development. This will help the stakeholders and tech teams clearly understand the limitations and what is out of scope.

The most important point that was missed is that you should write all of these things down together. If you write it yourself, and you describe it perfectly, and then throw it over the fence you won't have common understanding. If you do it together whatever you write simply becomes a reminder of what you already know.