7 Tips for Building Hardware with the JDM Model
There are a lot of ways to approach developing and manufacturing a hardware product. You hear a lot about CM, OEM, and ODM, so I won’t rehash those here (but read this post from Mindtribe if you need the primer). But, in addition to these three, there is an increasing popular fourth method – the Joint Development Manufacturing (JDM) model.
The JDM model has very little documentation online. In fact, a Google search returns only two relevant results.
Slim pickings out there
The second is the more useful of the two, a roundup of hardware manufacturing methods by Fabrizio Guerrieri. Fabrizio says:
“In the Joint Development Manufacturing (JDM) model, the outsourcer and the outsourcee work together on the design and manufacture of the product.”
That’s the crux of it there. Unlike the ODM or OEM model (where you are generally white-labeling an existing product or assembling a commodity product from existing blocks), or the CM model (where you’ve done all the design work in house, and are now tapping a third party to help manufacture it), the JDM model is about collaboration from start to finish. A hardware company generally kicks off the collaboration with a detailed specification for a product that can’t be built with off the shelf parts. The JDM will then set about designing the product, all with careful input and oversight from the outsourcer. The two teams will work together to navigate tradeoffs, obstacles, design revisions, testing, factory flow, and more, until you have a shipping product.
Let’s go back to our Google search. The first result was a brief edaboards conversation from 2012, where the original poster is a job seeker expected to have “knowledge of JDM.”
poor guy
It’s too late for me to help buenos from Sunnyvale, California, but today I can share some of my lessons learned from two years of working with the JDM model at Cisco Meraki.
Lesson 1: Make your expectations crystal clear
As I mentioned before, the JDM model usally begins with the hardware company writing a detailed description of the product they want to build. I can’t emphasize this first piece of advice enough – make this description as detailed as possible. Obviously you’ll include things like:
- What does the product do?
- What does the product look like?
- Major mechanical requirements (how does it assemble/mount/clasp etc.?)
- Major electrical components and a block diagram
But are you including things like:
- What are the exact performance requirements for sensor accuracy, Bluetooth range and throughput, audio fidelity, battery life, or whatever else is critical to your product’s user experience?
- Exactly what kind of drop test, vibration test, and other reliability testing should it pass?
- What kind of temperature range and other environmental factors should it operate properly in?
- How much power is it allowed to consume?
- How hot is it allowed to get?
- What are your precise cosmetic standards? Are small cosmetic deformities allowed? What kind of gap between the parts is allowable in the assembly?
Take the time to describe in detail, up front, everything that your products need to be and do and perform and appear. Taking an extra week to perfect your product requirements document will save months of time in late-stage product development iterations because your beta test revealed major product weaknesses or oversights.
Lesson 2: Stay plugged in
A detailed PRD is no reason to check out after the project gets kicked off. The fun is just beginning. The next year or two or more of your life will involve navigating the tradeoffs and unforeseen challenges of developing a new hardware product. More than anything (except maybe the PRD), it’s skillfully navigating these tradeoffs that will make sure you end up with a product that performs well, looks great, is usable by your customers, is sellable at a price point that will enable business success, etc.
I suggest a weekly conference call and regular visits (every 6-8 weeks at least). Be especially ready to visit more frequently when you’re defining and validating manufacturing process (late DVT through PVT).
Lesson 3: Ask a lot of questions
Often the team at the JDM will include experts in their field with deep experience developing the type of product you’re working on. Realize that they will know more than you, and have the humility to inquire when working through issues you’re not familiar with.
I spent my first few months working with JDMs pretending like I knew what I was talking about in areas outside of my expertise. Not only did this make for unproductive meetings, I was passing up a great learning experience. It wasn’t until my boss encouraged me to ask questions that I dropped this facade. I had a mechanical engineer at one JDM teach me all about plastic defects, and an RF team at another JDM explain Wi-Fi testing principles. This helped me grow as an engineer and program manager, and (once I had some idea what was going on) also enabled the JDM and I as a team to better navigate obstacles.
We're all scared of raising our hand. Do it anyway.
Lesson 4: Encourage transparency and collaboration
Your relationship with your JDM team will be what you make of it. You can either be the hard-ass client in the room making demands, or you can represent the perspective and needs of your company in a collaborative way. I recommend the latter approach. Everything gets better when your JDM team is happy to see you and talk to you. Most importantly, this will encourage them to be open and honest with you.
Think about it. You want your team to feel comfortable pushing back on you when you make requests. You want them to explain why you should use the expensive component instead of the cheaper one (because sometimes you should!). You want them to explain why you should accept a bigger gap spec than you initially wanted (probably so it won’t tank your yield rate). You don’t want them to say “ok” and walk away, knowing that it will make for a worse product.
Lesson 5: Teach the JDM how you think
The best way to eliminate problems before they even happen is to teach your JDM how you think.
When there’s a tradeoff to be made, don’t just make the call. Instead, explain to your JDM team why this is a problem, how you evaluated the possibilities, and why you came to the conclusion you did. Over time, this will teach your JDM team to understand your priorities as a company and how you make decisions on behalf of your company. This is invaluable, because this empowers your JDM team to start recognizing, evaluating, and fixing problems before they even occur.
As a program manager or engineer working in the JDM model, there’s nothing more gratifying than getting an e-mail from your team saying “hey, we saw this thing coming, figured it might be an issue for you, here’s how we’ve already fixed it, sound good?” This is the kind of thing that gets the right product shipped on time.
Lesson 6: Find a champion in the room
You’re probably seeing a pattern here — building a healthy and productive ongoing dialogue with your JDM team is key to project success. But, this can be tough. Sometimes there is a language barrier between you and most (or even all) of the team. Sometimes the team just doesn’t seem to “get” where you’re coming from with your requirements and requests.
Whatever the reason, it’s important to find a champion in the room. This is someone you can rely on to understand what you’re saying, and help you communicate the meaning and spirit of your intentions to the rest of the team. Ideally, your program manager equivalent on the JDM-side plays this role, but it might be different. It might involve approaching your JDM management and making sure a strong English-speaker joins all your phone calls and meetings. It might mean finding that one engineer who’s excited when you ask them to push the envelope, and asking for their help driving other investigations as well.
Lesson 7: Treat the JDM as a partner
Even when you’ve achieved a strong working relationship, it’s easy to see the JDM team as a service provider. Try to avoid this. Instead, treat them as a true partner in the product development effort. Thank members of the team when they deliver an excellent test report. Congratulate the team when you pass a major product development milestone. Emphasize the goal of your company and your project often – the problem you’re solving, the people you’re solving it for, the impact it’s going to have on people’s lives. And of course, how it’s going to sell like hotcakes!
Service providers do what you ask and walk away. A partner pushes you to develop the best product possible, sources ideas for the next generation of the product, introduces you to other partners who can help you both. Building a partner is a great investment not in just project success, but company success.
This is just the tip of the iceberg. I brainstormed 15 lessons in 5 minutes, and then wrote until I got tired. Additionally, I expect to learn much, much more as I continue to work in the JDM model. Still, if you’re new to JDM, I hope these tips will help get your project started on the right foot. It’s a great way to build hardware.
