Category Archives: Intel

Product Managers need time to breathe…

I’m going to make an assertion here, and please correct me if I’m wrong.

I believe that the vast majority of software product managers are running full tilt in their jobs, caught between the short term tactical cross-functional activities (working with Dev, Sales, Marketing etc) that are thrust upon us, and the important long term market research, business and product planning activities that are fundamental to managing successful products.

Do you agree? Disagree?

Companies want Product Managers to innovate, take bold steps, define new products, enter new markets, yet at the same time deal with all the day to day operational issues that arise and need to be dealt with. I’m surprised more product managers don’t burn out after a few years. Or perhaps they do, and like the trees in the forest, we’re not there to witness them fall.

There’s an interesting post on Innovation at Entitled, INNOVATION is an INSIDE JOB, the article makes several good points, but the key one is:

Organizations do not innovate. People innovate. Inspired people. Fascinated people. Creative people. Committed people. That’s where innovation begins. On the inside. The organization’s role — just like the individual manager’s role — is to get out of the way.

I couldn’t agree more. A lot of companies want to be innovative, but unintentionally put barriers in front of those best suited for the job by never really getting out of the way. It’s difficult to be inspired, fascinated and creative, if you are constantly required to focus on the short term needs of other teams. How can one extricate themselves so they can get out and learn and think and postulate and research and conclude and innovate?

One solution which I wholeheartedly support is to create Product Management teams who are responsible for delivering the goods. The teams can be structured in different ways. You could combine business focussed PMs with technically focussed PMs or you could split the PM responsibilities across functional areas of larger products. There are likely other ways to split up the responsibilities.

But the goal is to get to a level where the teams can work in a pipeline or leapfrog manner. i.e. while one team (team A) is focussed on bringing a release X to market, another team (team B) is out researching release X+1. Once release X is GA, team A can focus on researching release X+2, and team B is working to get release X+1 developed and out the door.

Now, before you start thinking — hold on a minute, how many product managers are we talking about here? — ask yourself a couple of questions:

  • What impact does Product Management have on your company?
  • Could it have a higher impact on optimizing Development, Marketing and Sales with a small increase in headcount?
  • How well could your company execute if you had deep market knowledge, clear understanding of user AND buyer needs, through competitive information and requirements that were complete, accurate and timely?

If you answered, “Significant”, “Yes” and “Much better than we are now” to those questions respectively, then think about defining product management teams in your company. Give them the time and tools they need to do a first-rate job, and then hold them responsible for it.

Challenge the teams to leapfrog each other in functionality, performance, scalability etc. The teams should view each other in a competitive manner. Why? Because your competitors are looking at you this way. They are trying to leapfrog you. They are looking at your weaknesses and trying to exploit them. They are going to try to out market and out sell you. Why not look at yourself the way your competitors look at you and beat them at their own game?

This may sound a bit unconventional but it works. Intel did this for several generations of their microprocessor chips. They had parallel teams working on successive generations of chips. Each new generation of CPUs (e.g. 286, 386 etc.) was to eclipse the previous generation. Not only did Intel make significant performance gains from one generation to the next, they kept upstart competitors like AMD playing a constant game of catch up.

Both AMD and Intel are successful companies, but which would you rather be? Why not take a lesson from an industry giant like Intel and apply it to your company?



Here’s the deal with Biz Dev (Part I)

Saeed has posted two fairly provocative items about business development. (Here are the first and the second.) Frankly, Saeed, you’re not following your own advice. To paraphrase you, “Enough with the missives about Biz Dev”.

If you’re getting annoyed by what’s going on in your company, then you have two choices — help fix it, or move on. There are a couple of other choices actually, such as do nothing, or complain about it on your blog, but to be honest, if that’s what you do, then you’re not as great a product manager as you think you are.


Certainly it’s easy to poke a stick at biz dev, and I could tell a few stories of my own. Several years ago, Intel was courting my CEO to have us port my product line to the Itanium chip, and thankfully I got to meet the Intel guy with my CEO for espresso at the old Starbucks by Moscone before we committed to anything. We were interested seeing what Intel might offer us, and my CEO really wanted to ink a deal with them. As Saeed said, it was “strategic”, and the Intel logo would look really great on our investor slide deck, or so our CEO felt. As is well known, the Itanium chip was a failure. Thankfully we didn’t invest.

In fact when we poked at Intel’s proposal, we found that the market for our product on Itanium would have been tiny; it would have been a tool to help people writing apps directly to the Intel metal, a specious group who wasn’t likely to increase our revenue. I suggested that Intel could pay a very large sum for our source code with an exclusive license on its doomed chip, but Intel didn’t bite. At that point our CEO saw that the logo on the Powerpoint slide wasn’t worth the distraction.

But I have also seen business development add major value to a company. When I was at Wily Technology, I saw how business development could be used strategically to strap a rocket to the company and create the engine for the company’s phenomenal growth. (And it was phenomenal. Eventually we were acquired for $375M, greatly exceeding the multiples of our peer group.)
What’s the difference between Saeed’s experience with BD and the Wily success story? It boils down to strategy, alignment, and value creation.

I’ll elaborate in future posts on this topic, so please stay tuned.