Saturday, December 12, 2009

A great Question for every product team member --Why are we doing what we are doing?

As a member of a product development team, one encounters the challenge of there being no single customer and instead a "Product owner" becomes the Proxy" customer. 

The Product owner interacts with multiple stakeholders and based on different priorities (and pressures) builds the resulting product roadmap.  Delivery team members live in the comfort that somehow the responsibility of priority rests with the Product owner and go about with blinkers trying to accomplish what is laid out.  Yet in so many product development efforts, we do not achieve financial success and features built are no longer relevant. Product team members are left bewildered at the consequences despite putting all the late hours and at time face the devastating situation of the entire effort being shelved.

As a team member how could you have prevented this?

I believe that active questioning of what goes into the product roadmap by all team members is crucial to improving the odds.

every team member has a right to know --Why are we building what we are building?

the following steps could be useful for a quick analysis would be
1. The target audience for the release : Customer or Prospect ( Some understanding of the segment being targetted wll be very useful as well)
2. The reason for the release which could be,
     a. Cost savings for the end customer
     b. revenue adding for the end customer
     c. regulatory needs
     d. contractual obligation
     e. catch up with competition
3. amount of revenues that will be generated
4. likelihood of revenues that will be generated by the development effort
5. Underlying assumptions for all of the above

I know it reads like the business case of the product release, however in practice business cases are not built in this level of detail and it is useful to simply question the "Product owner" in a manner that puts the context for the overall delvery effort.

Product owners in turn are bound to discover blind spots if all team members take upone themselves to get their own answer as to ---Why are we doing what we are doing?

ACID TEST ---If none of your questions as brought out above result in the Product manager changing the roadmap over the next 2 releases then either you are not asking the right questions or your Product manager is Perfect!

3 comments:

  1. Although I am in agreement of the delivery teams need to know “why we are doing what we are doing”, I am not sure of your linking it or relating it to what the product owner dictates as a feature need into the product.

    According to me a business case (revenues and economies of time and scale) should be made mandatory and every product company needs to have an approval panel before the case is taken up for development. This seems to be missing or given least importance which results into most failures and product team disappointments

    Walking the team thru the business case will then be the first step to get the team to understand the need, the timelines and revenues making it a team effort to get to the end release and avoid disappointments. This will also bring out any blind spots or open ends.

    Product development team should have the rights to reject any development effort that is not supported by an approved business case.

    ReplyDelete
  2. Shekhar,

    I had the good fortune to work in a highly successful Product Development house in Dublin, Rep. of Ireland. My role made making inroads into the minds and works of the Product Management team, rather easy. Two things that I observed (among others) stayed with me:

    1) There was a sizeable tech-side representation in the Product Management team. In fact, a couple of them came from the Engineering team itself with years of experience on what the core functionality included, what it didn't and what could _possibly_ be done to bridge the gap!

    2) Given a choice between Quality and Timeliness by the Engineering team, Product Management team almost always went for the former. They believed that a customer was more comfortable with less troublesome days post-release, than with a highly visible early release resulting in 2 calls to CS per week as days went by. Some of those customers (I have personally interacted with) included Boeing, Nortel, NTT DoCoMo, Alcatel and Raytheon. No pushovers, one would admit.

    So, Product Management and Engineering team need to live a life of symbiosis. One needs the other and each needs to be able to see the product from others point of view.

    My 2 cents.

    ReplyDelete
  3. Came late into this.
    As an entrepreneur building a software product out of India, I can honestly relate to a lot of advices here.
    I did ensure we have a very open discussion about the business need of what we are building with the development team. We involved the tech team in discussing the major features and allowed them to question the cost-benefit of including features in the first release vis a vis keeping it till later.
    Having a very tight budget helps!

    ReplyDelete