Product Scoping

In the history of project management failures, one of the highest contributors had been the “Scope Creep”. Not thinking through the scope properly or properly identifying the missing elements is a sure shot strategy towards a failed project.

Scoping a project is an art that one masters over time. Thinking through all the functional and non-functional requirements, mapping all the business requirements, and prioritizing them on a product/project roadmap defines the successful first step.

Definition: Functional requirements are all the essential behaviors and outputs you expect the system to perform given any input. All the functional points and user stories fall under this category. Non-functional requirements highlight how the system works. It takes into consideration technology stacks, performance requirements, HW or design needs etc. Both functional and non-functional requirements are driven by the business needs.

Back in the traditional waterfall approach, there used to be a lot of emphasis on project scoping and requirement analysis. Simply because it’s a linear model and any missing information has direct implications on the next step. However in Agile, it’s expected to roll out working software fast. Over the time while working with a lot of founders, we noticed many prevailing myths around Agility and Scoping.

Myth 1: Scope is not important in Agile, you just start building the software.

It never works that way. You have to think through your business requirements. You have to identify your higher-level functional requirements. You have to define the immediate goal, and if possible the end goal. You have to define and plan your initial sprints. If you don’t, there is either the cost, time or quality you have to compromise.

Interested to take a deep dive on Agile or Scrum, check out these quick reads.

Myth 2: Thinking too much through the scope often delays the project.

This simply undermines the importance of planning. Whether you are following agile or not, one needs to think thoroughly on what to accomplish in successive iterations. Your scope should be good enough to answer two basic questions: a) Is there a reasonably good milestone defined that covers some essential and important business requirements, b) Is that milestone capable enough to test certain user flows and take you to next level?

Never undermine the power of conceptual clarity of your business requirements. The more you are clear, the lesser time it takes to get your product production ready.

At times, founders are struggling to define the path to their end goals. It’s highly recommended to spend that time experimenting, talking to your customers, end users, partners, mentors etc. That input will be GOLD; you can use it to alter the path of your product development and those early pivots can provide acceleration.

Myth 3: Scoping is to avoid changes. Agile is to accommodate changes.

Yes, agile’s strength comes from its ability to let one accommodate changes. But scoping is not to avoid changes, but to be thorough in one’s understanding of the known and unknown requirements. It highlights the possible implications of the unknown on project timeline, cost or resource utilization. Changes are OK, but its wise to avoid the unnecessary ones.

Iron Triangle of Project Management helps in understanding the implications a lot better. If anyone is aiming to get the best of quality, time and resources, it’s like hitting a gold mine. That may happen, but the probability is extremely low.

We emphasize a lot on conceptual clarity. Instead of rushing into thinking and building software, we work with our founders to help them think in multiple dimensions of their business needs.

Founders are often carried away by too much of technology requirements mapped against their business needs. And they often miss out and undermine the priority of essential core features that are necessary for them to roll out first.

Our process of thinking aloud with them facilitates them to identify their initial assumptions that are critical for their proof of concept and gather user feedback. Testing the important assumptions and business model hypothesis establishes a business foundation. This helps prioritize the immediate technology needs and defines the initial sprints along with timelines.

Outcomes from our process are documented as a “Scope Document” that serves as a baseline. And we keep iterating it along the product roadmap to accommodate any minor or major pivots.