My Last DFM PowerPoint (And Why I’ll Never Make Another One)

Jeremy Andrews

May 26, 2023


min read

In 2016 I landed an internship at Tesla as a mechanical engineer, where I got to work on the Model 3 program. I’d always wanted to work in Silicon Valley and was interested in the automotive industry, so it felt like a dream job. Electric vehicles (EVs) brought about new engineering challenges that were particularly fascinating for me, so I was excited to enter Tesla and be part of working on the solutions. When my internship finished, however, I left Tesla inspired to tackle a different set of challenges… I wanted to rework the entire engineering design process.

During my internship I was responsible for designing several plastic injection molded parts for the Model 3 battery pack. I started going through the Design For Manufacturing (DFM) process, to kick off soft tooling for limited production runs of my parts. Our team needed to collaborate closely with the supplier which involved a lot of detailed communication using PowerPoint decks and email. Essentially we had to constantly update and share the same PowerPoint deck back and forth as feedback and revisions were exchanged. Internally, the process for communicating and solving design challenges was much the same.

So, although I was working at one of the most prominent engineering companies in the world... I realized that basic digital communication tools (PowerPoint, email, spreadsheets, etc) were still the universal standard for mechanical engineering collaboration. Being familiar the tools used in the software world, like GitHub and Jira, this came as a surprise to me. Software engineering seemed to be decades ahead of mechanical engineering. And, being a millennial, I’d already gotten used to modern collaboration tools like Google Drive, Slack, Asana, GrabCAD, and so on. I didn’t have the historical context to think, “This is just how it’s done.” And I couldn’t accept that mechanical engineers didn't have a better way to collaborate.

If collaboration was still happening largely via PowerPoint, even at Tesla, I knew it had to be because the right tools simply didn’t exist.

The Problem with PowerPoint as an Engineering Tool

Before I explain how I’ve managed to spend the last few years of my career avoiding PowerPoints decks, I should explain how I arrived at such a “dramatic” decision.

During the DFM process, creating an initial PowerPoint deck to communicate my design intent was painful. Sharing the files was painful. Receiving and interpreting feedback in PPT format was painful. (Particularly when language barriers were also present.) Providing my responses on resolved issues was painful.

Overall the process was — you guessed it — painful.

And it was slow.

My team lead, and various collaborators within the supply chain, were constantly emailing status checks or asking for information I couldn’t even provide yet — things they would’ve known, if they’d had better visibility on the process.

Multiply this by the 3 parts I was responsible for, then by 5 for the number of people on my team, then by 100 for the approximate number of teams on the program… I had to wonder: what impact was this having on the product? On the delivery date? On the company as a whole?

I suspected this was not a “Tesla problem,” but rather an industry-wide problem. What I’d noticed was a gap in the modern toolset for mechanical engineering teams. They were being held back by:

  • Low-tech processes (STEP exports, emails, slide decks, spreadsheets)
  • Slow design cycles (eg: taking several months to go from feature complete to manufacturable)
  • Poor visibility for all involved, which created extra work for engineers and team leads alike

I wanted to fix it. I wanted to improve this process — not just for myself, but for all mechanical engineers. And I decided  I never wanted to make another DFM PowerPoint again.

How a “CAD Plugin” Evolved Into a “Design Review Portal”

I started talking about it with another mechanical engineer, Adam, who had recognized the same problem. We wanted to know why nobody had found a better way to share and review designs among teams, suppliers, and other stakeholders. And, eventually, those early-days conversations led to the creation of CoLab.

At first we started working on a CAD plugin. The goal was to create a way for two people to edit an assembly file at the same time. We talked to a ton of awesome engineering teams about the idea as we started designing and building this plugin. At some point, we started mentioning another idea. We initially called it a design review “portal,” a place to share your completed assemblies for supplier feedback after you’d collaborated on them internally.

While the CAD plugin was something people found cool and interesting… the design review portal is what started getting them excited. The reaction was more tangible, more emotional. Engineers could immediately connect the portal concept to the pain points they were currently experiencing, or ones they were all-too-used to experiencing, that painful process of trying to share and review CAD data with suppliers or other third parties. Just like what I’d experienced.

So we pivoted.

We built CoLab 1.0, a minimum viable “design review portal.” It was a way to share and view CAD files in your web browser, with the ability to provide feedback by creating issues (without creating a PowerPoint). It wasn’t as sophisticated or advanced as we wanted it to be, but it was our first proof that we could actually build something to make this process easier. And, more importantly, that this was something engineering teams wanted.

CoLab 1.0

Building Collaboratively (And Starting Over From Scratch… Twice)

CoLab 1.0 gave us the reassurance we needed to believe we were onto something. But once we had that proof of concept, we knew we needed to go back to square one and start building out a more comprehensive solution. So along came CoLab 2.0, with even greater collaborative power. It was a more comprehensive and more secure replacement for design processes reliant on STEP files, PowerPoints, emails, and long meetings. Moving beyond what we started with CoLab 1.0, we added a dashboard, reporting tools, and an early version of a 3D presentation tool that we called the “Review Planner.”

It wasn’t perfect. But it was a big step up from CoLab 1.0, and something engineers could truly start incorporating into their workflows. To date, teams around the world have used CoLab 2.0 to share, review, and collaborate on thousands of 3D models and drawings.

CoLab 2.0 gave us the chance to learn from our customers and to build our product collaboratively, with input from hundreds of engineers. We incorporated all that feedback along the way, continually improving our software. But eventually we realized it was time to go back to square one… again. We had come to a fork in the road: we could keep iterating on CoLab 2.0, or we could start over and build our dream version of the product.

CoLab 2.0

And now — after almost a year of designing, building, testing, and iterating — CoLab 3.0 is finally here. 

It wouldn’t have been possible without so many engineers taking the time to engage in conversations with us and provide their raw opinions on what was working, what wasn’t working, and where they believed this should go. As more and more teams get up and running on 3.0, we’re continuing to roll out updates that improve the user experience. Over the next few months those updates will include our new LEADR design review process, an improved 3D presentation tool, better sharing controls, real-time feedback, Kanban boards, and our first-ever PLM integration with PTC Windchill — among other improvements and additions!

But this is still really just the beginning. Thousands upon thousands of mechanical engineering teams out there are still using email, PowerPoint, and exported files to share, review, and collaborate on design. And we're still focused on a mere slice of the engineering process, even though design review isn't the only pain point that needs a better solution. With 3.0 we’ve set the foundation to completely rethink more than just design review. We’re on a mission to revolutionize the entire engineering process.

I can hear what you might be thinking: “Whoa, hold on, Jeremy! The engineering process wasn’t cooked up overnight! It’s rooted in decades, if not centuries, of innovation, achievement, struggles, failure, iteration, and learning. It's complex for good reason. We work on mission-critical things. Sometimes lives are at stake!”

I get that. We get that. Rethinking and reworking this process is going to take time. It will also involve years of innovation, achievement, struggles, failure, iteration, and learning. But we’re prepared for that. At CoLab we value the processes that got the engineering world this far — yet we also believe that engineering teams can build a better future, even faster… and we’re already seeing the results that prove it.

Let’s Kill Off DFM PowerPoints For Good

There’s a lot of work left to do before we can fully and completely replace PowerPoint decks in your workflows. Before we can provide a collaborative design review system that meets all the needs of design teams worldwide. Before we provide a truly seamless level of global collaboration with manufacturing hubs like Asia and South America.

But on our journey from CoLab 1.0 to 2.0, and now with the launch of CoLab 3.0, we’ve been steadily taking steps toward reinventing the engineering process and bringing it up to speed with the 21st century. We’re constantly taking step after step on our path to unlock the true potential of effective, worldwide engineering collaboration.

And every day, we get one step closer to YOUR last DFM PowerPoint deck. 

So why not join in?

April 22, 2021

More from 



View All