Buy vs. Build: The NIH dilemma

Build vs. buy, the classic dilemma, pitting tech prowess versus priorities. Never a clear decision, it is worth weighing carefully by product management

The Dude checking in here to weigh in on a classic dilemma: Build vs Buy. The Dude has worked for several companies, and has battled with the NIH (Not Invented Here) mentality. 99% of the time, the Dude recommends and pushes to acquire technologies that already exist that are not part of our core competence.

One place he was, a design for a microscope X/Y stage was created. Instead of using one of the off the shelf motion control packages (Galil, Aerotech, and Rockwell, among many fine packages available), the EE’s thought they could design a better system. 9 months, over $40K in prototype and design revisions (not to mention the salaries and loaded costs of these two EE's), it “almost” worked. But it was hyper sensitive to component tolerances (LRC feedback loops, hysteresis and ringing noise in the circuits), it was judged a failure, and an off the shelf solution (at a total cost of $400 per system on a $150K instrument) was selected. Had the Dude been the product manager of that product, he would have bitch slapped the engineering team for wasting so much time and money to feed their egos.

However, buying technology has pitfalls as well. In the Dude’s current gig, way prior to his tenure, there was a need for an image viewer. The team at the time (circa 2004) found a 3rd party viewer with the needed attributes. The licensing cost was reasonable, and the company, while being small, had been very responsive to our needs. Really a win.

However, you really need to keep track of these little technology partnerships. Companies change, go out of business, or, as in the case of this vendor, be acquired by a quasi competitor. Back in May, the 3rd party company was acquired by a semi competitor. When it came time to autorenew the contract (as part of the terms), they told us that we needed new paper. And the new price? About 9x the original price.

Naturally, for something so simple, I do not want to absorb such an increase. Fortunately, my dev team has been understanding, and we were able to stand up a native, home grown replacement, and I was able to decline to renew the contract. But it could have easily been a disaster.

Things to keep an eye on:

  1. A partner today who behaves well may not always be the same. Keep an eye out for changes in ownership, and/or business bankruptcies. Periodically review the agreements, and know the terms.

If something is core to your product, consider keeping it in house. You really don’t want to be beholden to some small company that can become flakey.

If your devteam behaves like they have an NIH attitude, question them at each step. If they are too willing to outsource components that feel core to you, challenge it.

When you evaluate options to include, make sure you have 2 or more to compare. Keep some knowledge of the runner up. You may need to transition to them.

If you work for a larger organization, you may have a 3rd party technology team. Get to know them. They can help you negotiate a better deal, and avoid vendors who have poor trackrecords.

The Dude needs to write a version of this about wading into the Open Source sea. Or not. But it can be a harrowing adventure, enormous benefits, and some barely submerged hazards. Again, it all depends.

Like what you are reading? Subscribe now to get notified via email for new posts. Always free. Click to Subscribe

Loading comments...
You've successfully subscribed to The PM Dude
Great! Next, complete checkout to get full access to all premium content.
Error! Could not sign up. invalid link.
Welcome back! You've successfully signed in.
Error! Could not sign in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Error! Billing info update failed.