Standing On The Shoulders Of Giants
The October Product Development Issue
Welcome to the monthly issue of this newsletter focused on product development within the chemical industry. This is where I am trying to speak directly to the polymer chemists, scientists, engineers, and the financiers of the chemical industry that read this newsletter. I'm also writing to those who hope to come work in the industry. If you want to start from the beginning go here.
This issue of the newsletter is presented by:
Starting to develop a new product is the hardest part of any project. To do it correctly you need to bring together all of the functions in your company to see the same vision, agree on the path to get there, and know which milestones to celebrate when you reach them as a team. You also need to agree on what that new product is going to be, how it’s going to function, where it’s going to be made, what are acceptable raw material costs, and what are acceptable capital expenditures. This is where the concept of design for six sigma or DfSS shines.
The most powerful tool to have at the start of any project is information. What has been done prior to your efforts and what your competition is doing? When you know what exists, what’s protected through IP, and what didn’t work in the past you can avoid those areas. Fresh perspective might be able to connect some things that had been missed previously. Knowing what has happened before you enables you to not make the mistakes that are only obvious once they are known.
Keeping a database and records of what people have done can be very difficult. Setting your product development processes up for capturing not only the R&D efforts, but efforts from the other functions such as marketing, sales, technical service, regulatory compliance, and manufacturing is even more complex. Often, this information lives in the minds of the senior members of the team. You can identify a senior member by them doing the New York Times crossword while drinking coffee or they might occasionally chime in with the helpful phrase:
I tried that 10 years ago and it didn’t work.
Some of this needed information sits on some sort of shared drive, sometimes called “The G Drive,” or a filing cabinet and unless you know the organizational system (if there is one) it feels like looking for a needle in a haystack. I once saw a system based on Lotus Notes early in my career and felt like it was miserable and outdated. I was such a fool because it was the best system I have ever seen since.
My suspicion is that large pharma companies have already mostly solved some of these issues with large chemical compound databases that can be mined with data scientists. I’m not sure when the industrial chemical companies and downstream customers will figure out digitization of their information, but it’s not due to a lack of available software. I suspect it’s due to a lack of capital willing to be invested into something where the value is not immediately obvious. This is dumb because often a big shareholder complain is:
Product development is too expensive and it takes too long
I don’t think anyone with any experience thinks a new chemical product would take any less than a year or two to make it to a commercial launch, so let’s say on average 2-5 years for a new product to be launched taking into account any potential regulatory timelines. Then perhaps an additional 1-2 years for qualification and validation of a customer so maybe 3-7 years till actual revenue, which will typically be small. Let’s add in 3-5 years for market acceptance and volume growth so now we are 6-12 years for an ROIC to be measured on an organic growth project.
Being able to document all of these product development efforts within a chemical company is really important and it could save perhaps 1-2 years in timeline if implemented correctly. So much of doing product development is with standardized rigor and when you lack good historical standardization or even a good framework to operate within then I think things will naturally take longer. You might be able to recognize this when someone with a PhD and years of experience asks you how to use a commonly used piece of equipment. These things get even worse when an employee leaves a company, especially when that employee has a lot of knowledge in their brain that isn’t written down in an easily accessed place by their coworkers.
If you lose too many members of a product development team to employee churn then you might have to start over. A team might lose some key members to new jobs. The reasons are almost always from the list below:
The new job have gives a significant compensation increase
The new job is closer to family or it is a better commute
More responsibilities in the new role
The future is uncertain here
In theory all of these things can be mitigated by senior leadership. Leadership should understand when certain employees need a significant pay increase (i.e. greater than inflation). How work flexibility or a hybrid model might make a long commute less awful. Distribute responsibilities more evenly and test if someone is ready for a leadership role. Present a crystal clear vision for the future that projects stability. Great scientists don’t always make great leaders. A good product development process that functions means that they don’t have to be.
From my sponsor: If you are a leader of a product development team trying to build a new team then consider using a recruiter like Task Force Talent. You might not have the time to train a new person and bringing in a specialist that has significant domain expertise might be the best bet to fast track development on a new product. Reach out to them today. It’s free.
If it takes a year or more for someone to become a valued contributor then I suspect that there is something wrong. If an important contributor to a project leaves and it sends the product development team back to the beginning of the process then there is something significantly wrong. I think Dror Poleg highlighted something about the War on Talent versus the War for Talent in his newsletter worth quoting here:
Corporations are fighting two wars in parallel, the War on Talent and the War for Talent. The key objective of War on Talent is to convert [unique] into [unique but interchangeable]— to turn unique talent into an interchangeable resource. The key objective of the War for Talent is to recruit individuals that cannot be easily replaced. The War on Talent is waged with technology that aggregates, monitors, and assigns workers. The War for Talent is waged with higher salaries and office perks.
A robust product development process means employees are slightly more interchangeable, but it doesn’t mean that there is an abundance of people that can replace someone if they leave. If you have a very senior person with a significant amount of domain expertise leave a company, how many people exist in the world that could actually replace them? Perhaps there are 100-200 people in the world with similar skill sets, but how many actually want to move to Columbus, Ohio to replace this person?
So why aren’t polymer scientists just making crazy money? It’s easy to understand why we might think R&D is less valued in the chemical industry. Most of the product categories are very mature.
Phenolic Resins - invented 1907
Poly(methyl methacrylate) - invented 1930s
Polyurethanes - invented 1930s
Low Density Polyethylene - invented 1933
Nylon 6,6 - invented 1938
Epoxy Resin - invented 1943
High Density Polyethylene and Polypropylene - invented 1951
Poly(ethylene terephthalate) - invented 1974
Sure, we do small iterations on these things or things related to these polymers, but it’s not like there is a huge need for synthetic polymer chemists. There are some new polymers being launched out there, but it’s not 1930-1980 right now where new polymers went to market every few years. Rather, the innovations right now come in the form of better formulation, removing cost through process improvements, and commoditizing what was once low volume high margin. Patents expire and this enables lower cost generics or me too products become widely available. These are all races to the bottom and deflationary actions.
The chemical industry is constantly reinventing itself and we have shifted from giant vertically integrated syndicates to, “purer plays.” Documenting prior work into databases or searchable archives is common sense in the chemical industry. Just because we don’t publish papers doesn’t mean we shouldn’t be writing them for internal use. Patents can serve as useful markers for knowledge, but you shouldn’t base a company’s internal confidential intellectual property on patent submissions.
Innovation is expensive and there are no guarantees that spending 3% of revenue on R&D (usually tax deductible too) will result in a home run new product. This is why established companies want a risk adjusted home run. Start-ups need to swing for the fences because they are seeking to disrupt the establishment. Something I often hear is:
Product X, which represents ABC% of this business unit’s revenue, couldn’t even be developed today. DEF and GHI would never let us spend the money on how long it took to get that commercialized, much less approve the capital expenditure. Trust me, I’ve been here for 30 years.
How easy is it to access the records of what the people were doing back when Product X was developed. Did they keep records? How do you record what you do now?
If you can’t stand on the shoulders of the giants that came before you then it's no wonder you can’t see very far. Too bad all the low hanging fruit has been picked. Time to build a ladder.
Tony
If you liked this please check out some of my other writing on the topic of product development:
Another excellent piece, Tony. Many thanks for crystallizing your perspective… which I share in full!
This one really rang true -- both the "we tried this 10 years ago and it didn't work" bit, and the "all our expertise left when X retired in 2011" bit. I would add the "we stopped writing internal reports, and now only document project results in patent disclosures" bit.