How to Set a Framework for Scope Discovery

To build a successful product, teams need the right process for identifying and building features that bring the most value to users and the business. For early-stage startups, the stakes are even higher as resources are scarce and time is limited. That's why it's crucial to ensure your product development team is working on the right things to avoid burning time and resources on features that don't advance your business goals.

Scope discovery is the key activity in the dual-track agile product development process that keeps your team focused on building the most valuable things. At OAK'S LAB, our approach to scope discovery gives teams the space to innovate, drive decisions on what to build, align on how to build it, and validate why it brings value to users and the business.

In this article, we'll explore the fundamental components of scope discovery and provide a framework for implementing these techniques in your product development process.

What is scope discovery? 

Scope discovery is the process of identifying and defining a product's features, functionality, and requirements, based on the needs of its users and the goals of the startup. It helps the product development team establish a clear understanding of the product’s desired scope, which is vital for planning, prioritizing, and managing resources throughout the product development process. It involves collaboration with stakeholders, users, and other sources to answer crucial questions, such as:

• What are the most pressing problems that need to be addressed for the user?
• What solutions are available to address these problems?
• Taking into account technical feasibility, the business, and the timeline, what solutions should we build?

How we do scope discovery at OAK’S LAB

At OAK'S LAB, we recognize that the success of startup product development hinges on the right scope for the business and users. In the dual-track agile process, scope discovery is an essential activity in the discovery track, ensuring that the product features and functionality align with the startup's goals and user needs.

Framework for Scope Discovery in Dual-Track Agile

The following framework is our recommended approach to control the scope and determine if a new feature will have a significant impact on the success of the product throughout the development process.

‍Step 1: Assessing a New Feature Idea or Problem

New features or problems can be identified through user feedback, product metric analysis, or simply an idea from a stakeholder involved in the buildout process. Before deciding whether to invest time in scoping the feature, we recommend evaluating it against existing quantitative and qualitative insights to calculate a "User Impact Score." This score is based on the importance of the insights and their relevance to the feature. If the score is high, you should take the idea to the next step. If the score is medium or low, you should either icebox the feature for later or invest time in gathering more data through insights to better inform our decision.

Step 2: Conducting Discovery Tasks

After confirming important insights, we then recommend delving into the feature or problem. This may vary depending on the product, but three key questions should be answered before prioritizing the feature:

• Business Case: What outcome will this have for the users and the business?
• Design Prototype: What is the solution that would achieve our goal?
• Tech Feasibility: How much effort will it take to deliver the solution?

Business Case

The business case for a new feature should demonstrate how it aligns with your vision and mission and how it can help you achieve the business and product goals. Data such as user feedback and revenue projections can be used to show the potential impact of the feature. Common measures of business impact include revenue, number of users, reduction in user complaints, and time saved. If the business case for a feature is not strong, it may be necessary to de-prioritize it.

Design Prototype

To more clearly define the "what" of a new feature, it may be necessary to create some level of design specs. This could range from wireframing to a full click-through prototype, depending on the size and complexity of the feature, as well as the need for validation. Designs should be reviewed and confirmed and added to the feature description so that they are ready when you refine the tickets with your team ahead of the next sprint (see our article on meetings and ceremonies for our full sprint schedule). For larger and more complex features, usability testing or other qualitative insights can provide additional confidence in the hypothesis and allow for early adjustments prior to development.

Tech Feasibility

During discovery, it is important to evaluate both the feasibility and business impact of a new feature. To assess feasibility, we recommend considering the level of implementation at which the feature is needed and estimating the engineering effort required to implement it.

It is helpful to assign a score to the new feature ideas based on various drivers. Common drivers include:

• Business impact
• User need
• Effort
• Confidence

Each driver can be scored out of 5, and the scores are used to calculate an overall priority for the feature. The weights assigned to each driver can be adjusted based on the team's priorities. For example, if confidence is a particularly important factor, the team may want to give it a higher weight in the calculation. This can help ensure that the team fully understands the implementation before moving the feature into the delivery track.

‍Step 3: Transitioning to Delivery

Once the final priority score has been calculated, the team can use it to determine whether to add the new feature to the roadmap and create a ticket in the project management tool. If the score is not high enough, the feature can be put on hold in the icebox until it is ready for development. At this stage, the team should have all the necessary information to begin refining the feature description and preparing it for delivery.

Tips for scope discovery

1. Stay focused. As you gather more information, it's easy to increase the number of directions the team can take. This means that as the team continues to discover more scope, they will need to make judgments on what remains valuable and decide:

• What to focus on
• What becomes obsolete
• What to address in a later version of the product

2. Move fast and don't overengineer your scope discovery process. Stay focused on getting to the scope as quickly as possible. In the startup world things move at a fast pace and overengineering the processes will slow you down. If you're unsure of something, make sure you have a clear path to get the information as quickly as possible. Don't let things roll, as this can prevent progress beyond the next sprint or two.

3. Keep asking why. Once you have identified a problem go a level deeper to see if there is a separate root cause. This is because the first problem you find is not necessarily the cause and without digging deeper, you may develop a solution that has little/no impact.

4. If possible, make it measurable. Benchmark the problem to improve how you track success. Once you have highlighted something is a problem, record the key metrics that this problem affects so that you can set targets for the new solution (e.g., 20% reduction in time in to buy a property.

5. Validate your assumptions. Using insights to validate the information you get from scope discovery is absolutely necessary in order to ensure you are building the right thing.

In summary, focusing on scope discovery will help your product development team to efficiently identify and prioritize the most impactful features, align on the best solutions, and validate their value. Hopefully implementing these tips and techniques in your product development process will set your startup on the path to success and allow you to build a product that truly resonates with your users.

In our next article, part of the OAK’S LAB WAY series, we will focus on prototyping and usability testing.