Part 3: Understand Your Customer

In my previous blog I have talked about how the organisation layout is followed in most Product Startups. Often a lot of Product Startups dive into product making and forget the essence of market knowledge. This doesn't mean that the company should focus only on those requirements that are coming from the market. Sometimes there are some unexplored areas.

Lets closely look at the Product itself. It is basically a combination of Software and Hardware if we consider Information Technology based Business. During initial days companies generally focus on product making only. This involves designing the software and hardware and manufacturing it. Initially the requirements on which the Product is made is derived from the potential customers or market opportunity as seen by the founders. Once the product is made with the limited set of requirements it is marketed to potential customers. This is the time when ground realities hit.

I wanted chocolate in a Nice Box but you are selling it in a polythene

Often the engineering team focuses on making the software and hardware the most reliable. However is it desired. If one closely look at any software product, there are certain parameters that define quality. They are,

- Reliability (No issue on long run)

- Robustness  (No issue on bad input)

- Efficiency   (Fast and optimized)

- Maintainable

It is often very hard to follow all the parameters. Often engineering teams use all there energy to focus on increasing quality of the Product. But is it necessary at all ?

Here is the real case study of a Consumer Product Company X. When the marketing team comes up with the proposal to make a product, the Engineering team decides that it must make the software so secure that no one can crack it. However that makes it a tight product and enforces the Customer to use it in a special way. On the other hand market research reveals that similar product is already available in the open market and that has no protection. The company X marketing wants to simply sell the Product to promote it across variety of Customer spread across different regions.

There is a gap here between Engineering and Marketing teams of Company X.

The Company X must understand what is the purpose and what must be offered. In this case the marketing simply wants to promote and hence the focus should be on Branding and Communicating with the Customers. Investing on secure software offers no advantage over the competitor's product since the customers of Company X can get the unsecured Products in open market anyways and with simpler usability. Customers want this Product because they want to start a healthy Business relationship with the Company X not to buy a secure product with tighter control on usability. Basically they don't want security. They simply want the product to work. That's all. Sometimes it is not very intuitive but true.

The message is plain and simple, make the one that sells.

Part 2: Organization Layout and Conflicts

Yes it is important to manage people otherwise be ready for a disaster. It is always about "people factory" as Jack Welch says. Unless right kind of people are at the Job it is difficult to gain success. This is tackled by laying out a clear roles and responsibility structure in the company.

There could be deviations in org structure of startups with varied product areas. However most technology startups have similar role distributions. A typical organisation structure looks like this.

Although some roles overlap with each other during initial days, they become more and more important once company runs in its full pace.

One of the most important aspect is the way the organisation functions. It is essential for a startup in its initial days to be extremely agile since it needs to learn the way to make a successful product. That means having clarity in communication and taking leadership in problem solving inside the entire org. However once the startup forms a good base of customers and starts selling products sometimes these values dilute. 

There are times when the org goes through conflicts. The most observed ones are

• among developers
• between marketing and engineering

The senior developers generally play roles of architects/ designers. Due to the layered structure of software (assuming software products area) there tend to be multiple designers who possess conflict of opinion. The negative impact of this results a poor quality of software. Often it is ignored by the management who tends to incline towards few senior developers who has joined the company during initial days and hence get more respect. However the management is unaware of the situation that is building due to tension among the developers. Unless the problem is solved the quality is degraded.

It is the onus of the CTO or the VP engineering to identify and understand such issues and promptly address it. Often a good practice is to set up a process guideline for engineering development and ensure that it is followed religiously. An example is making a software design review with review guidelines. This ensures that the design is done correctly and also undesirable clash doesn't happen between the developer and the reviewer (generally a senior architect); thereby ensuring the quality.

There are also conflicts of interest between the Marketing and Engineering org. Very often the Marketing org functions in a sales driven way and the Engineering org functions in a optimized development (lazy but efficient; there is a point I'll clarify in another blog why I chose this). Sometimes optimized development hinders the sales demands. For instance the sales would require the product to implement a feature. However the Engineering is not ready to do that as it leads to improper hack or improper customization or poor maintainability which is difficult to comprehend for the Sales org.

This is classical problem but there is a solution to it. The respective heads must have the mandate to manage product. Product Management means making as well as selling the products profitably. Often there exists a product management org separately. The crux is there should be an effort to find out the cost vs profit of product features. Essentially a profitable (which could be a short or a long term benefit) feature is what a product needs. Hence it should serve as a guideline for prioritizing its development.

There are a lot of unanswered questions here. How to handle feature requirements etc. The upcoming post mentions them.