The BuildZoom platform can be thought of as a flywheel with three main components.

  • Data – This is the foundation of the platform and includes the data pipeline and core information architecture.
  • Marketplace – The host of systems aimed at improving efficiency within the marketplace; including the matching algorithm, methods through which we abstract relevant features of supply and demand to feed the matching algorithm (e.g. proximity score, win-rate), and applications used to codify useful market observations.
  • UI – The various interfaces that enable users to engage within the platform in increasingly productive ways. There UI component has several important functions. First, the more it enables users to perform, the less we have to help them. Second, the more users we have engaging on the platform in meaningful ways, the more signal we’re able to compile and feed into the Data component.

The flywheel works something like this:

  1. We use public data to gain a big head start in terms of understanding the market.
  2. The marketplace component uses this data to enable efficient market interactions.
  3. The UI component fosters user engagement. This user engagement creates additional data that is fed back into the data component, giving it more ammunition, which in turn enables more efficiencies in the market.

Much of this essay will focus on the UI paradigm as the gateway through which we perpetually compile valuable market data, which enables the flywheel’s momentum to increase (and perpetually improve the market’s efficiency).

The Legacy UI Paradigm

Here is one way to visualize the legacy paradigm:

Our initial hypothesis was that BuildZoom is a two-sided marketplace. The platform should connect supply with demand. Therefore, the UI should enable demand users to create a project description, view their matches, and ultimately select one. In the diagram above, functionality for demand users is represented as set D. Supply users need functionality to pursue leads and manage their pipelines. This functionality is represented by Set S. There is an intersection between these sets (S ⋂ I), best exemplified in the communication application we developed.

As you can see, there is a third set ‘Intermediary’ (I), which I use to refer to what we’ve historically called our ‘back office tools.’ In the legacy paradigm, the human roles within BuildZoom were limited to qualifying demand users, onboarding supply users, and working with supply users to collect referral fees. Technology built to support these functions was considered outside the scope of our platform strategy and often a secondary consideration in roadmap planning.

The Shortcomings of the Legacy Paradigm

While our legacy platform strategy shares similarities with companies like HomeAdvisor and Thumbtack that have generated significant revenue via a CPL model, it was not well-suited to the CPA model or the construction segment (which includes residential alterations, residential construction, and commercial alterations) we are addressing for several reasons.

Monetization Advantage – In a CPL model, the average lead value caps out as contracts increase in size. By taking a percentage of the gross contract, the unit value grows at a commensurate rate with the size of the contract. At a 15% conversion rate, we’re essentially able to extract 4x the revenue as the CPL model for a $250K contract. This monetization advantage is particularly important in the long-run as it enables us to buy all the demand of this type.

Supply quality – We learned early on, that premium GC’s and builders, tend to have a backlog of opportunities and are far less inclined to pay for leads they have to qualify and chase. However, they are willing to work with us when presented with a qualified opportunity that fits their business and only charged upon acquisition of a contract,

Incentive alignment – Finally, the CPL model dictates a strategy that results in routing demand to the supply willing to pay the most for leads; whereas the CPA model compels us to find the best actual match between supply and demand.

Ever since we made the decision to shift fully to the CPA model, the most significant business problem has been over how we monetize large construction opportunities. Not only have these opportunities represented a majority of the gross contract value (GCV) associated with leads, but this also represents a true greenfield opportunity in the market.

The Breakthrough

Through 2018, two breakthroughs formed the basis for what has become our repeatable sales model: First, the growth team’s efforts resulted in what we refer to as the ‘high touch’ sales motion; second, the BD team’s efforts ultimately evolved into what we refer to as ‘BuildZoom Premium.’ The synthesis of these two initiatives forms the basis for a sales model that:

  • Enables us to increase our overall take rate.
  • Significantly increases our conversion rate, which enables us to out-monetize competitors for demand.
  • Monetize earlier in the process by charging the demand side for BuildZoom Premium, which also creates increased financial predictability, and dramatically shortens the time it takes for a rep to make a positive financial contribution.
  • Create a greater level of product-market fit through BuildZoom Premium, leading to increased word-of-mouth referral.

Expands our target market to include pre-design opportunities and companies with repeat business (e.g. franchisors).

This new model has fundamentally changed the amount of value that can be created by an individual rep.

Divergence

In order to create the flexibility needed to validate and systematize the sales motion, a lot of interaction was taken off-platform. In 2019, the efficacy of this new sales model is driving much of the business strategy. However, there is an ongoing divergence between the customer UX and the actual UI within the platform.

Addressing the Divergence

BuildZoom’s goal is to be the dominant platform in the construction market. To achieve the next milestone within the next 2-3 quarters, we need to prove out the ability to convert demand into cash in a predictable fashion.

After years of hard work, we understand that achieving product-market fit in the construction market requires a human-in-the-loop (Note: I realize I’m being a bit loose with the application of this term).

There are two roles in particular we have determined are critical to the platform currently:

The Project Consultant (PC)

The PC serves as an intermediary between supply and demand. They fill several important functions. First, they help address the knowledge gap that often exists with Demand. Second, they are able to contextualize the value of Premium, which enables BuildZoom to better serve them. Third, they are able to support the Matching System by connecting with new Supply, but also by logging their interactions and learnings back into the Data System.

Finally, they fill an important psychological need when it comes to large purchases. Think about comparable transactions: for home purchases, you have a real estate agents; for weddings, you have wedding planners. Construction is one of the only major transactions that doesn’t actually have an established intermediary. Opportunistic architects will sometimes play this role, and there are some owner’s reps in the market, but the role is not established.

The Construction Engineer (CE)

The construction engineer plays a critical role in helping us achieve the delivery of value needed to achieve product-market fit in the construction market.

In conclusion, we have realized that a knowledgeable human intermediary is crucial for giving clients the right information, advice, and peace of mind that will enable them to move forward with their projects. Moving forward, I’ll refer to these roles as intermediaries (I).

From a platform perspective, this has some immediate consequences for how we should think about the marketplace layer, and dramatic impact in how to think about the UI layer.

The New UI Paradigm

Instead of looking at the platform as being exclusive to Supply and Demand (S ⋃ D), we need to shift our perspective and think about the UI layer as the union between supply, demand, and intermediaries (S ⋃ D ⋃ I).

Consistent with the legacy paradigm, there are sets for both demand (D) and supply (S). Historically, we have equated these sets to one persona of users each: PO’s to (D) and CO’s to (S).

Instead of just equating each of these sets to a persona of users, we can now think about these sets as containing functionality to support either supply or demand-side activities (in some cases, a contractor or developer may actually be interfacing with the demand-side UI. Additionally, the persona of users who access these interfaces is also broadening. On the supply side, we’re seeing new types of actors, such as architects and structural engineers, playing a role. On the demand side, we’re seeing market actors like property managers and franchises engaging with the platform.

Perhaps the most significant change in the new paradigm involves the emergence of I as an integrated set; and three new intersections: (I ⋂ S), (I ⋂ D), and (I ⋂ S ⋂ D). The evolution of our platform based on what we have learned, calls for a similar evolution in our product strategy.

The following are several ways our product will/may develop: (Note – I’ve removed some of the more proprietary elements from the following list):

Example: Fulfillment of BuildZoom Premium

In the legacy paradigm, the workflow through which Premium deliverables are assigned and sent to D, would be marginalized into set A. In the new paradigm, there is an opportunity to place this initiative in (I ⋂ D), which would systematize the manner in which we assign Premium deliverables to a CE and bill D for the fulfillment of these deliverables. Furthermore, a subsequent iteration would enable passthrough and collaboration around these deliverables between I and D.

Example: Collaboration between I and S

Currently, there are varying forms of engagement that occur between I and S off-platform, necessary to fulfill on Premium. Placing this initiative in (S ⋂ I) would move the engagement on-platform and open the aperture of what’s possible through the UI. Having I and S work on-platform creates opportunities to streamline the process, which decreases the marginal cost associated with fulfillment; but also creates the opportunity to add compounding value into the platform through these interactions.

How the platform evolves over time

In the present, expanding the aperture to account for the intermediary as a key stakeholder in the marketplace, addresses for the reality of what is needed to create a successful marketplace outcome. In the long-term, the goal is to optimize their contribution to our accumulating data advantage, and increase the flywheel’s velocity. This means greater autonomous market efficiency and an increase in the capacity of each intermediary. We’re already seeing this in maturing markets (e.g. the Bay Area), where the marginal effort needed to create a positive market outcome has decreased dramatically.

Conclusion

Our fundamental mission – to be the underlying platform for the construction industry – has remained unchanged. Failing to evolve the paradigm through which we think about the platform’s role in the marketplace, will inevitably lead us down a path with reduced scalability, efficiency, and deprecate our ability to contribute to our accumulating data advantage.

By moving past the old paradigm and embracing the intermediary as a stakeholder group within the platform, we acknowledge the reality of what is needed to create consistently positive outcomes in the marketplace, increased efficiency, and contributing to our accumulating data advantage over time.

This difference could be boiled down to an existential question of whether we want to strive to be a service-oriented company, with a lower ceiling; or a technology platform that accounts for intermediaries, with a much higher ceiling. My preference is the latter.

Each year, there are millions of construction transactions that take place in the market, and continuing to operate within the old paradigm, will result in limiting our ability to influence the overall marketplace. Shifting to the new paradigm will help us fulfill our fundamental mission and sets us on a path that truly aligns our revenue strategy with our product strategy.