7 Questions To Ask Your Prospective Outsourced Product Development Vendor

Small and medium sized software product companies face daunting market challenges today. These include disruptive changes such as SaaS and Cloud delivery models, along with other challenges such as the need for rapid development, automated testing and constraints in hiring. Increasingly, many of these software vendors are looking at product development outsourcing like some of their big brothers who have had outsourced global delivery teams in place for years. Still, a word of caution is warranted – Product development outsourcing does not work for all.

Companies start their search for a vendor and find themselves like “Alice in Wonderland”. A web search on outsourcing yields 200+ Indian and Chinese companies. The terrain is vast and unfamiliar. All the sales pitches sound the same. A company selects one and burns their ngers. They ask their friends and peers, sometimes blindly follow them regardless of whether there is a right fit. They nd out the hard way that what ts one company may not fit another.

So how does an SMB software vendor find a great partner that is right for them? Here are some questions to ask and have a conversation that matters. These are not the “usual RFP questions” that you ask to verify the company credentials such as company history, resources, global model, certifications, track record, local presence in USand IP security. Those questions can be found in any standard RFP or web search.

We present these hard questions that peel the layers of “the onion”. They will tell you whether what you are hearing is the usual sales pitch or if the company really does substantive outsourced product development. We suggest that you finish the initial RFP round, shortlist potential vendors and then ask these questions. The answers and conversations that follow will tell you what to ask next and help you eventually find the best company to work with. There are no right or wrong answers. Success of the partnership depends on how you work together beyond the basic credentials already verified by the “usual RFP questions” mentioned earlier. Here are “not the usual RFP questions”:

The answer to this question will help form your opinion about the company’s fit relative to your needs. Product development is both an art and a science. You need the right balance of skills, team size and structure to make a great product. You cannot build a product faster by just throwing hordes of developers into a team.

Even companies like Microsoft and Oracle build smaller core teams to work on specific product modules. So if a company talks of 50–100 developer teams as their typical size of engagements, they are probably working with large banks and enterprises developing, maintaining and supporting their business applications.

Would you get the attention that you need if you are looking at a 10–15 member team? Probably not. Product development as a practice may not really be their sweet spot. If the answer is 5–20, determine the approximate team size you are looking for and investigate further.

Team structure is an important component. The response lets you know whether the company has experience in structuring Outsourced Product Development (OPD) teams. For instance, the ratio of UI engineers or testers to developers at various stages of development shows their knowledge of OPD best practices.

Is the structure flexible and dynamic in terms of numbers and skills for you to get an on-demand, cost optimized model aligned with your market demands? This will help you convert your current fixed costs to variable costs.

Is there an experienced Project Manager included? If you are in the US, do you have an Engagement Manager in the US to liaise with? This will help you manage project risks and ensure success of the partnership.

This question is designed to help you understand more about the company’s experience, both in depth and variety, in developing software products. It will help you unravel their grasp on the SDLC (Software Development Lifecycle) specifically related to products. Further, you will better understand whether their sweet spot is staff augmentation or full-cycle product development.

Good OPD vendors know how to draw up specifications collaboratively with their customers. They also understand the need to do so. If the answer is “That’s fine, we do not need specifications, our developers are great; they can talk to you and get the tasks done,” then beware of rework, surprises, and chaos during the development cycle.

Even Scrum and Agile development models need specific documents and artifacts for success in an outsourced team context. There could be attrition among key team members; only adequate documentation prepared well by an experienced vendor can mitigate high costs from attrition. A key associated cost comes from steep learning curves for new team members.

A good vendor will insist on a Discovery phase—a requirements gathering exercise to create initial documentation and begin the process of institutionalizing knowledge management. They will insist on having strong business analysts, UI engineers, and people who understand design choices in the initial phase of development. A vendor will not rush into the development cycle without the requisite requirements documentation for your product.

Good OPD vendors work with a variety of product companies. They work with startups who have just a flow diagram on a whiteboard. They work with small Independent Software Vendors (ISVs) who may outsource their entire development offshore using a hybrid approach: part documentation and part face-to-face interaction strategy.

They also work with established niche players who rely on either very structured documentation or Agile development with cross-border collaborative teams. In each of these situations, the company will use different strategies to gather requirements, translate business needs into software specifications, and progress through each phase of development. Find out about their experiences and strategies from the responses to this question.

You may have a good grasp of what technology you want to use for product development. You may have done all your research. This question is still important to ask because it helps you understand your partner’s motivation and reasoning behind recommending specific technologies. You may also get a fresh perspective on various technologies from an experienced vendor, which is always useful.

If the answer is a quick readymade one, e.g., Microsoft, Java, Joomla, or Ruby on Rails, then beware. There are many parameters to discuss and questions to answer before making technology choices. Even within a product, there are multiple technology decisions to make for the platform, database, reporting, security, content management, and service delivery.

Looking ahead, your technology choices could depend on the skills you have for maintaining the product in the long run. Did the vendor try to understand your team, your technology preferences, and the available skills to maintain and enhance the product? Other factors that affect technology choices include the economics of build vs. buy decisions, integration with other custom or packaged applications, licensing fees, and hardware/infrastructure requirements.

At times, you may need prototyping or proof of concepts to test technology choices before making a decision.

Look for fresh insights into the appropriate use of technology while discussing this question with prospective vendors.

Did you hear $50,000 or did you hear half a million dollars within a couple of days without any Q&A or discussions? Then tread carefully. There are many nuances to effort estimation for product development. It takes time and effort from the vendor, along with collaboration from you, to prepare an estimate—even with a clear specification.

There are several assumptions you may have made about your business domain or about the role of your team in the development cycle that may not be evident from a written specification. Sometimes, a brief paid effort for a Discovery or Due Diligence phase may be needed from the vendor before they prepare a final estimate.

Lastly, product development is not a static activity. Specifications, timelines, technology choices, hardware, software, and infrastructure can change during development. Has the vendor cautioned you about the impact on cost and timelines and explained the process for managing these changes? Or have they simply given you a fixed number and said it will not change under any circumstances?

In the latter case, expect surprises and standoffs during development.

Look for vendors who engage in discussions and ask relevant questions about your specifications. Avoid vendors who promise unrealistic results without discussions or without highlighting the impact of changes during product development.

There are many good partners you can find for developing your product. But a real partner is one who can help you increase your product value in the eyes of your customers and investors. There are not many companies who can help you do this. A great OPD partner is one who will help you find niche features in your product to enable a gain in market share. They will help you make changes to the product roadmap which in turn helps you find new revenue opportunities, perhaps in new or expanded markets. Not many OPD vendors have the vision or the patience to deploy their time, effort and resources in helping you in these areas.

Secondly, you could be positioning for a lucrative acquisition in the future. At acquisition time product documentation, IP documentation, licensing models, engineering documentation and user manuals are important. Will you realize only then that you and your partner have no product documentation or documented IP to show to prospective buyers? Product and company valuation increases with availability of the right information and documentation. Is your prospective vendor aware of such needs? Is good documentation and IP protection part of their OPD strategy for their clients? Are they well prepared to help you increase your product value?

This question puts the focus on the company’s processes, particularly the existence of a metric-driven performance culture. The answer tells you whether you will be able to tangibly measure results from the partnership.

Many vendors are focused on selling based on cost arbitrage and providing resources to add to your team. But what you need is performance measurement at every step. A vendor that provides resources at a lower cost may have lower productivity, and you may end up spending more time on rework and wasteful communication.

Your partner should be able to provide metrics on productivity, quality of code, variance in cost and schedule at each phase of development, as well as indirect benefits from their contribution to product value, your business, and revenue.

Ultimately, the measure of success is the overall cost and time relative to what you could achieve yourself. While this evaluation must be done by you, unless your partner has a metrics-driven culture, they will not be able to provide meaningful data to measure engagement success.

In that case, your CFO may be left wondering why there is no overall benefit from outsourcing, even though it initially made complete sense.

Trigent is a privately held, professional IT services company and a Microsoft Gold Partner with its U.S. headquarters in the greater Boston area and its Indian headquarters in Bangalore. We provide consulting services in various technologies including Microsoft Solutions.

Our operating model is to conduct sales, customer relationships, and front-end consulting (e.g., business case, requirements, architecture) onsite with our clients and perform detailed design, development, integration, testing, and quality assurance offshore at our world-class development and support center in Bangalore.

We are a SEI CMM Level 4 company and an ISO 9001:2000 TickIT certified organization.

For sales contact: sales@trigent.com or call 508-490-6000.