[MUSIC] Hi, everybody. I'd like to introduce Rony Friedman who is heading the Apple design center in Israel. Until recently, Rony was managing a large development activity as part of intercorporation. Thank you, Rony for sharing your knowledge with our students. I'd like to ask you a few questions and the first one is what is the role of top management in the innovation process? >> First of all, thank you Avy for inviting me and giving me the opportunity to talk about my experience. I think that usually I view two type of innovation. One type of innovation is you have a roadmap of product and you need to determine what goes into the next product. And usually we are trying to identify two, three big things that we want to do in each next generation rather than having a long laundry list of improvements. Let's call that kind of next generation innovation. There is another type of innovation which is doing something which is ex curriculum, something that we didn't do so far and we want to get into a new domain. And of course, that's a different type of innovation. Because when you get into a new domain, you still don't know what will be the outcome. You need to explore. You need to build the knowledge in the team, so let's call that a more revolutionary type of innovation. In the first type of next generation innovation, usually we have an orderly process of development where management is kind of defining the timeline for the next generation. Identifying who are the people that will define the next set of features or the next set of innovation. Making sure that we have the right type of disciplines involved with architecture, design, software people and making sure that we are really crisp in terms of defining what are the two, three big things that we want to bring. Because usually you may have a kind of endless list of small things that people want to add to the next generation. But you really need to make sure that whatever we are adding has at least two, three things that are big and substantial. Another role of management is to engage the business units, usually they are the internal customers and figure out what for them will be viewed as a big selling item. Because whenever you are bringing a new product, yes, there is incremental improvements in every vector. But you want to be able to say in these two, three areas, I'm making a big step forward. So this is another part of management, engaging the business units, the business partners and working together on defining what are the big things that we want to bring in the next generation in the kind of breakthrough type of innovation or getting into a new area. That's usually more complicated. Because A, you need to determine in what area you want to get into. Because this is not something that you have been doing for years. And the second thing is how do you build expertise in a domain that you still don't have an expertise? So management really needs to work together with various teams to identify what is the area that we want to get into. Because there is a large variety of domains and identifying the few key seed people that will be the kind of start up for this new activity and supporting them through the initial phases. Be it by providing budgeting. Be it by providing support from other teams and getting the upper management support for the seeding activity. >> Thank you, Rony. How did you define a strategy in roadmap for future innovation projects? And how did you select specific projects in light of the strategy in roadmap? >> Good question, so let me again try to relate to the two type of innovation. So when we are defining the next generation product and we want to define what gets into the product. There are the usual goodness vectors that are associated we use each product line. So if we are talking, for example, about a laptop, then you need to bring improvement in performance. You need to bring improvement in battery life. You need to bring improvement in media features that in recent years have been key selling items in laptops. So this is one time of things that you are driving. You are doing competitive analysis to understand where you believe competition will be. You are identifying trends in the industry. For example, let's talk about imaging technology. So where the imaging technology is heading and based on that defining where you want to do, what you want to do in each of the vectors, performance, features, battery life, etc. In some cases, we need to engage external parties in order to bring the new capability. Because some of the capabilities are, we may not have the full set of capabilities internally and we need to partner with an external party in order to bring that to the market. So that's in terms of defining where we wanted to go for the next generation. We also know based on experience what are the selling items that the business you need can more easily explain to customers and what are the other items that are too technical, and you cannot really explain to customer what is new. So that's another factor that gets into the finishing process and we are going over this combination of technology trend, exploration about competition and what the marketing team can really sell and together try to define what we'll put into our next generation. Sometimes we have kind of bottom up innovation, people are saying, hey, we have this great idea. It's not something that deserves a Nobel Prize, but it is something that is interesting and we are trying to get that into the product itself by developing the interest in the business unit and asking them and having the dialogue with them. Hey, if we have this capability What can you do about it? Can you market it? Will that be interesting for the softer ecosystem, etc.? >> So what are the typical triggers for new innovation projects? >> So let' say- >> [COUGH] >> In this case, let's talk about, they're what we call the new innovation. Domains that you are not really vested in, because in domains where we are already investing for years, that's a bit easier. So in domains which are totally new for us, there are a couple things that we are looking at. First of all, there are various institutes that beat universities, or other research centers that are publishing what they believe is the maturity cycle of each technology. When they believe that each technology that today is stealing, a research phase will reach a certain maturity that can really be important for industrial usages and really hitting the market. So this is one thing that we are looking at. The second thing that we are looking at is, what is consistent with our capabilities? Because whenever you are trying to get into a new domain, you need to have some relative advantage stemming from your current capability. If it's a totally new capability, it's harder to make it successful. So you need to find the alignment overlay between the new domain and the current capabilities of the company, and the current capabilities of the team. And once you define this overlap between the technology maturity and the capabilities of the team, then you are asking yourself who are the partners that you want to partner in order to bring this new capability? It may be startups, it may be universities. And then you are building this small seed of expertise and trying to recruit people that are expert in this domain, and building a team that can develop this new technology. Whenever we are going after a new technology, getting a buy-in for this investment is not simple because you cannot really estimating any data driven or the return on investment, because you don't really know it's a new domain. But you need to convince management that there is enough potential here, that if everything will pan out, then there are this usage model, and this usage model, and this usage model that will benefit from this new technology. And this is how you are convincing. So usually it's not based on dollar numbers, and revenues and margins, but more about hey, you want to get into autonomous devices. This, and this type of capabilities will help you. You want to get into smart security cameras, this, and this capabilities will help you, smart home, etc. So this is how we go about getting into a new domain, which is you cannot really use the traditional return on investment calculation in order to convince management. >> Okay, so what information is needed early on in the project life cycle, when the decision to start a new project is made? The Go/NoGo decision. [COUGH] >> So I think that when we have the next generation project, that's relatively easy because we have already been in this domain, we know what the pricing we can expect in this domain. We know how the pricing stack looks like. And based on that, we can determine on one hand, what is the set of new capabilities and new features. On the other hand, what is the thermal or power envelope. And what is the cost constraint that we need to hit. So it's a regular engineering trade-off, trying to bring as much goodness as we can under this constraints of power, schedule, and cost. And there it's doing the- >> [COUGH] >> Due diligence, and coming up with the right set of features that we can implement in a given amount of time, in the given cost and power constraint. When you are getting into a new domain, which is you still don't have a tradition of products that were designed in this domain, and you don't really know upfront what may be the pricing that you will apply in this domain. This is of course, more fluid. And in that case, we are trying to have some partners. You need to learn the market, you need to learn the segments. And you need to find somebody who is already playing in this field, and he can help you guide through this initial phases. So for example when we started getting into machine learning or various technologies associated with autonomous driving, you want to find some people that are already playing in this field and they can help guide you, what technologies, what breakthrough may be of interest. And what is the kind of overall cost structure and power envelope that you need to hit in order to bring something which is substantial. By the way, the more breakthrough the technology is, the chances for success are dropping, right? Because you cannot say upfront that you will hit the constraints, and everything will be as expected when you are doing something totally new. And I would say that based on my experience when we were doing this sort of new innovation, probably the hit rate was one to three. One out of three, maybe one out of four. So you know it's not totally research that people are saying well, maybe the hit rate is one out of ten. But it is certainly not 90% confidence level. And you need to make sure that the team and the management is aware of the risks that is being taken because otherwise it won't be a big gamble, it will be an incremental move. >> Yeah, yeah. Who should participate in the initiation phase of a typical microprocessor development project, or any other project? What is the role of each participant? >> So usually when we- >> [COUGH] >> Are developing a new microarchitecture, we have the CPO or the SoC architects, these are our main contributors. We have people that are designing the platform that is being built around the SoC, they are another big partner in this improvement. For example, if there is some new >> Thermal solution or some new display technology. This is part of the platform or a new battery technology. So they are part of this definition process. Beyond that, so C architecture and the platform architecture. If we are running on a new process technology, we will involve the process technology people as well. That doesn't happen every year. But whenever you have a new generation of microprocessor and a new process technology, we are working together in order to make sure how we best utilize the process technology for accomplishing the targets that we have for our product. In addition to that, we have a core team of design people that at the end of the day need to implement the architecture. So they are involved A, to make sure that whatever we define is implementable. And B, there also looking whether from design methodology point of view. We need to modify or change, or add some new capability in order to design this new microprocessor. For example, let's say the next microprocessor is integrating some new analog capability that was not integrated before. You may need to change your design methodologies in order to allow this integration or you are running on a new process technology that requires changing your design metrics. So we are involving a small team of design people that are making sure that whatever is being defined is being defined in a way, which is implementable and also looking in terms of design methodologies. What needs to be modified or enhanced in order to design this product. As I mentioned before or later on once we have kind of a strong proposal, we're involving the business people. And are telling them, hey, these are the ideas that we have. Can you really sell that? Is that something that you believe will allow you to maintain the pricing or even increase the pricing? And once we all gel together, we are bringing the product proposal to ratification and then we start with the more detailed implementation. >> Can you tell us what phases are there in a typical development project? What should be done at each phase and what are the outcomes of each phase? >> Yes, good question. So we start with what we call a past finding. Past finding is exploring two, three big things that we want to do. By the way, the past finding is an ongoing process. Because usually this starts something that takes longer and you cannot squeeze it into a given development timeline. So the past finding, I view that as an ongoing process and we are seeing what kind of technologies which maturity that allowed them to intersect the next product. For a given product, we have the technology readiness phase where we have the SOC architect come from our architect design people are working together like I just described. At the end of the the technology readiness, we have designs specification. We have a design specification for the next microprocessor. And if we are deciding to apply some new design methods, we already defined what are the new design methods and we have done some small pilots on the new design methods in order to make sure that indeed, they bring the benefit that we expected. After the technology readiness, we are starting with what's called a front end design where we are writing the RTL and preparing the validation environment. Defining the test plans and capturing all the physical aspects of the SOC. What we call floor plan, partition it into sub-blocks, power delivery, clocking distribution, etc. And this phase is starting to execute where all the discipline are working in part of it. The design people, the validation people, the architects are supporting this activity and what we call the vacant people are doing the physical implementation of the design. About six months or so before the when we first deliver the product to initial manufacturing, we start to have heavier involvement of the implementation people. People that are really implementing the logic gates and the transistors, and doing the timing analysis, and doing the reliability checks. All those that are needed in order to make sure that whatever we are implementing until indeed is meeting the specs and meeting the reliability requirements of the product. And we start involving the post silicon people in this activity to make sure that when the silicon comes back from manufacturing. They have the right test equipment and right test content in order to test the silicone once it comes back. So after this front end, we have the back end implementation. And at the end of the back end implementation, we have the big event we just call. We are sending the masks for initial manufacturing and usually that may take three to four months until you get the silicone back. And in this period, we are having silicon readiness. So all the pass silicon teams are getting ready for the silicon in terms of developing the testing boards, developing the test patterns, developing all the equipment that is needed in order to validate the silicon. Silicon comes back and then we started the phase of silicone validation, and correctorization, and this continues until the silicon reaches the good enough maturity that we can give samples to our customers and then we have various phases of sampling to customers. Alpha sampling, beta sampling and then we continue to production. >> Is there a template that is used to start new projects like a process that is well-defined with very clear input and output at each phase? >> Yes, so of course, if you want to get predictability in your development, you need to have an orderly design process and you need to have an estimation how long each phase in this development process should take. And as we said previously, who should be involved in this phase. So for projects that we have already Done this types of projects before. We have a template, we have duration for each phase. And we have ways to track progress, how we progress in each phase. So during the definition phase, or the technology readiness, the main thing that we track is how the specification are progressing. When we are getting into the front-end of the design, we are measuring how the RTF coding, and how the test content in the validation is progressing, and whether it follows historical trends, or we are running behind in certain areas. When we are getting into the back-end part of the design, we are tracking how we are implementing the gates and transistors. And again, it's the pace of implementation, and the timing convergence, and the power convergence are following historical trends. Is the bug finding following historical trends? So by having relevant history, you can anticipate, you can plan ahead, and you can also track where your opening gap, and where you are on track. When you are doing a new type of product that you haven't done before, because it's a brand new micro-architecture or a brand new technology, then the predictability is impacted because the historical benchmarking may not be that relevant. So you are still trying to follow a template, maybe you give certain phases more time because you understand that there is a learning curve involved. But it's always very important to have this timeline with phases and to have a planned duration in order to make sure that even when you run into problem, you're still under control. >> What are the typical risks in such a project and how do you manage such risks? >> I think that's a good question because people always want to take risk but they don't want to bear the consequences of taking risks. So I think that there are different type of risks. Let's say we are implementing something new, a new features, so a mitigation of this new feature may be to do some early proof of concept, if the times allows. I think that's something that we are doing whenever we can. When we are doing a new mixed-signal circuit, we are trying to do a test chip in order to make sure that the combination of the new circuitry and the process technology indeed work according to our expectation. Because when you're implementing analogue circuitry, you cannot really say for 100% confidence that whatever you are simulating, this is how the silicon will behave. This is why we are doing test chip and combinations of test chip together with FPGAs. Whatever that can't get to the test ship, we are implementing in a FPGA, and the combination of the two allows us to test things before we are doing the actual tape-out of the product. When we are running on a new process technology, that introduces another type of theories because it's a new process technology. So we are working together with the process people, again, utilizing a series of test chip in order to characterize the process, and to understand what you can really get out of the process, and where you may have yield issues. What type of topologies may be problematic on the new process technology, etc. So it's the combination of proof of concept, test chips, and prototyping via FPGAs or other means in order to reduce the risk. >> What are the most important success factors that the project manager should focus on? Like the critical success factors, if you don't do it, you'll probably fail. >> So I think that first of all, you need to make sure that whenever we said that we are going through a technology readiness phase and we are compiling a product proposal, and then we are bringing that to a management approval. So one thing that we need to make sure that there aren't large deviation from whatever we brought there to the extent that the project is losing its value. Whenever you are implementing something which is big and complex, you learn things and you run into problems along the way. So it's never exactly 100% what you thought in the product definition phase, but you need to make sure that the deviations are not really substantial. So making sure that the product is still relevant and obeying the constraints that we took into account during the definition. The second thing that we need to track is, is there something new about competition during the implementation phase? Is competition bringing something new that we didn't anticipate that will affect the competitiveness of our product? That the second thing we need to track. And beyond that, of course, you need to make sure that the schedule is being adhered to because any goodness is indeed competitive if it comes in a certain timing windows. If you are missing this timing window in any significant manner, then the performance that you had in mind may not be that competitive, the features that you had in mind may be stale. And therefore you need to make sure that even when you have delays along the implementation, you are trying to minimize the gap and still hit the same marketing window. Because if you miss a marketing window, usually the goodness of the product is affected in a significant manner. And the last thing that you need to make sure that you keep on motivating the people, and making sure that they are energized, and they are not burnt out because it's a marathon, it's not 100 meter dash. And you need to make sure that the people are still energized for the next product as well. So you need to make sure that you are celebrating small milestone, and you are showing appreciation, and you are not demonstrating any anger or frustration where a problem arise. Because that's the nature of doing engineering, you always run into unforeseen issues, and you need to keep the people motivated and energized in order to get the best results. >> Is the voice of the customer heard throughout the project, and how do you do it? >> Yeah, I think this is an interesting trade-off. On one hand, you want to be customer-oriented, and that's something that's easier to do during the technology readiness phase, when we are doing a customer tour and collecting inputs during the definition. A process, so that's done in an orderly manner and that's the easier part. The problem, what we do when something happens along the way and you need to decide whether you can accommodate a new input from the customer, and to what extent it effects and impacts your product plans. So if there is a new input and you can accommodate that through a bit more effort and maybe doing some overstuffing in a certain domain, that's great. If that's not possible because it impacts the schedule, or impacts other parameters like the power dissipation, then you need to figure out what to do. You may say, well, it's too late, I'll do a derivative product half a year later in order to address the new needs that were raised by the customer. You made decide that, let's say the customer wants a low-PAR envelope. So you are working together with the process people, whether they can cherry pick a certain amount of material that have better PAR characteristics and that will serve the product. But it's always important to understand that our customers also have a timeline that they need to hit. They have to introduce their own product. And for them, us delaying our products in order to entertain their new requests is a problem as well. Because they need to hit market windows as well, so we are working together trying to find the right trade-off. Either by doing a derivative product a bit later, or finding some other way, like I said, having a small quantity of a material that can address a certain market segment etc. But in this market, usually, what importance is the cadence of products. You need to bring something new every year, and bringing something which is great, but late, has consequences. So usually, it's better to bring whatever you planned, or whatever you can accommodate with some extra effort on time, and do the additional improvement a bit later rather than delaying everything. >> How can a project manager motivate his team and develop a shared understanding of the project goals among his team members? >> So I think that's not an easy question because not all people are motivated the same way, and that's the nice thing about working with people rather than with robots. So everybody is motivated by different aspects. Some people are being motivated by the fact that they see a technical challenge, something new that they are learning throughout this project. And it really motivates them to bring that to completion and to see that being materialized. Other people are motivated by seeing a product in the market, something that you can really touch. And you know that you have designed something that millions of people throughout the world will be using. Other people may be motivated by the business success. Even though based on my experience, most engineers, or most of the engineers, don't really care so much about how much money the product is making. This is maybe why they went to study engineering rather than to study business management. So different people are motivated differently, some by whatever it contributes to their career. Others by the fact that they want to see and feel a product that will be used by millions of people, and others may be motivated by the business success. And there is another interesting group of people that are motivated by reaching success together with the team. If you have a team that work together for multiple years, the fact that the team is succeeding together is a large contribution to the morale as well. Because in the Silicon world, nothing can be accomplished by two people working in a garage. Usually, it takes larger teams in order to develop something which is significant. So the fact that the team works together, goes through the tough times together is a motivating factor as well. And this is why you have to make sure that the team exhibits the right behavior, the right mutual help. And assisting each other when there are difficulties because this is what makes the team work with great synergy. >> What is the best way to monitor and control the project throughout its execution? >> So I think that for product that we have done before, as I mentioned, we have regular schedule indicators and technical indicators. Schedule indicators are showing progress, again, plan and where we see deviation for a given module relative to its plan along the various design phases. And schedule indicators are important because they are showing both your actual progress as well as your future plans. I've learned to see that usually future schedule indicators are always optimistic because people believe that, yeah, until now they had problems, but in the future, everything will be easier. So usually, what we do is we trust more the actual progress up to now, up to this point, rather than trusting blindly the future schedule indicators, especially if you are starting to see delays in your actual progress. My experience has shown that when you have significant delays, not one to two weeks that can be covered by hard work. But if you have bigger delays earlier on, it's very hard to compensate for that later on unless you do something dramatic. You bring over staffing to the domain, or you reduce the feature set, or something along these lines. And another part of tracking is technical indicators. Tracking the bug trends, the timing convergence, the power convergence. And this is, of course, important because, at the end of the day, schedule means something only if you are meeting the work and the convergence that you plan to accomplish during that phase. Be it timing convergence or logic verification convergence, etc. So whenever we are tracking, we are tracking both the schedule indicators and the technical indicators. And the combination of those two What gives us confidence whether we are on track, as well as indicating where we have gaps. Another thing, which is very useful, is to compare our self to a similar past product. When you're comparing yourself to a similar past product, you can really better assess if you have gaps, whether these gaps are recoverable or not really recoverable. So that's another thing that we are doing. Of course, no project is really apples to apples and completely identical, but you are trying to find the best ruler in order to compare it to. >> Based on your past experience, what are your recommendations for project managers and their teams in this area of innovation? >> So I think that for the managers, I would recommend, continue to be very technical, and continue to ask the right questions all the time. Don't settle for being kind of a general purpose management because, otherwise, it will be hard for you to assess during the definition phase whether this is the right set of features? What is implementable, and what will be tougher to implement. And during the implementation phase, if you are kind of not technical enough, you may not identify problems earlier on in the time frame that you can still come up with a recovery plan without delaying the schedule. I think this is really important and my experience has shown that managers that remained technical were more successful because it allowed them to better guide the team. Apropos asking the right questions, people in this industry are really motivated, most people are really motivated. So when they have problem, they are really sure that next week, the problem will be solved, but that's not always the case. So an experienced manager that understands the technical difficulties may say, okay, you're telling me that this will be solved next week. But I'm looking at the last two months history, and I think we need to do something different here. Just hoping that it will be solved next week may not be the right approach, so this is why maintaining the technical understanding is very important. Another thing that I would recommend for managers is to talk to people at all levels all the time, in order to really sense where there are difficulties, where they may be pockets of frustration, or low morale. And you don't want to get that just through the hierarchy of the management chain. Yes, that's important to do as well, but you really want to talk to people, especially people that you trust, in order to really get the right sensing. And my guidelines have been always managers can talk to whoever they want. They shouldn't tell somebody what to do. That should go through the hierarchy chain, because otherwise you're undermining your management chain. But in terms of talking and sensing, you can talk to everybody. And usually people actually appreciate that because they see that you care, and you don't just look at technical indicators and so forth. In terms of driving innovation, I think that management has a huge role. They need to be the ones that are really making the bet in what direction you go, especially when we are talking about this new innovation, getting into a new domain. They need to have persistence when they are running into obstacles, or the initial upper management doesn't approve. They need to go through a lengthier buy-in process in order to convince that yes, it makes sense to go into this new domain. Even though we cannot demonstrate how it impacts the company bottom line because it's too early to tell. So in the new innovation domain, management has the role to bring the positive energy to get to the buy- in, and to really carve out a set of resources and budget in order to fund this new activity. And that's not easy because people are always lacking resources and everybody wants more computing, or higher budgets, or more people. And, therefore, you need to cover out some protected set of resources that you are directing to this new domain, even though you cannot still prove that it will bear huge results. But you have the hope and the vision that it will yield something significant. >> Well, thank you, Ronnie, for coming over and sharing your experience with us. We've learned a lot and I really appreciate it, thank you. >> Thank you very much for inviting me, I really enjoyed it. >> Thank you. [MUSIC]
