Ramblings of a Silicon Valley Tech Exec on Technology Commercialization and Startups

Monday, November 1, 2010

Process vs. "Product" People

One of the essential skills needed in building a company is the ability to hire and fit the right people to the right job. Most entrepreneurs spend a lot of time blending together the technical qualifications of their people. Some of the more savvy also focus on the personality or cultural fit. But in my experience, one of the key dimensions is whether the person is a process person or a product person.

A process person is someone who focuses on doing things the right way.

A product person is someone who focuses on getting to the end result or end "product" whatever that may be.

Now I can hear all the entrepreneurs thinking, "Of course we want product people. It's the end result that matters, not how we get there." And for the most part, they would be right...until it's time to scaleup.

The reason I focus on this element is that while I've found that smart people can learn missing technical skills and even interpersonal skills (harder), whether someone is process oriented or product oriented seems to be hard wired.

The truth of the matter is that most teams and all companies need a mix of both types. The actual mix depends on the nature of business and tends to evolve with time. So how does one determine the proper mix? Let's look at the circumstances that favor the need for a process vs. product orientation.

Product People
Product people have a natural orientation toward the end goal and are less concerned by the means to getting there.

Stereotypical product people are entrepreneurs, salespeople, and designers. They fill out their expense reports under duress, mess up the system with special deals, or do end runs around the system altogether. It's not that they don't appreciate the need for business processes. Rather they recognize that at the end of the day, the goal of a process is to achieve a result. And if that process isn't getting the results or they have what they think is a better way to achieve the result than via the process, the process is sacrificed.

Product people are usually comfortable with change, particularly disruptive change, and in fact may be the drivers of change in their organization. Change is synonymous with improvement in their minds. Product people often prefer the blank paper approach to problem solving vs. continuous improvement because it increases their freedom of action to solve problems.

As such, they are at their best when the environment is uncertain or undergoing rapid change, the situation faced by most early stage startups or by mature companies whose industries are undergoing some type of technological, economic, or regulatory disruption. Startups undertaking the process of developing product/market fit and proving out the viability of their business model need product people.

Unfortunately, product people tend to approach every challenge as a new problem, even when it may be similar to an already solved problem. They may develop guidelines for solving related problems, but rarely like to sit down and document the detailed steps required to convert guidelines into processes. As a result, there is a lot of reinventing of the wheel, details slip through the cracks, and the quality of work becomes highly dependent on that person's individual skill. This ultimately limits the ability of a company to scale up. A company dominated by product people can often degenerate into chaos.

Process People
At some point, someone gets fed up with the chaos. Enter process people whose main orientation is doing things the right way. In order to do this, there first has to be a right way, so they are the ones that corral the product people into a room, lock the door, and force them to document the way things are being done in laborious, but necessary detail. Good process people then collapse and streamline similar processes to reduce inefficiencies and link them together to eliminate dropped balls. Because a good process eliminates most of the micro-judgments that a person has to make, less skilled people (and therefore more widely available people) can be trained to use it to achieve high quality results which makes it scalable.

When it comes to change, process people are not as comfortable with it as product people. Establishing a good standard operating procedure is difficult and takes time to get running smoothly. So while incremental change in the form of continuous improvement is fine, disruptive change is not. Improvement to a process person means driving out error and waste. And they understand the biggest source of both is the fallible human being.

Therefore, process people are at their best in more stable environments particularly where complexity is high or errors are costly like in manufacturing, financial services, health care, or the military.

Unfortunately, in their quest to eliminate error and waste, process people tend to overbuild systems. They are the ones always saying "what if" sometimes to the point of absurdity. Process people also equate proper operation of the system with results which is not always the case. And as the process becomes part of the background, they often forget what the intent was behind the process and start focusing on the feeding of the system (anyone who's dealt with a government agency knows what this is like).

Getting the Balance Right: The CEO
One of my most important jobs as CEO was to get the balance right over the years I've developed some distinct biases and tricks.

The CEO should be a product person - Once a process is established, it tends to be self-perpetuating. Unfortunately, things change which inevitably leads to the process becoming less effective at delivering results over time unless someone is keeping the company focused on the end results.

Product people should outweigh process people - I don't necessarily mean that they should outnumber them. In fact, it is quite likely to be the other way around. By outweigh, I mean that management's bias should always be towards someone achieving the desired result. People should not be unduly punished for doing end runs around the system provided those end runs are not on a whim and they achieve the desired results. (You do need to take corrective action with people who are end-running the system and making mistakes the system was designed to prevent.)

Business processes should be required to justify their existence every so often - In one of my turnarounds, a key issue was that the company was buried in processes. We first identified and killed any process that no one seemed to be using and there were a lot. Many were "CYA" processes designed to address contingencies that someone had anticipated but that had never actually occurred. We then targeted processes that generated the most complaints from the end-victims and informed the process owners that unless they (not the victims) could justify the benefit of the process, it would be terminated. After much screaming, this usually resulted in significant streamlining of the process rather than elimination. Finally, after the major pruning, I made it a point to select and "pick on" a few core processes every year by making process owner performance reviews dependent on end-victim satisfaction, efficiency, and unobtrusiveness. It's amazing how much better processes get when someone's raise depends on it.

Balance is the key. Too many process people can efficiently run you into the ground but too many product people can effectively run you off a cliff.

I like the "Balance is the key" part at the end. I would actually go a step further, and I would suggest that both types are highly *complementary*, and both types have to *realize and appreciate* this complementarity (and that’s the tricky part). In a prior employment opportunity, I kept butting heads with my Product people boss, and after being away from that company for even just a short while, it dawned on me that the complementarity of our relationship should have been the focus of our discussions and working relationship, rather than being astonished at how far apart our perspectives were. Once I realized this complementarity aspect, it helped me appreciate the other perspectives and greatly tame my natural stubbornness as a Process person... :)