Can You Outsource and Still Build a Great Product?

< blog


Can You Outsource and Still Build a Great Product?

There is a typical pattern of what goes wrong when outsourcing. Here are the easy, vital steps to prevent it.

I have saved a few clients and friends from rather sticky situations after outsourcing their development. Is this because all outsourced development is destined to go wrong? Do agencies and freelance developers just not care about the quality of your product?  - I would like to think the answer is no to these questions in most cases. There are some very important steps to take though, if you want your outsourced development to go right first time, no money wasted and no nervous breakdowns along the way.

Step 1: Don't skip the discovery phase

This is absolutely the biggest mistake I see happen over and over again.

You have a great idea for an app, a website, a wearable, whatever and you have already decided that everything is wonderful about that idea. Based on the echo chamber of your own team, your friends, your mother, but not based on actual hard evidence.

Use your idea as just the starting point to then find out if it will work in the real world BEFORE you approach developers with a scope:

  • Who will your first users be? - What country/city, what age range, what job types etc (known as “Demographics” or within digital UX  “Personas”)
  • Does your initial scope idea match their needs and solve an important problem for them?
  • Does your competition already solve this problem? - and if so are you going to do it significantly better?
  • Is your product clear to your user demographic? - Do they understand what it is for and how to use it straight away?
  • How should the end user emotionally feel around your product? - Is it something that should feel exclusive, relaxing, motivating ...

Although lots of fun if done well, a discovery phase is not simple. There are many challenges involved, so I highly recommend ensuring you have an experienced team member involved in the process, or hire an expert to help you with this phase.

This will ensure you have a good start point. It is absolutely a false economy to skip this stage and rush ahead. “Technical Debt” is usually the result of starting with poor investigation and then getting to a point where it is wildly expensive to fix issues that should have been foreseen.

Step 2: Prototype it

Are you really so sure your idea is going to be successful that you are ready to fork out 10, 20, 50k to develop it now? It is always cheaper to make sure that the general concept, the branding and the high level customer journey actually work for your user by prototyping first.

A prototype of your app or website will save you tons of development time later. Get your prototype into the hands of users. Watch potential customers with your product and you will see the same areas of confusion and the same blockers over and over again. This gives you a chance to go back to the drawing board quickly and easily without having to pay developers for a change to the scope.

Again, don't scrimp on this stage, if you don't have an expert in-house make sure you hire help with this stage. You will know a real UX expert by:

  • How they explain their process
  • Knowing that quality and cost are key to clients and adhere to UX scoping in a prototype phase to keep costs down and quality high.
  • Experience, experience, experience. Junior UX staff are fine and have their place in growing companies, but basing an important project/product on one who is straight off a UX 101 online diploma is destined to fail.

Step 3: Don't believe everything you hear

Once you are ready to seek out the right development team, it is likely you have a figure in mind that you want to pay for development. This figure will be based on what you can afford, what you want to pay or what you have been told is budget by finance or stakeholders, and not based on any calculated estimates. If you have a fixed budget and a developer or agency says you'll have your cake and eat it too. They are usually lying. Not that they may not believe it too, but developers are optimistic people who rarely add in margins for what they don't know today. Others genuinely know that you won't get what you want, but see a foot in the door today that gets them a big cheque to clear their conscience later.

Here's the way to avoid this happening. It is almost impossible to come up with an accurate cost estimate for the whole product development at this stage. There are just too many unknowns. The only way you can budget is make sure that you scope out your MVP (Minimum Viable Product). Ensure that you are prioritizing only the features that must happen first. Then PAY your developers for a bucket of hours to thoroughly investigate this scope and add all of their technical details. With this kind of investigative work done at scoping time you can have a pretty accurate estimate for the MVP scope.

Not only will this save you time and money later, but it will save a lot of stress and arguments between you and your developers due to delays of 6 months or more and at triple the originally quoted price.

Step 4: Have a Product Manager

You know what developers are great at? - Developing. You know what they are less great at? - Managing staff, client relations, budgeting. "The developers just don't tell me what is going on!" - is a statement I hear a lot from unhappy entrepreneurs. That is because they are busy programming. It is therefore essential to have a Product Manager on the team (called a Product Owner if you are using Scrum). If you have the experience and the time to be that person, great. If not make sure you hire one as part of your outsourced team or separately. A Product Owner can be freelance themselves and not necessarily part of an agency. I have led many projects at the highest levels as a freelance consultant. Having this person outsourced rather than in-house can often be cheaper as well! They don’t get paid unless they are working for you, organise their own taxes and should be flexible to your needs to fit in with the team at large.

This person should be responsible for ensuring 

  • Your priorities for development are being met
  • You know how the product will actually look
  • You are aware of what blockers are occurring 
  • Where more time is being spent
  • You are constantly in the loop on if budget is running low 
  • You have options for next steps

Again, saving money by not having this role at the beginning will cost you big time later.

Step 5: Strive for full transparency

You may not be a techy or a designer and that is fine, but regardless you do need to know what is going on every step of the way. Here are a few easy tips for transparency you should expect with your dev team:

  1. Make sure you have a login to the project management tool and can have a look at the backlog (the list of features to be developed) at any time.
  2. Ensure that when you read these items in the backlog (called stories) that they make sense to you and you understand the tasks well enough to be able to discuss changing prioritizations with your product manager if they aren't to your liking.
  3. Make sure you have access to the code repository (github or whatever). You may not need it right now, but remember this code is yours.
  4. Ensure you have scheduled weekly or biweekly meetings with your Product Manager and dev team to understand progress and see how the development is progressing (Called a sprint review if you are using scrum).
  5. Ensure you have a login to a time tracking tool that your devs use, so that you can see where the hours are being spent. For example you may see too many hours being used to upgrade an OS or to fix some bugs, both of which you may want to decide with your PM if they are important right now.
  6. Know what methodology is being used by your team (Kanban, Scrum etc) and know what technologies are being used to create your product. You may not know much about either, but it is your team and PM's responsibility to educate you on the basics, for you to get the most out of the processes involved.
You can make a great product with your own in-house team or outsourced. Bear in mind that even in-house teams hold the same risks. Both need the right processes and investigative steps to make them work well. Skip them at your own peril.
Get in touch for more advice on developing your product the right way.



July 5, 2016

Subscribe to our mailing list