post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

Juan J. Ramirez is a seasoned Product Manager and UX Specialist. He works as a Mobile UX Designer at Procore Technologies in Santa Barbara, California. Previously he was a Product Manager for Seconds.com, Contactive (Acquired by Fuze) and Usuallee. He holds a M.E.T from Carnegie Mellon University. He earned his Bachelor's degree in Business Administration from CESA Business School, in his home country, Colombia. 

Contact him:

<a href="https://www.linkedin.com/in/juanjoseramirez">LinkedIn</a> //

<a href="https://twitter.com/whoisjuan">Twitter</a> //

<a href="http://whoisjuan.me">www.whoisjuan.me</a>.

Juan José Ramírez

<p>If you&#8217;ve ever heard stories about people who tried to develop products with outsourced developers (or if you&#8217;ve tried it yourself), you probably know how cumbersome and frustrating it can be.</p>
<p>The sad reality is that the bad reputation of outsourced development is not entirely unfair, but a lot of the responsibility for that also falls on the product managers outsourcing the development. It may be that you’re getting what you pay for, but it’s equally likely that you’re going into an outsourced development project with dramatically misaligned expectations.</p>
<p>Developing software products overseas or with external teams is probably one of the least profitable ways of developing software, largely because so much of the code written this way needs to be <em>rewritten</em> in later stages. However, it’s also true that, under the right circumstances of management, communication and strategy, outsourced development can be highly profitable &#8211; the key, as with everything, is in understanding exactly where the problems are.</p>
<p>In terms of the total cost of employment, outsourced development is significantly cheaper that developing local / in-house, so there’s a great value opportunity available. However, that’s only true when there’s clarity about how the outsourced development would fit into the strategy of validating a product and, more importantly, when there’s a clear long term strategy (be that a well-designed roadmap or business plan) that accounts for the costs of an evolving product (e.g: Code refactoring, transition steadiness, etc.)</p>
<p>So, in more concrete terms, you might decide to spend half of what an in-house developer would cost you in order to put a concept prototype into the market. There might need to do a lot of code refactoring at a later date, and there might e some slow-down when you transfer this project to an in-house team, but you’ll have validated your market cheaply. Alternatively, you might just throw away the prototype code once it’s done it’s validation job, and build something more maintainable in-house from scratch!</p>
<p>I recently lead a product that was being developed overseas and we successfully launched three versions of this product in record time, learning a lot about working practices along the way!</p>
<h2>Understanding outsource teams</h2>
<p>On the one hand, many of the challenges of working with an external team are not so dissimilar from working with (or building) an internal team. The main differences hinge on communication, domain knowledge, and how invested you and your external team are in each other.</p>
<p>When working with in-house developers, you might try and separate out the processes of hiring, “localising” and getting value from the team. On the other hand, when working with an external team, you’re essentially compressing all of those phases into either a single project or, at best, a high condense time-frame.</p>
<p>With that said, here are seven lessons on how to leverage an outsourced development team, and get the biggest possible return from their work:</p>
<h3>1) Hire a Development Firm or Individual Developer based on a references, not a Google Search</h3>
<p>Finding good external developers (be they overseas or even just in a different city) is a huge challenge. The best way to go about this is by looking for references in your network. Whenever you find someone who is willing to recommend a developer, ask for information about their strengths <em>and their weaknesses</em>. It maybe that someone writes epic code, but isn&#8217;t a great communicator &#8211; that may work for you, but only if you’re aware of that skills balance. An honest, balanced appraisal is essential.</p>
<h3>2) Test your developer for a few weeks</h3>
<p>There’s a reasonable chance of under-performance when you hire an outsourced developer. This might be for reasons of culture, skill, or even a lack of domain knowledge hindering their ability to understand what it is you’re asking for. Try to give them a small warm-up project that would supplement later development.</p>
<p>This is important because the earlier you detect a bad fit, the better. If there’s no good fit, terminate and move on to another developer.</p>
<h3>3) Learn to focus only on what’s critical</h3>
<p>You need to understand that when developing externally, you will usually receive less than what you expect. This is something that sadly seems to come natural to this model, perhaps because many of these firms don’t have the level of investment you might have in pixel-perfect UI fixes and polish.</p>
<p>Adjust your expectations so they match what you’re actually investing in development, and focus your energy in the most critical components and functionalities.</p>
<h3>4) Don’t introduce your bureaucracy into their development flow</h3>
<p>External developers usually don’t care about your Pivotal Tracker / JIRA / Trello + Slack setup. Don’t ask them to learn how to use your stack of management tools, because they either won’t, or they won’t do it well. After all, that’s not what you’re paying them for.</p>
<p>Instead, ask them about what method of communication and tracking they prefer and embrace that tool or system, whatever it is. You will find that it’s easier for you to learn this, and not the other way around.</p>
<h3>5) Get used to the QA role</h3>
<p>When working with outsourced development firms, there’s always the promise of High Standard Quality Assurance. Sadly that promise usually goes unfulfilled to some degree or other. The only way to assure quality is to perform your own testing.</p>
<p>When receiving builds or new releases, focus on the critical components of the software. Don’t assume that certain functionality is working just because it was working in the last release. Things get broken. Test everything!</p>
<h3>6) Be technical, or at least find someone technical to help you</h3>
<p>Just because you’re developing your software externally doesn&#8217;t mean that you get away with not having technical chops. In fact, when developing externally you need more technical skills than ever. The main reason for this is <em>not</em> the classic cynical reason of being played for a fool with technical jargon so the developers can justify their delays.</p>
<p>In reality the reason is simpler &#8211; outsourced developers don’t understand your business logic as well as you, and therefore they need granular and highly technical documentation so they can implement what you’re asking for.</p>
<blockquote><p>I need the software to make a payment when X happens</p></blockquote>
<p>&#8230;doesn&#8217;t necessarily get you anywhere.</p>
<blockquote><p>I need you to write a script that makes a request to this API, and then I need you to store the response in this database field</p></blockquote>
<p>is more likely to get you exactly what you want.</p>
<h3>7) Track the project!</h3>
<p>This is probably the most important lesson we learned. Tracking your project boosts the chances of success and helps you to speed up the development process. The whole purpose of tracking is to have a clear picture of the product state and viable next steps. This is obviously necessary with any team configuration, but it becomes <em>utterly essential</em> when you’re working with a team outside the company.</p>
<p>One of the best ways I have found to track an outsourced project is by using an agile-inspired chart I designed for some of my own outsourced projects. The chart has 4 main columns:</p>
<ul>
<li><strong>Issues:</strong> Here is where your backlog starts. All the bugs, tasks or fixes that you have determined or found on a build review go here. Usually this column gets filled with new issues after receiving new builds and/or releases from your developers.</li>
<li><strong>Committed:</strong> In this column you put everything that has already been submitted to the developers for fixing, be it via email or their own project management tool. Usually what I would do is write an afternoon email that they would see in their morning with all the issues that I found and that I’m adding for the next day.</li>
<li><strong>Rejected &amp; Done:</strong> When the developers send a release or build, they always send it with a set of release notes that describe what was fixed and/or added. Based on this, a review of what was sent is made, and all the issues that were tackled in the release are moved from Committed to either Rejected or Done.<br />
When something is rejected, this means that the issue needs to be recycled back into Committed again until it is fixed.</li>
</ul>
<p><img loading="lazy" decoding="async" class="aligncenter size-large wp-image-8295" src="//wp-content/uploads/2016/04/image00-1024x768.jpg" alt="Tracking a project with outsourced developers" width="1024" height="768" srcset="/wp-content/uploads/2016/04/image00-1024x768.jpg 1024w, /wp-content/uploads/2016/04/image00-300x225.jpg 300w, /wp-content/uploads/2016/04/image00.jpg 1999w" sizes="(max-width: 1024px) 100vw, 1024px" /></p>
<p>By following this simple tracking method, you can have a clear idea of the state and progress of your project, no matter where your dev team are based.</p>
<h2>Final Thoughts</h2>
<p>Developing a software product with an external team, especially an overseas team, can be very challenging. That said, sometimes there are budget constraints and involvement limitations that make it impossible to develop those products in-house, and so you don’t have much choice.</p>
<p>Equally, outsourced development can help to achieve specific goals that can later represent significant return on investment. The most relevant example would be developing the MVP of an untested idea.</p>
<p>For those cases, having a clear idea of how to proceed, and how to enable and give structure to the team can determine the difference between success and failure. Having a clear framework and a set of guiding principles like the ones above can at least boost the chances of success, and mitigate the downsides that come from developing a product with an outsource development team. Make sure you have something similar in place before you spin up an outsourced project, and if you’ve got any other tips for making sure these kinds of projects are a success, I’d love to hear about them in the comments!</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

7 Lessons on Building Product with Outsourced Developers

Juan José Ramírez

Comments

Read next