One of the greater challenges, I‘ve observed in the lifecycle of software development lay not in the technology, or in the method of solution, but with the interaction with the customer. The less fortunate case would be the lack of any interaction with a customer all together, resulting in a peculiar situation of over development.
An “Over development”, as I see it, happens when product features don’t match the majority use cases and no customer would be willing to pay for their development. Things that seem awfully cool to have, but don’t actually assist in the selling process.
I’ve been involved in many corporate development projects. These were huge projects, with large groups of developers, all working for functionality defined by a single customer. The past two years, I've been managing the development of a leading product for the paper press industry. This product is an “off the shelf” reporting solution for the production process of a commercial printing house.
The product tracks and accumulates data in any provided format. It produces a wide range of analyses and diagnostics, regarding the production line of a printing house operation.
Although the two development scenarios may seem different, I consider them to be quite similar, with a slight variation: in the development of an “off the shelf” product, the customer is the sales department.
For both development scenarios, the one big issue that stands out is having the application go into production. As obvious as it may seem, it is the least trivial, and to my mind, the hardest.
I’ve started out with a product that was extremely over developed, and not a single customer. The first thing I did was to set a goal for myself (i.e. my group), to push the product into production as fast as I could while shrinking the development cycles.
The sale department managers helped me come up with a bare bone requirement list of features. I used this “can’t go without” list to determine the entry point of the product. I used this leverage to get the sales department to arrange the first beta customer. Once there was a real life customer in the development cycle, crucial information began flowing back, requesting features and functionality.
There are two good things that a customer may give the application developer. One is money for the product; the other would be rejects on the product. The latter, when provided from a customer is worth more than any internal brainstorming process within the development group. To my opinion it is the best way to have the product pushed forward and to make it robust and usable.