ISV SMB
Investments Product Development
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.