Integrated QA Approach is a paper that we are working on internally and this is something we have been practicing all these days and years and we wanted to bring out the value of this in the form of  a paper. We have been brainstorming about this for quite sometime. This primarily is a way by which you bring all the stakeholders to the table and ensure that the product released is of very high quality. One of the key things that we wanted to cover as an extension of this paper was the real-time collaboration that is required between various stakeholders and some of the techniques that we use to get all of them on the same page.

We also were doing a number of activities towards this collaboration that we wanted to bring out as an extension of this paper. During this work, we came across a document published by Aberdeen Group and it has interesting findings which I wanted to share here.  This release was around usage of video conferencing towards effective collaboration.

Some of the top corporate goals for doing collaboration was identified as follows:

  • 67% of the respondents responded accelerated time to market
  • 54% said about the ability to produce higher quality products
  • 52% said about the ability to better respond to market and customer requirements

Some of the collaboration activities that the respondents used real time virtual collaboration to support are:

  • Review designs in an interactive enviornment – 63%
  • Include suppliers in regular project status meetings – 55%
  • Include customers in regular project status meetings –  47%
  • Simulate real-time meeting environments for dispersed teams – 47%
  • Enable virtual brainstorming/white board sessions – 40%

But then any collaboration needs to be tailored to the requirements of the organization. These come with their own set of challenges. The identified challenges in the study are:

  • Adapting presentation/meeting styles to incorporate remote teams – 75%
  • Learning to use meeting collaboration tools quickly – 64%
  • Being able to access meeting collaboration tools – 56%
  • Smoothly transmitting high density design imagery – 51%
  • Protecting intellectual property in the global design – 66%

Video conferencing is one solution that addresses most of these challenges while still meeting the goals of real-time collaboration. Based on the requirements of the organization and the comfort levels of stakeholders, many different systems can be used that can address the challenges faced by teams both in terms of using the collaboration environment as well as addressing the quality, time-to-market and customer support issues.

The existing collaboration solution that we use at Aspire Systems, addresses many of these challenges and we have been successful in using them for the betterment of the Product Engineering (Producteering) activities in all our engagements.


I have been thinking quite long and hard over the past days on how producteering can be tangibly represented with respect to the business of making software products. Before I get into it, let me define what Producteering is.

Producteering is a set of principles and practices, driven by the right people and supported by the right platform. Producteering, when applied rigorously, enables products to be built better and faster (Quite simple!, isn’t it?)

Coming back to the original purpose of this post, here are my thoughts on the business of software products and its relationship to producteering:

1. You are better-off producting great software as opposed to mediocre software

2. Producteers have not been, and will never be commodities, and they are the ones who can make great software

3. Premium model Vs. freemium model (Many biggies have killed out-of-the-box startups quite easily through this model, though this is not the intention behind this point! Google is a great example though).

4. Be agile and release working software frequently as opposed to incubating and keeping your software in stealth mode for too long.

5. Product innovation Vs. business innovation. This is what differentiates a successful software business as this is what is bought into as opposed to just engineering superiority

6. These are good times for software product companies as the capital costs are low, and engineering processes have matured

I have done my half-a-dozen and I am expecting to hear from people who can add more to this.

For every ISV, commoditization of their product is a reality, sooner or later.  Innovation, bundling and segmentation would be three probable ways to differentiate your product in a commoditized market.

Differentiation can be around availability, performance, delivery model, pricing models and a few more, considering that you are in a commoditized space. It is all left to the imagination of the marketer on how your offering is packaged.  Most likely, it is the messaging that spells out the differentiation and delays the commoditization of your product.

For instance, when Bajaj moved from lightweight scooter market towards commoditized motorcycle market, their messaging was about B-to-B. This B-to-B is about bikes-to-babes, bikes that get you babes. Their messaging was about making a lifestyle statement and this definitely differentiated their product from the commoditized market.

As peter drucker says, for if we dont differentiate, “In a commodity market, you can only be as good as your dumbest competitor”.

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.

I came across this post in one of the product management forums and also read about it in Thought, I will have this information shared in my blog as well.

Does anyone know of ratios of employees in a product development organization? This is related to the ratios on product managers to engineers to QA to UI designers to architects etc.

Beyone of course, saying that it will always depend on a variety of factors, here’s what Marty Cagan of SVPG has to say:

Engineers: One Product Manager for every 6-10 Engineers

Designers: Think 1:4:8, where one visual designer supports 4 interaction designers, and each interaction designer supports 2 product managers

Architects: It would be 1 architect for every 5-15 developers. The lower-end would be 1 architect to 5 developers, typically for new product development that require hands-on architecture and the higher-end would be 1 architect to 15 developers, typically for ongoing management or developing more stable or legacy technologies.