Product design purports to be a mystical art, which can only be practiced by a chosen few. It is not.

It is a simple thing if you think about what a computer is supposed to do in the first place. All it has to do is to

take inputs from you as machine-readable data,

  1. process the data as per certain rules laid down by you,
  2. send you back the processed data in human-readable format.
That's a piece of code, not a product puritans will argue.

That is a good point. Then what else do we need to add to that "piece of code" to make it a product?

1. User Configurable: We can change the behavior of a program by changing the code wherever required. But that requires a) technical knowledge and b) a sound knowledge of the program's architecture.

An average user possesses neither of those. But his business demands certain behavioral changes in a program. A product should be, to some extent, handle such deviations.

Why? Because the builder of the product builds it in such a way that common choices are taken care of in code.

A car manufacturer knows that his customers would have different choices when it comes to color. So every model he launches comes in colors like royal blue, fiery red, olive green, etc. For him, his car model is a product which has to be acceptable to customers in different forms.

A software product owner may keep changing his choice throughout the lifecycle of the product, just by navigating to a certain form and assigning some elements certain values.

2. Permanent Configuration: This may sound trivial, but not always obvious. The configurations that a user does should persist in the secondary memory (usually HDD). So the user should get the same behavior across sessions.

In Microsoft Windows, you can tile a few open windows on your screen particularly. Once you reboot your computer, the pattern will be gone.

So you store the configurations in a text file or a database. You create UI pages to keep those updated. And you think you are through. It was not a big deal after all!

Well, your code needs to "consult" the configurations every time it performs a "configurable action". And you need to write code for each configuration option.

If you have a modest 20 config attributes and each having, say, 3 user-selectable options each, you are staring at 20*3=60 original use cases! And you have to make sure your code handles each of those 60.

3. User Authentication: A product *will be* used by multiple users. So you have to have at the very least some mechanism for user creation, password saving and update and an authentication UI. You also need to arrange for an administrator account.

The whole point of a multi-user authentication structure is to have user-based discriminatory access to data and functionalities. User A may be privileged to access global stocks, while User B may be restricted only to his country. User C can build and run analytic models on global stock, while User A can only see the stock as it is.

4. Data Partitioning: User data needs to be partitioned user-wise. If a signal comes from the Authentication module that User B should not be allowed to see any stock outside of his country, the Data Partitioning module should be able to implement that embargo.

If you try to push the problem to the DBA, he will most like to come to the meeting with a baseball bat instead of his usual laptop. You cannot ask a database user for each application user. It is a huge security risk. Any breach at the front-end would hit the database directly. You will have to manage with one database user!

5. GUI: Every task a user or a superuser may perform should have a corresponding UI page. There should not be any exception, as you cannot open up your server for a configuration change, however small. Per page, you will need at least three REST APIs - for GET, PUT and POST, respectively. For 10 pages it runs into 10*3 = 30.

Product development is not an easy task!

6. Logging: This is a thorny issue, and a political one too. Product developers do not want to give full access to all the server logs to users. The reason for public consumption is that only trained professionals would understand the highly technical logs. More so, they are the ones who are authorized to take any action on the server side based on what is found on the logs. Otherwise, you will void your warranty or support agreement. It is the same type of warning that you see behind your microwave oven or LED TV.

Support revenue as AMC is a major source of income for any product developer. Because of this very reason, the business of product development is as lucrative as that of office space rentals. You buy a building once and collect rents forever.

However, in a rare occasion, you may need to use honesty as a tool for enhancing your business. In that case follow these basic guidelines:

1. Write some of the logs in English.

2. Instructions to fix an issue should be clear and precise.

3. A user, sufficiently privileged, should be able to start logging from front-end.

4. The same user should be able to locate and download the log files from some UI page.

5. Never ever build such a functionality without your manager's explicit approval.