Recently, we’ve been spending a lot of time enhancing our existing products and deciding which of our new ones make it out of the lab and in to development.

In order to aid the latter we put together a set of seven principles. I don’t pretend these are exhaustive or anything more than common-sense, nor are they suitable or relevant for every organisation, but they’ve helped us formalise and speed our decision-making as to which products to focus on.

We’d be interested to hear your thoughts on this and whether you’ve come up with anything similar. As to our products, we’ll be putting a section up on the website soon to showcase existing and upcoming products.

I: A product must have a raison d’etre

• Who will buy or use this product?
• Why will they choose it over others?

II: A product should have a roadmap

• How will this product evolve?
• What truly makes it a product rather than a piece of software designed to solve a single / local problem?
• What is the bare minimum this product should do (i.e. what’s sufficient for a 1.0 release)?

III: A product must have a champion

• Who will set and re-set the business and technical direction of the product (we expect this to be two champions in reality)?

IV: Products should be designed to be flexible

• They should be easy to integrate.
• This allows products to be formed to make a suite (which increases the value of the products).
• Don’t reinvent the wheel and use existing standards where possible.
• Only specialise (i.e. use proprietary formats) where requirements dictate or it creates significant competitive advantage
• Favour open-source libraries.
• Don’t rely on clients’ data models (instead integrate with them and adapt to a neutral or
  standardised data model).

V: Products should use established and widely-known technologies

• Greater selection of development partners.
• Easier to sell to clients.
• Greater scrutiny of widely-known technologies means they are (usually) more robust than others.
• The exception should be true innovation where the development could not be done in existing technologies or it is significantly quicker to develop in newer technologies.

VI: Use technologies sparingly

• Select a few, established and robust technologies to build products with.
  • It’s easier to support more products with fewer people.
  • It’s easier to innovate (as there is a shallower learning curve).
• Technology choice and migration will need to be partly led by the market – i.e. if a new technology emerges and begins to become the leader (e.g. a new, popular language or platform) then we may need to port our products (e.g. moving products on to the Google App Engine)

VII: Build in diagnostics from the start

• Instrument the product to make support and troubleshooting easier