The most important aspects of your product (are the ones costliest to change)

I was recently in a discussion about a version 1 product, where the product had a great user interface, but the software team had pretty much made a mess of everything else (the underlying implementation didn’t scale, it wasn’t cost-effective, etc.). Other participants in the discussion were critical of the product, but I felt that the exceptional user interface made it a worthy product.

No version 1 product is perfect. With version 1 products, teams have much more work to do than available resources, and have to pick what to focus on. The right aspect to focus on is usually the interface to the user, even at the expense of other aspects of the system. For consumer products, the user interface is what the consumer cares most about. It is the factor most responsible for a product’s image. Changing it later on is costly, because it causes cognitive disruption to users. It is necessary to get it right the first time. There’s a reason the CEO of Apple is deeply involved in user interface design – it’s because that’s the most important part of the product.

For a programming language, the most important thing is the interface that the developer sees – i.e., the language design. Language design, if not carefully done, can be impossible to rectify later on (because developers will have written code against the language which will also need to change). Indeed, it’s better to focus fully on language design in version 1, even if other aspects have to be compromised. Java did not succeed because it had a superior compiler, or a superior development environment – it succeeded because it was a well-designed language. All the rest of the plumbing can always be improved later on; but it’s important to get the language right because it is the costliest to change later on.

Yet other times, it’s not the interface at all. For a database system, the database schema is the most important decision. Once data has been stored in a particular schema, it’s virtually impossible to migrate it into a new schema. So it’s important to get that right.

But whatever that aspect is – software teams should pay careful attention to the aspect of their product that is costliest to change later on, and then focus their energies to getting that right – especially in a v1 product, even if it means getting some other things wrong.

Leave a comment