I heard Hank Paulson, when he still was the Treasury Secretary, give an interview to CNBC’s Maria Bartiromo about a week back. Paulson was questioned mostly on the economic crisis gripping the US in general and Wall Street in particular and it was only towards the end that Maria came down to asking questions about Paulson’s general belief about business (you can read the transcript here, but sadly this does not include the section I refer to in this post, which was moved to the “Closing Bell” section).

Asked about advice he usually had for people who work for him, Paulson made a remarkable statement. He said – “I ask them (his people) to not become restrictive in their work and to define their roles expansively”. The statement struck me as profound because I have seen so many people succeed just by the way they handled boundaries. Only the naive would expect roles to not come with boundaries, explicit or implicit. The ambitious follows what Paulson mentioned – they either create an expansive definition of their roles when the existing definition is not explicit or – should the limits be explicitly mentioned – push the boundaries when they hit against it. The I’m-happy-the-way-I-am-thank-you s on the other hand create a narrow definition of their jobs perhaps to just hedge against failure (and have their egos take a beating).

An expansive job definition immediately sends out a positive message and prepares the person for assuming either more responsibilities (horizontal expansion) or higher level responsibilities (vertical expansion).

In Product Management I have seen many define their roles restrictively – “I am only the functional specs guy so if you need to enhance the workflow design, ummm, I guess I am not the right person”. Death knell. On the other hand – “you know what, I know my functional specs specifies this to be the workflow but what the heck, I know the alpha clients reasonably so why don’t we set up a call with them to see if there is a better way to get this done”. Skin in the game – now we are talking.

Effort and Reward: Compensation Conundrum

Behavioral scientists proclaim three characteristics that make a job attractive. Autonomy, challenges and a clear relationship between effort and reward (Malcolm Gladwell makes copious references to this hypothesis in his most recent book – Outliers). No one can really debate the first two but the third is screaming out to be tossed around a bit in the intellectual cauldron.

Let me make my position clear before I start – I agree with the house on that proposition. I am more interested in trying to understand that causal relationship between reward and effort.

There are two ways in measuring performance – input based and output based. Input based measurement works very well for outcomes that have heavy dependence on physical labor as a factor input. The amount of time a weaver puts on the mill directly defines the amount of salable cloth that will be produced. So the manager of the weavers will ensure that she goads every weaver to come on time, take less breaks, be more productive and in general find ways of maximizing the input labor factor of production. Output based management on the contrary works on the premise that it is the output that matters and not so much the input. The quality of an ad copy has got nothing to do with the quantum of time the copywriter has spent on it. Nobody pays for a painting based on the hours the artist has put into it. Managers who are output oriented look more closely at the finished product than what went into making it and how. Both these methods are good enough to judge effort – but are they good enough to calibrate reward is the question that troubles me.

A weaver put in an amazing year – no sick leaves, no long breaks, worked at peak productivity for 3 standard deviations of time worked and produced more scarves than he did ever. However, the store that bought supplies from the scarf manufacturer shut shop on 5th Avenue and the inventory had to be sold at bargain basement price to a different shop uptown. Should reward reflect the production or the commercial outcome? Take another example – this time on the other end of the spectrum. A product manager had a lousy year – no earth shaking features introduced, no improvement of usability, pricing and positioning could not be simplified and yet his only other competitor product suffered heavily when some folks in charge of managing their data centers were acquired and a few storage optimization companies went under as their credit lines got squeezed.  A lot of customer base migrated to the stagnant product resulting in very healthy top-line growth. Given that a lot of product managers are remunerated through commercial outcome based schemes, should this product manager walk away with $100,000 bonus for an event he neither controlled nor engineered?

Modern investment theory has a nice solution for this problem in the money-management industry. Fund managers are evaluated on both the beta (market driven, systematic and non controllable) and alpha (manager skill, churn factors, sector allocation, stock selection effects) factors of their performance. Perhaps a loose analogy of this for examples I mention earlier would be to create a combination of input based and output (or outcome) based evaluations. In the absence of mathematical rigor of application of such a system, a fair amount of the reward process will still be subjective.

Till such time, grin and bear is all managers can do now as the performance appraisal and remuneration season hangs upon us.

Hierarchy of Equals: Mahesh Ramakrishnan

expertszonThe traditional pyramidal team structure is outdated. Though the arrangement has served the IT industry well so far, we need something else to take us into the future.

With ever dwindling margins in IT services it is imperative for organizations, especially in India, to build innovative software products and services that would command premiums and ensure robust profitability.

The pyramidal team structure is inflexible and ineffective in anything but the most industrialized domains, and software product engineering is least amenable to industrialization.

My small team of 10+ serves over a couple of thousand users with our product offerings. We are based out of Bangalore, India and most of the clients based in the US. Our usual functions include envisioning the roadmap, participating in pre-sales processes, rolling out to new clients, maintaining and enhancing current installations, production support and providing inputs to the finance team. Basically the whole gamut of activities in running a product.

With a variety of factors- different time-zones, no face contact with customer, accent differences etc. not in our favor, the way we organize and manage ourselves has critical impact on our ability to meet and exceed customer expectations.

The key factor that drives this is in how we organize ourselves. From that emerges a host of required patterns that are instrumental to our success.

Patterns for Winning Product Teams

Activity based leadership

A static pyramidal model has is too straight jacketed to serve diverse opportunities for product growth. We follow a model where each team member ‘owns’ a particular function or client. While it resembles a traditional model, it differs in the sense of being dynamic in execution. I might be the product manager normally, but can play a senior developer role under the ‘owner’ of that particular feature. Such an activity based leadership allows most team members to be groomed into leaders and allows other senior folks to have a low level perspective first hand.

We call this the hierarchy of equals. The person most skilled to do a job takes the leadership role. And is willing to be subservient in another role in a different context.

All decisions will typically be made by the owner of that initiative, usually after discussions with other relevant team members. Which leads us to the next point.

Collaboration and Consensus

In a situation where a person is new to the role it is essential to mentor and groom them in the process. Or if the problem has many aspects, then it becomes necessary to have all relevant team members weigh in with their views. Instead of an arbitrary fiat, consensus becomes the way forward, aided by collaboration within the team.

Collaboration requires transparency, which is the next item.


The key to good decision making in such a fluid team structure is transparency, to ensure complete information flow about all the nuances of the problem. Be it an irate customer, the expectations of senior management or even organizational process hurdles, each of these is approached collectively by the team. If we have to take shortcuts, either in product implementation or managing external expectations, both are done with the clear understanding and buy in from the team.

This assumes that each member of the team has a wide understanding of the product envisioning and delivery process. This is our next pattern.

A continuum of skills

A narrow role definition of a QA or a developer of a small function does not provide people with the best context to contribute to the success of the product. Enable people to play a variety of roles within the team. We have QA folks who manage client relationships, do product roll-outs, conduct product training and pre-sales demos. Each of these non-core activities widens their understanding of what makes the product tick. Instead of a being restricted to a skill silo, we now have multi-skilled people who do their core functions better after viewing the product in a different light.

Acquiring such skills is not a easy matter, especially if it requires traditionally introspective folks to be extroverted in dealing with customers or participate in pre-sales processes. We need people with ambition to grow.


This entire model does not tick if people are not ambitious. To re-invent and re-learn skills quite divergent from the core skill is trait few posses. And it is essential for rest of the team to believe in the individual who goes through the re-skilling process. Through all this pain of change, ambition can act as a strong motivating factor.

With ambition so plainly laid out, there has to be a moderating factor, and this is political savviness!

Politically savvy

All this change and adrenalin of swimming against the tide of mediocrity produces tension, both within and without the team. It requires political savviness to deal with inter team issues that would invariably crop up or to deal with stakeholders who want things just done and care a hoot about how you organize the team or even with customers who want the product delivered to them yesterday.

Managing these often conflicting priorities require people and political savviness. And what good is savviness without the ability to communicate in an articulate fashion?


Much depends on the leader’s ability to communicate within and without the team. To sell a new product vision to stakeholders, to convince a potential customer about the strengths of your product, to generate internal buy-in to a new process initiative. Each of these require the ability to articulate a vision and initiate discussions on how the team might get there.

All of the above factors could merely be accidents of people and circumstances, the entire approach could go in flames one fine day. What will determine the eventual success of the team is the next quality.


Every failure and stumbling block to an overarching ambition can be a lesson learnt, the tuning of the team into a fine instrument to build, own and sustain a successful product. Take a long term perspective and do not judge your progress by the fruits of a momentary setback. Identify the weakness and address it. Refine your strategy, process and mindset. A healthy dose of resilience is all that is required to turn every situation around.

There is a ton of detail we could cover, especially on the people recruitment and mentoring front, in how customer management is done from a remote location from another time-zone, how we manage innovation etc. But all these essentially are built upon the first tenet of having a hierarchy of equals, to believe in the best people and enable them to exceed every expectation. 

About Mahesh Ramakrishnan

 Mahesh manages a Research authoring and workflow product for Thomson Reuters. Adept at both  business and technology aspects of Product Development, Mahesh brings about an unique value to the  table. He runs a professional blog as well one that borders on philosophy and mythology from around  the world.

Basking in Shame

They are the ones who have – or ought to have – their fingers on the pulse of a company they cover. Their intellect is what investors trust. They are the ones who go through a company’s business and financials with a fine tooth comb, unrelenting in their persuasion of the truth, unforgiving in their wrath when they discover a wrong. They are the High Priests for the investing fraternity. They are the Analysts.

It would be funny if it were not sad how many times this tribe has failed the world when it most needed them. A group that was tasked to lead through foresight ended up championing the hackneyed phrase that hindsight is 20/20. Time and again Financial Analysts have shown that they really do not add any more probability points for an investor who is taking aim with his dart at the universe of stocks in search of a sound investment.

Performance of Analysts in the Satyam fiasco is no different. Brokerage houses (institutions that hire the Analysts) have been almost falling over each other to shed positive light on a stock that now isn’t even worth the electricity it takes to show the blinking ticker on a trading screen. Here is a snapshot of – even I am tired of using the phrase – irrational exuberance. A collective display of irrational exuberance actually (and this is just between 01-Dec-08 to date).

High Fiving on the edge of an abyss

Announcing Intellectual Diversification

Sometime during the week, this blog will start carrying posts from people other than I. I hope this new addition will allow readers to get new perspectives on issues that experts have found important to write about. Additionally, this opening up allows an intellectual diversification to topics that I honestly was not capable of writing eruditely about.

The section will be called “Expert Zone” and will have its own visual badge. All posts will be fully attributed to the contributor, including photographs, bios and links. If you wish to contribute please drop me a note.

Reflecting on the 2008 Product Management Survey

clipboardThe 2008 Product Management Survey is out.

While the respondent universe – totaling up to a measly 1,100 – may not accurately reflect facts, some of the findings are interesting.

  • Product Managers are spending far too much time in meetings (35% go to 20+ meetings a week, that is 4 every day. One hour per meeting implies 50% of a workday spent in meetings!)
  • Steven Haines of Sequent Learning Networks, in his book makes a compelling argument about Product Managers getting about their profession without a formal training in the trade. Fragmentation of qualification possibly directly reflects the fact that Product Management is still a function scattered across a firm. I couldn’t believe that 11% Product Managers actually reported into the Engineering organization!
  • Given that on an average a Product Manager manages 3 products, it so stands that these products are supported by 1.4 Marketing staff, 9.2 Sales and Pre-sales staff and 13.1 Engineers. A fair balance.
  • Analysis of the Activities section reveals that outbound tasks dominate. Overlay this with the fact that 89% of the Product Managers claim high degree of technical (I assume this also connotes “technological”) capabilities and we may have a dichotomy. Is the industry staffing the function with incorrect skills?

I hope the 2009 survey will have more responses and will go a little deeper in slicing and dicing the information received. Understanding how a function is implemented and operationalized by the industry goes a long way in perfecting it.