-
NPI: A How To Guide for Engineers & Their Leaders
-
Leading from the Front
-
Marcel Tremblay: The Olympic Mindset & Engineering Leadership
-
Anurag Gupta: Framework to Accelerate NPI
-
Kyle Wiens on Why Design Repairability is Good for Business
-
Nathan Ackerman on NPI: Do The Hard Thing First
-
JDM Operational Excellence in NPI
-
Building the Team
-
Quality is Set in Development & Maintained in Production
-
3 Lessons from Tesla’s Former NPI Leader
-
Maik Duwensee: The Future of Hardware Integrity & Reliabilitypopular
-
Reject Fake NPI Schedules to Ship on Time
-
Leadership Guidance for Failure to Meet Exit Criteria
-
-
Screws & Glue: Getting Stuff Done
-
Choosing the best CAD software for product design
-
Screws vs Glues in Design, Assembly, & Repair
-
Design for Instrumental - Simple Design Ideas for Engineers to Get the Most from AI in NPI
-
Best Practices for Glue in Electronics
-
A Practical Guide to Magnets
-
Inspection 101: Measurements
-
A Primer on Color Matching
-
OK2Fly Checklists
-
Developing Your Reliability Test Suite
-
Guide to DOEs (Design of Experiments)
-
Ten Chinese phrases for your next build
-
-
NPI Processes & Workflows
-
-
Production: A Primer for Operations, Quality, & Their Leaders
-
Leading for Scale
-
Greg Reichow’s Manufacturing Process Performance Quadrants
-
8D Problem Solving: Sam Bowen Describes the Power of Stopping
-
Cut Costs by Getting Your Engineers in the Field
-
Garrett Bastable on Building Your Own Factory
-
Oracle Supply Chain Leader Mitigates Risk with Better Relationships
-
Brendan Green on Working with Manufacturers
-
Surviving Disaster: A Lesson in Quality from Marcy Alstott
-
-
Ship It!
-
Production Processes & Workflows
-
Failure Analysis Methods for Product Design Engineers: Tools and Techniques
-
-
Thinking Ahead: How to Evaluate New Technologies
-
How to Buy Software (for Hardware Leaders who Usually Don’t)
-
Adopting AI in the Aerospace and Defense Electronics Space
-
Build vs Buy: A Guide to Implementing Smart Manufacturing Technology
-
Leonel Leal on How Engineers Should Frame a Business Case for Innovation
-
Saw through the Buzzwords
-
Managed Cloud vs Self-Hosted Cloud vs On-Premises for Manufacturing Data
-
AOI, Smart AOI, & Beyond: Keyence vs Cognex vs Instrumentalpopular
-
Visual Inspection AI: AWS Lookout, Landing AI, & Instrumental
-
Manual Inspection vs. AI Inspection with Instrumentalpopular
-
Electronics Assembly Automation Tipping Points
-
CTO of ASUS: Systems Integrators for Manufacturing Automation Don't Scale
-
-
ROI-Driven Business Cases & Realized Value
-
If it weren’t for Nathan Ackerman, Microsoft’s HoloLens may have never made it off the production line. A veteran engineer with roots in Microsoft and Amazon, Nathan was one of the founders of Owlcam and Senior Vice President of Engineering and Chief Information Security Officer at Signifyd. Nathan’s matter-of-fact approach to engineering and project management is strongly opinionated – and, most importantly, produces results.
Do The Hard Thing First
Nathan’s fundamental rule sounds simple but is, surprisingly, difficult. “Discipline and process come down to asking the hard questions upfront and doing the most difficult thing first,” Nathan explains. It’s how he managed to take Owlcam from a back-of-the-napkin design to a shipped product in 10 months – and how he raised the First Pass Yield (FPY) of HoloLens’s first production line from 0% to over 60%. “The easy stuff is always easy. What is highly unpredictable and ultimately valuable is the hard stuff.”
Do I have technology that exists today that I can assemble together to meet this demand?
Nathan AckermanFounder of Owlcam
The advice has practical and philosophical consequences. For Nathan, product development starts by identifying a need or demand. Then, he works backward. “What do I need to build to meet this need or demand? Do I have technology that exists today that I can assemble together to meet this demand?” Unless he can answer “yes,” he doesn’t proceed forward.
With this guideline, the technology must be available to accomplish your goal before you're ready to build your product. If not, you need to develop the tech first, which is generally the hard part. Marcel Tremblay’s approach to taking the biggest risks off the table first is very similar.
Nathan’s other observation is that if anyone can do the easy things, they’re easily replaceable. “The value to you and to the company and the organization is in being able to do the hard thing.”
Decouple the R from the D in R&D
Don’t try and D stuff that’s not fully R’d.
Nathan AckermanFounder of Owlcam
In other words, your ability to develop a product completely depends on the trail of technology and components that have already been researched. If that isn’t in place, you can’t move forward with development. Or, as he puts it, “Don’t try and D stuff that’s not fully R’d."
Of course, researching new technology isn’t easy, but it’s better to overcome that obstacle early on. “If you have the technology to a place where it's feasible to productize, then the actual product development from concept to mass production is highly repeatable. And all of this must work backward from the end goal first.”
Get the Right People in the Room
Nathan’s background and specialty in hardware give him a unique perspective when it comes to software. “Software,” Nathan maintains, “isn’t organized in the way that hardware is because software can be changed so easily, or at least that’s what people think.” Hardware has specific goals and completion guidelines, and moving from one stage to the next can require hefty investments. Software, however, can seemingly be updated or changed at any time. This means people tend to plow ahead without having clear goals in mind. “People think having an upfront conversation wastes time because it’s ‘really easy to change later.’”
But as anyone who’s worked in software can attest, this line of thinking can result in significant time wasted pursuing features that never make it into the final product – time that could have been saved if the right people had invested in a single hour-long conversation upfront. “One of the big sins I find in software is that people don't even have the right people in the room to talk about what you're going to deliver.”
Nathan’s advice: “The very first step for hardware development, and frankly, universally, any project, is getting the right people in the room to agree on what needs to be built.” Getting everyone who’s a stakeholder – including marketing, finance, and engineering — on the same page from the start can save weeks, if not months, and millions of dollars.
Even delaying a project by a week or catching a miscommunication in concept review is preferable to the alternative: a development cycle, followed by a possible recall if marketing and engineering aren’t aligned about the product being delivered and damage to the brand’s reputation. “But my real advice [to leaders] is to prioritize these meetings and actively engage in them [yourself] so that you can achieve the schedule you want.”
Move Slow and Break…Nothing
Ultimately, Nathan’s secret sauce to supercharging project development is a master class on efficiency and resource utilization. “The best way to improve your velocity is to make highly efficient use of your people by being clear on the most important task right now,” Nathan said. “Only spend energy and effort on the things that you actually need to build and that are going to deliver the value that you want.”
In practice, that means making sure you’ve worked out the “science” of the technology before you start development. It means getting everyone who needs to have a voice in the decision into the same room and having a conversation about exactly what it is they’re all working on. And it means having the discipline to avoid distraction and wasting time on easy features and checkboxes.
It means, at the end of the day, doing the hard thing first. And that’s no easy feat.