Our guest today is Mr. Yoav Hochberg. He's a graduate of Technion with a bachelor's degree in computer science and an MBA. You have worked for 30 years at Intel, serving in various technical and managerial roles. For over 12 years, he was the Vice President of Strategic Planning and Business Development. Leading the product definition for many of Intel's CPU products. He also built and managed the business development group for the Mobile Platform Group and was a strategic investment manager in Intel Capital. Thank you for coming and sharing your knowledge with our students and viewers. Thank you for being with us. My pleasure. I want to ask you some questions and I'd be very happy to get some insight regarding your product development in Intel. First, how did you define the strategy and roadmap of future projects and how did you select specific projects in light of the strategy and roadmap? So, the Intel roadmap is driven by Moore's Law, which up until recently was that every two years we doubled the number of transistors. In order to deliver the roadmap we applied for the last 15 years something which is called the tick-tock model. Where you want to reduce the risk between new product development and new process development. So, every two years you build a new process on a previous architecture, and then the following year you come out with a new architecture on a mature process. And this tick-tock model enabled Intel to pull ahead of the competition, by delivering new products and new processes all the way down to the seven nanometers which we are today. This basically drove a cadence that says that, you have to deliver every two years there was a new product and it's either a new architecture or a modified architecture. So, the cadence of when we need to deliver the product was pretty much set back in 1950 when Moore's Law was invented means we have to deliver a product every two years. The strategy is driven by the company's strategy, because when we decided to move into mobile products we had to optimize for power performance. When we were delivering service, you have to optimize more for performance or also power performance. So, the overall corporate strategy is driven by part of the corporate strategy office and where the company wants to go. And the cadence of when the product comes out, was driven by the process generation. So, basically we knew when we had to deliver. All we had to decide was, what do we deliver? Okay. Can you tell us what are the phases in a typical microprocessor development project at Intel? What should be done at each phase and what are the outcomes of each phase? So, there's a very clear distinction between pre-silicon and post-silicon, because everything that comes before silicon can be changed quickly, everything that comes out after silicon is really hard to change. So, if we take a look at the pre-silicon stages, the first stage is really the pathfinding where you identify what are the things that you want to put in the product. You then go through a process of what we call tech readiness of saying, if I had to implement this idea, what would it take from power, from execution, from engineering, from circuit point of view. That's the elements that which is the tech readiness. Then there's the execution stage, where hordes of engineers go at the product and actually build a product, the logic design, the circuit design, the layout. Then there's the validation to make sure that the product does what it's supposed to do. Then you tape it out. When silicon comes back you go into the whole post-silicon element, where you have to verify that the product is doing what we asked for it to do. That from an electrical point of view, it meets all the parameters for the electricals. And that from a reliability point of view, since we are going to ramp hundreds of millions of products in a very short amount of time, you have to verify the robustness and the quality of the product. So those are happening post-silicon. There are some iterations when you find bugs you sometimes go back and do re tapeout. But basically, then you ship it out to the customer. From beginning to end, usually takes between three to five years, while the post-silicon is around a year, three quarters to a year. The execution is about two years and then the planning depends how early you start. Okay. And what is the process for the product definition phase? For the product definition phase, we call this the pop, the product opportunity plan. And at a very high level we have four phases that actually drive the product definition. Pop l zero is really when you look out into the future. Since we start the product definition five to seven years ahead of when the product needs to ship and in the current environment when things change so quickly trying to look ahead, seven years into the future is not simple. So product pop l zero, what we call the first phase of the planning exercise, is looking at where the wall is going regardless of what the product is going to do, you try to assess what are the major trends that are happening in the world, and what is happening in order to understand what do people want? What are the biggest problems that are going to have to be solved? Which gives an environmental thing, this is the world in which my product needs to fit into. So, that's the pop l zero, which is really said. Ignore the product, let's take a look at the award. Then you move into what we call pop l one, which is the lending zone. It basically looks at the wall that we defined in l zero and says, "Where does my product need to lend?" You know it's in this quadrant, is it targeted for mobile, is it targeted for cellular, is it targeted for servers? What are the big elements that it actually has to deal with, if it's security, if it's perceptual computing? So, this l one it's really a lending zone and says this is the area where the product needs to target. Pop l two, which is the third phase is feature freeze. Say what are the features that you need to really get into the nitty-gritty details of thing? What are the exact features that are going to be implemented and are going to be delivered as part of the product? The last stage pop l three, is really you now take a look at the computing require, the headcount required to really assess can you can you build it? That is when you sign off on the product and say, I'm committed to deliver these set of features in this time frame and these are the resources that I need to actually go do it. From a planning point of view, those are the four major phases for the product planning. Okay. And who should participate in the initiation phase of a typical microprocessor development project? What is the role of each participant? Okay, so, since the product is called the product opportunity or the POP process, we have a POP team. And it is a very multidisciplinary team. It actually brings together all the elements that are associated with the planning, execution, and delivery of the product. On one hand, it's run by the strategic planner. So, the strategic planner owns, driving the process, and it has people from the architectural group. Because at the end of the day, when you define a product, it's a balancing act of trade-off because they have to trade off schedule for performance, cost for dice size, feature for complexity. You have a multi-dimensional trade-off that you are trying to drive. So, first, you need to assess, is it a product that people would want to buy? Because at the end of the day, the purpose of building the product is to have people pull out their wallets and buy your product and not other people's product, which is your competitive advantage. So, we have a set of people that are associated with understanding what do people want. If it's the marketing people, the business unit people, people from Intel labs that actually look at people's behavior. We have a large ethnographic team that looks at what do people want and can give, bring insights from that element. Then you have the technology people saying what are the new technology from the Intel labs, from the architectural group. Then you have people from the execution organization, the engineering that says can they build it. How many people will they need? Is it doable? Have they done this before? Because you have to assess the maturity and the complexity of everything that you're trying to put into the product. Then you have the finance people. And then you have the people that actually there have to sell the product, so you're bringing people from strategic marketing and from the back end part to say, as an example, what kind of debugability features do I need to put into the product? So, I have people for post production or post Silicon also participating. Because the sooner you understand what you need, the higher your chances of putting it into the product. One of the problem with a Silicon product that if you missed it, you need another six months and millions of dollars to actually re-spin your Silicon. So, you really are trying to get all those things upfront discussed in the product opportunity discussion to define what are the features, what do they do, how do they do it, and all of that. So, it's a highly multi disciplinary, cross-functional team that actually has to run through this process. Okay, and is the voice of the customer heard during the project? How is it done? Well, the customer is actually we are what we call experience-driven. So, as I said, we have people that are UI and UX experts to understand what do people want, how will they use it. We have people that are from the business units that talk to customers every day. We have several checkpoints where we take the product proposal and we go out to customers and we ask them if we build this, would you like it? What's missing? Henry Ford said that if you ask your customer what they want, he would say he wanted to fix the holes, not an internal combustion locomotive engine. So, you do have to make sure that there is a very good and strong customer voice into the product. But on the other hand, you also have to understand that the customers,, in many cases, are looking at the problems they have right now, not what they would see in three to five years. So, balancing the technology capabilities that enable new experiences, looking at the existing problems, looking at where the world is going, looking at doing focus groups with customers, with potential uses. So, definitely, the customer has a very large seat in the table, in the POP process. So, is there a model or a template that is used to start new projects? Yes, and as I said, the POP, the product opportunity plan, is a template. We do have a very detailed format of what needs to be put into that POP process. It changes from project to project because things change, but the questions don't change. Sometimes, the answers are different, but the questions don't change. And we make sure that as we learn from one project to the other, we add new stuff. One of the things, I believe, that strategy actually has to have a closed loops. So, we identify the product lendings on in POPL one. In POPL three, when we send the project to execution, we asked the product planning team to go back to what they said about the lending its own and see if it's still valid. When the product hits the market, we then go back and look at everything that we said about the product when we defined it to see where we were right, where we were off because it has been several years. And then we take all those learnings and we sort of feed into the next project that we do to make sure that we have a continuous learning cycle. So, what information is needed early on in the project lifecycle when the decision to start a new project is made, the go/no-go decision? So, again, many aspects associated with the information. A, you do need a lot of information about the market. What do people want? The trends that are happening because when social networking became really important, what features do you have in order to add to that. Security became important. How do you add security into the core fabric of the product? So, you need a lot of information about the market that you sells and the value chains, the business models, all those are very important. You need a lot of information about the technology. What is the new technology that's happening out there? We set a very wide net outside. So, we look at Academia to understand what technology comes out of the Academia. We take a look at into labs, what new things they've walked up with, the architects, the designer. So, we look at a very cross sort of, sometimes, great technology drives great experiences, not always. They say technology looking for a problem. So, if you invent a new technologies, sometimes, you can do stuff with it which people didn't think about previously. You look at the financial aspects. How much is it going to cost the product? You have to trade off between the cost and the volume. So, how much money is the product? If it's not a feasible product from a financial point of view, you don't do it. You take a look at competition because you are trying to drive a specific strategy as we've talked previously. So, if the product that comes out does not drive you in the direction that your strategy needs to go, then it's the wrong product. So, you look at the strategic elements and you look at competition because you do want to make sure that you will outperform the competition. So definitely, you look at a very wide range of elements as you build the product and define it. What are the triggers for new innovation projects? Well, you know people look at innovation. There is a misconception that people think that innovation only comes as a new product. That a new product is the only innovation. But when I'm able to take an existing product and ship it with one half of the cost or in one quarter of the time, it requires an unbelievable amount of innovation in order to make that happen. So, the drivers from an innovation point of view, of course, there's the need of what needs to come out in the market. There is the new technologies that people come up with. There is, if it's a verification process, if it's the cost structure, all those things drive innovation both at the feature level, at the methodology level, at the execution level, at the marketing level, at the business level, so every one of them, and it takes a village. It's not just that one idea. When you're building a two billion or 28 billion transistor device, which is what we build, we know the client part is about two and a half billion devices, and the server part is 28 billion transistors. When you are building such a device and there are hundreds of people associated with it, there isn't one single item, so that is the key driver. It's really a very wide range that you have to balance between them and you have to make sure that you take them all into account. And you can't do them all. For sure. What is the role of top management in the innovation process? Top management has a very critical role in innovation and it needs to set the tone that it requires innovation. Okay, you can easily kill innovation by saying the wrong things, or by rewarding the wrong behavior. So number one, it is about setting the tone, setting the expectation that innovation is needed in order not just win, but even just to plain survive in a very competitive landscape that we are in right now. Then it needs to make sure that the right infrastructure and the right environment is there for the innovation. There's needs to be trial and error. There needs to be the fact that if you fail, it's not a problem. Okay? It's a learning experience, which means you have to build what's called a you know a growth mindset, not a fixed mindset into the organization. And when people come up with innovation, you need to find the right investment model to test them out because it's very easy to kill innovation very early. If you don't have the staying power, if you don't say, okay, I do need to invest because it doesn't happen in a day, okay? You need the ability to invest for the long run, but you also need the ability to say, okay, it's done, I'm going to kill it so that I can move my resources somewhere else. So, all of those elements are management elements in the innovation process. What are the most important success factors that the project managers should focus on? Well, by far, it's execution because at the end of the day even if you have the greatest product definition and the greatest strategy in the world, it's as good as your execution. So at the end of the day, you know the project is managed by did it meet its targets. Did it sell? Did it meet at the cost target? Did it to meet the sales targets? Is it a product that people really liked in the marketplace? Otherwise, why did you do it? Maybe it was interesting but that's not a reason to do it. So, it is about, number one, complexity. Okay? One of the biggest problem in huge microprocessor product is the complexity. There is a tendency the complexity just keeps like entropy, just goes up and up and up, specially as you add more features. It is about the ability to execute. How do you manage such a large project. So that is another key element. Of course, the financials, which is you know, it's very easy, there the creeping elegance. You get okay, you know I call this the Hanukkah effect, which means that every light is a small light, but together we are big light. So you know this feature doesn't cost very much and this feature doesn't cost very much and this feature doesn't cost very much, and then it's a very expensive project or a very complex project or a very big and it takes a lot of time to build it. So all those elements of complexity, maturity, execution, the fact that the market doesn't change. So as a project manager, you really have to make sure that the projects you're building is still valid; that if things have to change, you catch them on early and the drive the change within the organization. What are the typical risks of microprocessor development project? And how do you manage such risks? So I think I mentioned some of them previously, but I'll reiterate. Number one is complexity. Really complexity is one of the biggest risk or creeping elegance or creeping you know, the best is the biggest enemy of the good because you say, okay, I can make it just a little bit better and then it takes two extra amount of time and then it takes three extra amount of work and that's a problem. The second risk is, of course, is maybe not prioritized, but it is about execution. It's about can you deliver it, can you build it, can you manage all the people, can you integrate all the different functions. And then, of course, still there's the market risk. Are you still building a relevant product if things haven't changed? And the way to manage it is we have a very large set of both indicators of a product planning, not strategic planning, but more planning element of thing. Okay, I know there are bugs because people designed it, not your machines designed the product. Is the rate of completion of identification. If you don't find any bugs in your validation process, it means you're not checking. It doesn't mean that you don't have any bugs. Are you identifying the bugs at a good enough rate, which means that your validation is good enough. Are you closing those bugs at a good enough rate? So you are constantly looking at the indicators. There is a very big set of both a weekly, monthly and quarterly indicator that you look at how is the project converging. You put in what we call leading indicators of saying, okay, we need something, if this is happening then we have a problem. You try to be proactive and not reactive to some of that stuff. So those are all techniques of managing the risk, identifying what the risk. And I always say that in a Silicon Product, if anyone came to me and said that everything is okay, I know that either he didn't check everything or didn't check everything all the way to the end. So most of it is okay, but on the rest we are still working is probably a better solution because, again, when you have so many things happening, in so many dimensions, in so many disciplines, in so many transistors, things go wrong and know what you need to do is not how do I make sure that there are no issues, how do I identify them as early as possible and fix the ones that actually have the most impact on the project. My final question is what is the best way to monitor and control the projects while it's execution? So, as I said, it's similar to what I said previously. It is putting in the, when you first of all, you have a very long history of previous projects. So, doing every project that we did, we completed with a very detailed postmortem of appreciative inquiry as it's called today in a positive manner, if the project is not dead. So, first of all, you learn from previous projects. Second, we apply something which is called the premortem. A premorterm is a very strong tool where you sit the team down, and you tell them, "Okay, the project that we are building which is supposed to ship in three years completely failed. What happened?" And then, people start to talk about, "Hey, we didn't do this. We didn't do that. We didn't do that. " There is no finger-pointing, which usually happens in postmortem because it didn't happen yet. People are more open to actually share they'll concern. And you have a time machine. It didn't happen yet. You can fix it. So, those are elements that you use in order to do it. You sort of look ahead into what needs to happen, and you put in the leading indicators to say, "Are you on the right track?" I'll give you an example. Taping out the project which is a process of taking the database and turning them into masks, used to be something that we would outsource, but then, it became so complicated that we had to build it inside, inside. So, a year into the project, we were two years before the project to tapeout. I took my lead mask designer, and I told him, "I would like you to assume that we are taping out tomorrow, and actually run the tapeout." And then, we found out that this new project requires more computing resources, than we have in the whole facility. So, we actually ran through two mock tapeouts before we reached the real tapeout. So, we were prepared. So, by the time, we got to run the tapeout itself, it's not that nothing, no surprises happened, but fewer surprises surprised us. And that element of looking ahead into time, and then, understanding from where you came, looking ahead, and trying to identify what could go wrong, and then, thinking about it. Those are some of the elements of making sure that you have a higher chance of making it, to have the project just be a little bit late, and not completely late. Thank you, [inaudible] I'd like to ask another couple of questions. Sure. Based on what you have said. How can the project manager motivate his team, and develop a shared understanding of the project goals among his project team members? So, definitely motivation is a very key factor because throughout the project, people are working really hard, and especially toward the end of the project, there are many white knights where you actually have to fix, work really, really hard. We start out by really explaining to everyone of why we're doing the projects. There's a very famous, Ted talk about, "Don't tell people what you do, tell people why you do it." So, I think, example when we started Sandy Bridge, which was our 2011 product. We had a, what we call, its previous name was Gesher, but we call it a Gesher Day, where we actually collected all the people are going to work in the project, and really show them why are we doing the project. What is the motivation? I'll give an example. When we started working on Sandy Bridge, it was back in 2004, 2004, 75 percent of our customers were [inaudible] and 25 percent were consumer because we just started with the mobile revolution. It started with Centrino, and then, we identified to the fact that, video is going to be a killer application, 2004. So, I remember people ask us, "Do you really believe that people would sit down, and watch movies at work? You're completely crazy." And we said, "Yes. That's what we believe with the way the world is going." Now, you could asked me, "Did you foresee YouTube?" And the answer is "No." Because otherwise, we would be having this discussion on my island, not here in the Technion. But what we did do, we integrated into Sandy Bridge, the Quick Sync which is the world's fastest, most powerful media engine which enables you to watch two DVD movies on a single charge in your Notebook. And when you explain to people why you're doing the project. It's not, "I'm going to give it 10 percent more performance, or three percent more of these, or two percent less cost." You're explaining the products that we built, 80 percent of the world's computing runs on the products that we build. So basically, my team between 2006 and 2016, over 80 percent of Intel's revenue was done, was generated by the products that my team defined. So, what you explained to people that are not just working on our execution cluster. They are defining what computing is going to look like in the world. And when people understand what they are doing, they understand why they are doing it. And they understand how it's connected to what other people are doing, then they identify issues which you couldn't tell them upfront to look at. They have much more motivation, and they want to get the job done because they really believe that they are changing the way computing is done in the world. Okay and what are your recommendation for project managers, and the teams in these area of microprocessor development projects? So, microprocessor, building a modern day microprocessor is in the state of the art technology. It's not an endeavor for the feeble minded, or the softened heart. You have to really want to do that. You have to be able to undertake a significant project which has a large amount of complexities, multidisciplinary, a lot of people from different domains trying to work on it, hundreds of people working on it. So, definitely it is a big project. You need to make sure you have the perseverance, and persistence to see through. But at a very high-level, I believe that there are sort of key elements to building a project. You first have to think, then you need to plan, then you may need to stage, make sure that all the pieces are in place. Then, you need to execute, you need to monitor what you've executed, and then, to learn from what you've done. So, these are the sort of the, think, plan, stage, execute, monitor, and learn. I think those are the key elements that if you put in the right things to do those things, then your chances of success are higher Thank you [inaudible] for sharing your experience with our students, and I really appreciate it. Okay. Thanks a lot. Thank you.
