Distinguishing Make-to-Order versus Engineer-to-Order Service Businesses

Service businesses often begin by displacing the internal development or employment of a skill. For example, “I’ll hire you to shovel while I move on to this other thing.” As the sophistication of the skils move up the intellectual stack the singular skill is often replaced with judgement balancing across multiple skills. For example, “I’ll hire you to advise me on this new situation.” The result of this still basic need is the foundational elements of an engineer-to-order service. Each situation is uniquely fit to each customer.

Some service businesses like consulting, law and engineering remain in the engineer-to-order category forever. Some of them grow quite large and employ specialists that are fit together in operationally unique ways. The sales workflow is usually differentiated by involving project leaders earlier in the customer onboarding experience. Project scoping and workshops can be extremely valuable to make smooth handoffs to the team of experts. Apprenticeship programs develop to replace the experienced professionals in time.

Other service businesses develop templates and kits which the customer configures for their needs. In this way, the grouping of like-kind customers enables the business systems to harden around specialized use cases for the given niche of customer problems. The design of the templates is where the engineering takes place. The solution design is usually best led by the sales leader rather than the operations leader. This is not always true but the frontline typically has more insights on the repetitive work that could be handled more programmatically.

Prior to Little Engine Ventures I started a consulting business that I quickly turned into a make-to-order business model. While I enjoy encountering new problems that require new solutions, I prefer to build systems that can handle like-kind problems at scale. Then, let the humans add their unique touch on-top-of a nearly-complete solution. In this way, as the business owner, I could build machine-enabled, super-human, problem-solutions. This pathway of specialized, machine-enabled tools and systems to extend human talent led me into software, which led me into software-as-a-service.

I bought two engineer-to-order consulting businesses and converted customers to make-to-order SaaS. This was a pretty cool journey. Customers and owners won big. Fewer people were able to make more money. We eliminated waste and improved outcomes for those involved. It was with this backdrop that I launched LEV. Let’s do something like that again.

Our challenge is the playbook to convert an engineer-to-order business to a make-to-order business is unnatural. It’s akin to the boxer lifting his backward stepping foot. You can learn to do it but, it requires hours in the gym before it becomes second nature. I am working up a “How to convert an engineer-to-order business model to a make-to-order business playbook.” However, it’s not yet complete. Let me know if you have interest and I’ll push a bit harder to finish it.

In the mean time, I’m distinguishing between these here because I see us improving our services in a number of categories and want to make sure we hold some of the basic principles top of mind. What are we today and where do we want to go? I believe the decision to remain one or the other of these two categories is important in product and service development over the long term.

My personal preference is toward the make-to-order model. A make-to-order (“MTO”) business model usually undercuts the engineer-to-order model (“ETO”) on price for the same customer. And, because the MTO model gets more throughput per labor unit –by eliminating options– they usually can increase unit throughput. This results in more total units per year. The combination means they learn and see things the more customized business does not. The gap between them grows as the MTO model selects sub-niches within the original niche. And from these insights they usually grow faster and produce a higher return on tangible assets. The caliber of employees bifurcates between a handful of knowledge workers and many “doers.” Yet, because of the systems the frontline workers are paid more in the MTO model than the ETO model because these people cannot even get into the ETO business, let alone make more within this industry. Thus, the first unnatural move is to underserve the customer in a systematic way.

The compromise is usually made easier when conducted by a non-technical founder/CEO. He or she is not the craftsman of the space and is willing to forgo all the possible options to best-fit the solution and settle instead on the option that satisfies the customer. He or she can then delight the customer on the sales journey by lowering the price, making the purchase process easier, and/or surprising them with a nugget of insight post completion of the given work. In this manner the MTO often outpaces the ETO model with high velocity of delighted customers.

Magnet led ball programmatically makes art in sand under a table top.

There are circumstances where the engineer-to-order model beats the MTO model. The best circumstances are where the ETO business is working on a mission critical solution. The problem is either so severe that it might ruin the customer if it fails. Or, the problem the ETO is working on has such an enormous upside that the customer is willing to be less efficient in the short term in order to realize a chance at the later windfall opportunity. The decision of which circumstance you are in as the customer is also important. What is your long term purpose? Will this vendor provide me with something special? Do I need that distinction to be between me and my past experience or between me and my competitors? If it’s the first case then a MTO might be better. If it’s the second situation then consider the ETO further.

As a business owner, it’s important to know your business model and change it very slowly, before changing it very fast. This is probably my second unnatural advice. Before toggling between models, be sure you have a workable solution for a target customer base proven in the marketplace. If it’s not workable then don’t toggle. For an example within LEV, Mikel built our roll off dumpsters company an internet-exclusive self-check out process. The solution was simple and elegant. It probably could scale across multiple SMBs across the country with ease. And, it would easily undercut the telephone operator in terms of cost. We tested it. And customers didn’t like it. New customers wouldn’t use it. I think it’s largely because retail people don’t rent roll off dumpsters often enough to trust it. They want a little more guidance and assurance that they are making the right choice. They want to talk with a human and confirm their flowerbeds won’t be ruined. They value their property upon which the big metal box will be dropped. Whereas the repeat dumpster rental customer already had a good solution within our email or text support for re-ordering. They didn’t want to go to a user interface and place their credit card. They just wanted to text the key info to our customer support representatives and have it handled. We already did that smoothly.

So, not everything can or should be totally SaaS-ified. You cannot always niche down another level and scale it. But, it’s still worth thinking about and looking for.

Finally, I would recommend placing the “development” function of R&D close to HQ and close to the owner. In a MTO model you should already have the sales process queued up for production. Be sure management keeps their eyes peeled for solutions to improve the templates for everyone.

We will email you the whitepaper.
We send a monthly newsletter with hyperlinks to future blog posts. That's it. We don't sell lists.