The Product Pulse

Several years ago, as a young programmer recently out of graduate school, I joined a small company and inherited a large amount of code that had been created by a previous employee. The code implemented a complex user interface and I had received several customer product change requests.

A sizable amount of the code had been automatically generated sometime prior to my involvement through the use of a user interface design tool. The tool allowed a non-programmer to graphically define the parameters of the user interface while magically generating working code on their behalf.

If any of you who have ever seen automatically generated code, you know that it's hardly fit for human consumption. The code typically has poor structure, much redundancy, and no domain knowledge.

After the automatically generated code was created, other programmers had made additional code changes, which meant the design tool could no longer be used, resulting in a horrific mixture of poorly generated code liberally sprinkled with many hacked-in changes.

Now back to my role in this story; I studied the code carefully and found that I could scarcely make sense of it. I could sort of see how the other programmers had tried to fix various issues, but I had no luck determining how the generated code was fully operating. It became clear that any new functionality requests could not be developed using the existing code.

Next I made the same mistake so many young, overly confident developers make. I told my boss I'd work over the weekend and fix it. He looked at me over the top of his glasses and said, "You do that."

To make a long and very painful story short, I threw away the existing code and rewrote everything from scratch with zero documentation on how the code was originally intended to function. The project impacted the company financially, operationally, and created a negative customer perception. Costs were tallied based on the missed product release deadline, numerous customer complaints, development time, missed opportunities, and some lost product functionality, resulting in frenzied hot-patching.

Today, as a much older and wiser (I hope) software development executive, I look back on this painful event knowing that my decision to rewrite the code caused a great deal of hardship, lost revenue, and costs. I also know that the code that I inherited had been so poorly maintained prior to my arrival that no other choice could have been made.

While I was clearly culpable, the culprit here is a concept known as code debt.

I invite you to read the Wikipedia article titled, Technical Debt. The article explains that code debt is commonly caused by: business pressures, lack of process or understanding, lack of building loosely coupled components, and lack of documentation.

The code I had inherited was literally a big pile of code debt. For years prior to my involvement, various programmers had been pushed hard by business stakeholders to make quick changes for near term and inexpensive customer requirements. The programmers didn't really understand the code in its entirety as no documentation existed in terms of original requirements or change requests. Programmers simply hacked in changes without complete understanding of its effects. Additionally, no time was allocated to refactor the code into something better and more maintainable.

Well designed code that is documented, understood, and surrounded by good unit tests is relatively easy and safe to change. The weeks of development work I dedicated to whip the user interface into shape was literally the interest paid on the debt. I'd also bet that the other developers prior to my code overhaul had also paid some amount of interest simply by attempting to decipher the code.

The objective cost of the interest is hard to measure, but the subjective cost of code debt is often extremely high. Code debt is responsible for many cases of late releases, buggy code, under-performing code, non scalable code, high development costs, high test costs, unhappy customers, and abject project failure.

Just like real debt, code debt is easy to ignore. Stakeholders want to hear, "I can do that in two weeks" not "that will take four months." Non-developers often take the "How hard can it be?" approach to product development. Developers are typically optimistic and want to please while customers want the new functionality tomorrow. All together, it's a recipe for building up code debt. All involved have the tendency to say, "Let's just do this quickly now and fix it all later." Doing so adds to the debt and the debt grows in some non linear fashion.

The best way I've found to avoid code debt is to use an Agile process and a focus on the following principals taken from Extreme Programming:

• Coding standards
• Simple design
• Refactoring
• Testing
• Pair programming
• Continuous integration

Code debt adds to the complexity of resource planning. As IT professionals, we are continuously challenged with making better use of limited resources and focusing those resources on work that brings value to the organization and aligns with corporate goals.

I'd love to hear from you. What are your experiences with code debt and what have you done to prevent it from taking place in your organization?

Your product pipeline might be perfectly streamlined and efficient. But if you're like many organizations, your portfolio may have some issues that are costing your organization in terms of revenue, product failures, and eventually reputation. Maybe you've wanted to implement a Product Portfolio Management Solution but haven't defined or designed your processes yet. Did you know that it's actually recommended that you go ahead and get started with a PPM solution so you can grow your processes as you go along? Here are some sure-fire ways to gauge whether it's time you invest in a software solution to improve your chances for success.

1. Failed Market Launches
   Has your organization launched unsuccessful products that have blemished your brand or product line? Have you missed critical time-to-market deadlines that have cost real money? Product Portfolio Management allows you to analyze your portfolio before you make the decision on what will be on your roadmap. It enables you to evaluate every piece of your portfolio so you have a complete picture -- the impact on your brand, competition, resources, sustainability, and bottom line. What has a failed product launch cost you? Chances are, a lot more than what it would cost to implement a solution.
   
   
2. Limited Resources
   You've repeatedly heard and our recent Benchmark Surveys have confirmed that the #1 pain point around Product Portfolio Management is too much work for available resources. You may have people presenting great ideas, but you only have a limited capacity when it comes to people. If you say 'yes' to every good idea, you spread your resources too thin and few of those good ideas actually make it to the market on time. Product Portfolio Management gives you tools to run 'what-if' scenarios before you execute. It allows you to perform comprehensive portfolio analysis to understand your current capacity, usually based on role or skill, and then evaluate all of the things in your pipeline to go on the roadmap to ensure they can actually get done on-time with the available resources. When you use your resource capacity as a filtering mechanism, you have a much higher chance of success.
   
   
3. Market and Product Conditions
   Look at the size of your product catalog and the number of markets you serve. If you have a large number of products, multiple projects that deliver a product, a large number of metrics to analyze the performance of each product, multiple markets or global markets, or if your roadmap is frequently changing, you're ready to centralize and automate your product portfolio to maximize visibility and reduce risk. Are you still updating your roadmap manually through PowerPoint? That's a not just a sign, but a neon flashing sign telling you it's time to convert to a formal solution.

Take a look at your current product portfolio and see if any of the 3 signs above are present. If so, you just might be ready to call in reinforcements!

It has been an amazing year in the product portfolio management space and it is time to reflect on accomplishments and new goals on the horizon. As the year comes to a close, I'd like to share the most popular product development resources of 2011. The list covers a variety of information on how PPM tools coupled with best practices can achieve a greater ROI while effectively managing resources to maximize productivity. It's a good set of reference material as you begin planning initiatives for 2012.

Five most widely read product development resources of 2011:

1. Navigating the New Normal: How Companies Handle the Portfolio Management Question -- The article addresses how companies are navigating the potential pitfalls and unknowns facing product development professionals today.
2. Improving Portfolio Decision Making -- Author Jim Brown of Tech-Clarity reveals how PPM plus best practice processes are a great enabler of ROI for product development firms the world over.
3. Right Resources, Right Management, Right Time -- The video highlights how to effectively allocate and manage resources to maximize productivity.
4. Play to Win with Your Product Portfolio -- The webcast shares proven strategies on how to confidently assess the value of your product portfolio and improve the odds of success.
5. Innovation Tools: Enablers or Derailers? 4 Easy Steps to Keeping It on the Rails -- The post provides answers on how to drive measurable business results through innovation processes and tools.

We want to hear from you. What resources did you find beneficial and why? Did you find a particular subject valuable that did not make the list? Tell us why by posting a comment below.

Happy New Year and I look forward to connecting with you in 2012!
Linda

Hopefully, you've had the opportunity to read Part 1 of this 2-part blog series. Carrie Nauyalis began our series with 3 of the top 5 game-changing tools that you can take advantage of to improve product management in your organization and make your life much easier. The last 2 tools are equally important.

Social Product Management -- "Are Product Managers going social?"

You bet we are. I follow a large number of blogs on a daily or weekly basis and post my own Tweets and blogs as well. Why? I can post questions and get great responses that help me better deliver products that I know customers want. Blogs also allow me to follow competitors, analysts and industry experts so I am first to know if there is an issue with our customers. It's amazing what you can learn about your company when you follow Twitter! Industry experts reveal predictions and the next big trend, while competitors use blogs to make big announcements. I'm not waiting for a formal press release… I want to know what's going on NOW.

Another key aspect for us at Planview in social product management is collaboration. If you're in the middle of a product development or sprint, you need to communicate with your global team at a moment's notice. What if you could click on a team member's name and instantly video chat with them to ask a question or get a live update? If you could do that from your product management dashboard, that's powerful. With Planview Enterprise, you can.

Product Management Analytics -- "What data do I need?"

The most important question a product manager can ask themselves is 'what data can I use to show we're doing our job and the product is performing as expected?' Real-time access to centralized data is crucial to answering this question and performing critical analysis.

Key data that we closely track at Planview:

1. Analysis of product backlog
2. Mix of Innovation vs. Enhancement vs. Customer Requirements of the product backlog or next release
3. Cost release that includes capacity planning scenarios
4. Revenue forecast by product and market
5. Roadmap by release, product, technology and market

So what is the bottom line? You need to be able to automate everything from ideation through launch -- and be able to see it and manipulate it in real-time. Product development is a key part of this automation. To be an effective product manager, you must have the analytics that back up each one of these stages. The impact of these 5 Game Changers in Product Management is the ability to take out the tactical, manual, day-to-day slogging we had to go through before Planview Enterprise and automate the process. Now it's your turn to be a Game Changer in Product Management!

Related post: 5 Game Changers in Product Management - Part 1

As a product line manager in charge of several software products, my job is challenging. It's a constant balancing act around delighting the customer, minimizing risk, maximizing revenue, leveraging resource availability, and about 12 other considerations. While I quite often think the pain of having to make difficult tradeoffs between good ideas, I have never had the opportunity to "measure" the portfolio that I didn't choose. That is… not until I got to participate and help facilitate a Discovery Lab called Reinventing Portfolio Management at this year's PDMA Global Conference in Phoenix.

The session was led by SmartOrg's Co-Founder, President, and CEO David Matheson who is a regular lecturer at Stanford on the topic of Strategic Portfolio Management. In his brief introduction to the workshop, David introduced the dice game. While the portfolio simulation sounded interesting and fun, I had no idea how enlightening it would be. While I don't think we "reinvented" portfolio management, I certainly gained a perspective on portfolio management that was new. And after 16 years in the portfolio business, new is uncommon, and delicious.

Through the dice simulation, we were tasked to pick a portfolio of R&D projects to invest in. But that left a collection of projects not included in the selected portfolio but that still clearly had some sort of value. Before evaluating the selected portfolio, we were told to roll the dice to calculate the success and value of the unselected projects. For my Type-A personality, this was a little unsettling on two fronts:

1. It's very disturbing to me to think that a "roll of the dice" could be considered an accurate metaphor representing my chances of success with my portfolio. SURELY, I was a much better product manager (with better assessment criteria) and way too controlling to leave things up to chance, right? Statistically speaking, given the number of project and product failures, it can be a less than certain game, especially with new technologies.
2. The second thing that was so disturbing to me was the fact that there was so much value in the projects that didn't get selected. When you think of that value going unrealized, it can be a bitter pill to swallow. I've never actually considered calculating the potential value associated with my product backlog. Ouch.

I think that the dice simulation really opened my eyes about the real risk and uncertainty we deal with daily in portfolio management. It seems that this dice game gave everyone in the class (see picture below -- such a good looking group!) a different insight or nugget to take home, based on the dynamics of their particular organization. Check out the post-class review video for some of those takeaways.

I recently did some research on how companies can take a practical path to improve PPM decision-making. I won't keep you guessing (if you were), there are some VERY good best practices that have been developed by the new product development (NPD) community. The research consists of interviews with three distinguished manufacturers in different industries, and they all concurred that the best approach is to start small with PPM and grow over time. The report, Improving Portfolio Decision-Making: Marrying PPM Best Practice Processes and Technology to Drive ROI, provides an overview on the value of PPM in addition to laying out a practical plan to leverage best practices tools and techniques to driver better portfolio decision-making and drive up company profitability.

The Research

During the research I had the pleasure of talking to several very knowledgeable PPM practitioners:

• Don Kingsberry, Enterprise PMO, Green Mountain Coffee Roasters (the man should really write a book, I told him I thought so)
• Ian McKenna, IT Business Partner, Infineum (a joint venture between ExxonMobil and Shell)
• The Manager of Quality Management, R&D, and Legal Applications for a medical device company (who unfortunately was not permitted to share his company name in the report, but I promise you I didn't make him up!)

The Value of Improving PPM

The first thing I discussed with them was why they invested in PPM in the first place. I had done some past research in this area, including Issue in Focus: The ROI of Product Portfolio Management, and thought it was important to start with the business in mind. I was very impressed with a statement from the participant from the medical device company. He saw PPM as his responsibility to be a steward for his company. How many companies would love to have that form of dedication, work ethic, and contribution from their employees? He offered that "PPM processes and tools help us be good stewards of our business. It costs a lot of money to develop products and we should do what we can to select them right and do them right -- because then we have more money to invest."

Mr. Kingsberry of Green Mountain Coffee Roasters (GMCR) has implemented PPM multiple times, and shared experiences from GMCR as well as past experiences where he says PPM has a "profound effect" and "each time I have found the return to exceed our expectations." He shared the history from one of his past experiences in a very large, well respected company saying "we cut millions of dollars of projects that were wasting time and we shouldn't have been working on. We got clarity on that immediately and had a huge multi-million dollar return in 6 months. PPM software and process help bring visibility to those things." What more can I say when people that have "been there and done that" are so positive on the value they received?

Taking the Practical Approach

One of the other key findings of the report is that too many companies overthink their PPM implementation. For some of you that know me, you might be falling out of your chairs! I am always a proponent of a well-planned, well thought out implementation. And my PPM benchmark research at Aberdeen Group showed that business processes and metrics were even more crucial to best in class PPM performance than in any other enterprise technology I have researched. So what gives? People need to understand that the goal of PPM is to provide better information, in a standard way, so people can make better decisions about product investments. Too often, even in my own experience when I ran product management for a software company, I have had people want a scoring algorithm to magically spit out an answer. Don't get me wrong, the metrics and analysis are very important. But they are just one input into a decision making process. As such, it's important to find out what information and metrics the decision-makers will actually use and trust (think simple versus black box voodoo) to make decisions.

In fact, the companies interviewed used some really straight-forward metrics that helped them make decisions. "We implemented fairly standard calculations, NPV (net present value) being an example," explained Mr. McKenna of Infineum. Don Kingsberry also suggested that based on his experience companies need to strive for simplicity, particularly as organizations get bigger.

The other aspect of simplification was to start small and grow. I heard this from every company I spoke with, they all agreed that you shouldn't do too much at once and go "big bang" with your PPM implementation. This is particularly true because companies are now integrating and extending PPM processes further into the front end of innovation and trying to develop a more integrated, streamlined innovation process. Now this is where I get back up on my soapbox about planning ahead. Just like with my "PLM Program Approach," you can start small and build -- but you had better have a plan for the bigger picture you are trying to achieve. You should also partner with a software company that can help provide the path to your larger objectives as you mature and improve. Don't paint yourself into a corner, you want to make sure your initial investments and learnings serve as a foundation for even move value over time.

Implications for Manufacturers

So what does this mean to manufacturers? First, there is a lot of value to be had from PPM. Second, you don't have to reinvent the wheel. There are very good methodologies and metrics available, and software solutions that encompass and enable them. Third, don't spend months trying to invent a process or algorithm that automatically makes portfolio decisions. That is not realistic and likely won't be used. Take the time to provide good, trusted, simple information in a consistent way so decision-makers can compare "apples to apples" when reviewing portfolios.

So that was a quick peek into some recent research on product portfolio management, I hope you found it interesting.

Note from Planview: If you would like to read Jim's full report, it is available here: Improving Portfolio Decision-Making: Marrying PPM Best Practice Processes and Technology to Drive ROI

If you've been in product management for a while, you know there are a lot of things you could be doing with your time to manage your product portfolio. But which things are the most important and effective at helping your company reach its goals.

This 2-part blog series will disclose the top 5 game-changing tools that are at your disposal and can make you a hero at your organization, not to mention make your job easier.

Portfolio Prioritization -- "Are we working on the right things?"

The discipline of Portfolio Management isn't new, but applying it in a product organization may be. Your competition is prioritizing their product portfolio so their hottest products get to market. Are you? Here are the things you need to consider when evaluating your product portfolio:

1. Will it drive revenue?
2. Does it align with our corporate and product strategic goals?
3. Do we have the resources to deliver it on time?
4. What is the risk involved?
5. How will this impact the brand?
6. Will this help us leapfrog the competition?
7. What will the sustainability impact be?
8. Will our customers be delighted?

The key is to run multiple 'what if' scenario on products, projects, programs, or features to evaluate how those align with set targets, and whether you have the capacity to deliver. There are powerful tools available to product and portfolio managers that pull all of this information together onto one central page to give executives the information they need to make the decisions that drive the best, most profitable products to market.

Resource Management -- "How do I best utilize my people?"

It's simple math. If you don't have the resources to execute, you can't deliver desirable products on time and on budget. According to our annual benchmark survey on product development, this has actually been found to be the #1 pain point for product development organizations for the past two years. Effective resource management breaks down into 3 key components:

1. Organizational capacity planning
2. Development resource planning
3. Ongoing change management to schedule and resource assignments

If you take this three prong approach to Resource Management, you can expect to achieve these benefits:

• Clear visibility of demand and capacity to avoid resource bottlenecks, reduce risk, and hit launch targets
• Forward and backward-looking resource planning to eliminate resource cost overruns
• Resource management processes that lead to consistent, proactive responses to change

Agile Product Management -- "Why should we care?"

Making the switch from Waterfall to Agile was difficult for me. I felt like I was losing control of the schedule and what was being delivered to our customers. But I soon discovered that Agile actually gave me ultimate control and flexibility as a product manager. In fact, through our Inner Circle program, we regularly show customers what's going on and get feedback from them, involving them in the decisions that need to be made along the way, so I can ensure we're "delivering to delight." But what, specifically, does Agile do for us?

• Iterative sprint cycle ensures we're delivering what customers want
Central repository for all product ideas and backlogs reduces risk and saves time
• Ultimate flexibility with stories and priorities allows us to quickly respond to change
• Testing done throughout development often leads to higher quality and met deadlines

Embrace the change to Agile. You'll come to love it, like I did.

Be sure to check back for our next blog post to learn about the remaining two game-changing tools. Louise Allen, Vice President of Product Management at Planview, will finish our series. I encourage you to evaluate your processes and tools to see if you are maximizing your product development potential.

"Why is innovation in everyone's DNA and not in every organization's DNA?" According to Darwinism, the weak eventually die and the strong, most adaptable ultimately survive. However, if that is the case, why hasn't the spirit of constant improvement effectively spread throughout the business world?

We discussed this topic and more at the recent Stage-Gate Innovation Summit in Miami a few weeks ago. The moderator of this panel was Damian Killen, managing director for Thrive, an international human resources consultancy based in Dublin. He has spent more than 20 years researching and speaking about the application of the Myers Briggs Type Indicator.

The Myers Briggs Type Indicator was developed by a mother-daughter team who built upon the findings of Carl Jung. The key principles to remember with their test are that while humans are all dissimilar, they vary in comparable ways. Understanding this concept, patterns of behavior can be determined.

Killen, with his lilting Irish accent and his sarcastic wit, proved to be an extremely entertaining speaker. He defined innovation as the implementation of creative ideas and thus, an innovative organization is one that is constantly applying ideas. According to Killen, true innovation comes through gathering and utilizing people's different strengths. The understanding and use of personality type theory can help organizations determine where, when and how best to utilize their people in order to achieve the best results.

Although there are four dichotomies, for the purposes of Killen's presentation, he focused only on Sensing-Intuition (S-N) and Judging-Perceiving (J-P) as the other two (Thinking-Feeling and Extraversion-Introversion) were found to not have a significant impact on innovation behaviors. Sensing-Intuition pertains to how a person takes in information while Judging-Perceiving deals with how someone sees the outside world.

• Sensing (S): focus is on the present, notices details, practical
• Intuition (N): focus is on the future, notices patterns, imaginative
• Judging (J): stickler for following plans and schedules, likes closure, decisive
• Perceiving (P): flexible, energized by last minute pressure, likes to keep options open

The breakout is approximately 48% SJ, 27% SP, 8% NJ, and 17% NP. You can find all of the details of this principle in Killen's book, Introduction to Type and Innovation, co-written with Gareth Williams. The basic principle is that SJs strive for outcomes and perform best in the delivery phase, SPs enjoy simplifying matters and perform best in the definition phase, NJs align ideas to needs and perform best in the decision-making phase, and lastly the NPs like to develop and generate ideas and perform best in the discovery phase. This is not to say that a personality could not do well in another area or that someone's persona cannot change over time or in differing circumstances. After all, the Myers Briggs assessment is concerned with discovering a person's preferences and does not say anything about their intelligence or abilities.

By merely understanding that people have diverse personalities and thus different strengths, organizations can build the most effective teams for their projects and rotate people depending on where the project is in its lifecycle.

An Excerpt from "New Insights for Driving Innovation in Product Development" Webcast

This is part three of my three-part series on a recent Planview hosted Webcast titled "New Insights for Driving Innovation in Product Development: Is Your Organization a Lean, Mean, Innovating Machine?" featuring Sanjeev Pal, Research Manager of Product, Project and Portfolio Management Solutions at IDC, and me. Previously, I summarized our discussion of market trends and innovation. Now, let's talk about the role software can play in product innovation.

Software as a Solution

Sanjeev recommends that companies not only use industry-specific software, but software that understands the company's processes. Generic software won't be as effective or cost-efficient. Also, this software should be used in conjunction with the lean and operational improvement principles he discussed.

We then highlighted the role software can play in product innovation. Software can manage the mass amount of internal and external ideas companies receive. It links ideas to a product. Of course, not every idea is feasible within the current marketplace. Software allows companies to save these unused ideas for the future to continue the innovation process.

PLM and how product management software can help companies throughout the entire process was our next topic. Sanjeev illustrated steps within the product lifecycle related to product innovation:

• Idea management
• Product management
• Virtual simulation of product
• Product analytics
• Supply management
• Manufacturing process optimization
• After market support

Although the process may vary, there should be a constant flow throughout the product lifecycle of innovation and collaboration. Also, this process doesn't just apply to manufacturers. Product development organizations want to know how to foster innovation and track it throughout the product life cycle as well.

Finally, Sanjeev offered his closing thoughts and recommendations. He predicts that the sluggish economy will continue and has already become the "new normal." Even if you implement several lean principles and practices, if you don't innovate, your company won't have a very secure future. He reiterates that this doesn't have to mean creating a brand new, game-changing product, but rather can occur through incremental innovation.

To hear more, listen to the podcasts on this topic at Software as a Solution Part 1 and Software as a Solution Part 2.

To learn more about the topics I've covered in this series, listen to the complete Webcast New Insights on Driving Innovation.

Related post: The Business of Innovation

An Excerpt from "New Insights for Driving Innovation in Product Development" Webcast

This is part two of my three-part series on a recent Planview hosted webcast titled "New Insights for Driving Innovation in Product Development: Is Your Organization a Lean, Mean, Innovating Machine?" featuring Sanjeev Pal, Research Manager of Product, Project and Portfolio Management Solutions at IDC, and me. Previously, I shared our discussion on trends in the marketplace. Now, let's look at examples of innovation.

Industry Examples of Innovation

Sanjeev discussed three technology companies to illustrate how both software and hardware trends are causing companies to change the way they operate in order to be more flexible and innovative.

1. Google®
   
   Google, a "constant innovator," as Sanjeev calls it, has gone from simply being a search engine to offering services such as Gmail and Google Plus, as well as the Android operating system. Google Plus isn't that different from other social networks, but is a small step towards the social network paradigm of the future. Being innovative doesn't necessarily mean you have to reinvent the wheel. Innovation is really when a company takes an existing product and modifies it to make it more unique and desirable.
   
   
2. Microsoft®
   
   The second company he covered was Microsoft, who is currently trying to redefine itself. Is it a hardware company or a software company? It's also facing a dilemma as to whether it should abandon Windows and develop an entirely new operating system or if it should just improve its existing product to be more like the competition. While Microsoft has an innovative product in the Xbox Kinect, one innovative product can't keep a company profitable for the long haul.
   
   
3. Apple®
   
   Lastly, he discussed Apple, who like Google, has evolved from simply offering computers, to having multiple product lines. He highlights the iPad to illustrate how Apple has used innovation to distinguish its product from the rest of the tablets in the marketplace. He also discussed the impact of the loss of Steve Jobs.

Sanjeev listed various techniques that organizations have used since the 1970s to streamline operational processes for improved efficiency. The techniques include:

• Just-in-time
• Total quality management
• Six Sigma
• Lead production
• Lean Six Sigma

Companies need to be constantly making operational improvements. The faster you can collect innovative ideas and determine feasibility, the quicker it will generate products people want. Not only will it improve the products, but the process to facilitate innovation consistently.

To hear more, listen to the podcast on this topic.

My final installment of this series will cover the role software can play in product innovation. We encourage you to listen to the complete webcast to hear Sanjeev cover these topics in more detail. Listen to the complete webcast.

Related post: Trends in Innovation