MVP Scope of Work [by Jobresponse]

Why Scope of Work?

If you’re looking to build an MVP, you’re most likely going to use (in part or in full) the outsourced resources. Whether working with a freelancer or a development agency, a well-crafted SoW will get you the expected results.

Scope of work gives ground for a thought thinking process when you assess a vendor and hints at what to expect from the partnership. Many founders come with Figma designs, but it’s not enough. Moreover, it is premature. The design should come after you do your homework on outlining the product specifications. However, you may want to showcase some of your mockups to your early adopters, but the interface design could not solely raise ground for the scope of work.

The Scope of Work is very similar to PRD (product requirements document) and SRS (software requirements specification). It is just a style of calling the same document with different names at different companies.

Goals of SoW

It is okay if you’re looking for an estimate at this stage, and you can ask the vendors for it at this stage. But remember that an estimate at this stage is still an approximation, a ballpark price range. Best vendors won’t give you an estimate, but you can ask what the budget for something similar may look like.

The only goal of the SoW is to start the conversation. It is how you can vet vendors. It is your job to ensure the success of the project. You only have one shot, while for vendors, it is yet another project that won’t kill the company if it fails.

What’s the use of the SoW?

The SoW helps to keep you on the same page with a vendor. A software vendor that works with startups can help you define a better implementation around your product. So go ahead, craft your SoW and start assessing the vendors.

What to include in SoW

Here is the high-level plan:

INTRODUCTION

Start your SoW with the proper introduction of the challenge your product is supposed to fix—the audience and similar solutions on the market. Make the reader dive into what you are trying to improve.

SOLUTION

How is your product supposed to fix the problem? A mobile or web application that is supposed to improve X, save $$, or make better Y. A few paragraphs can help the reader understand the field and industry and think about your product more thoroughly.

Because you’re looking for an outsourcing partner, you won’t be able to change them easily down the line. The mistake here entails a long and brutal process, so ensuring the requirements cover all aspects raises the project’s success rate.

REQUIREMENTS

This section will require you to think but not overthink. Too few details can make your vendor not understand it; too many details can make your vendor overestimate the project. In both cases, you’ll end up with huge numbers in the estimate, and the former will be built on assumptions only.

Outline the functions of your solution, explaining how a user will interact with an app. What a user can accomplish and what features are there will be available. Having a thorough feature list is good, but don’t overthink it at this stage. It’s a high-level plan and should help you and the vendor find common ground to work together.

An easy way to not overthink is to define just one killer feature the app suppose to do and go from it.

Make a functions list:

• User Registration
• Onboarding flow
• User account
• Search bar across all screens
• Filter functions
• Main feed
• Product page
• Check out

Make a detailed data structure per each function:

And so on, you got the idea.

If you have the designs or wireframes, write down some user-system interacting scenarios.

• User taps X - a system responds Y

TIMELINE

In this section, outline some of your thoughts on the timeline. Remember one simple thing: you can only plan your project against three things: timeline, budget, and features. One of these should always be capped. For example:

• The project has a fixed timeline: then your vendor should get you whatever they’ll be able to deliver in the given timeline. Obviously, to deliver in the given timeline, the vendor may propose to increase the budget or cut features. (Remember, nine women can not deliver a baby in 1 month).
• The project has a fixed budget: then your vendor should deliver on a fixed budget. This may be a trap if your requirements may change down the road (which they always do). Remember that we’ve sent them high-level requirements. Be careful if a vendor says they deliver on a fixed bid — this is not always true. The most harmless that can happen is that the vendor can deliver the product later but still within the same budget and features.
• The project has fixed features: then your vendor should deliver that volume of work no matter how long and how much it takes. You may not want this as it is not a fit for a startup.

As a general rule of thumb, it is recommended that you ship MVP no less than three months, so keep that component capped. Although we’re waiting for an estimate from a vendor, your best estimate is what the dev team burns per month. 3X this number, and you’ll get the estimate of your MVP.

Of course, not all MVPs are delivered in 3 months. Some take more, and some take less. Just be realistic about the timeline. Keep in mind that the more the challenge, the more team members a vendor may propose to hit the goal, but too many engineers are good for not all projects.

Furthermore, three months of delivery is not three months of development. There is a time for the team to onboard, speed up, and run tests after the development. Communications eat up to 10% of the time too. If you choose a good partner, you won’t worry about the delivery time. Virtually (don’t tell this to the vendor), the timeline is tentative in the projects without a full set of specs. You’ll need to build enough trust with the vendor for them to deliver as close as possible. If it’s a week or two later, it’s okay. But if the timeline is ever-shifting, something is not right here.

TECH STACK

If you defined a tech stack, outline your assumptions in this section. You may also ask for a vendor’s input here, so they propose what tech stack they usually are building with. If you prefer the app built with a particular technology, make sure the vendor has that as their expertise. Include any information that is relevant to your product tech stack, including third-party services and APIs.

ACCEPTANCE

Acceptance testing is gold. This will highly impact the estimate. If the project is large and complicated, you should outline what kind of acceptance tests you will be running and what the results should be. MVP may not be as complicated to make full-scale tests as you’d typically do for large-scale enterprise applications. A vendor team usually includes QA to go through the app and ensure all works, but sometimes, this work can be done by a project manager or you if you’d like to save on budget. This section defines your expectation, so make sure you communicate them to a vendor.

CLOSING NOTES

It’s time to finalize the SoW and discuss what you expect from the vendor. Outline what type of dev style you prefer, the business and dev environments you prefer to work in, what the estimate should look like, what the estimate should include, etc.

It is not necessarily that you need to include all aforementioned sections in your SoW. There is still agility to keep it high-level or go hardcore in tech details. Most of the time, it depends on the complexity of the project and is followed by way of implementation.

NEXT STEPS

This section outlines what will happen next after they submit the estimate. Keep the vendor engaged within your process, and show them you are looking for a long-term partner.

If done right, you’ll get some great responses and estimates of your project from professional teams who are your potential partners and can help get your product out there for users to start using it.

The Scope of Work is a great exercise to set out the product assumptions and intend to be the first step. However, you can skip this step and let the vendor do the job for you, but this would mean that you’re stepping right into the direct engagement with the partner. The good news is that you and the vendor can agree to work on the Design Sprint, which isn’t considered a product development phase but the one that comes before the main phase.

We’re covering the Design Sprint [by Jobresponse] in our following note.