Product Management for Pummies

2008-08-06T11:30:00.000+05:30

Habitat Level Product Management
1. Introduction to Product Management
2. Customer and Satisfaction
3. End User Requirements
4. Business Summer and Winter
5. Relationship and Revealingship Sales
6. PLM from Product Business Perspective
7. PLM from customer perspective
8. Competition Focus & Market Tracking

Also Refer to Product Management Cartoons

Product Management Cartoons

2008-07-28T10:46:00.008+05:30

See post here

See Post here

How and When of PLM..

2008-07-25T18:40:00.007+05:30

In the last post, I had talked about PLM from Product business perspective. In this post, I will talk about PLM from customer perspective.

PLM conundrum
There is a fundamental conundrum in PLM. Customers require a stable service without disruption with least management and that goes on expanding its features that fetches them more revenue to fight against their competition. This means that Vendor has to ensure his product is continuously upgraded seamlessly.

Also Vendors life depends on the product. Hence vendor has to ensure that the given product has to provide continuous business that is profitable to maintain. Vendor is also interested in continuous seamless upgrade.

The conundrum is in a more fundamental aspect. The aspect of ‘Change’. Change is rather a series of discontinuities than a continuous flowing element.

Hence change poses a limit to which continuous upgrades that enhances the real value of product can happen. Continuous upgrades can embellish a product further and enhance sales to certain extent. They won’t necessarily give the much needed new life or revenue to the product.

This is the conundrum in which developers perceive change and the customers want change. Customers often want change as smooth flowing and developer perceive it as a series of discontinuities.

Sometimes in my experience, I have seen some continuous upgrades have provided a big lift to the product. But if investigated, it would turn out that the given set of changes/features could have been easily visualized at the definition of product. It is more a ‘catching the tail’ effort, in these cases.

Real product enhancements can happen only when fundamental shifts happen in the way we define the product. This could be due to change in environment, better understanding of customer environment, change in technologies that enable new ideas etc.

When such product enhancements happen, mostly it is difficult to provide it as a seamless continuous upgrade. So the issue of life of every product assumes importance. When to effect the change in product (when to kill the old version) and how to effect the change in customer environment are important decisions for PLM.

Twin Problems of PLM: How and When..?
The twin problems of PLM, when to kill a product version/model and how to do it in customers place can be resolved only specific to customer environment.

Migration Path
Customers do not bother about fundamental shift in the product design or technology. They look at solutions that fulfill the need. Hence they may not give credit to the fact that fundamental design has changed. They would like to have the new version anytime, if that does not bother their operations or working and is guaranteed to provide more satisfaction.

But that is not the case always. Generally fundamental shift in design is always associated with shift in the way product lives in customer environment. The shifts could be in the form of databases, operating systems, hardware or the concept of user interfaces. So it becomes necessary that customers experience a pain in migrating to new product.

While customers may want new product models, they may not want the associated pain. If they perceive a pain exists in this process, they will throw out the idea of new product models. And this will result in obsoleted product models getting stuck in customer places, requiring expensive support. This could result in bad blood with customer, who if forced to change to the new product with pain, may change the vendor himself.

In my experience the fundamental problem in this is that a migration path is not well defined, when product gets developed and maintained. Frankly in 90% of the cases, a painless migration path is possible in software products, even across disparate and diverse platforms and architectures. But Product Managers and Technology managers do not define the migration path, when new product models or versions get developed or changed. They do not provide great importace to this migration path.

At times, defining a migration path may not be that much difficult. It could be fairly simple. But since no though process goes into it, it appears very difficult and is often left to poor customers.

Hence it is important that Product Managers drive their technology counterparts to define a migration path that makes the life easy for customer, after understanding the customer environment very well.

Timing of Migration
It is important to time the migration of product models in customer places. Product development happens in its own cycle and Customer’s business happens in its own cycle. These two may not necessarily match, as product development follows the aggregate of customer business movement and not individual customer.

Most of the time, I have seen Sales pitching new product models and versions with customers at opportune moment of theirs and not the opportune moment of their customers.

And to identify the opportune moment sales need to work continuously with customers without imposing the new model or version, but by enabling customers to understand that their product versions and service offerings are improving.

When to start NPD..?
Product development for new models and versions can start anytime, once the roadmap is clear and requirements for next set of product versions are frozen.

But these requirements have to be mapped with clear cut business objectives and revenue objectives for the business. The business objectives consists of sales volumes, revenues and margins, future business that are possible, new market/geographical segment or customer diversification that would be made possible etc.

Many a times requirements are not tied with business vision for new models and versions. In such cases there is no way to calibrate the business achievements or success of the new model. Unless there is a goal or business objective is set at the definition stage, its success cannot be measured.

In general it is a good practice to create a P&L for every model, both at the start of the model and with every sale though at times it calls for painful changes in business process. This should be done atleast in important models.

Generally PLM is more treated as a non-revenue, techno-commercial function. But in this blog, I had categorized PLM as an aspect of Revenue categorization under Revenue Focus in Habitat Level Management.

Earning Focus
The next parameter in Revenue focus is Earning Parameters focus. What I call as Earning Parameters are those parameters that determine the success of the product business. They could be Gross, EBITDA or Net Margins as the case may be.

I would strongly recommend Product Managers to understand their business and determine the earning parameter that they need to concentrate on. They need to synchronize this with their management.

In case multiple products or models or versions are being managed, then a parameter like EBITDA can be used effectively for relative comparison of profitability of product businesses. EBITDA is a good parameter at this level as a comparing metric for earnings of different products and over time.

Once a product manager has an earning focus, he would definitely ensure that all upgrades and models are valued appropriately and the values recovered by pricing the upgrades appropriately.

This is needed because Product Managers need to be clear in their mind what is part of Annual Maintenance Contract and Warranty terms of Customers and what is not. They need to communicate it to end customers through appropriate channels and be in sync with customers on that. Once the revenue focus is there it would automatically drive the Product Managers to clean up their house in terms of what they offer to customer on a continuing basis.

With this I end my thoughts on Revenue focus. Let me share my thoughts on Competition focus in my next post.

-Balajee Rajaram

The Product Manager: Laborer, Mason, Engineer and Architect

2008-07-15T15:54:00.002+05:30

Revenue Categorization: Understanding the Product Life Cycle
Before I proceed further with revenue categorization, let me talk about Product Life Cycle Management, which is a very important dimension of Habitat Level Product Management. Understanding Product Life Cycle Management in proper perspective is important to understand the benefits Revenue Categorization leads to.

Product Life Cycle Management starts at the time product gets conceptualized and defined. But traditionally people start Product Life Cycle Management, when it is on its deathbed or sometimes after it has expired.

At the habitat level, Product Life Cycle is all about adapting the product to the different customer requirements, new features needed for operations, customer business etc. In short it is all about creating different species of the product for its adaptation and survival.

But Product Life Cycle management can be thought of as simple as Version management particularly in field. An unskilled laborer says he is placing bricks on cement and mortar. A mason says he is building a wall. An engineer says he is building a house. An architect says he is building a home. It all depends on Product Manager being a laborer or mason or engineer or architect.

Product Manager should have the vision of an architect, plan of an engineer, objectives of mason and work like laborer.

A product generally grows in three different dimensions.

1. One dimension is that of new features as envisioned as requirements by Customer’s or from market that could be applied across to multiple customers. This grows with respect to time and has end-of-life and support issues.
2. Another dimension is due to obsolescence of components or features generated by Product development teams. This also grows with respect to time and has end-of-life and support issues.
3. Third dimension is that of those customizations that are restricted to certain customers or geographies. This grows with respect to customers. Typically these solidify as product models and exist all the time.

Product Manager as a Laborer (Version Control and Management)
The first job of Product Manager is to ensure that there are no uncontrolled versions of products floating around. The next job is to ensure that the number of versions are very limited in all three dimensions. Version growth is like Population growth. It is advantageous in the sense it gives multiple forces to fight the market. It is disadvantageous in the sense it depletes our resources. The product manager has to find a balance in the population growth by working with customers as well as technology teams.

What is the right rate of growth for population..? Ideally slightly less than 2 kids per family. Similarly per particular market segment ideally not more than 2 product models, which may grow in versions as time progresses. Again ideally at any place a version should not exist more than 18-24 months, unless the product model growth has stopped further.

But these could be re-defined based on the product market and geography. The idea is a Product Manager must know what these values are. The product manager has to ensure that the models and versions are well controlled.

Product Manager as a Mason (Model Control and Management)
At a mason level, the Product Manager has the responsibility of defining the models appropriately for different segments and customer needs. He will not be looking at it as version management. The idea here should be to monitor individual models as individual products and track their lifecycle separately.

As a mason, product manager should bring in a serious revenue perspective to growth of models. Models grow based on revenue and revenue potential. As the mason builds walls after walls, a product manager need to build models based on revenue.

Product Manager needs to properly categorize revenue based on the models. Current revenues and Revenue potentials decide the life and intensity of a model. It would be a good practice to create P&L for every model, so that not only revenues, but all associated expenditures are tracked and a realistic margin is arrived at.

Many a times, for revenue categorization Product Managers may have to tweak business processes and how Finance and Accounts handle the revenue and expenditure categorization, as that vision might not be originally built in.

Product Manager as an Engineer (Planning the Basic Models)
At an engineer level, the Product Manager has to plan for different models apriori. Different market segments and needs, customer and customer cultures need to be understood before defining the models.

The key decision is to define when a model is to be formed. Left alone, Technology teams decide models based on features, code base, hardware platform or operating system. This is like building walls based on availability of wood or mortar or cement. Just because materials are available, will we keep building walls..?

The right way to define models is based on the customer need and the revenue differentiation it would bring. Product Managers have to perceive the different product models as like the walls of a business house. They have to be in the right place, conveying the right value.

The value of a wall is in providing separation in terms of privacy and security. Similarly product models need to provide revenue separation in terms of growth prospects and revenue stability. That is, Product Managers should create product models if model definition brings in a different revenue growth and revenue stability.

Sometime Product Managers try to make every product positioning as a model. It would work sometimes. Many times it would not work. I have observed that it works only when the justification for the model based on different product position is due to different revenue flows or revenue growth from other positioning.

At this level, the Product manager should have P&L’s for every model as well as the whole product and understand which model moves currently and what can move in next 3-4 quarters.

Product Manager as an Architect
An architect has to visualize his construction even before a single activity is carried out. Similarly product managers need to visualize their product business even before the product is designed. Once a vision of the product business house is in place, as product develops, reaches customers and matures, the vision can be modified to enable more profits, more cash-flow and more customer value.

Hence the product manager must have a roadmap for the product in terms of its applicability and adaptability. An architect while envisioning a building would clearly know for what purpose the building is being built, to what all purposes it need to be adaptable, how much of air, water, light, parking and other sanitary facilities would be required etc.

Similarly a product manager as an architect need to have an idea of which market segments it is currently applicable, to which it can be adapted, to which it cannot be adapted or will be difficult to adapt, kind of resources it would require at customer premises (space, electric power, CPU power, hardware, operating skillsets etc) and kind of resources it would require to develop (Human resources, skill sets, software requirements, hardware requirements etc).

Once these are known, the product manager should set about defining every aspect of the product, to develop it and as it would exist in customer premises. He should also define some basic models possible and then leave it to the engineer for further re-definitions as product moves in the market.

At this level, the Product Manager has to have a P&L for the overall product in terms of its models for next 24-36 months. Product Manager should also have an idea of upgrading the product to newer products. This is because once a product is in market and with customers with decent revenue generation, it gives a huge customer base for the next product.

Version or Model or New Product..?
Often there will be issues in classifying the product as a newer Version or Model or a totally new product.

The desire to ride on existing product would force Product Managers to pitch it as a new model that is upgradeable (or exchangeable). Desire to create more revenues would force us towards New Product approach all together. So Product managers simply end up marketing a product as new product but selling as a new model. Similarly the desire for revenues pushes product managers to determine newer versions as newer models.

The distinction between them is blurred and flexible.

A thumb rule that I use is as follows:

If a particular version could be frozen and it could fetch fresh sales in the market or could be used to trigger fresh sales in the market, I define it as a new model.

If a particular model offers a break with the past, if contrasted with the existing environment, particularly technology-wise or sometimes business-wise, then I would define it as a new product.

I would NOT make these decisions based on if it is upgradeable or not, though that would be a factor to consider from the customer angle, for positioning the product.

Issues in Product Life Cycle Management
The critical issues generally associated with Product Life Cycle Management apart from the above are When to do it and How to do it..?

When to bring out a version, model or product..? Is it the traditional method, when we start hitting the slump..? How to ensure upgradeability..? How to sell upgrades or new models to customers, when they have already invested in our product..? Can everybody become Bill Gates and ask their customers to buy their product every 2-3 years..?

This and more in my next blog..

-Balajee Rajaram

Relationship Sales and Revealing-ship Sales..

2008-07-10T22:14:00.001+05:30

Price Determination
How to price a product or a service..? As I wrote in the last blog, our margin has to be near the fire (which is the value of the product) in such a way that it gives us heat and light, but not so near that it hurts us. Margin represents our value addition to the value of the product.

How to determine this distance..? There are three parameters that determine this distance. First of course depends on the business environment, as explained in the last blog.

Second parameter is the value that is really perceived by the customer. In the fire that we lit, we expect a value. Our customer may perceive a different value of the product than us. Most of the times the pricing issues boil down to this difference in perception. If pricing can break a sale, then it is because of this condition.

Third parameter is the simple pressure on Customer side sourcing departments to constantly cut costs and prices of procurement, particularly in electronics goods. Customer departments will try to achieve this by promoting competition (even if it is innovative products) and hard bargaining. Most of the times, pricing issues due to this can delay the sale or reduce the sale, but not stop it entirely, unless the product is abundantly available and non-innovative in nature.

Coming back to the second parameter, the value perceived by customer, one method to determine the value perceived by the customer is to create a P&L for the customer, from the customer shoes. Many a times, product managers create a customer’s P&L in such a way that they need to sell that P&L first, before they sell the product.

Such a situation is ridiculous. Product manager needs to create a P&L only based on facts and that finds acceptance with Customer at face value without any great issues. No customer is going to accept a P&L projected by Product Manager. But then his objections should not fundamentally change the P&L.

Another way is to quantify the customer benefits of our solution in terms of loss that would otherwise incur to the customer. This is easier said than done. Many a times such quantifications would be 1 or 0. Either customer looses a lot or customer gains nothing. To arrive at a value that makes sense is difficult. Still one can put a probability of such occurrence and quantify the customer losses. Ofcourse this is not exhaustive.

The fundamental idea is to quantify the customer benefit or loss and from that derive the value of the product. Once quantification is done, the pricing can be determined more close to the value perception of customer.

The third parameter, the pressure on customer side sourcing department, has to be handled through a mix of relationship and what I call as revealing-ship. The customer needs to see that we are to our bones and there is not much he can extract out of the sale anymore.

In some cases, I have seen sourcing department personnel not only want to see their suppliers bone dry, they need to get the feeling that they have made them bone dry. Then only they will get satisfied. So the sales managers need to give that pleasure to the sourcing department personnel in 2-3 steps, so that they get satisfied of their action. This is what I call as ‘revealing-ship’.

A product manager needs to determine the price of a product taking into account all three factors.

Selling the price to Customer
There are several environments in selling the price to a customer. One is when there is no benchmark or competition for the product pricing. In this case the pricing depends on the value of the product as discussed in the last section.

Another is when there is a benchmark for pricing and we are actually above the benchmark. And the product manager finds it to be difficult for him to manage the pricing expectation. This turns a real hard bargain. This causes a lot of heart-burn in the sales team that is sandwiched between the customer and the product manager.

Product managers and Sales need to take a call together on the realities of the sale. The product manager needs to work as a team and share the stress of the sales team. The Sales need to deploy the best of their relationship. The product manager needs to bring out differentiation of the product either in customer need or in terms of future pricing benefits or in terms of scalability of product needs.

At some point they may even need to take a call on qualifying the sale and its potential together. They may need to decide on progressing with the sale or dropping the sale.

Pricing Pressures
A product manager often needs to face revenue related pressures from different quarters. There will be pressures from sales on squeezing the price, there will be pressure from management on increasing the bottom line, there will be pressure from operations or technology for increasing resources.

There is no way a Product Manager can handle this pressure all alone himself. It is simply out of question for anybody to do it.

The only way is to make revenue focus as part of business process in different departments. Sales, Technology, Operations or Support need to see their activities in terms of Revenue they generate.

Once when I was talking to sales groups on driving revenue focus, a sales person retorted “I know the revenues that I am generating. I can have revenue focus. How will a technology person have it?”.

I told him “It is simply the realization that you earn your salary and are getting paid out of your own efforts”.

And a successful product manager will communicate appropriate revenue focus to his technology and sales organizations. Just because Sales teams are handling revenues, it does not mean that they will have revenue focus. Many a Sales people I have met, who think their salaries are getting paid by investors and shareholders and not by their sales.

And one way to communicate this revenue focus is to make a P&L for every business activity. Even in a product, it could be done for every project, so that Sales and Operation teams see every project in revenue perspective.

For every product model or version, the technology has to see a P&L. They have see their efforts and the results. A product manager needs to create these tools and keep communicating this vision to his people.

Unless the revenue focus is built into every level, revenue pressures cannot be handled by product manager.

Revenue and pricing pressure is like the Temple Chariot. It needs to be pulled by all the relevant people in an organization. It cannot be left to be handled only by Sales or Product managers. And to ensure that is the job of a Product manager.

Revenue Categorization
The next challenge in Revenue focus is to assign or categorize the revenue appropriately to the product or project. In B2B organizations there are Product Revenues and Project Revenues. Project Revenues are those associated revenues with delivering, installing, commissioning, operating or maintaining one or more of products. Product Revenues are those associated with a product. Sometimes several products can get combined and typically sold in one lot.

In these cases it may be feasible or infeasible to separate the revenues out and categorize them. Hence Product Managers do not categorize the Revenues appropriately. They typically assign the revenues to the product that they perceive as the maximum value.

But if a product manager carefully categorizes the revenues, it may be possible to make a sale at higher profits or avoid loss making sales.

How..? In my next POST…..

-Balajee Rajaram

Business Summer and Winter

2008-07-07T19:06:00.001+05:30

The second basic principle in Habitat Level Management is Revenue focus. There can be no product management without revenue focus. Product Management without Revenue focus is like a Sword without a handle. However sharp it is, it cannot be used effectively.

As one would see in the following paragraphs, Cash flow is the oxygen to any product or business. A primary responsibility for the product manager is to ensure oxygen supply to his product and business.

In many organizations, Products or in Internet services, Product managers concentrate on margins and do not monitor cash flow. In my experience, I found that cash flow monitoring and management is as important as revenues and margins in terms of product management to drive Sales, Technology and Delivery teams.

The challenges in Revenue focus are
1) Business environment Determination
2) Price Determination
3) Selling the Price to customer
4) Revenue Categorization
5) Earning Parameters focus

Determining the Business Environment
Running a product business is like sustaining a fire.

Customer need is the fuel for this fire. Basic value of the product is the actual fire. The distance between fire and us (our business) is the margin. Our business needs to assimilate the light and heat out of this fire, so that it becomes strong and blows oxygen into fire. Cash Flow is the oxygen for this fire. Effective Revenue collections is the assimilation of light and heat. Oxygen supply depends on this effective revenue collections.

Product managers have to understand the environment in which they are operating. Is it day or night, is it hot summer or cold winter. Every geography will have its own nuances in terms of seasons.

Day is like severe competition; Night like nil competition. Summer indicates decent affordability for our product with customers; Winter like un-affordable. And then there are various shades and combination of these that are possible as an environment.

Too close to the fire, we will be left with nil margins to do business. Our business will get burnt up. Too far off from the fire, we will not receive light and heat to sustain ourselves. This means we can’t pump oxygen (cash flow) back into business and it will die again.

Determining the Business environment is the job of Product Management at Environment level management. The product manager operating at habitat level management has to understand the environment as understood by his management. If there are differences, he should highlight it and ensure synchronization of the environment perception across management levels.
If this synchronization is not there, then business cannot run coherently for long.

Business Winter
Winter is the environment, where affordability is tight with the customer. Environment will fluctuate between day and dark lonely nights, competition and almost nil competition. Product Manager should have developed a complete idea on how long the winter will last and how severe it will be.

The severity of winter determines the distance which we can stay away from fire. If it is severe, we need to be closer to the fire. Our margins are going to be tight. If it is not, our margins can ease. But there is a limit to which he can go close to fire, beyond which the fire will start hurting.

The length of the Winter will determine if it really pays to wait through the winter. If it is too long, may be there is no fun in waiting out for the winter. We may need to exit the environment as our nomadic ancestors did and seek out better climes.

And soon day could break out, even in winter. Our product value may get greatly diminished in competition. Still we may need to keep on with the fire burning to wait out the day. And that requires enough oxygen (cash) supply to the fire.

During the day, we cannot burn the same amount we burnt during the night, when we burnt alone. We need to re-tune our burning to ensure that we burn lower, adjust to an also-ran position, but keep the future in mind and ensure enough oxygen supply to burn for long. In wintry times, definitely days will be short and night will be long. Competition will fade much faster. It all depends on our ability to sustain the oxygen flow.

Product managers have three options to handle Business winters. They can exit the climes with different product positioning. Through product positioning it is possible to position the product in a different environment. It may not be possible in all cases. This should be the first choice.

In case we need to sustain in the same environment, Product Managers need to ensure enough and right margins. This is important and the second choice. We cannot burn ourself up. At the same time, not too far way from the fire.

Third, they need to ensure correct payment terms and conditions. This is very critical. Assimilation of light and heat of the fire is very important in wintry conditions. Hence revenue collections are the most important and the tools for revenue collections start at setting the correct payment terms and conditions.

Business Summer
Summer is the environment, where affordability of customers is decent. But here also environment will fluctuate between day and night, high competition and low competition. Definitely days will be longer than night. It depends on market geography. You may have Sun shining in the middle of night too.

Everyone aspires for Summer Night. But it is short. Creating a product positioning for Summer Night should be the dream/ideal of every Product Manager. But then, there are limits to our wishes becoming reality. Even if a product manager succeeds, by very definition that summer night will be short and end soon.

Days in Summer could be scorching. Our product value may get greatly diminished. Again here too, the basic necessity is to keep the oxygen supply (cash flow) up and running smooth. Business Summers could lead to a lot of competitive fires running. Competitive fires are those running their business from the same customer need as we are running. Since affordability is not an issue in summer, competitive fires could reach high temperatures. Surviving in summer is different from surviving in winter.

One way to handle summer is to re-define our product with better product positioning so that we shift towards summer nights. It is easier said than done. A product manager should seriously attempt it along with his technology teams.

Another way to handle competitive fires is to start several smaller fires that could cut off oxygen supply to competitive fires. But then it is rather said than done. The competitive fires are huge in numbers and we cannot deal with them one by one.

The best way to handle them is to join hands with some/several of our competitive fires so that they hurt not our oxygen supply but our competitor’s oxygen supply. This could be done either in terms of Sales Partnerships and alliances, OEM relationships or Key Value Adding Channel partnerships.

The key is not to cut off competition, but to ensure that our oxygen supply is least disturbed through strategic sales alliances and partnerships.

Why not these alliances and partnerships in Winter..? Why in Summer..? Partnerships and alliances are always welcome. But they increase the distance between the producer and consumer, there by increasing the transactional costs.

In our summer definition, affordability is not a problem, pricing can sustain such transactional costs. In our winter definition, affordability is an issue and it may not sustain such transactional costs.

Questions and Answers
Product Managers need to answer themselves several questions at different points of time. Is this Day or Night or between what is the transition happening..? Is it Winter or Summer or between what is the transition happening..? Should we exit and seek better climes..? Given our oxygen is precious, what is the right amount to burn..? What is the right distance to maintain from the fire, during the day and night..?

All these questions need to be asked and understood across management. The top management and middle management should synchronize on it. Sales and Technology should synchronize on it.

But this is where I see a big challenge. Many times, I have seen that this perception is not uniform across organization. At times, the perception is not common across top management.

Business processes play a great role in synchronizing this perception across organization. A product manager at Habitat Level Management in his own interest should ensure that the perception of environment for his product is common across him and his senior management.

Pricing
There are various issues that get debated with respect to pricing a product. Should it be always cost+? Should it be geography based or Customer based..? How to handle fluctuations in Exchange Rate or Inflation..? How to handle sudden overhead increases ..? Should pricing fluctuate..? What should be the life of a quotation, given the pricing instability..?

I had a product Manager, who used to argue that pricing should always be Cost+. It is simpler that way and moralistic. Or otherwise we would be cheating our customers.

I told this story once to him.

Ramu had a cow, which he treated as Goddess Lakshmi and which got him 10 litres of milk everyday. He used to tie it up in his shed and feed it over there. He used to take it for grazing in the evenings.

Once one of his friends told Ramu, that tieing up his Cow in the Shed seems like imprisoning Goddess Lakshmi. Instead he can raise fence levels and allow it to roam freely and tie it up to a post only during milking. Ramu implemented the idea. But the cow which got used to roaming freely inside the shed, resisted any attempt to tie it up to a post. Ramu found it difficult to milk.

Another friend then suggested that Ramu should tie it up not inside the shed, but just in front of his house. This way Cow will have enough free air and sights. It will also be always tied and milking is not a problem. Ramu implemented the idea.

That night, a thief stole off the cow. Since he could not sell it, he killed it and sold its meat.

Pricing is like this cow. If tied up in an open market, it will get killed by competition. If allowed to roam around freely, it would go out of control. Your own sales team will run it off the course.
It has to be tied up, but at different places based on the geography. Inside the shed it is tied to a post, when it is grazing, it is tied to a tree with a longer rope or roam around freely inside the product manager’s vision.

More on pricing vagaries in my next blog..

-Balajee Rajaram
/* Some people did not read my first blog where I classified Product Management into different levels. They started asking me about role of Market Research, Market Communication etc in Product Management. For them I wish to clarify, I am still talking about Habitat Level Management, which is at ground level. When I discuss Environment level management these also will come in. Ofcourse this structuring is my own philosophy*/

/* I welcome one and all to use the principles and practices mentioned here at their own risk, as long as the usage is not talking, writing or CCPing (Cut Copy Paste) about these. The Intellectual property behind these is mine and based on my personal experiences in the industry */

End User and Requirements focus

2008-07-07T18:54:00.002+05:30

The only customer satisfaction parameter for a product manager is the repeat sales that is happening with the customer. And this CSAT focus in one of the key focus areas in customer focus for a Product Manager at Habitat level Management.

Customer support departments often use Quantitative data of product usage to determine C-SAT. Sales people use perceptions of their compatriots in customer organization to determine C-SAT. In many cases I have seen Repeat Sales not happening, when both C-SAT parameters are excellent.

Not only cases of Operation Success and Patient Dead happens, but also the converse.

Operations seem to be an abject failure, but patient somehow seems to be in pink of health and business grows, irrespective of the fact that customer keeps on with chronic complaining.
Since nothing succeeds like success, business/sales heads stop worrying why they succeeded and start thinking about their next year, citing their luck, hardwork or god’s grace for their success.

Continuous Product Positioning
In B2B products, no matter what amount of satisfaction customer has, unless the customer’s business is growing in the segments where our product is used, repeat sales is not going to occur. It is important for a product manager to understand where the product stands in customer’s business scheme of things.

And if it is not in the place where it can grow in customer’s business, can it be positioned there, now or in next few quarters with or without some modifications in the product..? Many a times, Sales people in their heat, will keep on banging their head against a wall with the hope that in due course of time business would eventually grow.

This may or may not be possible. It is the product manager’s responsibility to ensure that newer ways of positioning the product for different applications is made out for existing customers in close interactions with the Sales Teams and better understanding of Customer’s business plans.

The Product Manager has to have the complete understanding of technology, its nuances, applications and different ‘species’ possible on the product. Whenever Sales people (who are relationship oriented) are backed up by good Product Managers (who are technology and business oriented) the team work will produce exciting results.

The Business War
It need not be two different people. I have seen some good sales people who can wear dual hats and do both the jobs effectively, particularly in BFSI domain. In Telecom domain also, I have seen some people who are good in both, but very limited. Probably it is because of the complexity of products and solutions that are possible, Product Management becomes more complex. It might also be that Telecom Organizations are huge and relationship management at different levels and departments itself will consume a lot of energy.

I often tell my team that Business is like waging a war. Product Managers are the Mission Control sitting at the Base. Sales team are the Soldiers and Ground Commanders in frontline. Project Managers are the Logistic supply columns. Ammunition and devices are the various technology solutions that Product managers keep giving to their front-line operations to move ahead. Business Development is the Air Cover that is needed to keep the 30,000 feet view of operations.

Once when I was discussing this, our Customer Support Manager became agitated. He said “How dare you call our customer as our enemy? In your example, it seems customer is the enemy to be beaten dead. Then where is my role? ”.

Another person interjected “Your job then is in Crematorium. Customer disposal”

I had a tough time controlling the session and bringing it back to my point.
Then I said “Market is the ground that we need to capture. Competition is the enemy that we need to beat. Customers are the landmarks that we would gain control of. Customer Support are the defense troops guarding our prized possessions”.

In general, Salesmen and Sales Heads are like soldiers and commanders in the front-line. They will be able to do their ground strategy effectively. They will definitely understand their direction and extent of progress. But then they are at ground level. They need continuous base support for ammunition, logistic supplies and on-air support to cover their troops movement. That is what the Product Managers need to do. Keep supplying them with new ammo and devices, provide effective air-cover in terms of strategic analysis and ensure that they are in progress.

What to win: Customer’s Heart or Mind..?
This is a debate that goes on in any Sales/BD teams. To answer it short and sweet, winning Customer’s heart ensures long term relationship while winning customer’s mind ensures immediate business.

Sales people of all types concentrate on winning the customer’s heart. Relationship is the basis of their sales process. Product Managers need to concentrate on winning customer’s mind. They need to help sales to win over the customer’s mind.

Who is our Customer..? Customer or Customer’s Customer..?
In B2B products one dilemma that product managers often face is to define who the customer is? Is it the customer or the Customer’s customer..? How do we define the product..? From whose perspective it needs to be defined technically..? Whose satisfaction is important..?

The product definition has to be from its users perspectives. Let us say product has two components. One component used by our customer and another used by customer as well as customer’s customer. The two components have to be defined differently.

The component customer uses should be defined with customer background in mind. The component customer’s customer uses should primarily be defined with respect to Customer’s customer background. We can reasonably expect our customer to be an engineer, but not customer’s customer.

This End user focus needs to be there in the Product definition with the Product Manager at Habitat level management.

When it comes to the question of whose satisfaction is important to be measured by me, my answer is our direct customer’s satisfaction is important to be measured. The End users satisfaction is important to our customer and not to us. Spending resources on measuring it does not give us any direct benefit.

It is because unless our customer takes the responsibility of his customer’s satisfaction, his business cannot grow. Unless our customer is focused on his end-user, his and our business cannot thrive. If we are in a situation where our customer is unable to understand end-user perception and thrusts end-user satisfaction on us, then we need to correct that situation in customer organization, rather than doing his job for him.

In these discussions I mean customer as our customer and not Channel Partner.

Requirements Focus
There are very many quality management systems that I have experienced. It all started with simple ISO 15 years back. Then it was TQM, 5S, Kaisen, 6Sigma, Lean Management, CMM, CMMI, Tao, BPM and many other methodologies.

When I entered industry as a trainee 18 years back, my Quality Manager asked me to define Quality. I said “working well”. Then he corrected me “There is nothing like working well. It is meeting the specifications”.

Some time later, when he asked about quality, I answered “Meeting Specifications”. He again corrected me “No. It is meeting customer requirements”.

Some time later, again when I answered quality is meeting customer requirements, he corrected me “No. No. It is customer satisfaction”

Few years later, he said “No.No.No. It is customer delight”. Meanwhile the organization got closed down.

When there is a problem, will we treat the symptom or will we treat the root-cause..?

Defining Quality in terms of requirements, specifications, customer satisfaction, delight are all like treating symptoms for a problem. I define quality in terms of meeting business objectives of us and our customer in the most efficient way.

To some it may appear so simplistic. It is not. A well-tuned process increases the overall efficiency of an organizations business delivery mechanism. It does not increase the effectiveness of the organization.

Effectiveness is the key to organization. 100% efficiency is useless if it is ineffective. Hence Quality has to be stated in terms of effectiveness first and efficiency next. At the same time, without an efficient process, organizations will fail to delivery repeatedly. Hence proper Quality Management Systems are important.

But for a Product Manager at Habitat level management, Quality is meeting the business objectives. Now with respect to the business objectives, be it product development, maintenance, service delivery or a software release, with respect to the business objectives for that particular release, requirements and specifications need to be frozen.

This kind of Business objectives focused Requirements has to be brought in by the Product Manager. The Product Manager has to ensure that requirements transacted and understood by technology are well in line with the business goals.

*** To be continued ***
-Balajee Rajaram

Customer and Customer Satisfaction Focus

2008-07-07T15:28:00.001+05:30

/** I won’t say these are golden rules, as I firmly think nobody can set golden rules except for nature. But then these are the pearls of my painstaking product development and management experience */

As my Product Manager asked me “All this lecture is fine. So what do u want me to do now..?”. He had actually meant “Where do I start..?”.

Product Management is a 360 degree function. It has to encompass the entire business cycle of a product. In general, I visualize 4 phases of business cycle for a product or service.

For products they are 1) Market or Customer Need/Requirements to Product Development 2) Sales Leads to Order 3) Order to Delivery of Product (including customizations if any) 3) Delivery to Repeat Sales.

For (online) services the Sales Leads to Order becomes Bringing customer to Service, Order to Delivery becomes Online Delivery of Service, Delivery to Repeat Sales becomes Repeated Usage of Service.

Many Product development companies (such as ours) use RAD model for deployment, where in products are released in shortest time to market, but then keep on upgrading to reach the desired features. In such a scenario, Product Management at habitat level becomes extremely essential to ensure revenue optimization.

There are four principles in Habitat Level Management that I have understood.
1. Customer Focus (Customer Business Focus, CSAT focus. End User Focus , Requirements Focus)
2. Revenue Focus (Focus on revenues, margins, P&L)
3. Competition Focus (Direct and Indirect competition)
4. Delivery Focus (Budget, Time, Quality)

Once when I was explaining to an aspiring product manager all these functions, the person got zapped up. He was silent for some time and then said “Ok.. what will others be doing in your company, anyway?”

Scrutiny and Judgement
The Product Manager function is like a captain of the team. A product manager needs to LEARN how to use his team for his purpose. If a Product Manager sets about doing everything by himself then he will loose vision of his 360degree function.

But then the team cannot be expected to play well every time. At times the middle order collapses or the tail does not wag the amount it needs to. A product manager needs to develop an independent judgement on various inputs from his team and should be capable of qualifying those inputs through thorough scrutiny.

In fact a Product Managers performance depends a lot on the depth of his scrutiny.

Customer Focus
As I wrote earlier, ideally a Product Manager has to be part of the process that parents the product. If not, atleast he should be completely knowledgeable of the process that parented the product.

My Product = Customer’s Business

The customer focus has to start right from the Customer’s Business. As far as the Product Manager is concerned, the product gets used always in Customer’s Business. The product could be a gaming service and customer may not treat playing games as business. But product manager has to perceive gaming as customer’s business (important for Customer’s survival) and ensure that customer is able to do his business well.

Product Managers should spend some time in understanding how the customer would use the Product and the environment in which customer will use the product.

Position properly: Understand the Customer Organization

In B2B products, understanding the Customer Organization is essential. When I interview Product Managers who I understand are doing Habitat level management, the first question I ask them is about their Customer Organization. Understanding the Customer Organization for their products is the first day responsibility of Product Managers.

Most professional Customer Organizations have diverse departments that would be odds with one another. The Operations group will be focussing on current issues, Technical group will be concentrating on roadmap, SCM group will be on Price and Business group will be on EBITDA.

Though Product positioning is typically done with respect to a market, the product positioning for B2B products has to be diverse and take into account all customer expectations. Very often I have faced situations where CTO of Customer organizations push the product after complete development but the operations/business groups stall it.

The Product has to undergo a thorough and painful revision once again to meet their expectations.

Position Properly: Understand the Customer Segment

In B2C products, understanding the customer segment is essential. The customer segment could be based on age, language, religion, culture, education etc or a matrix of these. Without defining the customer segment, a B2C product cannot be positioned properly.

When products get defined, there is an idea of customer segment for the product typically. But the customer segment either spreads to several other segments or concretizes to a much narrower segment than as earlier defined, during the course of the time product lives in the market.

A product manager has to understand the customer segment and look for change in customer segment that is visible through quantitative and qualitative data.

Customer Satisfaction: Mirage or Image..?

It is very easy to talk about Customer satisfaction in theory. In practice, Delivery and product managers either go bald or grey in chasing Customer Satisfaction. It seems a customer can never be satisfied.
And it is true. Only if he is not satisfied, he is your customer.

Why ?

If customer says he is completely satisfied continuously for sometime, either he is not growing or the information flow with the customer is not proper. In either case, re-evaluate the customer.

So Product Managers need to look for Customer dis-satisfaction rather than Customer Satisfaction. Anyway Customer Support Managers are there to look for Customer Satisfaction.

Customer Expectation depends on price customer pays

This seems a commonsense logic. But when in the heat of business, many product managers do not comprehend this clearly.

Once when we trialed our Software product to our customer(s), the feedback was excellent. After the first quarter, when sales was no-where near expectation, I started drilling down. I found that customers have not exploited our software during the trial period to the extent we would like to. Hence the dis-satisfaction with the product in its final application environment translated into lower sales figure.

That day I learned an important lesson. A customer may not seriously evaluate a trial product. Trial versions can bring out an indicative feedback mechanism of product. But using it as an estimate figure for prospective sales or Customer Satisfaction is not a right approach.

I have time and again seen this in many different products not limited to Software. I have seen it also in online hosted services.

Put Horse before the Cart

I often talk to my Sales colleagues to put the horse before the cart. Horse is the Sales Relationship. A relationship established between the customer’s mind(s) and our product value to customer. Only after the horse is completely ready to drive, we need to add the cart (trials).

Trials (particularly those that cost) need to be brought in only when we determine the customer has enough reason and is keen to do business with our product. A trial can further cement or enable a sales relationship. But for that a relationship should have already been established between customer’s mind and our product.

Sufficient excitement should have been created in customer’s mind by Sales Teams, before trial stage is entered.

At times Sales in their eagerness to widen the Sales funnel push for trials at many places. Trials (at many places) is not a tool to accelerate sales. It is just a sweetener.

Win the Confidence of your Sales Team first

Product Managers need to scrutinize trial requests without emotion and guide the Sales Teams accordingly. Since they are not part of the emotion that a Sales Team is in, they can do this perfectly.

But they should do this without affecting the flow of enthusiasm with Sales. This needs a lot of team working capabilities with a Product Manager. Very Often Product Managers will be seen as hurdles by Sales Teams, if they do not really work with the Sales Teams. For this they need to take part in the Sleepless agony that their sales team is going through in reaching their targets. The Sales Teams need to perceive that the Product Managers are with them.

A Product Manager needs to get the confidence of his sales teams that he is helping them to increase Sales and not trying to add hurdles in their path. Hence they need to enable the Sales Teams to decide themselves and should have their confidence such that they are willing to take the help of Product Manager to get their decisions checked.

Operation Success; Patient Dead

Many a times, Product Managers rely on quantitative data fetched from Sales or Customer Support to determine how the Customers use the Product and the level of Satisfaction with the product. Qualitative data is hard to get and also inconsistent at times.

So Product managers go with the perception created by the Quantitative Data. But that is not true always.

I used to get MIS from Customer Support which says our customer’s network is up 100% of time and end-users have fault-free operation 99.99% of time. But the Repeat Sales would be going down with that customer. What is the use of claiming operation a success, when patient is dying..?

What could be the issues..? This and more in my next post
-Balajee Rajaram

Introduction - Levels of Product Management

2008-07-07T14:10:00.001+05:30

In many Product Organizations, Product Management has become like Socialism. A hat worn by anybody, for a convenience and then discarded. In this process the hat keeps on shifting from a Development Manager to Project Manager to Customer Support Manager to Receptionist to Security.

In an environment where technology keeps changing rapidly and products face the heat of competition, product management needs a lot of stamina. And hence the reason it gets thrown between lot of people like a soccer ball.When something becomes too difficult to handle, either it gets specialized to a very few and loathed by others or it gets handled by almost everyone.

Product management becomes an item too hot in many places.In another perspective, if the product management vision is not shared by people involved (if not get thrown between people like soccer ball) it won’t survive the competition and fast changing world.

Like a soccer game, though ball gets played between everybody, like a captain directing the game, a product manager has to direct his team.Much like the soccer captain, he has to allow individuals to play their games, not interfering with their work and style, but ensure the end output, as desired by him.

If a product manager is not responsible for work and style of his team, what parameter does product manager has to control his team..?It is the vision of his team, that product manager needs to set. A successful soccer captain sets the vision of his team on field with respect to the opponent, playing terrain and team strengths and use that to drive the team to play in his way. Similarly the product manager needs to set the vision of his team with respect to competition, eco-system and the strengths of his team to drive the team towards his goal..

What is in reality Product Management..?

Product Management, I often tell my team, is a metabolic evolution. Not that they understand it this way better. But it makes them to listen to me more, as they become angry and gnaw their teeth.

In the way life evolves in an eco-system, products evolve in an economic eco-system. Products do not have a meaning, purpose or energy to live outside their eco-system, in the same way as a biological being. But then the eco-system is not a constant one. It keeps changing, due to changes of nature as well as the changes caused by the living beings themselves. Which means that living beings need to continually adapt to their eco-system of which several changes are caused by themselves.

In the same way products in an economic eco-system need to continually adapt due to changes in economic eco-system caused by other factors as well as changes caused in the eco-system due to products themselves. This leads to evolution of new products.

Every life takes some energy from the system and gives out energy in some other form back to the system. Same way every product consumes energy (which can be monetarily quantified) from the economic eco-system and gives out energy (which can be monetarily quantified) in another form.

In this metabolism, there are two parameters that every product manager need to monitor and control. Efficiency of this metabolism and more important the effectiveness of this metabolism.Efficiency in terms of how fast product adaptations can happen with least energy input possible and effectiveness in terms of the returns that product need to generate for him (his organization) and his customer.

No doubt. Effectiveness is more important than efficiency in product management.

Again if effectiveness needs to be better, then how well the product is adaptable to its eco-system (in terms of depth of user acceptance), how wide the product is able to proliferate and survive in different environments (verticals and geographies) needs to be better.

Though Product management seems to be a monolith, function it is not. Typically product management happens at three different levels, in my experience.

The three levels are

1) Habitat level (Target customers level)
2) Environmental level (Market level with competition, disruptive changes considered)
3) Eco-system level (At a macro-economic level considering changes in the overall eco-system that could shift the whole paradigm or frame of operation permanently or termporarily)

Above all these levels, I define a fourth level for internal discussion with my team members. That is the ‘Fate level'. Those invisible lines that are supposed to be running inside our brains and make all of us act in the way we do, can change things beyond our imagination. One cannot handle this level with management. One needs the supreme philosophy of any management which is acceptance.

In any organization that is involved in Product development, effective product management at these 3 different levels is essential. Product could be anything be it hardware, software, combination of the above or an online service.

The Habitat level product management is much more focussed on the immediate set of existing and perceived customers and their requirements. The product is expected to change in this level. The level of change is not in-depth. The fundamental functions of the product remain the same, though different ‘species’ of the same product may evolve in this level. In this level Product management will concentrate on users and revenue maximization from the users.

The Environment level is focussed on the technology, regulatory, financial, manufacturing (if applicable) and marketing environment of the product and is to ensure adaptation of the product to its environment. The same product could be used in different verticals and geographies and the environmental product management for them would be different for each of the environment. The product is expected to change in this level. The level of change is slightly in-depth at times.

Some fundamental functions of the products could change, appearing as if the old product is dead. Some times totally new products appear as successors to the previous product, but having no direct relationship with them, except for the fact that unless they are seen as the next-generation, it is not possible to sell. Sometimes product might not itself change, but business models themselves will change.In this level Product management will concentrate on next generation developments, re-use for next generation developments and multiplication of revenues through environmental adaptation.

The Eco-System level is focussed on the overall business environment, economic environment, technology evolutions that are on-going, disruptive technical and business events in the offing etc. To adapt to eco-system level, business models might need to change. The perception of revenue, profit & loss may change.

The concept of the product or service may undergo a total change and current understanding may become irrelevant or redundant. Product management here will concentrate on possible re-use to cut short time to market, but will be developing fundamentally new products for new environments with newer business models if necessary

Sometime back when we I had a new Product Manager, I lectured to him for almost an hour on Product management and its relevance to our organization.He patiently listened to me and then finally asked “Well.. What do you want me to do now..?”

Actually, I wanted to share my experiences on product management and how to go about doing it, but then as usual I have lectured around it (probably to an empty hall).But then, I am from the genre of those politicians who stand in a street-corner dias and keep talking, irrespective of who is listening to them. I can’t be stopped. I will continue on my Habital Level Product Management in my next post.

I also owe an explanation on why I call my Product Managers as PUMMIES. Though it is not correct, in many organizations pummies are brought into the picture after DUMMIES (Development Managers) and MUMMIES (Maintenance Managers). Dummies start it up all without much knowledge and abandon the product mid-way to sole care of Mummies.. Mummies toil hard to breathe life into the product. Poor Pummies have to lend their initials as the dutiful father for the orphaned product and struggle to grow it and find a business(job) for it.

In successful product organizations Pummies are the real parents and the products grow so capable that they find their business (job) themselves. That and more in my next post..

**To be continued ***

-Balajee Rajaram

Competition focus - Market Tracking

2008-07-06T15:56:00.000+05:30

Competition is present in almost every aspect of our life. It is present whether we are developing solutions as part of service domain, developing products as a product company or offering services.

There are 3 different dimensions to competition. 1. Market. 2. Product 3. Customer. Hence Competition focus has several sub-sets to it. They are
1) Market Tracking
2) Competition Business Tracking
3) Competition Product tracking
4) Customer characteristics tracking

Competition is not just about an individual or organization vying to grab our business. Competition is all about learning and sharing the experiences to derive the maximum output from the market. Without competition substantial portions of the market will remain un-served.

Hence Competition is a vital part of any industry. Definitely competition decreases efficiency of the resource conversion by over exploiting of resources for the sake of profits. But it promotes effectiveness in reaching a product or service to a wider audience. Due to competition, vendors search not only for more profits, but also for newer market segments and newer set of customers. There is no other known mechanism in the world today that can drive product or service distribution to a wider set of people.

From a customer angle, competition gives the customer a choice in the availability of service. It gives the customer a confidence.

The issue is how our product or service is going to fare with respect to competition. It is easy to write eulogies on competition sitting in the cosy space of an office. It is rather difficult to feel the heat in the field when customers toss around products and services with the aim of optimizing their business. Not just product or service delivery, business methodologies, sales relationships, financial models all go into determining the outcome of competition.

Here is where Product Managers need to fight along with the sales. Product Managers are the mission control. They need to share the heat of the Sales teams and fight the competition together.

There is no defined methodology that I have seen till now to ensure victory in a competition. It is simply as they say, nothing succeeds like success. If we win, we may pat ourselves for our intelligence. But we may very well be rest assured that the same model may not work next time. It is very difficult to pin point what worked in a model and what did not.

The only way to fight competition is to fight vigorously but be prepared for accepting defeats. The only solution is to have sufficient sales funnel to manage the different outcomes. Still there are accounts which Sales and Product teams will be placing higher energies on and accounts where they place less. This may be planned or happens intuitively.

One way to fight competition effectively is to ensure that the energies being spent in different accounts are distributed optimally to ensure maximum success. To determine where to spend our energies we need to track the four parameters mentioned at the start of this post.

Market Tracking
Often people talk about the new Hare and tortoise story without understanding the real meaning of it. In the new story, Hare and tortoise run together and share each other’s strength and weakness to run the fastest possible run.

The real issue is not if they ran together or ran against each other. The real issue is they understood the market and their terrain better. They understood their market comprises of not only bushy lands, but also ponds and thorny patches. Hare understood while it is fastest in the bushy lands, the tortoise is fastest in ponds. In thorny patches, both are equally good or bad.

Whether they run together or not depends on how much ponds, bushy lands and thorny patches are there in the forest. More important it is about their perception of the forest that will determine if they want to run together or not.

Now, this is market tracking. Understanding what the market needs are, how the terrain is, how we are matched against the terrain and where our real strength lies is market tracking.

Market is a generic word that actually denotes a whole set of people. Like a forest that involves terrain, vegetation, environment and climate, a market involves customers, their needs, business/financial environment and regulatory/government environment.

Once I was asked “If you develop a product towards a customer, how can u address it to the entire market..? Should we not develop a product towards the market..?”. I answered them thus “Market is the aggregate of customers. If we are not able to focus and win in one customer place we are not going to win in the market at all. Hence we need to devise a product for a customer with overall market in the background of our mind”.

It is like the field of vision and our aim. As in the mythological story, Arjuna’s field of vision, when he took aim of his arrow at the distant fruit on a tree would be definitely covering the branches, leaves and the fig that held the fruit. But when asked by his guru, on what he is seeing, Arjuna replied that he does not recognize the branches or leaves or even the fruit. He said that he is recognizing only the fig of the fruit that holds it to the tree.

What he means in reality is that his mind has been able to establish a clear path between his arrow to the fig of the fruit that is uninterrupted by any branches or leaves, so that when he releases the arrow, it strikes the fig and fruit falls down. This does not mean that Arjuna did not see any other thing than the fig that held the fruit. If he had not seen all those branches and leaves, he would not have been able to establish this clear path for his bow.

Tracking several customers and aggregating them and their needs to a great extent is market tracking of customer needs. But this alone is not enough.

Market tracking also involves technology tracking, business/financial models tracking, regulatory and government environment tracking.

Most of the product managers or technology developers do not track technology. The best way to track technology evolution is to be part of the eco-system of technology development, be it at Integrated Chips, ASIC, Engineering concepts related to the field of operation, Software development/testing methods, processes, database evolutions, tools etc.

Of course it is difficult to track all of these technologies simultaneously. So the product managers need to determine which technology sectors affect them the most and make a conscious decision to track them by becoming part of the sector development, either through online or offline magazines and periodicals.

Tracking emerging business and financial models is much more difficult. In most products the models don’t change at all. In these cases, product managers can look at if there is any real improvement possible by slightly re-casting their current business models. They need to do it at appropriate levels.

The best way to track the changes, in businesses where models change, is by networking. Networking by Business Development, Sales and Product Managers to understand how the customer’s business and financials work and how it could be put to use for the advantage of our business deliveries needs to be worked out.

One of the critical thing required here is a periodic internal meeting and institutionalized knowledge sharing by BD, Sales and Product Management teams on market, business models and environment. It should be structured as a formal business interaction session. Iit should come out with action points for different teams. This would help largely in understanding the business and financial models of customers and improving them.

Regulatory and Government environment tracking is required only if there is a direct hit on the business from regulations or government policies. In such cases, is better to have a “Consultant Advisor” on organization’s rolls, paid a minimum for sharing information, but paid by the project if any needs to be executed and driven by BD. This also needs to be reviewed during the formal business interaction session. In case it is in-direct, there is not much tracking that is required, except those of reading magazines and newspapers.

In the next post, let me write about Competition Business Tracking..

-Balajee Rajaram

Simply Swadesh Cartoon Series..

2007-08-06T11:32:00.002+05:30

For more swadesh (my son) cartoons refer to http://simplyswadesh.blogspot.com/