Software product developers are trying to do more with less and this specifically is one of the reasons for product failures. Sample this, software vendors will increase new product releases by 70 percent and upgrade/version releases by almost 40 percent. But, only 30 percent are expecting to increase their rate of R&D spending. Look at some of the scenarios:

  • Product rollout schedules are tightly linked with marketing deadlines
  • Mistakes are repeated from one project to another
  • No customer feedback has been sought by the developers
  • Resources aligned to one important project is diverted to even more important projects within 6-8 weeks
  • Developers divide their time among numerous projects

This is typical of most products that dont succeed in the market. Unless the software vendors develop a good product development system, they would never build better products.

A good product development system involves all aspects of a product company that include Product Management, Product Engineering, Product Marketing, strategy, communications and human resources as it is about technology and technical issues. Some of the key factors to be considered for a product development system are vision, process, customer requirements, resource planning, appropriate metrics and continuous improvement.

One of the best strategies to improve the product development system is to partner with specialists that have experience of working in multiple products. Global product development has become a necessity and reality for software product companies. It makes a lot of sense for them to partner with specialists and adopt the best practices of a product development system that will make their products a success in the market place.


Satisified customers are the ones that ensure the success of a business. Having said this, I want to take a look at producteering from the perspective of a service provider that help an ISV build products.

As far as the service provider is concerned, which is typically Outsourced Product Development companies, the customer is the ISV and the end-user dynamics are not involved in their engineering activity. This probably is an approach that is fraught with many pitfalls that may result in the product not being really successful.

In one of my earlier posts, I had written that service providers need to think about customer’s customers (end-users) and this becomes critical towards adding value to the ISV engagement. It definitely becomes essential for the service provider to understand the end-users wants, needs, and desires.

How best can we ensure that the end-users get what they want, as customized and as quickly as possible? This can be achieved only by involving the end-users directly in the engineering process. End-users definitely are the biggest source of talent, engagement, innovation and agility. It becomes imperative to connect to the end-users and those that interact with their end-users stand to reap the competitive advantage.

How does a OPD company do this? Because, their point of contact and exit is the ISV themselves and not the end-users. Primarily, OPD companies need to engage with ISVs at a higher-level and be a part of their engineering team. The best way to start would be asking relevant questions that are connected to end-users feedback. OPD companies should also try to be a part of the professional services team of the ISV in their beta, alpha and interact with the end-users.

Engineering a product, this way, will definitely qualify to being called Producteering 2.0

Most Outsourced Product Development (OPD) companies focus on customer requirements, treat these requirements as god-sent, and try to fulfill those requirements. Is this approach right or wrong?

To say the least, OPD companies that are specialists in Product Engineering (producteering) need to look beyond the customer and at the same time not neglect the requirements of the customer.

OPD companies essentially need to look at customer requirements and the customer’s customer requirements. The difference means long-term success of the software product rather than just focussing on the tactical needs of the customer, just by following the requirements provided by the customer.

OPD vendors can add value to the customer at various phases of development and look at long-term benefits of the software product by engaging themselves along with the core PE (product engineering) group of an ISV. How and where to get involved and how OPD companies can add value depends on the nature of products and the stage at which they are in.

This approach may not be applicable for all product lifecycle services that are provided by OPD vendors and may need to be looked at based on the tactical and strategic benefits that it offers.

Your product development effort has been outsourced to an OPD vendor. You think you have strict project management controls and disciplined measurement and reporting of metrics. After all, you have many Gantt charts, graphs, dashboards, and health indices to prove it. Yet your product development is in deep trouble and this scenario is more common than you might imagine. The question to ask is if you are measuring the right things?

Managing an OPD effort is different from managing an in-house effort as you are dealing with another entity whose objectives are different from yours. Even if it is your own captive facility, their objectives may not be the same as yours, and it gets complicated further that their customers happen to be internal people. Defining a proper set of metrics is a great place to start to make OPD a success. People who are best in doing it are the vendors who have expertise in doing it for multiple customers of theirs. This, in turn, can act as a roadmap for continually improving the collaborative effort between the customer and the vendor.