ajax loader

Why Commercial Real Estate Still Lags in Adopting New Technology

Urban Land Institute was kind enough to publish this article.

By

June 24, 2016

 Joseph Stecher is a member of ULI and has invested in real estate globally as a principal investor at General Motors Pension Fund, Goldman Sachs, and Morgan Stanley. Today he has his own capital placement agency, Candlewood Investors, and is also a senior adviser to RealConnex, a real estate technology startup.

At the 2016 ULI Spring Meeting in Philadelphia, ULI convened a meeting of chief executive officers of real estate tech startups, and other senior executives of real estate firms that have had success in adopting new technology.

We were asked the following questions: “Why has commercial real estate been slow to adopt new technology, what are the impediments, and how can they be overcome?” Some of the answers, we realized, apply to every industry, but many are specific to how we do business. The takeaway from this article should be how leaders of real estate firms can develop best practices to blend technology into current business practices, and also why they should make the effort.

I suggest putting aside imprecise analogies like “we’re dinosaurs” and “we’re not digital natives,” because they allow senior people to abdicate responsibility to lead the firm in developing best practices around evaluation and use of new technology. In particular, these self-styled dinosaurs have deep business understanding—what techies call “domain expertise”—that software developers may lack but which they need to create and improve useful products.

A much more useful way to think about the specific contributions that a firm’s leaders can make to technology adoption is to understand that we are essentially reliving the literacy revolution of the 15th century, when Johannes Gutenberg invented the idea of the printing press using movable type. Before Guttenberg’s time, most jobs did not require reading and writing, because producing and distributing books was highly specialized and expensive. Literacy rates were under 50 percent or less in Europe, and probably much lower outside cities. There were literacy specialists like lawyers and especially the clergy, some of whom spent all their time copying and recopying classical and religious texts, just as today about 10 percent of the population can code and we think of them as technology specialists.

Thanks to Gutenberg, printed materials became easier and cheaper to reproduce and distribute. Jobs then changed and required literacy, and therefore more people had to learn how to read and write. Today, almost no jobs require digital literacy, but during the lifetime of people who are alive today, every job will require some level of coding, or ability to evaluate code, system design, and implementation. Right now, however, we are at an inflection point where people and organizations have to make decisions about using software, but are in essence looking at a printed page with no ability to evaluate the quality of the printing, paper, and ink, or even to know if the letters on the page are Genesis 1:1 or gibberish.

So what are some best practices for software assessment over the next ten or 20 years—that is, until digital literacy is as common as reading and writing is today? One pretty clear mistake is to let the “IT guys” handle it. Generally, members of that department lack the domain expertise to evaluate a product that the business team can use. At the other end of the effectiveness spectrum, many real estate firms are reportedly looking for a chief technology officer (CTO) who would combine in one person both domain expertise and digital literacy. Most firms, however, are not even considering the subject, so for the time being digital literacy is needed but absent from the decision-making toolkit of most real estate firms.

But just as virtually all real estate firms lack the software expertise to evaluate a product’s effectiveness in terms of both the impact on the bottom line as well as its functionality and scalability, it is also the case that few software developers have real estate backgrounds (though many do). They need their customers’ domain expertise to help evaluate and improve their new products.

The way forward, then, is for the leaders of the firm to develop a process to bring to bear internal and external resources in evaluating software decisions.

LOOP_graphic_x619

A good framework for understanding how real estate firms absorb software into daily practice is the above admittedly oversimplifed chart, which is relevant to all industries. In essence, it says that a software developer identifies a business practice—often involving spreadsheets, email, Post-it Notes, and voicemail—that can be better executed digitally. He or she develops some code that becomes a product, and eventually the product ends up in front of someone at a potential customer’s firm who agrees to adopt it, and then the adopter’s organization integrates the product into the way it does business. Two success stories are Hightower and VTS, which took a broken supply chain of information between leasing broker and building owner and digitized and standardized that flow of information in a way that delights their customers.

During integration, the developer will almost certainly get “battlefield” feedback that is likely to be much more useful than could be derived from a smaller-scale test (called a “beta”). A smart developer will use this new information to improve the product and start a new loop of development, adoption, and integration.

The first fork in the road for the customer is buy versus build, and in almost every case it is better to buy or otherwise rely on a company that actually builds software while the customer focuses on building actual buildings.

But how a customer buys matters a lot. A successful model appears to be to appoint a senior person with parallel nontech authority and with deep domain expertise to be the adoption-gatekeeper tasked with evaluating many or even all of the new software solutions that vendors propose. The adoption-gatekeeper then oversees a product’s movement into the integration phase, using a small testing team of business people and IT people to evaluate both effectiveness and functionality. The test team should be a broad cross-section of users giving honest feedback—relying on quick, untested, top-down mandates appears to be a path to failure, possibly because the actual users/testers feel their voices will not be heard, so they don’t provide software developers the needed feedback to improve the product.

The gatekeeper also has to manage the process “up” so that his or her peers at the top of the organization understand the risks and benefits and lessons of the beta test. As the product moves through the Technology Feedback Loop, it can be rolled out to a wider and wider circle of users, who (a) will receive it knowing that it has already worked for colleagues with similar jobs, and (b) should feel that the Technology Feedback Loop is still operating and that the product has the potential to be further modified based on their feedback. The IT team is integrated into this testing team to assess functionality, integration with other systems, and scalability. A well-run integration program will be met with questions like “when do we get to try it?” instead of “do I have to use this?”

Some firms actually invest directly into software companies on the theory that if they help create something of real value through their inputs to the Technology Feedback Loop, they should share some of the upside. Furthermore, these firms understand the business environment and feel they have a competitive edge in evaluating what works.

Others are satisfied to participate in the Technology Feedback Loop without an equity stake, and eschew venture capital–style investing for two reasons. First, they are real estate investors and not venture capital investors, and they feel that they should use investors’ capital for the intended purpose. But also, while some investments do produce a massive profit, the venture capital model usually involves investing in a lot of losers, and a real estate firm is likely to invest in too few companies to have enough winners to offset the losers, so that the profits—if any—compare unfavorably to how that capital could have performed had it been invested in real estate. More subtly, product diversification in a venture capital portfolio matters as much as property and location diversification in a real estate portfolio, and the real estate firm whose tech portfolio consists solely of products that a firm might use in its “day job” is likely to have quite a concentrated portfolio. Another subtle point is that success in venture capital investing is often a result of early access to great teams and products, and real estate firms are likely to suffer from a negative selection of opportunity.

Conversely, until quite recently, venture capital has not been available for commercial real estate technology, possibly because venture capital investors did not see the massive market that exists for consumer products like Facebook, or even quasi-business (or “enterprise”) applications like Zillow/Trulia in residential. So one impediment to industry-wide adoption and integration of technology may be a gap in venture capital funding.

An example of how technology might create winners and losers in the future is the services provided by LiquidSpace and PivotDesk, which help tenants find short-term space—as short as a day—as quickly as one can call a Lyft car or book an Airbnb reservation. Landlords who work with these two firms have the possibility of extracting some revenue from usable space that cannot be rented (think of a floor that is encumbered by a near-term expansion option), while landlords who don’t reach for this low-hanging fruit will experience narrowing margins relative to those of their competitors.

Another discussion topic for business leaders to consider is that both real estate tech firms and real estate firms need to let go of the idea that controlling information is a necessary net competitive advantage. Obviously this topic is controversial. But many firms—including CompStak, Honest Buildings, CoStar, Yardi, and MRI—have enormous amounts of customer data on leases, expenses, occupancy, construction costs, and many other data points. There is an argument that customers and the industry would benefit if they allowed these vendors to aggregate these data and publish them in a way that does not disclose any one firm’s information (so that average rent in midtown is $67.33, not rent at the XYZ building is $80). Not every real estate leader agrees that this trade of proprietary information is a good idea. Counterintuitively, tech firms are guilty of “old thinking,” too. Many tech firms (often) outside of real estate tech build “application program interfaces” (APIs) that allow two websites to share information and processes to deliver benefits to customers that neither could deliver on its own. You are able to share your Flickr photos on your Facebook page, or embed your SlideShare presentation on your LinkedIn profile, because the two firms have in essence built a path between their sites that allow their customers to extract certain benefits from both sites. Regardless of how much you agree with the late Susan Hudson Wilson that the data want to be free, most real estate tech firms agree that they could do a better job with this kind of complementary sharing of data and other functionalities. Eventually, some existing or new firm could access this data through an API, combine the data with other information about the economy, and use the data to make better predictions about rents, tenant demand, construction, and perhaps government tax or land use policy. In this way, the firm could help investors and operators suppress the volatility and smooth out the fluctuations of over- and undersupply that contribute to the real estate industry’s boom-and-bust cycle. This might reduce the whole industry’s perceived investment risk, attract new sources of capital, and bring down the cost of capital across the risk spectrum, benefiting every member of the industry—and society as a whole.

Leaders of real estate firms and real estate tech firms have to get informed, and take a position on whether or not this new approach to information sharing is worth the cost. Some observe that other industries are beginning to benefit from “mining” vast repositories of customer data, weather data, and the like—called “big data” for short.  But the real estate industry—it could be argued—doesn’t even have the data yet.

And it is incumbent upon leaders of real estate tech firms to become teaching organizations and produce and publish case studies about how their products specifically benefit customers in practical ways today, with a bit less emphasis on changing the world.

So it is time to put the dinosaurs back in the kids’ toy chest, and to stop building a wall between yourself and the digital natives. Leaders of the real estate industry have the misfortune of having to lead in an environment where they should be digitally literate but are not because we are all living in the first day or first year of the second literacy revolution, but this one is a digital literacy revolution. Rather than abdicate their role in technology adoption and integration, leaders have to understand the value of their deep domain expertise in devising technology solutions for their firms, and implement a best-practice approach to the Technology Feedback Loop.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>