Anyway, I have finally gotten down to this entry, which is about my thoughts on some of the driving concerns related to software product development. Developing a product is different than just writing a program to a set of requirements elicited from a customer. This is due to several factors starting primarily from the economics of product businesses.

Lets take a look at the basic business model around a software product in comparison to other types of software businesses. The typical systems integrator or services company interacts with a client, figures out how much work and costs will be incurred to provide the client what they want, add an amount to cover risks, factor in the profit margin, and ultimately charges the customer for this. One way of looking at this is that the recovery of costs and customers is 1 - 1. The products scenario however, is different, with the same product being sold to several customers, hence only a fraction of the creation cost is charged to each customer, to end up with the same overall profit of a 1 - 1 engagement.

This solves several problems for the development company and the customer, and it creates certain problems for both as well. On the positive side, the customer pays a fraction of what it would have costed to have the same software specifically developed for them. Similarly, charging each customer less than what it would normally cost to develop gives the software company an opportunity to sell more easily. Then again, when it comes to support, the product company is able to share support costs across several customers, making it available much more cheaply than support for bespoke software. On the other hand, because of this very same factor, the customers may not be getting exactly what they want, and the software company may not realize the benefits of the lower cost they offer if this difference is too high. Most specific aspects of product development can be traced back to this model.

One reader kind enough to comment on a previous posting said "Building a product better and faster takes a right set of principles and practices driven by the right people and supported by the right platform". I totally agree. That covers a lot of ground, and I would just like to highlight a few of the principles here, while ignoring for now the practices and platform for now. (may be another entry in a year from now ......:-) ). Let us take a look at these factors specifically:

• Generality versus specificity
• Requirements, meta requirements and meta meta requirements
• Customization versus features

Generality versus specificity: The more general a product is, the more people you can sell it to. Therefore generality is good, right? In fact this is one of the cornerstones of a product -- in fact most people would argue that without this you do not actually even have a product. But consider this -- the more general it is, the less specific problems it can solve for any given customer. Therefore the software development company needs to add features that are specific to certain customers, or groups of customers to interest them. This starts moving you to the other end of the pendulum, which is that the more specific it is, the more it costs to develop, potentially requiring the development company to charge a customer for features they may not be even using. So there is a fine balancing act needed in the features of the product. They need to be general enough to provide value to a large set of customers, at the same time rich enough in the value provided to each individual customer.

Requirements, meta requirements and meta meta requirements: The typical software project will have developers at various levels of expertise and experience talking to people who "know" the requirements. These people would then go back and develop software that implemented these requirements. The problem of this approach in a product development scenario is partly due to the previously discussed generality versus specificity problem. Any conversation with a specific customer is likely to bring out requirements that are equally specific, and possibly not of interest to another customer. The obvious next step therefore, is to speak to more customers, until you have enough information about common requirements that will enable you to start your development process. What you are indirectly doing in this method is discovering meta requirements. A common underlying information and/or operational model drives what you have discovered as common requirements. In the future, your understanding of this underlying model (the meta requirements) could even make a conversation with a single customer provide insights into requirements across other customers. So why have meta meta requirements when meta requirements themselves seem to address the generality versus specificity problem quite well? It is a question of providing additional value, filtering noise, and discovering nested requirements. Additional value is obvious enough -- if you just cater to the existing operation and information model, you are just automating, and not necessarily extending the possibilities that exist due to automation. Also, noise is often created by requirements that are stated, without being examined as to their validity as a solution to an operational or informational problem. Questioning the need for that requirement can sometimes reveal a totally different requirement, or even none at all. Nested requirements are frequently not identified as such, leading to their potentially being developed in line instead of being something that can be tweaked across customers, locations and time. For example, some requirements may be related to tax laws, and while it would be simple to factor in the prevailing percentages into the calculations related to these, it is probably something that should be externalized in order to facilitate change without having to change programs. Therefore product development requires you to get into customer needs, the needs for the needs, and the needs for the needs for the needs. In fact organizations which have deeper insights than three levels of needs built into their products probably have much more successful solutions in terms of doing what their customers require than others.

Customization versus features: One way to get around the generality versus specificity problem is the ability to customize software. This may be by way of introducing their branding into system outputs, altering workflows to take into account their operations, integrating with their authentication mechanisms and so on. Of course, the more you can customize, the more the cost of customization. So if the product company has a highly customizable product, it might need to consider charging separately for the product and for customization. In this case, the balancing act needs to consider the total cost of ownership of the end of the day for the customer. If it turns out that the total cost is going to be as much as bepoke software development, the customer would probably opt for that instead.

Another reader commented "Product engineering requires high level of competencies in the area of lateral thinking, innovation, creativity.... basically freedom of thought." Again, I do not disagree, however, there are enough caveats I would add to this opinion in order to qualify agreement. In other words, I think all these factors help, but I think it is possible to do product engineering and succeed, even in the absence of the above. In general, high competancies are important in areas where there are no frameworks or guidelines on how to proceed in general. In other areas, training and the use of the valid model can create the level of competancy needed.

To start from the basics, the product needs to be something that solves a problem common to a number of customers. This can be done by a structured study across customers with a conscious application of the requirements -- meta requirements -- meta meta requirements approach. Applying a generality versus specificity decision set to the outcome of this exercise, and coming out with the product that solves the problem with the required ability to configure it for specificity is then the bare minimum requirement for developing a potentially successful software product.