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 or Features 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 one would go for this approach ?
  • What would be your comment on this kind of approach ?
  • I don't know what a Product Vertical or Service Vertical is. I attempted a search in Google, Bing, and Wikipedia and none of those site have any definition for those terms. Can you please elaborate on what you see as the definitions for those terms.
    – Pemdas
    Jan 31 '11 at 2:32
  • By vertical I meant: Designing Software Products or Designing Software Solutions for Clients providing them services.
    – Rachel
    Feb 1 '11 at 0:09

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:

it’s apparent that Facebook’s culture has really embraced product management practices so it’s 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 is

  • less 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.