In every industry there are two verticals Product Vertical and Service Vertical, so my question is:How does design approach changes while designing Software for Product Vertical as compared to developing Software for Service Vertical ? What are the pros and cons for each case ?Also, in case of Product Vertical, How you go about designing Product orFeatures and what are steps involved ? Lastly, I was reading How Facebook Ships Code article and it appears that Product Managers have very little influence on how Product is developed and responsibility lies mainly with the Developer for the feature.So is this good practice and why onewould go for this approach ? What would be your comment on this kind of approach ?
Software Design for Product Verticals and Service Verticals
web development;design;architecture
I guess it can be a good practice in specific cases. It requires a special business model and company culture, which Facebook seems to have. It surely does not mean that it can be copied by any other company as it is.Quoting from the article:its apparent that Facebooks culture has really embraced product management practices so its not as though the role of product management is somehow ignored or omitted.  Rather, the culture of the company seems to be set so that everyone feels responsibility for the product.This indeed requires very conscious and user-oriented developers who can switch to wear the Product Manager hat (as well as the Developer and Tester hats, already more well known in Agile circles). Which in turn requires not only selecting them carefully, but training and mentoring them appropriately.I believe if the developers really embrace this view, it can be very effective, as there isless distinct layers of communication between end users and developers, thus reduced need for communication,developers are forced to fully understand the domain, and to assess the implications of their specific technical decisions properly, so there is much less risk of introducing usability issues and bugs.The downside is that it is easy for developers to get excited about bells and whistles which look intriguing for them, but does not make any difference for the users. This seems to be avoided by live usability tests:arguments about whether or not a feature idea is worth doing or not generally get resolved by just spending a week implementing it and then testing it on a sample of users, e.g., 1% of Nevada users.