Nathan Ackerman on NPI: Do The Hard Thing First

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.”

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

Building off his perspective that development can’t proceed if the technology isn’t available, Nathan treats research and development as two distinctly separate things – and successful engineers need to know the difference. “Research turns science fiction into science fact,” he says. It takes an idea and makes it deployable. Development, however, is essentially “debugging assembly challenges and putting all the individually working pieces together.”

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.