When to Outsource vs. Build an Internal Team
You’ve got an idea for a product. You’ve validated it with user testing (If you haven’t, check out 10 Simple Steps to End User Testing). Now how do you get this product to market?
I engage with a lot of clients that are at these very early stages. They may be just validating a product idea, or be creating their strategy for raising funding and want to scope out the effort it will take to get a product idea to market. These are very consultative conversations, but at a point they shift to execution. Who will bring this product to market? How will they do it? And when will it be ready?
A fork in the road emerges shortly after deciding to build a product. The question is, “Should I work with a product development partner to build this product, or should I start building my own internal dev team?” So rather than offering a prescription for how to bring a product to market, I’d like to offer some things to consider. I know that no two clients or products are exactly alike, but there are some common activities and ideas for how to get the product to market in the most efficient manner possible. The key word being efficient. When bringing a product to market, you want to move as quickly as possible being conscious of your burn rate. Similar to saying “Stop looking for Mr. Right and start looking for Mr. Right Now,” this isn’t your long term ideal team or process, but for right now it will get you where you need to go and put you in a great position to succeed in the future. Who knows, Mr. Right Now may turn into Mr. Right in the end!
Here are 5 considerations you should think about when trying to determine the best team structure for you and your product:
Time & Budget
When time and budget are tight it’s often a good opportunity to partner with a team who can quickly get your first release to market within your time and budget constraints. Because product development partners are poised to ramp up quickly and good teams will have proven methodologies already in place for bringing products to market, this is a way to quickly get a first release to market while controlling time and in the end having a more stable monthly burn.
If you choose to start building your internal team, be sure to take into account the time to find the right people and allow the team to mesh. You should also be sure to have at least 1 team member either internal or through a partner who is experienced with some form of product development methodologies. Common methodologies are Scrum, Kanban or Xtreme Programming, all of which are forms of agile development that focus on iterative development and continuous feedback.
Core Components vs. “Packaging”
If you have an offering where there is a core component or piece of core IP, consider ramping up your internal team around this core component and allowing a partner to build the “packaging” around the IP. This will allow you to control the most important part of the product, but also utilize the speed an experienced team can provide. By all means, this doesn’t mean you can’t eventually transition to your own internal team, but with so many moving parts when launching a product you should consider when is the right time to make that transition. Utilizing product development partners can also be a great tool to help glean best practices that you may want to inoculate your team with in the future.
Length of Engagement
When considering your ideal team structure you should also consider how long you will need this expertise. For example, you may burn hot with a 3 person iOS team for the first 3-4 months, but after the initial release is completed you may really only need 1-2 developers full time. If you’ve hired these team members as full time hires you may be in a predicament trying to determine if you should let them go or “find work” for them to do. If you work with a partner you can easily ramp the size of the team up or down based on need without having to worry about downsizing your core team, possibly disrupting morale, or momentum.
Team Experience (Process/Methodology)
As mentioned above, one of the most common indirect benefits of working with a partner is gleaning process and methodology best practices. This may not seem like a big deal, but if you have a junior team or even an experienced team with varying backgrounds, this could be the difference between success and failure. It’s easy to become unfocused and have scope creep especially if the entire team (business and dev teams included) is not bought into the same processes for moving forward. Ensure you have someone on your team, internal or external, who can lead this charge and ensure best practices are being followed. Trust in the process and you will be rewarded quickly with demoable product in a matter of weeks rather than months,not to mention any changes can be worked in quickly rather than waiting until the next big release.
Outsourcing Does Not Equal Offshoring
I hear a lot of people misconstrue the term outsource for offshore. In some cases this is true. If you outsource, it may be financially attractive for you to work with a team in a different country. This is not the only option, though. There are plenty of organizations that offer onshore development teams or a mixture of on and offshore resources. A model that I’m familiar with and that seems to work out nicely by balancing on and offshore team members is utilizing a Product Manager onshore who can work closely with the clients and also with an Engineering Manager offshore who can manage the dev team locally. This set-up allows you to still have high touch communication while benefitting from lower monthly costs over an all onshore team.
When looking to bring a validated product to market, consider the above items in reference to your product and your team’s experience in order to determine the best team structure to get your product in the hands of your users as soon as possible. Remember that there is 1 goal, to get your product to market, and many paths to get there. Not every path will work for every company so be self-aware of where you have experience and where you may benefit from a partner’s expertise.