A Blast From the Tech Blogosphere Past
A friend and colleague of mine recently pointed me toward a great Tech Crunch article from way back in 2010. I immediately assumed that the article would be dated and irrelevant, as with nearly anything tech-related conceived so long ago. I was wrong. It is a fantastic article, both because of its insights and in spite of them. It contains excellent points and some very strong counterpoints about product development outsourcing.
I strongly recommend anyone who is building digital product or who owns a digital product company read this article. I also recommend that readers consider my counterpoints below when determining the right course of action.
The New State of Digital Startups
So why bring this article up now?
The reason is simple. RocketBuild, among many other small agencies and development shops, has seen a spike in opportunities to build digital products of late. 2016 seems to have been the year of the micro-startup; small companies with big ideas and only a short runway provided by investors. These startups are addressing niche markets with targeted digital product solutions. They are scrappy, often bootstrapped, and rarely have more than a few full-time employees.
This differs from the landscape that the Tech Crunch article seems to allude to—an environment where investors shell out millions to help build a team that includes a CTO, multiple developers, and product owners. This is the world of big software, where big investors make big bets on solutions that tackle big markets. In that world, handing off software development to an outsourced team is less appealing. The article’s author nailed it.
Counterpoints to Conventional Thinking
In the aforementioned Tech Crunch article, Vivek Wadhwa gives six distinct reasons to keep product development in-house. They are all great points when considering the product development reality he imagines—one where investment is strong and teams are large. I offer a counterpoint to each of his arguments based on the reality of the micro-startup. My comments also come from an assumption that outsourcing does not necessarily mean off-shoring, which seems to have been the assumption of Vivek at the time.
Communications and customer needs. Developing a product requires a deep understanding of customer needs, and extensive user interaction. Locating R&D personnel away from customers limits the ability to develop innovative products that meet market needs.
Absolutely, ideally. In a perfect world every developer would have intimate knowledge of their product’s users. In the world of the micro-startup it is often more important to get an MVP (minimum viable product) or beta version into user’s hands quickly and at a low cost, with little input from users prior to testing. It is also necessary to have multiple developers working iteratively, leveraging expertise and experience to “get the product out there.” You just don’t get that on a tight budget without leveraging a pre-existing team of developers who have done similar work before. The case for outsourcing hinges on building quickly based on sound development principles, then trusting the internal product team to get feedback and work with the outsourced developers to implement.
Components must fit together. Complex software is more like a Swiss Army knife than a meat cleaver. The blade, bottle opener, and screwdriver have to work in an elegant manner and can’t be developed independently. In a similar way, members of a software-development team need to work closely together.
Modern software development is far removed from the days of this being written, obviously. I’ll keep it short by saying that the evolution of the cloud and the microservices methodology of developing complex applications allows small teams to work independently in short bursts, then come together to put the pieces in place. Think Voltron. Think Legos. An outsourced team can very easily work on a product, or pieces of a product, from a remote location, then work with the product owners to integrate and deploy. It’s normal. It works.
Management bandwidth. It is a lot more challenging to manage diverse teams at multiple locations and in different time zones than to manage them together. Additional layers of management are often required.
This might be the only point made by Vivek that I find completely inaccurate. In all frankness, leading a team of developers is a specialized skill in and of itself. Too many product companies and creative agencies have tried and failed to build good engineering teams. The failure is rarely in the skills of the developers themselves. More often it is due to a manager or leader treating developers like a process or a machine. The leaders have very little understanding of the work their developers do, and often have even less respect for their time and talent. In the case of a dedicated development firm there is an opportunity for developers to lead and manage other developers. There is dedication to the craft. There is respect for the work and the workers. Good management creates efficiency and bolsters the culture for the developers.
Fewer developers can often produce more. In the tech world, scaling up development teams doesn’t always lead to greater productivity. Small teams are often the most innovative and productive.
Maybe. I’m not sure of any data that would support this statement. My guess is that it is true, but only because of what I mentioned above—the leadership of the internal developers has no compunctions about burning out the team by working them 60 – 80 hours each week. Of course, this is a bad practice. It creates turnover, which creates a gap in knowledge and experience. A well-managed outsourced product team likely has a broader range of experience than would a newly formed internal team of developers. They also likely have stronger processes, better accountability, and a sense of teamwork that the internal team will not yet have created.
Skills scarcity. The specialized skill and mindset that tech companies look for are hard to find. For example, India doesn’t have programmers who have grown up to understand the intricacies of computer-game development, because few can afford the high-speed Internet connections needed. In India, the best developers gravitate to prestigious companies like Infosys and Wipro, not to small startups.
Yes, there is a general skills scarcity in technology fields. That said, it is no easier for an internal team to find the talent/skills needed than it is for an external team. In fact, a good on-shore development company is likely to find it easier to hire good developers than a brand new product startup. Developers tend to gravitate to one another, as is true of most professionals. My company receives applications from numerous developers every month. We don’t have to go searching. Why? Because great developers want to work with a team that understands and respects what they do.
Intellectual-property protection. This is a particularly strong concern in China, where it is almost impossible to protect trade secrets and where piracy is rampant. Employees often leave to start ventures that compete directly with their foreign employers, and the laws provide little protection, because they aren’t enforced.
In an age of digital abundance, there honestly isn’t that much IP that most startups are going to have. If they do, there are plenty of legal protections for such IP, particularly if the startup works with outsourced partners in the Unites States. Lastly, any reputable development shop is going to want to help protect your IP both to keep their reputation and to help ensure that you continue to bring work their way.
A Micro-Startup Product Development Strategy
The new way of spinning up digital product companies requires a new way of thinking about building digital products. In the absence of huge investments and a rapidly scaling team, startups need to find development partners to get their first version into the market. The best strategies include identifying an experienced team of developers that can be guided toward building a testable version 1.0 of your software, then working closely with them as they build. Find local partners if you can, but definitely make sure you have direct, regular access to the development lead. Build a strong relationship based on trust and accountability. Channel your users to the developers. Don’t hesitate to explain “why” things need to be a certain way—the “what” is not enough. Most of all, be willing to learn from the developers as they learn from you.
