If you're new to software development, you might not be familiar with the idea of product scope or a PRD, or the fact that changing them costs you extra. Here's a resource to help you understand why.
6 October 2021
Although it has a reputation for rapid innovation and constant upheaval, today’s software development industry is really a mature, established market. Tech giants have been building and maintaining large-scale software products for decades now, and even young upstarts and disruptors tend to follow a clearly defined process for raising money and growing their teams.
One side effect of this stability is that software buyers and sellers have settled on a common understanding about how app development should work. In other words, before development even begins, engineering teams generally have a clear sense of what they need to deliver, and software buyers know what results they can expect.
The key concept that enables buyers and sellers to reach this understanding is called product scope. In software development, product scope refers to the sum total of all features and characteristics that a finished product should contain.
A product’s scope is usually defined in a document called a product requirements document, or PRD. When a development team produces a PRD and a buyer approves it, that PRD officially represents the full scope of work that the development team is contractually obligated to produce.
If you’re new to software development, you might not be familiar with the idea of product scope or a PRD. When you hire a team to build an application for you for the first time, the following questions might come up:
These are all important questions to ask in advance of a software build.
A software development transaction might seem simple at first: you pay developers to build an app, and the developers build that app for you. In reality, though, describing the specific details of the transaction can get very complicated, very quickly.
For example, let’s say you want to build a food delivery app that is similar to DoorDash or GrubHub. This might seem straightforward at first: the app should help customers order food from a restaurant, and it should help the restaurant fulfill those orders.
But what devices should the restaurant’s customers use to access the app? iPhone, Android, or both? It will cost more to support both platforms and even more to add a web app. Will restaurants upload their menus? Will these menus include pictures? Does the app accept credit card payments? How should customers create accounts? Do you want to integrate social media login? If so, which social media platforms do you want to include?
The list goes on, and each of these considerations has an impact on the time and labor it will take to build your application.
If you don’t explicitly define every single desired feature for the development team, then the team will probably fail to build the product you want. You might assume that developers should know which basic features to include in most apps, but there’s simply too much risk involved in guessing about a client’s needs.
For example, if the team assumes that you want a handful of features that you never mentioned, then they may end up adding unnecessary features to the app and blowing out your budget. Conversely, they may include too few features and deliver a product that you consider inadequate.
Every feature included in your product scope affects the total cost and timeline required to build the application. This is why development teams and clients agree to product scope beforehand: it ensures that the correct product is built, and that the correct price is paid for that product.
Imagine that you’ve paid a construction crew to build a 4-bedroom, 2-bathroom house that is a total of 2,000 square feet. After a few months, when the crew has already installed a foundation, framed the walls, added insulation, and finished the siding, you decide that you would like to add an extra bedroom and bathroom that will increase the home’s size by another 400 square feet.
As you might expect, the construction crew would charge you extra money for the added labor required to build this new section. They would also delay your move-in date, because the additional work will take more time. And since your new addition requires them to reconfigure the home’s existing plumbing and wiring, they may charge a higher hourly rate to account for the added complication and planning.
Building a software application is no different. When you change your product’s scope, you’re changing the features that were agreed upon at the time of purchase. In essence, you are changing the product that you intend to buy while it is being built.
The development team will require added labor costs to add or change features, and they will need to take extra time to write new code that wasn’t part of the original build plan. Depending on how far along they are in your build, it might require a large amount of added labor and testing to retrofit the existing codebase with your requested features.
This is why it is a widespread practice to revise an application’s overall cost and delivery date in response to scope changes – usually in the direction of a more expensive app that is delivered at a later date.
This doesn’t mean that once development has begun, you’re locked into the features listed in the PRD. Scope changes are a natural part of software development, and all veteran engineering teams are used to shifting their build plan to account for unanticipated changes.
To formally request a scope change, you should speak to the product manager or project manager who is overseeing your app’s build. Specifically explain which desired new feature(s) are not included in the current build plan. Confirm that the current PRD does not include this feature (or one that is close enough), and ask for the PM’s opinion on how to best achieve the missing functionality.
Once you and the PM have reached a clear understanding of the changes to be made, they will separately consult with their developers about the projected cost and timeline impacts. The PM will then get back to you with your revised scope for your approval.
It is your PM’s responsibility to provide you with a clear and detailed explanation of how your requested changes will impact timeline and cost. If you are unclear on any element of your revised scope, don’t hesitate to ask your PM for clarification.
Although scope changes can introduce more work for development teams, most PMs prefer formal scope changes to “scope creep“, or the process of product scope informally expanding due to repeated customer requests. Scope creep can inflate a project’s cost and timeline just as much as official scope changes, but scope creep lacks the benefit of a formal agreement to keep everyone in the loop.
If you’re working with a tight budget or a demanding timeline, you may not be able to afford many changes to your product scope. It is unfortunately common for first-time app buyers to temporarily pause the development of their app because its revised price has exceeded their budget following a scope change.
As a client, there are three things that you can do to limit your risk of ballooning costs and delayed development:
Before you approach a development agency to build your app, make sure to think through as much of your application as possible, including visual design, underlying workflows, data requirements, launch platforms, third-party integrations, and your strategy for selling or using the finished product. The more planning you do in advance, the more comprehensively the team can capture all your app’s necessary features within the PRD.
It can be daunting to plan a custom application without a formal technical background. If you’re wondering where to begin, here’s a useful resource that explains how to write clear, actionable tech specifications.
Both before and during development, take a few minutes to prioritize the features within your app from most important to least important. Generally speaking, the most important features will be those required for the app to function in its most basic form.
Try to be honest with yourself about what is necessary versus what you are most excited about – you can always add cool features to a simple application, but a non-functioning application will be dead on arrival.
Once your app is in development, try adding any new feature ideas to this list to see how important they really are. If they’re not essential, then you might decide to simply store them in a backlog for a future release. Alternatively, you may decide to bump less important features from the list to the backlog and insert your new features in their place.
The following is an all-too-common exchange in the software development industry:
Client: “Why doesn’t my app have Feature X?”
PM: “Feature X wasn’t included in your product scope.”
Client: “Why wasn’t it included? Every product has Feature X.”
PM: “Feature X isn’t necessary for your app to function. You approved the PRD without Feature X in it.”
Client: “But I didn’t know that Feature X wasn’t in there!”
It can be hard to understand a PRD the first time you see one. They usually break your application down into a series of “user stories“, which may not be a common concept to you. On top of that, most PRDs consist of long, bulleted lists, tables, and descriptions – not exactly a thrilling read.
However, the only way that you can know in advance what your app will include is to carefully review your PRD in its entirety. Your PM is counting on you to catch any missing features and ask questions before the build, specifically to avoid any unexpected additions later on.
There’s no shame in taking your time to really sit down and go through your build plan. Ask questions about anything that seems to be missing or inaccurate – you and your PM will be glad that you did.
Product scope exists to provide a common agreement between agencies and clients about what is being built. PMs are accustomed to making small changes to scope after a build commences, but large changes can severely jeopardize the agency-client relationship by introducing unexpected costs and delays.
By diligently planning your app and reviewing your PRD from the start, you can set your application up for maximum success. However, if you find that you need to make changes during the process, your PM is there to help you understand exactly what you can expect.
At Crowdbotics, we’re constantly improving our scoping and re-scoping protocols to ensure that your app build comes in under budget and on time. If you’d like build your app with the help of our expert PMs and developers, just get in touch.
