The guide to outsourcing a digital minimum viable product

This is a mega post on outsourcing a digital Minimum Viable Product to test the viability of your idea with real customers. This would be a great read if you're looking to build an MVP for your startup or enterprise and don't have much experience from outsourcing technical projects.

This post is divided into 6 chapters:

1. Keeping it real with Minimum Viable Product
2. Scoping your MVP using User Story Mapping
3. Writing a request for proposal
4. Finding a great partner for outsourcing your MVP
5. Tips for writing an outsourcing contract
6. Managing an outsourcing project

1. Keeping it real with Minimum Viable Product

Let's take a look at how and why you should try to go minimal when building a minimum viable product (MVP) application. Yes, I know, it's in the name. But let's dig a bit deeper!

"The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." — Eric Ries, Author of The Lean Startup

The purpose of an MVP is to test the market viability and learn about your customers. Your MVP should have just the bare minimum features needed to deliver that value and get your customer to part with their money.

Staying focused

When you're close to the idea it is easy to get carried away and start adding cool features. Try to avoid this at all cost. I've noticed that it is a good habit to write down the ideas for later to get them out of your head. This will help you let go and keep focused on the core value delivering features.

Keeping the scope small and manageable will maximize the chances of MVP project success. It is far easier to successfully execute a tight, well-defined MVP than a complex, monstrosity of an app. This will, as well, minimize your losses in case your MVP flops or turns out non-viable.

You should aim to get to an MVP which you can build and launch within a few weeks to a maximum of a couple of months. Generally, that should be enough time to build most MVPs. If it takes longer, you're likely building something that is too big i.e. a much riskier investment.

Exercise in minimalism

Let's assume you have a clear idea of what is the problem you are solving. Next, you will want to drill down to find the core of your product that is just enough.

Unfortunately, there is no secret shortcut or strategy that will let you come out with the correct feature set every time. Ultimately, you'll have to interact with your future customers to find out where the sweet spot is.

We've used the following process successfully to establish which features should be included in an MVP:

• Create a list of product features that will solve your client's problem.
• Step into your customers' shoes and see what is the bare minimum feature set that will deliver the value.
• Get in touch with your future users and see if they agree. If you can, try pre-selling to validate the value proposition of the minimal feature set.
• Iterate points 2 and 3 until you have validated the minimum set of features.

Essentially, you will be repeating this process after you have your first MVP out. Take in user feedback (learning) and release new versions to address that and better serve your users.

Detecting non-essential features

Even with the best intentions of whittling down your product, you easily end up having too many features. Here are a couple of ways to spot features, which you should cut:

• For each feature you intend to put in your MVP, think: “can I still deliver the value if I do not have this?”. If you can, then cut the feature.
• The feature was added as a result of "It would be nice/cool/great to have X...". These are often nice-to-have features that are not critical to your MVP.
• The customer is saying "If your product had an integration with X, then I would pay...". The integration is probably not what you need. It might be a warning sign that the core value of your product is not high enough.

This should help you keep it minimal when it comes to building your first MVP!

2. Scoping your MVP using User Story Mapping

In the previous chapter, we took a look at why you want to keep your MVP scope minimal and some ways to come up with the core features. This chapter will dive into how you can put it down on paper following loosely the User Story Mapping method coined by Jeff Patton.

A solid product scope document is a critical part of an MVP project. You need to be able to describe your idea to stakeholders, be it people inside your company or an outsourcing partner. Especially if you are starting work with a new partner, you have to assume anything you have not written down in your scope document, will not get built.

Generally speaking, the less you pay for the outsourcing, the more effort you have to put into building a very detailed definition document and managing the development process to ensure quality output. We will get back to this in a later chapter when we talk about finding a partner.

Enter user story mapping

There are several ways to approach scoping your product. In this article, I will introduce you to user story mapping. User stories help you step into your user's shoes and see the product from their eyes.

This is a good technique to enable you to describe your product in great detail. Which is exactly what we are looking for. I will be using Tinder as a fairly simple example here.

If you are right now going through the process, it's time to whip out your favorite word processor and start typing.

1. Define the primary goal/benefit of your product and write it out. For Tinder,this could be: "Users can find and connect with people, who find each other mutually romantically interesting."
2. Define the main high-level process to achieve the primary goal. Visualize how you as a user of your app would go through this process and write it down. In Tinder's case it could be:

• User signs up
• User sets their interests/settings
• User can browse through profiles matching their interests/settings
• User can indicate interest/disinterest per profile
• User will get notified when there is a "match" indicating mutual interest
• User can chat with matches

3. Focus on each step of the process at a time and write down a list of features available in that step. You should try to visualize yourself using the app. It might help to draw each step on paper.

• Identify and prioritize critical features and put them on top.
• Clean up and add more details.

You will want to be very specific about how each step works. For example, in the signup step, you have to answer questions like:

• How does the user initiate this step (e.g. opens app, tap a button)?
• What does the user see first? Are there animations?
  What info should be collected at this stage (e.g. name, email, password)?
• How will each piece of information be collected (e.g. text field, dropdown, third party integration like FB login)?
• What happens when they submit the form? Possible error messages?

This is the user story for the core flow of your application. Next, you will want to repeat this process for each feature of your MVP until you have described the whole app. In the end, you should have a document detailing all the possible use cases for your application.

3. Writing a request for proposal

In the previous chapter, we looked at how you can scope your product using user stories. This chapter's topic is writing a request for proposal (RFP). This is the document you will be sending to potential outsourcing partners.

The purpose of the RFP is to describe the services you're looking to acquire in detail. You'll want to include your scope document as an attachment as well.

Next, we will go over the key sections a killer RFP should cover. Get your word processor warmed up!

Project overview & background

This is the standard start, where you give an overview of your project and some background info. You should tell a bit about the project, your company, why this project is being considered and an overview of the goals.

Project goals and target audience

Explain what you plan to accomplish and what will be the expected outcome of the project. You should also describe your target audience as this will help the vendor to understand requirements better.

Scope of work

The Scope of work describes the services you're looking to purchase. This will be the design and development of your MVP as well as any additional services you might wish to purchase. For example, you might want to include a landing page and a hosting solution on top of the design and development work.

Scope of product & technical requirements

Here you'll want to reference your scope definition document that describes your product. In addition, you should describe the technical requirements of your project. E.g. device/browser support and testing, future scaling needs and the use of a viable technology stack for going forward.

One important MVP-specific technical requirement is tracking. The purpose of an MVP is to gather learnings about your users. You should have a way to track what your users do. This could go from a simple Google Analytics setup to a complex Mixpanel/Kissmetrics integration depending on your budget and needs.

This is a part where you should be looking for technical help to ensure things are in order. It could be a qualified friend or an outside consultant. In the full course, my RFP template includes some valid example technology stacks, with PROs and CONs listed. But still, every project is different and one size rarely fits all when it comes to building digital services.

Timeline

You should describe the timeline you'd expect to get the project done in. A smart strategy is to ask the vendor to divide the whole project into small deliverable parts and have a deadline and separate payment for each stage. This enables you to see how things are progressing and if the work is satisfactory without investing in the whole thing at once.

Point of contact

Here you will let them know who to be in touch with regarding the project and who has the final say on decisions. It is critical that your vendor has easy access to the person who can do the decisions.

Budget

Yes, you should really put in a budget - at least a rough figure. MVPs are like cars or houses. You can get a crappy one on the cheap. For a luxurious end-product, you'll be paying a lot more of course.

You should be up-front about how much you're willing to spend, this saves time on both ends. You won't spend time reading proposals that are too expensive for you. And on the other hand, vendors do not waste time writing proposal out of your budget range.

If you cannot trust your future vendors to not screw you over with pricing, maybe you are looking at the wrong vendors. Trust is a key part of a successful outsourcing project. If you don't have that from the start, then you're already going down a perilous path.

Additionally, having all offers come in with similar price-points makes it much easier to compare the offers. For example, someone might throw in a round of user testing whereas the other just offers the features.

Support/retainer

Once the MVP is launched, you will want to secure help fixing bugs, improving existing features or adding new ones. In the future, you might be looking to hire your own team to work on the product. But to support the MVP and facilitate the transition, you should have the option to continue the relationship with the partner.

Criteria for selection

You should let the vendors know what are the key criteria for selection. Depending on your specific situation this might be a combination of cost, timeline, previous experience from similar projects, demonstratable know-how in some specific area etc.

Format & proposal timeline

Here you should let the vendors know in what format and on what date you'd be looking to get the proposals in.

Now you have an understanding of what a comprehensive RFP could look like. Writing a great RFP from ground-up is no small task. It could take you anywhere from four hours to a few days of work.

4. Finding a great partner for outsourcing your MVP

In the previous chapter, we looked into what a comprehensive RFP should contain. In this chapter we will be going over how to find, vet and choose your future partner.

Finding the right partner for your MVP outsourcing is perhaps the most critical part of the process. This is going to be a long one.

The process

A thorough process could look like this:

• Come up with a list of potential candidates
• Do a preliminary round of vetting
• Send out the RFP to the vendors who passed
• Vet the received proposals and select the final candidates
• Do further vetting on those
• If you have the budget, run a proof of concept project with your favorite 2-5 candidates
• Trust your instincts above all else. If something doesn't feel right, do not proceed :)

But first, let's take a quick detour to right a common misconception people have about outsourcing development...

Cheap, good & fast

One of the major fallacies people have about outsourcing software is that all software is built equal. You cannot get something that is cheap, good quality and delivered fast - having all three qualities in one vendor is just a bit more likely than winning the lottery. You will have to be prepared to compromise on at least one of the qualities. Let's look at it through an analogy of building a house.

You can spend a little money on a cheap labor contractor to build your house. You'll have to probably describe your house in great detail to get what you want. If you do not specifically request you'd like a roof and a door - you might be missing both! And still it will have problems like leaky pipes (you forgot to specifically say they should not be leaky), toilets not flushing and lights working only half of the time. The project ran late as well as you might have guessed... In the next year when you decide to build that second floor, the new contractor says that the foundings are not strong enough and the whole house needs to be rebuilt. It was cheap to start with, but in the end, you ended up paying more.

Alternatively, you reach out to a well-known, and yes expensive as well, contractor and let them know your wishes. They understand your demands and execute your vision with speed. You will have a beautiful house, where everything works. And the project is on time. They even went beyond expectations and included a beautiful hand-carved nameplate on your door. Next year, the second-floor project will be done at ease as the foundings are rock-solid.

This is how it is with software as well. You will VERY likely be getting what you pay for. There are exceptions to this, but that is leaving things to luck and guesswork.

The takeaway from this detour is - if you are looking to outsource to the cheaper developers, you really have to put in the effort beforehand to ensure there will be a door and a roof to your house. :)

Types of vendors

Generally, there are three types of vendors to choose from when outsourcing your MVP. Any of the choices can work for your project, but I'll give you some pros and cons of each below to make it easier to pick the best for you.

Freelancers:

• [+] can be cheaper
• [+] work with one person, easy to build a relationship
• [+] fast-moving
• [-] riskier, can disappear / no support going forward
• [-] lack of resources building something larger

Small agencies (~2-15)

• [+] move fast still
• [+] work with a team, still able to build a relationship
• [+] more resources
• [-] can be more costly than a freelancer

Large agencies/companies (15+)

• [+] lots of resources
• [-] harder to have a good relationship, people change
• [-] quality changes depending on the team (previous references not indicative of future success)
• [-] more overhead, costly
• [-] move slow

Finding vendors

The best way to find great candidates is by a recommendation from somebody you know and trust. Especially if they have actually worked with the vendor before and are basing the recommendation on that experience. If it's just a word-of-mouth recommendation, then you might want to take the recommendation with a grain of salt - particularly if it's a larger company. As you might just get unlucky and have an incompetent team working on your product.

Another option is to use communities you're a part of to ask for recommendations. Think Facebook groups you're a member of, your housing association meeting or the folks at your yoga club for example.

If recommendations don't bring up anything, then you'll have to trust the internet. If you're looking to find a freelancer you'll have many, many sites available (Upwork, Elance, Craigslist, etc.). For finding agencies or companies, you can turn to google. You can find quite a few agencies focusing on building MVPs with a proven track record. Search terms could be "startup agency" or "mvp startup agency" for example.

Vetting vendors before sending RFP

The first round of vetting should be a quick check to see if they have a decent website and some previous work shown. You should find links to actual live products you can play with. It's a definite red-flag if you cannot find any projects to play with. If you have a technical friend available, you could ask them to take a look at the technology side of the reference projects.

Vetting after receiving proposals

When you start receiving proposals, you should carefully go over them and see how well they match your requirements. Then you'll pick the ones that seem to be the best fit for your project and proceed to vet them further. The further vetting would include contacting previous clients for comments and in-person meetings with the person/team you'd be working with.

Next step would depend on your budget. Nothing really beats actually trying out each candidate for a small proof of concept project to see how they fare. If you have the budget, you should hire your top 2-5 candidates and have them all complete the same, small piece of your product. Then you can assess the work and the experience of working with each vendor.

With these steps completed, you should have a good chance of having found a great partner!

5. Tips for writing an outsourcing contract

In the chapter we talked about finding and vetting your future partner. In this chapter, we'll be looking at how to seal the deal with a solid contract.

The project is starting to look good to go. Next, you must prepare for the case that despite all your efforts some problems arise during the project.

If you're working with an experienced partner, they will probably have their own contract that they will be looking to use. In fact, seeing their contract or lack of can be one more step in the vetting process. In case you're working with a freelancer, you might need to come up with your own contract.

In any case, it is wise to involve a lawyer in the process. Depending on the depth of your war chest, you might wish to engage an experienced contract lawyer from the get-go. A more economical option is to get the contract as far as possible just between you and your chosen partner. Then at the end of the process hire a lawyer to check and fix potential problems.

Let's go over some of the key points your contract should cover.

• The contract should explicitly state what you're hiring the vendor to do. This should summarize and reference the request for proposal as well as the definition document.
• Define the responsibilities of each party and what happens when there are problems (delays, disagreements, etc.).
• You will want to ensure the transfer of immaterial rights on payment. You will want to have the contract be very clear that you or your company will be owning the IP rights to all deliverables produced (code, graphics, etc.).
• Non-disclosure. You will want to ensure your confidential information is not used in a way that you don't want.
• Testing and fixing of bugs. You will want to touch on how your MVP is tested and how bugfixes are handled.
• Dispute resolution. How and under which law and where are possible the disputes resolved.

In case you have to come up with your own contract and lack the resources to hire a lawyer to do it, you can scour the internet for templates. With a lot of time and effort, you can put together a reasonable contract on your own as well. Still, it's best to involve a local lawyer to ensure it's valid in your and your vendor's countries. A very lightweight starting point could be Contract Killer by Stuff & Nonsense.

Especially if you're looking to get funded, it could be critical that your contract is well thought out and covers your bases properly. Investors could view the lack of proper contracts as a risk they don't want to take.

6. Managing an outsourcing project

There are many ways to run a successful outsourcing project. Some principles, however, hold for most projects. I've put down some key ideas here to help you tackle your project.

Build a relationship

Building good relationships with your developers and designers will make or break the project. You will want to personally know the people working on your project. You should talk with each one to ensure they are on board with your vision. Having a good and easygoing relationship will ensure they will not keep you in the dark when there are problems - which are sure to come up in any project. You want your team to be open and upfront about problems so they can be sorted quickly.

Depending on the type of partner you are starting your work with, they might have a project manager manage your resources in their end. This can be riskier than building real relationships with the actual people, who are doing the heavy lifting in the project. Adding more layers will slow things down and you risk suffering from the broken phone effect where the extra layer of communication changes the message on the way.

In some cases, you might have a team of developers who need a manager because they don't understand your business or do not speak your language. Then there's no choice. But in that case, you really should consider another option/team.

To build relationships you need to communicate well. Meeting your team and treating them to dinner can be a powerful way to start the relationship. If this is not possible, try to arrange for a personal call with each member. Remember to give your team feedback and praise when appropriate.

The larger the project is, the more critical it will be to retain the people working on your project. Developers are not cogs in a machine. Having to replace people WILL slow your project - no matter what your outsourcing partner says. Also, the quality of work suffers greatly when there is no ownership of the code. You will want to keep your team together.

Remote work & communication

When you are outsourcing your MVP development, it is likely you are working with a remote team. Below are some best practices on successful remote work:

• Get to know each person, it will make remote work much easier
• Ensure sufficient timezone overlap (min. 2-4h would be best)
• Use project management software to stay on top and monitor progress (Basecamp, Jira, Trello, Asana, Github Issues, Linear... anything that works for you)
• Have set communication channels (e.g. Slack for day-to-day communication, Skype for facet-to-face meetings)
• Communicate asynchronously, interrupting developers every time you want to ask something will cost money & frustrate your team

The work process

You should ensure an open and interactive development process. This means that you should have access to the product being built from week one. You don't want to close yourself from your product and hope that all is well. You need to be involved in testing and using your future product. Have your friends and associates try it as well.

This enables you to see progress and help your team iterate on features as they are being built. It is much more efficient to fix things the moment they start going wrong.

Also, for usability testing on the cheap, you should let your mother and father try your product. This is a surefire way to find and fix a lot of usability problems. :)

Choosing technologies

Choosing popular and opinionated technologies is especially critical for product owners with no technical background as you cannot evaluate your vendor's technology choices.

1. Popular and open source means that you should have sane technologies and no vendor-lock in.
2. This will make your MVP more approachable for your own future team. Finding developers with relevant skills will be much easier.
3. A strongly opinionated framework (e.g. Next.js, Rails/Ember/etc.) will ensure that most choices regarding architecture are dictated by the framework (safer)
4. These frameworks often let you build faster as the focus is on business logic and not on the configuration.

You can find some inspiration at TechStacks.

With these tips, you should have a better chance to outsource your startups or enterprises MVP. :)