In part 2 of this post, I wrote about two key factors that influence aspirational builders – talent retention and personal achievement. Accounting for ongoing maintenance and updating of custom systems can be a challenge not only for aspirational builders, but for vendors as well.

Product lifecycle

Vendor engineering organizations succeed by building products for many customers.  This leads them to design products for multiple use cases and degrees of scale. The product lifecycle accounts for deployment, support, patches/repairs, and upgrades in varying environments. These responsibilities contribute to customer perceptions that some vendors take too long to deliver on their requests. Product managers can make the mistake of building too many features and unwittingly fail to satisfy any customers due to a lack of focus.

IT operators succeed by deploying new services quickly to their business’ specific requirements. This leads them to evaluate the task at hand and implement exactly what is needed. Though they will sometimes be given latitude to think further ahead or to build for multiple services, urgent timelines and thin budgets often make these unaffordable luxuries. While this behavior can yield rapid prototypes or production systems that fulfill the need of the day, long term flexibility can be overlooked. IT operators may find themselves rebuilding from scratch rather than leveraging past efforts as the cycle repeats.

When IT operators do approach building a longer-term solution, lifecycle considerations and multiple use cases require time to incorporate into the design process. It took me longer to build my custom cabinets than a professional cabinetmaker would have required. The cabinetmaker has all the right tools and builds cabinets every day. I have some of the right tools and build a cabinet every few years. I’m simply not going to be as timely in replicating the cabinetmaker’s work. IT operators face the same relationship with vendor engineering organizations. The business imperative to quickly deploy a service to specific requirements takes priority and results in inevitable trade-offs.

Product managers regularly encounter situations where the product nearly matches the aspirational builder’s requirements, but somehow falls short. This forces the aspirational builder into a choice of employing workarounds until a new version is ready or building some portion themself. Rather than trust that a future version will address their needs, the aspirational builder may instead say:

“All I need is this one thing. I’m sure we can do this faster than the vendor.”

The aspirational builder may be correct. Yet, I’ve watched such customers underestimate the scope of work on multiple occasions. (To be fair, we all make mistakes sooner or later.) As the cabinetmaker observes daily variations on customer orders, raw materials, and tools and continually adjusts the manufacturing process, vendor engineering organizations do similarly.

While the product manager needs to respect the aspirational builder’s timeline and requirements, there is an opportunity to better understand their business requirements and use cases to identify alternative implementations that are cost-effective, timely, and that will make the customer successful. Often, it is not what is scoped to build, but what is missing from that scope that results in difficulty.

This is a great product management opportunity to build trusted customer relationships by getting out of sales mode and letting the conversation go wherever the customer’s success criteria take it. Each side has access to information the other may not possess. Customers have the benefit of speaking to multiple competing vendors, each helpfully pointing out flaws in others’ strategies. The product manager has the benefit of speaking to many customers and engineers, learning about how others are approaching the same use cases and where subtle pitfalls lie.

The buy argument

Making a case to buy requires the product manager to walk in the aspirational builder’s shoes and recognize legitimate reasons why the customer should not buy the product. This is a time for less marketing spin and more accurate analysis of the benefits and downsides of building what can, at least in part, be bought. If the customer is already biased towards building, marketing spin will be detected quickly and used as proof that buying is not in their interest.

Increasing the aspirational builder’s awareness of the long-term lifecycle dependencies in building and identifying which portions of the product are not required increase buy argument credibility – rather than trying to sell everything. The product manager has to be willing to cede some territory to build trusted customer relationships. When working through salespeople via collateral and sales tools, the product manager has to enable the same type of relationship by training the sales team on how to identify scenarios that favor buying or building and engaging the customer as appropriate.

Regardless of how individual customer engagements turn out, product managers have valuable opportunities to improve their products by adapting to new use cases for all types of customers, including aspirational builders.

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.