Product Manager – A Cross-functional Leader

(This post was first made in LinkedIn)

Product manager, as we all know, is a cross-functional leader without any authority over other stakeholder teams– viz. Engineering, Sales, and Marketing et al – in an organization. However, product managers own the sole responsibility for the success- both tangible and intangible – of the product. This conflicting expectations demand a product manager to balance the product priorities and to acknowledge the anticipations from the stakeholder teams.

There are many approaches or organization based frameworks that are available to aid in prioritizing the product features. Few of the popular frameworks include Kano analysis, affinitization diagrams etc. With that, acknowledging the stakeholder teams is a very sensitive area that requires some special skill.

I have tried to cover some of the key points below that, I feel, are important for a product manager to manage the expectations of the cross-functional teams:

Communicate: As the word “stakeholder” suggests, each team owns a part of the product and it is important for them to understand the business problem that is being solved and also the business value the product is expected to deliver. MRDs and PRDs are expected to provide all necessary information for the respective teams. In reality, teams do not have bandwidth to spend time on reading over the complete documentation. Hence the product manager should schedule an elaborate kick-off meeting to explain the feature in detail and to answer any queries from the stakeholder teams. This is a session to get everyone on the same page, and to clear any doubts. Post this meeting, PRDs and MRDs can be treated as a reference documents. The communication channel initiated at this point should be open until the delivery of the product.

Listen: Though product managers are expected to cover all details about the features with the MRD and PRD, in reality there might be some valid points that are bound to be missed in these artifacts. Product manager should always keep his/her ears open for the questions or suggestions from the stakeholder teams, without any presumptions. Each of these queries might carry a value add to the product and the feature in question. A good product manager is someone who always gives due respect to the thoughts of the team members and treats their suggestions on merit.

Give and Take: Based on my experience, product delivery and implementation is not always a one way channel – especially with the Engineering teams. Teams would like to add some features that they feel are important. There should be constructive discussions around these suggestions and product manager should weigh these suggestions against the available backlog and the problem in hand. Mostly these suggestions might fall under R&D category, which might require building the feature with some hypothesis. Instead of shunning the idea down, product manager should try to give some bandwidth to build a PoC, at a small scale, with a satisfactory hypothesis. Doing this, the product manager is acknowledging the drive of the engineering team or other teams, and also validating the idea in the market. Instead of missing some new and disruptive ideas, with some narrow vision, this step will open doors for a new level of discussions that will help the product to address customer pain points.

Deliver: It is imperative for the product manager to respond to the requests from the teams on time, every time. From the initiation of the project, there is always some information exchange that happens among the stakeholder teams. Product manager gains credibility by delivering the necessary information – be it an email reply or an artifact – on time as promised to the respective teams. It gives assurance to the stakeholders and ameliorates the trust.

I am sure I might have missed some key points that are worth discussing here. Feel free to add comments so we can build a framework to help a product manager to be a better cross-functional leader.

Advertisements

Pulling a product out of the portfolio?

Sunsetting a product, from a portfolio, is the decision to pull the product out of market based on profitability numbers. Cost, profit and revenue are the three critical metrics that drive these decision. If a product’s cost to profit ratio is increasing, it is a better to pull the product out of the market. Any product or feature that does not justify the investment, with corresponding sales and profit, should be pulled out of the market. Though the decision of pulling a product out can be driven by these three factors, pulling out a feature from a product can be a challenge. It is important to understand the key value add that feature provides to the customer.

First step in pulling a product out is to stop any developmental efforts, while continuing the support for the existing customers. Important decision had to be taken with respect to the support, as supporting one single customer might be an overhead. Continuing support is not a good option, unless it serves a statistically significant number of customers.

Sunsetting a product:

This is a collective decision taken by the product, the sales and the marketing departments. Sales team should contact the current customers and plan their communications. Marketing team should modify the brand communication based on the change.

Product managers make this decision based on following reasons:

Strategic fit: The product might be profitable, but it might not align with the organizational strategy. This product can be pulled from the market.
Market Factors: Don’t have a product that serves the market that is technologically old. Organization should concentrate on market that is advancing and that has a future, else the product is a candidate for pull out.
Portfolio fit: Redundant products can be pulled out of the portfolio, as a cleanup activity.

These activities must be planned keeping customer in mind:
Inform the customer: Give prior information and transition plan to the customers, in order to avoid any surprises.
Act as a strategic partner: If there is no substitute for a product within our portfolio, play a role of strategic partner and suggest where they can find the product.

Unplugging a feature:

Earlier companies used tactics like surveying customers to understanding features that added value to them. Currently, there are various new solutions to identify features that add values to the customers. Click stream (CS) analysis can be seen as a frontrunner. Integrating CS with any product will provide deep insights about highly used features and irrelevant features. Companies should either improve their training to help customers to use the features or pull them out of the product.

As discussed in my feature decision post, identifying value adding feature is a real key for nurturing the product. A strategic decision to be made before implementing a feature for a single customer. Any investment to a feature should be seen as an investment that can provide recurring revenue without high additional marginal cost. Similarly, a single customer feature has to be removed if it does not make any financial sense to the organization.

Un-launch Plan:

There should be a clear un-launch should be in place for pulling a product out of the market, with all communications well planned. Inform the existing customers via sales team. Inform via the website and revise the feature chart of the product.

With a well planned execution of this unlauch plan with transparent process, organizations can sustain their good will of the customers. Sunsetting also helps the companies to focus on what really matters for its strategy. Any distraction from the product strategy should be slowly moved out of the way.

A/B testing and misconceptions

A/B testing is one of the most used and one of the most misunderstood testing methods in internet product management.The drive for making this post was taken from a sentence by one of our senior managers. The statement goes like this “… we can do A/B testing to see how the posting works within our system and directly in the platform…”. The abovementioned testing is a refined form of a regression testing to verify the system functionality, and not A/B testing.

A/B testing, for example, will help companies like Amazon, Flipkart etc, who rely on consumer purchase cycle to realize revenue. These sites’ user interface should motivate consumers to follow through each and everystep till purchase of a particular product. Hence they typically choose 1% of their target population to test the variations in their webpage and track the conversions. The variations will range from position of buttons, banners, product image etc. The beauty of software, especially internet products, is the ease of iterating after every launch. These products can release a variation every day, if it promises increased conversion.

A/B testing also will give a clear insight on page loading time for each variations, customer drop rate for each page and customer click stream. I came across an article, which explains A/B testing – with do’s and don’ts. Read More.

Product – Feature Decisions

Normally a Product Manager will be bombarded with new ideas and features every day. Apart from all the cost – and profit – center decisions, PM must be equipped to spot the features that are most aligned to his/her existing product portfolio. Failing to decide might result in a feature that is completely out of current product line, which means wasted investment. With growing pressure to keep the product alive, some product managers continually feed the feature resulting in misaligned investments.

The following three dimensional analyses will provide a method to analyze whether a particular feature or product is a part of product portfolio.

Thanks Prof. Joel D. Goldhar for the 3-D analysis.

Whenever an idea is proposed, it is important to understand the target customer and the problem we are expected to solve. To understand the target market, we normally perform market research, anthropological studies, and customer interactions. A product manager should have clear understanding of the whole experiment, as s/he is responsible for the success/failure of the product. This initial step of understanding the market problem will help her/him in working outward-in to develop a product or a feature.

To get to the second part, i.e. what problem are we solving; a PM should be aware of the competition and their competitive advantage. Basically they should apply Porter’s Five Forces to understand the whole market place for that particular product feature. This would help in understanding the worthiness of the investment they are planning to make.

By doing the first two steps diligently, a PM will have a clear understanding of the customer and the problem before addressing the How. How involves whole business side decisions – Distribution strategy, Buy –Build or Partner decisions, Positioning, Sales Process etc. (All these are a part of decision making according to Pragmatic Marketing Framework).

After these steps, a PM can view the product in two ways – deliver the feature as a value-add to the existing customers or make this product feature independent of the product itself. If they are serving entirely different target segment, then the product has to be delivered independently and should be managed separately.

Google Wave can be a better example, as an independent product, it was a failure. But when served as a value-add with Google Docs, the cross collaboration is a great success. Similarly, Google Buzz provided as a value-add with Gmail was a failure. This shows the importance of a PM role as a visionary.

Comments and Arguments are Welcomed.

Value Differentiation Strategy

As a product manager, one has to come up with innovative ideas to beat the competition. Innovative ideas that do not cater to market needs are often useless, it is for this reason a PM should be in constant touch with the customers and prospects to gain a clear understanding of their needs. Normally in highly fragmented markets, PMs spend major part of their time in imitating their competitors and miss their opportunity to innovate. Through this post, I would like to share my opinion on key differences between these two strategies.

Value differentiation is explained by three circles concept Mr. Joel and Mr. James in HBR, which is shown below.

Every product from an organization should try to increase the points of difference by moving towards right, i.e. covering maximum customer needs. This can be done by performing market research, anthropological studies or by having constant discussions with their customers and prospects. One should be wary of the fact that their competition will also try to do the same. This might result in increased points of parity. PMs also know that there is some grey area in customer needs circle, i.e. some needs customer is not aware of. Innovative PMs try to come up with features that solve these issues, which will delight the customer. These are the steps that always give an edge for a company.
 
PMs should keep a close eye on their product and its life cycle. In early stages of a product cycle, PMs can make investment decisions to increase R&D as each feature added might result in improved top line or a new customer acquisition for that product. While in the later stages, PMs should be careful in making investment decisions as they have downward price pressure and all their R&D investment decisions should be made based on the RoI contribution. Companies that understand the role of constant innovation are clear winners. Google, Apple and Amazon are epitome of value differentiation strategy, with their products that always hit the grey area in customer needs circle.
 
Catch up strategy is the exact opposite of value differentiation strategy, where the company is trying to imitate their competitors and lose their edge. Their competitors are always one step ahead and the company always fights for a share in points of parity. This will result in a redundant product and this will lower the switching costs for the customers.
 
With these two strategies, the pivotal role of PMs is very clear as they have to come up with features or products that clearly differentiate from their competitors. Within a big company, this will result in delightful customers or new customers, resulting in improved top line/bottom line. In an early stage company, this will result in a new customer or a buyer, who is ready to pay a premium.

Be Agile!!!

From late 80s to early 2000, all companies used SDLC and waterfall model– gathering requirement, design, development, testing and deployment -interchangeably. Currently, there is a huge surge towards Agile and every organization is moving towards Agile methodologies. I believe (add your thoughts in the comments) following are few key components to drive an Agile product/project management.

a. Absolute understanding of customer requirements
b. Clear process and communication
c. Cohesive team with an ability to maintain the pace
d. Above all, understanding the real Agile

Any product that does not comply with user requirements is bound to be a failure. Product Manager, inbound or outbound, should have a clear understanding of all the use cases of the feature requested. More time spent in this initial stage guarantees quality feature that satisfies the client, and also less time spent on firefighting in the later part. Further, this stage should help the product owner to define the workflow and user stories for this particular feature.

Many might question the inclusion of process here. A robust configuration and release process is required to be a superior Agile product team. Agile is quick, and having processes – like configuration management and release management – will help the team in working on their deliverables, and rest will be taken care of by the existing process. Apart from that, the team should be able to communicate well, which is the reason for having an Agile war room. The main problem with the distributed teams following Agile is communication. This can be solved by religiously following the daily standup meetings, where each one of the team member can provide some hint on their progress. To give an insight, during our training 16 members answered the questions pertaining to the daily standup meeting in 10 minutes. It should be that short. One important goal of this standup meeting is to share the impediments they face, which other team members might be able to solve or help to solve. These standup meeting is not a resolution meeting, but more of an awareness meeting.

The development team should have a clear mindset to sustain their pace in every sprint. Product owner plans a sprint and decides on a sprint backlog based on the team’s velocity. Though product manager can accommodate any drop/improvement in the team velocity, if the team can try to have a constant velocity – which I know is hard – will help the product owner in better planning the further sprints and releases.

Typical agile process is mentioned in the below diagram.


Courtesy: http://www.codeplex.com

Any agile product should have a backlog of user stories written by the product owner or by the team facing the customer. User stories should follow expected format with acceptance test criteria, which will help the development team in knowing what they should achieve. Release planning meeting should have all the user stories that are planned for a release. A release is a combination of sprints; 3-4 sprints can be combined to be a release. Based on the team’s suggestion, each user story should be sized. The user story size is a key while moving the user stories from product backlog/release backlog to sprint backlog. This size is a key in generating sprint burn down and release burn down charts. As a strong believer of evidence based decision making, I believe these charts are important in deciding future releases and sprints. Sprint review meeting and retrospective meetings will help the team in understanding the key challenges they faced in earlier sprints and also key process changes they have to make to perform better. Any team that follows agile should have this process.

Though Agile has many other components, if we have these things set. We can rule the Agile world. Any additional thoughts to improve the learning are welcome.

Does this mean Self-Learning is better than teachers?

Sugata Mitra, educational scientist from India, has done various experiment from 1999 to test children’s self learning capabilities. He introduced ‘Hole in the Wall’ concept in many part of India to allow students to use the computer freely and learn from that. His results were astonishing and hope this will continue to expand all over India.

Children these days need a guide, not a teacher. They can learn everything themselves. They need someone to say which is the easy way and what is right. I believe Indian educational system will take this and implement this soon.

Looking forward for the change.