Value Engineering and Build vs. Rent

I’ve been writing lately about product waste: building features or capabilities that aren’t used or don't add much value.  And calling out the need for some honest discovery before we embark on major engineering efforts.

Let’s focus on a specific subset of product waste: building capabilities that are readily available from non-competing SaaS vendors – which we could rent at 1-5% of the cost of building them ourselves.  Renting (licensing) means we can put more of our own effort into market differentiators.

Imagine we’re a SaaS company selling logistics software that helps companies track their shipments, warehouse inventory, goods reordering, and time-versus-shipping-cost analytics.  Our customers are logistics companies, ecommerce players, and physical goods manufacturers.  But along the way, we need to do all of the things that other companies do: run HR; handle payroll and payables; secure our app against cloud hackers; track support issues; model system scalability; etc.

We want to invest our always-scarce development efforts in work that truly matters to our customers, or where only we can do what’s necessary.  So building our own HR system or support ticket app or machine learning platform is a poor use of our time: there are scores of commercial products for each, and our end users won’t care at all.

So a first pass at value engineering – doubling down on our core tech and market differentiation – might look like this:

And renting has the virtue that our vendor’s survival depends on their app.  They have a whole company dedicated to supporting and extending their product, and they get first-hand feedback about improvements from the broader market.  (Usually, they anticipate our next few asks.)  And we can license finished products for pennies on our development dollar, since they amortize their R&D across hundreds or thousands of customers.
This would seem obvious, but every week I discover another engineering/product organization building generic software in-house that’s not strategic to their core business.  (No ticketing system is good enough for my developers, but that’s a poor reason to build our own.)

Three main culprits I see:

[1] a variation of the Dunning-Kruger effect: the less we know about an application, the easier we think it will be to build (aka the iceberg effect: 90% of the requirements aren’t obvious).  Once we start, we incrementally discover the next issue or dependency or complexity... and then the next.  HR apps have lots of privacy and delegation issues that we don't understand until we’re deep into building.  Security monitors have complex "who do we trust to reconfigure our system?" and "is that a legitimate software update?" issues.  CRMs need to manage identically named people and handle multi-tiered organizations owned by other multi-tiered organizations.  The water gets deep fast.

[2] forgetting that we have to maintain and update the new code forever. There will always be emerging customer and business needs; new data types and values; bugs; improved logic on corner cases; deprecated tools; and so on. Everything we build will include ongoing costs for staff coverage, testing, maintenance, and cross-training for holidays or organizational shifts.

[3] overlooking that our development team (like every team on the planet) is already over-committed — backlogged on truly critical work — but is somehow optimistic that we’ll be more efficient next week/month/sprint and find time for this interesting side project.  With 8x or 14x more strategic demands than we can ever complete, low-value generic apps shouldn't make the cut.

This also plays to our egos: how hard could it be to build a weather prediction tool or a password manager?  After all, we're smarter than other teams.  

[Industry veteran Dave Taber notes that all three of these are related to The Illusion of Control, the tendency for people to overestimate their ability to control events. We worry that we can't see what vendors are doing, and don't know their plans.   Somehow, if we build things ourselves, we believe that we'll get more of what we want — even though our own people/resources are fewer; we're not experts in that application area; our focus is elsewhere; and we dramaticaly under-estimate both initial and ongoing work.]

Especially True for Infrastructure

A more subtle version of this build-versus-rent problem is with Infrastructure as a Service (IaaS) where third parties have underlying technical capabilities that are ready to deploy.  No small company should want to build its own cloud application platform (leave that to Amazon, Microsoft, Google) but it’s easy to fall into other big holes that initially look very small.

Example: Connectors

We need two-way data exchange between our logistics app and the top few corporate finance apps (Oracle, SAP, Microsoft).  Each has published APIs, and it can’t be that hard to code to them. Looking for "connector" vendors and inspecting their products is slow and uninteresting.  So one of our crack engineers pulls together a test version over the weekend…

But we’re quickly going to (re)discover that each finance partner has multiple offerings and versions (Oracle NetSuite, Oracle Financials Cloud…).  And that some customers will undoubtedly have a different finance system (Sage, QuickBooks Enterprise, Workday, Acumatica, AccountsIQ, or 80 others).  And that that we need a thoughtful architecture to manage 6 or 15 or 43 home-grown connectors.

So rather than having a plan for handling a potentially unlimited number of these widgets, we wander into hand-crafting the first 2 or 3 ourselves.  We (re-re-)learn that new customers appear suddenly with obscure finance systems; that each connector needs ongoing testing; that we have to track every vendor for updated specs/versions/deprecated features; that no two customers have exactly the same field names for financial items; etc.  And our smaller customers are choosing from a different vendor set (Xero, QuickBooks, Freshbooks, Zoho, Patriot…) than our enterprise customers.

Thinking about this as a value engineering problem, our product management team could look for companies in the connector business with off-the-shelf products.  In return for a SaaS subscription, this shifts most of the technical burden onto our vendor — who has hundreds of people focused exclusively on the connector problem.  Even at $1000/month, it’s 10x-100x less expensive than building and maintaining it ourselves.  And we get ongoing leverage from them: fixes, new connectors, version tracking, regulatory certifications, and their narrow/deep connector expertise.

This creates a strategic imperative to license tech from a company that is dedicated to that business (MuleSoft, Zapier, Boomi, Postman, Workato, SnapLogic…).  Folks who spend their days on the many-to-many-to-many problem, who make sure each endpoint works over time, and who will accept a trouble ticket if (when) something breaks.

Unless our customers will find some truly unique value from us building our own connectors (20 or 50 or 241 times), we should be renting this tech and keeping our ever-so-scarce development effort on things that differentiate us in our logistics customers’ eyes.

Example: Price Lists

Part numbers and price lists are another seemingly simple problem area that teams naturally want to solve themselves.  It should be straightforward: all we need are a series of part numbers, names, and list prices...

And then probably some bills of materials logic, to confirm what each customer actually gets.  And then an audit trail for changes, since we may redefine what’s included.  And then a way to apply or track discounts, either one-time or ongoing. And then a lookup of tax rates or VAT in every city/state/province/country where we do business.  (Who will keep our thousands of tax rates current?)  And then reports showing which customers got which products, and when their license comes up for renewal...

So unless we’re in the price list management business, we should look for an outside vendor that reasonably meets our needs. (There’s always one red herring requirement that sounds important but no vendor has – and supports the "build it ourselves" argument.  Do we really need nine levels of sub-sub-sub product numbers, or could we meet that need a different way?)   BTW I always ask vendors how quickly an average customer gets to full production:  if we need 6 months, 860 hours of consulting, and an in-house team of 3 to complete our deployment, then maybe we’re talking with the wrong vendor.

What Should Product Folks Do?

Engineers will naturally see themselves as more knowledgeable about infrastructure than product managers.  But we have an essential role to play, so should:

• Keep raising “strategic customer value” questions about generic or undifferentiated work, especially technical infrastructure.  Does that really differentiate us with our customers?  Can we rent it, including ongoing support?
• Humbly and politely push back on “seems easy, have it by Friday” optimism.
• Look at feature matrices for COTS solutions.  Notice that they have long feature lists and go much deeper than we anticipated.  Probably because their customers demand those items, revealing more of the iceberg...
• Raise the ongoing engineering staff question.  When we’re done with v1.0, who will maintain it?  Which group will build the inevitable stream of enhancements for v1.1 and v2.0 and v5.3?  What’s our annual overhead?  If Benicio or Fatima (the two people who built our tech) leave the company, who will pick up support?

Sound Byte

We're always dealing with scarcity of time, people, focus, energy.  Wherever we can, we should rent non-strategic applications and infrastructure — getting leverage from partners/vendors and their embedded expertise.