Thanks, but I’ll build it myself (Part 1)

Soon after seeing a product I would like to have at home, my thoughts rapidly turn to evaluating if I can build it faster, better, or cheaper. The thought of building it myself, to my specifications is a temptation I have given into on many occasions. The DIY Network was made for me!

Are my decisions “correct?” To be honest, it depends on my success criteria. The enjoyment/hobby factor weighs strongly to the positive. Home-built projects usually (not always) cost me less than buying off-the-shelf. Quality varies according to the importance I place on the finished product, how frequently it will be used, and whether it will be on display. Custom cabinets are used everyday and are readily visible. My home-built vacuum forming machine is used rarely and stored in the garage. Time, however, is not even close. The cabinets took me weeks to build and the vacuum forming machine more than six hours. Taken alone, converting time to money using reasonable hourly rates makes my endeavors look dubious. Of course, I build because I enjoy building.

Throughout my product management career I’ve seen IT professionals make their own build versus buy assessments. Many are definitively in the buy camp. Whether for lack of interest, time, expertise, or something else they make no pretenses about building custom IT systems. These customers want to focus on their day job and not divert attention and resources to building what can be reasonably bought.

A few IT shops have world-class IT engineering organizations and the conviction that they can reliably and repeatedly build systems to their own specifications with better overall outcomes than buying off-the-shelf. Those success criteria may be overall cost, but more often it is something more. These organizations view IT as a business advantage more than a cost center, believing they can deliver new services faster and better by building their own systems. Their engineering teams rival or exceed the capacity of many IT vendors. They have a critical mass of talent sufficient to attract, hire, and train new talent. Their scope allows for career development and advancement on par with vendor engineering departments. They routinely publish research papers, file patents, and share their progress as guest lecturers, in blogs, or at meet-ups.

The aspirational builder

That leaves a set of IT organizations in the middle who appear to want to build much of their IT landscape, but struggle to reliably and repeatedly generate business value from their efforts. I’ll refer to this type of customer as the “aspirational builder” who often has most of these characteristics:

  • Fortune 1000 organization with strong buying power
  • Capable engineers and managers on staff who keep up with industry trends
  • Share their accomplishments with others
  • Vision to offer new services where IT differentiates the business

I see familiar aspirational builders at industry conferences and sit in the same sessions listening to their world-class peers discuss their latest project. Seeking to emulate their peers, aspirational builders set out to create systems of their own while avoiding the marketing efforts of IT vendors, who intensely compete for their high-volume business.

Surely, IT vendor products are imperfect and vendors have been known to oversell a product’s capabilities and benefits. Given such risks, why shouldn’t the aspirational builder create their own system? When something goes wrong, engineers are already on-site, rather than having to wait for the vendor to respond. IT problems often reach across vendors who point fingers at each other to deflect responsibility. Furthermore, in-house development may allow the aspirational builder to purchase commodity products at lower capital cost, helping to defray development costs. Slam dunk!

Product managers should understand and respect three key factors I have observed that influence aspirational builders, the goal being to develop relevant products and meaningfully engage these customers:

  • Talent retention
  • Personal achievement
  • Product lifecycle

Part 2 of this post will begin to explore these factors that heavily influence the success of any organization choosing to build core capabilities. Any type of organization can theoretically manage these things, but lack of awareness can be a critical stumbling block. Send me your views on when IT shops should build or buy.