A major challenge for product teams is how to find quality development partners that align with the goals of the project as well as the budget. In the quest to control costs, the option of using offshore vendors is often considered. It’s a huge decision point, and one that needs to be carefully considered before jumping on that bandwagon. Make the wrong decision, and you can delay or even kill a product. For startups with a single product, that can spell disaster and potentially sink the company.
This is especially treacherous for startups with small budgets who are particularly vulnerable in this situation. Over the years I’ve talked to dozens of founders whose development projects had stalled, or failed entirely, because they selected the wrong offshore vendor.
The story goes much like this:
The founder has raised some funds, often a combination of personal resources and friends and family, but realize that they realize they don’t have enough money to get their product built with local resources. To save money and stretch their runway, they decide to use an offshore team because they believe they can get it done for a fraction of the cost. A year later they still don’t have a completed product, their money has been spent, and they are panicking to get across the finish line.
Raising funds is now the priority instead of launching their product. Unfortunately, with little to show for their efforts, and because they have not been able to validate their product in the market, raising additional funds is nearly impossible and they shut down. So, what went wrong? The details vary from project to project, but include one or more of the following reasons:
Soaring Costs
Projected development costs were attractive, but they were charged for multiple out of scope requirements that blew the budget. With an offshore company, there is little recourse for resolving disputes.
Lack of Plan
Discovery was sketchy, the developers didn’t have a clear path, so the project wandered and what was delivered didn’t work.
Wrong Solutions
Tech stack was the wrong choice. They used an outdated or mismatched framework, or maybe it was a fringe product that has a poor following, so they can’t find onshore teams to finish it.
Poor Design
UI was rough, ugly, incomplete, and unworkable, resulting in a bad user experience, and workflows that were clunky.
Lack of Management
Project management was unprofessional or nonexistent, and the founder didn’t realize things were off track until it was too late to pivot.
Insuffient Code
Code quality was poor, and when they pulled it from the offshore vendor for completion with a competent team, they learned that everything must be scrapped and started over.
Those are just some of the horror stories we’ve heard over the years. So, is this an indictment of all offshore vendors? No, it’s not of course. But the difficulty of the decision that non-technical managers face can be daunting, and a misstep can be disastrous.
Be Cautious of Firms that Outsource to an Offshore Team
One of the things to watch for are firms that have an onshore presence but outsource to an offshore team. And this is where it gets a bit trickier, because there are many really good onshore firms that have partial or full offshore teams that are quite competent. For those firms, project management, design, and other roles are onshore, but some engineering and development is done offshore. In these cases, you get the best of both worlds – management in or close to your time zone with local accountability, but some engineering is done offshore at a lower rate. It’s a hybrid approach that can work very well.
However, problems can arise when a local firm outsources the entire project to an outsource team but isn’t really managing the project. We have seen this many times when the firm you contracted with isn’t fully engaged and is essentially brokering the project. When it goes sideways, you have an even worse problem because you have a middle party that’s not accepting responsibility between you and the people doing the work. Finger pointing and blame shifting begins.
We see this scenario often occurring when you have a web design firm that wants to stretch their capabilities and take advantage of development projects but doesn’t have the technical and project management skills and experience to pull it off seamlessly. So just make sure that you are selecting a firm that has good onshore technical and project management skills and experience, and is fully accountable to you and the process.
Understanding The Product Owner Role
There are many roles needed to build a successful digital product including roles such as a Chief Technology Officer, a Chief Product Officer, a Project Manager, Technical Product Manager, Director of UX/UI and Product Owner. Those people work in concert with each other and the product design and development teams to keep things aligned with the goals of the organization, the product requirements, and the budget. For those teams, using offshore development teams is much less risky.
While all those roles are critical and will need to be fulfilled either by the company, or with a vendor or consultant, hiring all those people is usually out of reach for smaller companies and startups. However, there is one role that founders should consider embracing and potentially fulfilling themselves – the Product Owner.
Creating and building a successful digital product requires a Product Owner.
So, what is a Product Owner?
The Product Owner defines the vision, and is in charge of the features, the backlog, and sprints. The Product Owner isn’t a coder or an engineer, but someone who is the point person that’s responsible for the product is going to become. They evaluate stakeholder feedback, communicates the vision, and prioritizes the objectives.
If you are going to outsource your development to a team, offshore or onshore, having a Product Owner on your team is crucial. This gets even more critical with offshore teams that often like to work autonomously and without accountability.
Founders are notoriously bad Product Owners because they usually are visionaries, but don’t have the experience to manage all the development details. If this is a role that you decide to take on, you will really need to do your homework.
Conclusion
Outsourcing development always has risk, but the risk goes up exponentially when you outsource to an offshore team. Evaluating those vendors can often be challenging, and if you do decide to select and offshore team, make sure that you vet them properly, and have the right controls to ensure that you are getting what you pay for. And consider embracing the Product Owner skillset as a safeguard.