Excerpt from another blog
"Good business analysis helps you make sure you build the right thing, at the right time, for the right reasons. By focusing on an organization's business objectives, tracing those to a viable solution with the necessary set of features, and then tracing further to detailed requirements, Business Analysts ensure that the organization's efforts are focused on the right things (features and requirements) for the right reasons (business objectives). In this economy, no company has the luxury to "build one to throw away" or even "fix it in release two." We all have to get it right the first time, and that's exactly what business analysis lets you do."
Though what Mike states in above post is true that in hard economic times organization can't afford to build and ship the unwanted product, I could substitute the role of business analyst with a product manager in above excerpt . (Though, in a non-product based, custom IT department organization, business analysts do have to wear the hat of a product manager).
A skilled product manager is equipped with powers to filter incoming demands, translate them into detailed product requirements, prioritize them for upcoming releases, and align with organization's vision and objectives.
Additionally, this fuziness of roles between a product manager and business analysts in especially dominant in asian market even in product based companies.
From another post,
I’ll be brought into a company and they often don’t have product managers or user experience designers – they generally do have project managers, andmaybe some form of “business analyst,” and of course IT developers, and they all usually report into a CIO. Sometimes I even find that the company has been outsourcing “the website” to external agencies to design and run.
Compared to a inhouse/custom IT solution, a consumer product requires higher standard of user experience in terms of performance, availability and ressilience, and product management techniques need to be applied to make sure the software doesn't fail.
Showing posts with label recession. Show all posts
Showing posts with label recession. Show all posts
Saturday, April 4, 2009
Monday, March 23, 2009
16. Understanding and trust
There has been a pause.. and a long one.
Finally, after a month of absence, I am back to jotting my journey. I came out of my current product manager role. Worse, I was asked to leave. I am now figuring out the next assignemnt and analyzing what went wrong with the last one.
In my next few posts, I will jot down about an ideal group I should be working with.
Notice: Following is a professional rant post! Skip it, if ranting makes you uneasy. or maybe, there is a lesson for some PM some where.
For one, it was clear from the beginning that I was to work on a product with long history of unresolved issues.
Two, I was working for a company that was essentially multiple products bunched together, with no proper insight into vision and direction. Top brass is still too busy tactically trying to hold on for survival like a scavenger holding on to remaining pieces of meat. Strategy was out of question.
Three, product engineering team had absolutely no trust in management, and vice versa. Engineering team was shouting for refactoring and were being ignored. Infact, engineering teams were fired as a whole more than once to curb the voice. But, every new team that came in was sure: they need to refactor code.
On the other hand, people in marketing, sales, customer support, and customers themselves were worried about managing the production deployments, and silence from engineering could mean losing trust with customers, and ultimately losing business.
We lacked leadership. We needed someone who could tell the customers what's wrong, and how it can be fixed, and when it will be fixed. Someone who could take approval from customers and pass on the approval to engineering. We needed transparency between customers and engineering.
Instead, as a scavenger would do, company was discussing exit strategies for the product. Not a bad thing to do, if current resources are limited and there is little assurance of future resources to keep going.
As a product manager, it was my responsibility to tell customers that we are in trouble and need time. We needed patience from our customers. And I went on a spree to start interaction with our oldest and most loyal customers. And as I expected, they understood and offered willingness to stand-by while we fix the product. Efforts were taken to bring transparency to marketing, sales and customer support, and give visibility into engineering operations. Many complained, but everyone understood. Half the battle won!
The other half of the battle was to bring more transparency and visibility to engineering team. (Although I was placed in same office as engineering team, my interaction was limited to engineering managers only, which was later narrowed down to single point of contact: program manager.) Anyways, my job was to tell the engineering managers what customers wanted, while at the same time, to tell customers NO, because engineering is doing something more fundamental.
But, it backfired. And badly.
Engineering team saw my presence and efforts as a waste of time. They were already booked for next 2 years, and were not interested in knowing what customers wanted. They wanted silence so that they could fix the product, and did not want me there with them, in their office. They wanted no interaction: no product manager, no customer interaction, no customer support interaction.
After much effort, my interaction with engineering head improved, and we started to understand each other.
Then, something happened. CEO, CMO, CTO, all changed, overnight! There was choas in the company. Engineering head, with whom, I had finally developed cordial relationship, was replaced. And he concluded that my interactions with program manager are creating choas in engineering and hindering his new relationship with his team. Of course, my superiors also did not want to have a bad relationship with new engineering head.
And here I am, wondering and analyzing: what went wrong?
Here are the possibilities:
Finally, after a month of absence, I am back to jotting my journey. I came out of my current product manager role. Worse, I was asked to leave. I am now figuring out the next assignemnt and analyzing what went wrong with the last one.
In my next few posts, I will jot down about an ideal group I should be working with.
Notice: Following is a professional rant post! Skip it, if ranting makes you uneasy. or maybe, there is a lesson for some PM some where.
For one, it was clear from the beginning that I was to work on a product with long history of unresolved issues.
Two, I was working for a company that was essentially multiple products bunched together, with no proper insight into vision and direction. Top brass is still too busy tactically trying to hold on for survival like a scavenger holding on to remaining pieces of meat. Strategy was out of question.
Three, product engineering team had absolutely no trust in management, and vice versa. Engineering team was shouting for refactoring and were being ignored. Infact, engineering teams were fired as a whole more than once to curb the voice. But, every new team that came in was sure: they need to refactor code.
On the other hand, people in marketing, sales, customer support, and customers themselves were worried about managing the production deployments, and silence from engineering could mean losing trust with customers, and ultimately losing business.
We lacked leadership. We needed someone who could tell the customers what's wrong, and how it can be fixed, and when it will be fixed. Someone who could take approval from customers and pass on the approval to engineering. We needed transparency between customers and engineering.
Instead, as a scavenger would do, company was discussing exit strategies for the product. Not a bad thing to do, if current resources are limited and there is little assurance of future resources to keep going.
As a product manager, it was my responsibility to tell customers that we are in trouble and need time. We needed patience from our customers. And I went on a spree to start interaction with our oldest and most loyal customers. And as I expected, they understood and offered willingness to stand-by while we fix the product. Efforts were taken to bring transparency to marketing, sales and customer support, and give visibility into engineering operations. Many complained, but everyone understood. Half the battle won!
The other half of the battle was to bring more transparency and visibility to engineering team. (Although I was placed in same office as engineering team, my interaction was limited to engineering managers only, which was later narrowed down to single point of contact: program manager.) Anyways, my job was to tell the engineering managers what customers wanted, while at the same time, to tell customers NO, because engineering is doing something more fundamental.
But, it backfired. And badly.
Engineering team saw my presence and efforts as a waste of time. They were already booked for next 2 years, and were not interested in knowing what customers wanted. They wanted silence so that they could fix the product, and did not want me there with them, in their office. They wanted no interaction: no product manager, no customer interaction, no customer support interaction.
After much effort, my interaction with engineering head improved, and we started to understand each other.
Then, something happened. CEO, CMO, CTO, all changed, overnight! There was choas in the company. Engineering head, with whom, I had finally developed cordial relationship, was replaced. And he concluded that my interactions with program manager are creating choas in engineering and hindering his new relationship with his team. Of course, my superiors also did not want to have a bad relationship with new engineering head.
And here I am, wondering and analyzing: what went wrong?
Here are the possibilities:
- I was going too fast, and trying to change the company culture faster than could be handled. My attempt to bring transparency and visibility may have been the over-estimation of skills of my conact in engineering team (program manager) to digest and utilize the visibility.
- The new engineering team management reacted too fast to decide visibility is a hole, and fix it. The visibility I was providing (with authorization from my manager) to program manager was somehow proving to be choatic in engineering team. And top management of product management wanted no friction from the top management in engineering, and as result, I lost a chance to further learn from my experienced peer product managers.
Subscribe to:
Posts (Atom)
Posts
