Showing posts with label Product Management. Show all posts
Showing posts with label Product Management. Show all posts

Sunday, May 29, 2011

How to take a Transaction Based Vendor Relationship to the next level?

In the following blog, I talk about "What is the definition of a strategic partnership with a vendor?" and outline a few thoughts on how large enterprises should engage with their vendor partenes and what the expectations of such a relationship should be.  A fellow blogger of mine expressed his "dissapointment" with vendor partners and their focus on selling new product as opposed to helping maximize the returns from the existing IT Assets.

I whole heartedly agree the pressure from vendors can be exasperating.  I was thinking if there is a way to turn this around. What if  as an example, your IT product vendor were told that they would have to provide expertise (at no cost) to solve current interoperability issues or resolve performance bottlenecks between their product and one other product while show casing a operations admin and management/ monitoring tool - OAM tool?  This would be their elite product engineering or premium consulting service participating on-site mentoring your team and not the "support" organization which has to trouble shoot remotely.

Another example, if this is a package solution vendor with a long deployment cycle then the vendor can be asked to offer (again for free) analysis tools or processes or best practices and other accelerator kits that improve speed to market for their product, with the chance to demonstrate components of their next generation product.  Again, the vendor has to part with IP (intellectual property) and address your pain point with the chance to demo a product that would or could be a fit in "your" enterprise.


The result would be the ability to extend or enhance the life of existing investments, while evaluating the vendor product, vendor processes and expertise in a real life scenario.  Most importantly however, you are putting their resolve to test as to whether they are able to or willing to be your strategic partner and not just a transactions based product vendor.

Of course, I would be remiss in not stating that VMO, PMO and your legal departments would have to help with insuring this was a fair and scientific discovery process and also, that the licensing models were conducive to both parties.

As always your comments are welcome. 

Surekha -

Tuesday, October 05, 2010

Should Architects aspire to be Product Managers?

One of the interesting trends I am observing is that Architectures aspiring to be Product Managers. Have recently come across multiple PM who were architects and have also been approached my a few who are interested in becoming one.

Following are my thoughts on when Architects should consider PM as their career path.
  1. A true Business Architect with the ability to map the technology strategy to align with the Business Strategy
  2. Good understanding and hopefully first hand experience interacting with the real customer (not the business units)
  3. Good understanding of revenue and business model
  4. Passionate and believe about the role of the products in the customers life (whatever they are using the product for)
  5. Ability to influence cross-functional team and get everyone passionate and focused on the product
  6. Willing to change course mid-stream based on customer/market feedback
  7. Ability to ride up and down the market roller coaster
  8. Ability to keep singularly focused on an single product/portfolio

Do not take on the role:
  1. by assuming that PM get to define the product and every one else will follow without any questions (the PM is responsible for bringing every one on board)
  2. consider whether one would be a great Architect vs. a good Product Manager (focus on what one is better at doing - a great advise given to me by my manager)
  3. do not want to deal with constant communication with customers / leadership teams
  4. assume that the grass is greener there - doing what one does best shall reap the right rewards

Just my point of view and this could also apply for taking on a role of a Business Liaison in an IT organizations.

- Yogish

Key Learnings - Using EDA to implement the core SOA principle of "loose-coupling"!!!

A lot has been said about how SOA and EDA are unique "architecture styles". It seems like only one or the other architectural prin...