In part 1 of this post, I defined the aspirational builder – a type of customer who wants to build something that is wholly or largely available from an IT vendor.  While there are famous examples of world-class IT shops that succeed in building their own infrastructure, it requires an organization and culture aligned to the goal.  This post will look at two key risk factors that aspirational builders face.

Talent retention

Everyone struggles to retain key talent in an economy where your competitor wants to hire your best people.  Beyond natural employee turnover, vendor engineering organizations can fail when they allow too much key talent to leave without hiring and training replacements in a timely manner.  Successful engineering organizations have critical mass to withstand a reasonable key talent departure rate.  They have staff development and recruiting to ensure continuity in product design and development.

Aspirational builders often lack critical mass in their engineering organizations due to overall business size or other business priorities.  Managers who decide to build a new capability instead of purchasing it implicitly create dependencies on talent retention.  Choosing to build means custom implementation and maintaining in-house experts who know intimately how the system works, how to build it, how to fix it, and how to operate it.

I’ve met aspirational builders as they are setting course for custom development who have introduced me to their team who will get it done – typically one or two experts whose stated goal is to reproduce a service similar to what one of their peers atop the built-it pyramid has done with tens or hundreds of engineers.  I’ve wondered if the executives sitting next to them are fully aware of the talent retention dependency being created at that moment, not to mention the business and technical risks being undertaken.

Not infrequently, the same executives reappeared a year later in our briefing center with a new plan, sometimes with a new technical team.  Employee turnover is natural for organizations of all sizes.  Depending on the state of development and organizational structure, such departures can cause serious disruption or outright failure.  Vendors are not immune, but it’s a question of degree.

As a do-it-yourselfer, I respect the aspirational builder’s desire to innovate, be free from the vendor’s limitations, and take matters into their own hands.  As a product manager, I take the opportunity to ensure the customer understands the magnitude of their undertaking.  In doing so, I can better understand my product’s limitations and the industry forces driving the customer’s decision.  This exploration may – not always – result in that customer rethinking some their scope and choosing to use my product to reduce risk or accelerate delivery.

Personal achievement

Building custom cabinets for my home is something I do not because it is the most practical way to acquire furniture, but because I enjoy it and derive satisfaction from the personal  achievement.  Aspirational builders share this mindset whether explicitly stating it or not, creating the challenge of influencing a decision with a personal underlying motivation.

Anyone who actively manages their career thinks about how their current job, responsibilities, and accomplishments will look to a future prospective employer.  Recognizing that those atop the build-it pyramid frequently publish papers and speak at industry events, aspirational builders wish to do the same.  The desire to work in a new area or employ a new technology to solve an existing problem can greatly influence build versus buy decisions.

Aspirational builders will ultimately be judged on their delivery effectiveness; how an IT project is implemented is secondary to delivering on-time and on-budget.  A project is composed of many individual pieces, each of which has more or less achievement value.  The aspirational builder may ideally wish to build everything, but instead recognize an easier path to success by including off-the-shelf products, while preserving the key personal achievements being sought.

The product manager has an opportunity to build a trusted customer relationship by understanding the aspirational builder’s overall success criteria and respecting their desire to build key portions.  More broadly, these learnings can be applied to the broader market segment by describing a class of use cases and associating product elements with each.  The product manager may uncover product gaps – usability, functional, licensing – that, once resolved, make the case more appealing to aspirational builders.  It takes a willingness to look at the product from the customer’s perspective and critically ask what the decision would be if the tables were turned.

It works, we’re done!

Building what amounts to an in-house IT infrastructure product merely represents the early steps in a longer product lifecycle.  Day two and beyond becomes the real test, which I’ll cover in part 3.  Send me your views on working with customers’ navigate build versus buy decisions.