Below is an edited transcript:

Jessica Ching, CMO at Product Realization Group:

How do you manage the resources needed to support NPI?

Martin Lynch, COO at FreeWire:

I don’t have a good answer for that. It’s very, very tough. We were well-funded, but even in a well-funded company like FreeWire, you can always run out of money. In some sense, perhaps we over hired a bit and rotated pretty hard in that direction. But now we got a product out, and now we’re delivering, and now we’re scaling. We still are manufacturing in-house, but we’re very close to closing a contract manufacturing contract now, and awarding our business, which is good to get that partnership. I don’t think we could have done it without our operations maturity.

You’re going to have to make some very tough choices on your budget– how many engineers you’re willing to accept on the team, how many hours a day you’re going to go to work, which we all do in startups. You’re kind of working all the time. You’re going to have to bring in some good people that really understand what it takes to go test a product, manufacture it, assemble it and test it. That’s really fundamental to NPI.  If you can’t build it, it’s (nearly) worthless. You’ve got to be able to test it. You will need some help on the product side. You will need somebody to really validate what you’re doing as a company and make sure that the product intentions you have are in fact being met by a market that’s willing to accept what you’re delivering to them and the compromises you make. You’ll make half a dozen– you’ll make a dozen compromises and NPI will change things. We had to make massive changes to get things going, and it’s a tough deal. I don’t have a clear answer for you.

Jay Feldis, Sr. TPM at Product Realization Group:

So my approach to this goes back to project planning.  There are the processes and steps to do a product. There’s a lot of stuff documented on this. The problem is is that if you try to do every single thing you theoretically should do and should test, it’ll cost you gazillions of dollars, right? It’s not realistic. And you’ll never ship. Infinite resources, infinite dollars.

When putting the project plan together, you’ve got to think about what your limitations are and what your priorities are. Generally the trade-offs are schedule, cost, and the feature set of your product. If you haven’t done a plan and you’re kind of winging it, you don’t really know where your boundaries are on those things. You may not know if you’ve overspeced it. Maybe it’s not achievable within your budget or your time, and all of these other factors.

One of the main things you do when you put together a plan is you put a stick in the ground.  You plan it out and then you look at it and you say, “Hey, this is going to take six months longer than we thought and cost a million dollars more than we thought.” At that point, you have to step back and ask, “are we doing the right thing?”  You can only squeeze so far. That’s where you start making compromises and judgments. you say, well,

“Which of these process steps do we really need?”

“Which of these do we really need to test,?”

“Which we can take a risk on?”

“Do we need to scale back some of our feature requirements?”

“Do we need to find more money so we can speed things up?” or

“Do we need to take more time so that we can do it right?”

The important thing is that early on, you’ve looked at this. That’s what a TPM does for you.The TPM breaks down those details, and then presents them to the team and to Martin.  I know you want it by December. Here’s the things we’re up against. Here’s the other options we have to make to get there. We may have to give up this particular design change you want , or we need to get a person in ASAP to do this particular function. These are the detail workings of the planning process. It helps you manage that as you go. You can make the greatest plan at the beginning, but t’s going to change. Things are going to go wrong, so you have to be always on top of what is going on and be ready to respond and make those changes in an informed manner when things happen.

Jeff Rosen, Principal at JSROSEN Consulting:

Getting the resources in place is very difficult. The most important thing you can do is create  some amount of operating structure– Martin was really adamant about this from the get-go when he started. It scares people. People want to be able to free-flow and do what they want, but you need the  efficiency of those resources because you never have enough resources. You never have enough people. So how you utilize resources efficiently is the most important thing because you’re always going to be running around looking for more resources.

First and foremost, it’s a basic operating structure, program teams, clear roles and responsibilities. The immediate thing that Martin put in was a structure, and then separating teams so there wasn’t this ridiculous cross-pollination and confusion. You’ve got to put some structure in place, and quickly. You cannot let the chaos go for long periods of time. There are some people that say that chaos is good and chaos helps innovation. NPI and chaos are not necessarily things that go well together.

The second thing that I will add is that there are always areas in your company that you will hire experienced people on and you have to make your choices. And more often than not, you will make very important decisions about your technology and the experience in the people and the engineers you hire. I would advocate for hiring experience in the NPI process– you don’t want to be learning this one on the fly. You need some capability and some experience, as Martin said– people who’ve actually shipped products and gone through it. It sounds like motherhood and apple pie, but it’s not a place for learning on the fly.


I’m a very, very strong fan of structure. That feels opposite to engineering sometimes. We all want to be creative,  and we [FreeWire] were impulsive. For example, I get this idea hanging out, eating breakfast. I come in to work and want to make it happen. But what I urge you to do is is when you’re trying to get that product to mature, and you got an idea, sit down and talk about it — whiteboard it and structure it, so you’ve got a good understanding of the trade-offs of what you’re trying to do.

We had a ton of impulsive people at FreeWire, just making changes all the time. I have a saying, “If you change it, it will break.” You think, “I got this great idea. It’s going to work. It’s going to fix all these problems.” It will. And it’ll create 10 more. To add on what Jay said,I’m also a very, very strong believer that somebody’s got to own the program. You’ve got to put a program manager in charge, like Jay.

I always broke it  [the product] down into five metrics. It was cost, quality, manufacturing, schedule, and budget. We would constantly recycle those five objectives. Quality, by the way, means that the product meets its specifications and it’s reliable. It’s an engineering requirement. It’s just not, hey, when I put it in snow and rain it’s going to work. It means it meets the spec under conditions that the customer will operate it in, and that it’s a reliable product.


The concept of creativity and how you manage too much or too little creativity came up. My experience with this is to think of it as your process as a funnel that you are going throughl. At the early stage, when you’re just conceptualizing your product, it’s wide open, right? You can change anything you want because it’s only on a piece of paper. But as you go through NPI processes, you go through each step, we call them gates, where you decide whether you’re going to go ahead and prototype, and then you can decide you’re going to go ahead and tool, and then you decide you’re going to go ahead and manufacture. You have to narrow that funnel, and your room for creativity has to reduce. So it’s about the time and the place.

Early on, create like crazy. When you’re trying to get ready to ship, the only thing you should be creative about is how am I going to get this shipment to go faster,  not how I’m going to change the design. When we have to do brainstorms, let’s say you have problems. It’s very good to bound it. For example, you might say, “Okay, you guys need to go work on solving this problem creatively. You’ve got a day, a week, two weeks, something. Then we have to be done with it and we’re going to go with the best solution you have.” So you allow the creativity, but you set a boundary so that it doesn’t take over your project and throw things out of control.


I’m going to put a little plug in here. From what you all have told me, this is a process that’s highly dependent on educated judgment and expertise– and some deep technical expertise– while you’re doing many things at once. You probably work on your current product as well as your next, and you need resources all the time. I know that Product Realization Group placed six temporary consultants from anywhere from two to seven months, and also two full-time hires, which helped this process [NPI] happen,. In addition to all of the technical boundaries and the lessons learned that we have from here. So that was a great insight on how to manage the resources.