White Paper
7 Questions To Ask Your Prospective Outsourced Product Development Vendor
Product Development
ISV SMB
Introduction
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”:
Q 1 - What is your typical team size and structure for client engagements?
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 be 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.
Q 2 - I don't have any documentation. It's all in my developers heads. How do we start?
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 understand better if 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 with 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 – a requirements gathering exercise to create initial documentation and begin the process of institutionalizing knowledge management. They will insist on having good business analysts, UI engineers and people who understand design choices in the initial phase of development. A vendor will not hurry 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, part face-toface 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 to software specifications and progress through each phase of development. Find out about their experiences and strategies from the responses to this question.
Q 3 - What technology shall I choose for my product?
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 know your partner’s motivation and reasoning behind recommending specific technologies. And you may 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 so many parameters to discuss and questions to answer before making technology choices. And even within a product there are technology choices to make for the platform, database, reporting, security, content management and for service delivery.
Looking ahead, your technology choices could depend on skills you have for maintaining the product in the long run. Did the vendor try and understand more about your team, your technology preferences, and available skills to maintain and enhance the product? Some other factors that affect technology choices include the economics of build or buy decisions, the need for integration with other custom or packaged applications, licensing fees and hardware/infrastructure to support these technology choices. 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.
Q 4 - Here's the specification. How much it would cost to build my product?
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 so many nuances to effort estimation for product development. It takes time and effort from the vendor and some collaboration with you to prepare an estimate, even with a clear specification. There are several assumptions that you may have made about your business domain or about the role of your team in the development cycle that maybe easily evident from a written specification. Sometimes a brief paid effort for a Discovery or Due Diligence may be needed from the vendor before they prepare a final estimate.
Lastly, product development is not a static activity. Specifications, time-lines, technology choices, hardware, software and infrastructure could change during development. Has the vendor cautioned you about the impact on cost and time-lines and informed you about the process for management of these changes? Or have they given you a fixed number and said that it won’t change under any circumstances? In the latter case, expect surprises and standoffs during development.
Look for vendors who engage in discussions and have relevant questions on your specifications. Avoid vendors who promise you the moon and the stars in exchange for a specification without any discussions or relevant caveats if changes occur during product development.
Q 5 - How will you help me increase my product value?
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?
Q 6 - How can you help me win business and grow?
This open ended question helps you understand a vendor’s perspective on outsourcing. Are they focused solely on work for hire? Are they focused on providing resources for your use to get compensation and nothing more? Do they understand that your business with them grows if you grow too?
A great partner helps you win more deals by working with you to identify new business opportunities and revenue generation models. They help you develop pre-sales and estimation strategies that provide you market advantage. They can also advise and consult with you to develop best-in-class products that will be market leaders, not laggards. For instance they can help you build cloud, mobile and social strategies for your product.
At the same time the partner should help you organize your team structure to optimize your development and maintenance costs. This helps you be more competitive in the market and win more business. Understand their perspectives and capabilities from the answer to this question.
Q 7 - How shall we measure success?
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 you resources at a lower cost may have lesser 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 on cost and schedule at each phase of development and 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 do yourself. While this evaluation has to be finally done by you, unless your partner has the necessary metrics driven culture, they will not be able to provide you metrics to measure your engagement’s success. And your CFO will be left wondering why there is no overall benefit through outsourcing, although it made complete sense in the beginning.
Summary
Finding the right OPD partner is not easy, but not difficult either, once you have a good understanding of how OPD vendors operate and what drives them to success. An SMB should first do its due diligence andbsend out the “usual RFI questions” to weed out companies that simply don’t work for them. Then they should shortlist 2-3 firms for serious evaluation. They should use these 7 questions during their interview process and decide on the right partner for their outsourcing engagement.
About Trigent Software Inc.
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 the detail design, development, integration, testing and quality assurance offshore at our world class development and support center in Bangalore. We are a SEICMM Level 4 company and is ISO9001:2000 TickIT certified organization.
For sales contact sales@trigent.com or call 508-490-6000.