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.