Where does a company start NPI?

Below is an edited transcript:

Jessica Ching, CMO at Product Realization Group:

Where does a company start? With all the challenges and things to be done at FreeWire, how was the starting point determined?

Jeff Rosen, Principal at JSROSEN Consulting:

Remember, when I said when I came in it was “hey, we’re ready to go. We’ve got this single source of truth, this great product, we’re just going to go take it out on the supply chain and ramp it.”  What you realize pretty quickly was that it was nowhere near that. Where you start is you have to start sticking an anchor in the ground, and that anchor in the ground–and Martin said this–and this is where I started, was that single source of truth.

Getting one product documented in a system with some amount of change and revision control, and then alongside of that, starting to build out a product life cycle process. Because without any of that you will just be swaying back and forth forever. There’s no anchor in any way, shape, or form.

For me getting going, I went in with the guidance of where to go, but it was immediately clear that there was no anchor. You can’t even go to the market to get this thing manufactured because no one knows what you’re manufacturing. For me, it’s always about the basics, which is to get everybody locked down, and as Martin said–draw that line, put that stake in the ground, stop the changes, document all of those, put a process in place to start managing that. Then at the same time, put that rigorous product life cycle process in place so that you know have you done the requirements. How are we introducing changes in this process in a logical manner. Forget NPI. All that stuff upstream hadn’t even been done yet , so for me, that was the immediate pivot.

The immediate start was putting in that base structure before, as you said, general contracting. I don’t even know if the quote was done and the house was starting to get built. No disrespect to the client.

Jay Feldis, Sr. TPM at Product Realization Group:

I’ll back that up a little further. The anchor to your anchor is the product requirements. The very first step is: what are you building? What’s your market? Do you have a market? Can you analyze the market? Can you put together a market requirements document? And then from there, have you defined what your product needs to do so that you know what you’re building? And remarkably, in many, many projects they get very far down the path without actually being sure what they’re building.

You may have a document– sometimes you do, sometimes you don’t– then you might found out that there is a document that says one thing, but the lead engineer thinks we’re building something slightly different. Or you get two different people on the team who think they’re building two different things, slightly different. These kind of problems and disagreements can end up in major disagreements and major delays as people go back and forth changing their minds about what they’re developing.

It’s not to say you should never change it, but you should have a very clear document at all times about what it is you have agreed upon as an organization that you are building. Then if you decide to change it, you change it,  and there are implications.

In FreeWire’s case, there were requirements, but there was disagreement about what some of those meant or about what they should be. We had to go through a process of revisiting those requirements so that the engineering team and everybody downstream knew what they were actually building and trying to do.

Martin Lynch, COO at FreeWire:

I definitely would endorse having your requirements documented, or your specifications. That’s fundamental, but you’d be surprised at how often you develop that and it’s completely wrong. But it’s a stake in the sand. Like I said, freeze the BOM. The BOM is composed of not just components that are functional, but components for assembly and components for tests.

A lot of the issues we had were not just engineering functional issues, but just so many saying well, but I used this screw. Well no, but I used this screw. Or I used a tie wrap. Well, why are we tie wrapping stuff down? Isn’t this stuff mobile? Doesn’t it move? You know, sticky tape for stuff that’s moving around. Just those kind of little basic things. When you freeze the BOM, it helps you answer some real fundamental questions about your product because you’re forced to answer or ask those questions and figure out what you need to do to solidify it. Getting a BOM frozen was a big, big step for us.

The other one though was the spec piece that both Jeff and Jay talked about. The founders and the original designers had a view of what the specs were. There were enormous assumptions built into those specs.  When we tried developing, it didn’t exist and it was because they either misread the specs on the spec sheet from the supplier, or they assumed something that couldn’t be assumed.

The NPI process gives you what I call a quality funnel on your truth and vision about what you’re trying to do as a company, so that when you deliver it, you’re actually true. Because engineers (I’m an engineer, right?) all love to dismiss things that we think nobody will care about or that will not be found. It’s just the nature of the beast.

You’ve got to be very careful because in a  tech company because most of the people are engineers. You’re probably not going to have a quality person or a test person, so you’ve got to be really careful and honest with yourselves and make sure that you validate assumptions. If people don’t know the answers, test until you do, or find somebody outside the company that is able to answer those questions for you.