How can you tell if an AI project will work? Three types of feasibility questions can do a lot of that work for you.
If a real estate developer proceeded to build a building by first gathering a bunch of material and trying to put it together before doing market analysis, architecture, engineering, etc., they would likely have a very short career as a developer.
We find, however, that many AI projects in real estate proceed in this way. There are some very basic questions that can significantly improve your chances of successful AI outcomes, avoiding those that were never feasible to begin with, and from our experience, both reduce the amount of time spent in the development phase and increase the functionality we achieve in those projects.
Artificial intelligence initiatives in real estate often fail not because the AI is ineffective, but because projects are not properly vetted before development begins. Organizations frequently pursue applications that sound compelling but lack clear value, sufficient data, or the resources required for successful execution. A structured vetting process is therefore essential to improving the probability of success and ensuring that AI investments align with business objectives. Vetting is not a simple yes-or-no decision; rather, it is a systematic evaluation of whether an idea can realistically deliver value given the constraints of a particular organization.
What I have found confusing is the difference in the amount of analysis and vetting of real estate developments/acquisitions compared to the vetting of technical projects. Real estate companies spend months and often tens or hundreds of thousands of dollars asking extremely detailed questions about a potential real estate project, but comparatively little when it comes to technical projects. My opinion is that the lack of technical vetting stems from a lack of technical backgrounds in real estate firms. Real estate people know real estate, they know what matters in making a project successful, and they know how to evaluate the answers they get in due diligence. But how many real estate professionals know how to do the same for technology?
This is not a criticism as much as an observation. Technology is just not what real estate people do well and hasn’t been a large part of the real estate industry historically. But now it is and that expertise in technology has not matched the real estate expertise, which is something I very much think needs to change (I’ll be publishing an article that makes the argument that between real estate and technology professionals, real estate professionals are better positioned to make an impact with technology).
The importance of vetting is amplified in AI and machine learning applications because these systems are inherently sensitive to data quality, problem structure, and implementation complexity. Not every problem is well suited to AI, and not every organization has the capabilities required to implement advanced systems effectively. Without vetting, firms risk investing significant time and resources into initiatives that ultimately cannot deliver meaningful outcomes. Conversely, early-stage evaluation allows organizations to fail quickly, redirect resources, and prioritize projects with a higher probability of success.
The vetting process can be organized into three major categories: value feasibility, technical feasibility, and execution feasibility. Each category addresses a different dimension of risk and collectively provides a comprehensive framework for evaluating AI initiatives. These categories should be considered sequentially. If an idea won’t provide value to the firm, there is little reason to proceed to figuring out whether it’s technically or executionally feasible.
Value Feasibility: Identifying Real Business Impact
The first step in vetting an AI initiative is determining whether the proposed application provides clear value to the organization. This requires evaluating whether the system will improve efficiency, accuracy, speed, or strategic decision-making. In an environment saturated with technology hype, organizations must resist the temptation to pursue solutions simply because they appear innovative. Instead, decisions should be driven by business needs rather than technological possibilities.
A critical question in value feasibility is whether the initiative represents a solution to a real problem or merely a “shiny object.” Many AI projects begin with an appealing technology and attempt to find a use case afterward. This approach often leads to applications that generate minimal value or fail to gain adoption. Organizations should instead identify specific operational or strategic challenges and evaluate whether AI meaningfully improves outcomes.
Value feasibility also requires distinguishing between different types of value. Some applications generate operational value, such as cost savings or efficiency improvements. Others create strategic value, such as enhanced decision-making or competitive advantage. Both types are important, but they must be evaluated differently. Operational value may be easier to quantify through ROI metrics, while strategic value may manifest indirectly over time. Organizations should consider both tangible and intangible benefits when assessing value feasibility.
Another challenge in value evaluation is realism. Real estate professionals understand that real estate development projects require significant detail and careful analysis before success can be achieved. The same principle applies to AI initiatives. High-level narratives about transformation must be grounded in practical considerations of implementation complexity, data requirements, and organizational readiness.
Technical Feasibility: Data, Computation, and Accuracy
If the answer to the value question is yes, the next step is evaluating technical feasibility.
I want to add a note here. Almost everything covered in this series after this point depends on your/your firm’s ability to evaluate whether an idea is technically feasible. This requires understanding data, understanding how models work, how to estimate cost of data, cost of engineers, time, risk, and many other factors related to technology development. I will write a series of articles solely on technical and execution (next section) feasibility that should bridge this gap, but for now I’ll just describe these concepts at a high level.
There are three main types of technical feasibility we evaluate: data sufficiency, computational suitability, and accuracy threshold.
To determine data sufficiency, the first thing we do when we start working on a new project is to create a diagram of a system.
A VERY contrived example of a property valuation system is immediately below. A full breakdown of all the hundreds of relevant features for the valuation of a commercial property would not be legible, but this should serve as a sufficient guide. Information we would extract from leases alone would be significantly larger. Same for market and submarket trends, macroeconomic cycles, etc. We usually end up with hundreds of individual features for the valuation of a commercial property covering the property itself and the market trends around it. The image to the right is more of what a real system breakdown would look like for a small problem.
We have found that this helps us work through all the information we’ll need (or would be ideal) to solve the problem. We don’t start with what’s available, we start with what’s ideal. Once we feel comfortable with that, we then go figure out what data is available.
The way we figure out the availability and sufficiency of data is with a data table. We list all the features that we identified in the system diagram as being “ideal” to solve the problem, put them in a table, and start exploring what sources offer that data, as well as the format, structure, timeframe, and geographic (national, state, city, county, zip code, etc.) and temporal (annual, quarter, monthly, etc.) coverage. The two images below are examples of a data table with geographic and interval mapping.
Something that should immediately jump out in these tables is how different the fields are. In the top table, many of the “Historical” (start and end dates) are all different, the source formats of the data are different (API’s, CSV downloads, web scraping, PDF files). In the bottom table, all those empty cells represent data that doesn’t exist. It’s just not available. So you’ll have to figure out if you can work around those gaps and different dates. And you’ll have to determine the cost, time, and skill sets needed for collecting and merging all the relevant data.
These tables help us figure out what data is available, whether the data that’s available is sufficient for our purposes, and gives us a lot of information about what kind of data engineering we’ll have to do to get the data into a usable format. In real estate, because the data is so fragmented by use case, geography, source, etc., data collection, initial processing, engineering, and storage often take multiples of time more than what is needed in other industries. And you may not be able to address some of these complications. For example, if you have the GDP of a metropolitan area, how do you know what portion of that GDP should be allocated to individual submarkets? Same for employment growth. A property is in a specific location, so population growth on the complete other side of the city won’t be of much help. Knowing the limitations is essential for technical feasibility evaluation. This is something that real estate companies almost universally underestimate.
This also allows us to evaluate computational suitability. The more your data has quantitative measurements or discrete categorical (hot/cold or rainy/not rainy, for example), generally the more computationally suitable the problem will be. But we have found features such as the value of a view out of a Manhattan apartment, the quality of certain features in a home (how “nice” is the pool), or the location value of a commercial property very difficult to use in models because these are all qualitative and subjective values. For example, how would you quantitatively compare the quality of one view vs. thousands of other views? Perhaps a scale of 1 to 10? Which means there are only 10 possible qualities of views in apartments in Manhattan? We know that’s not the case. How about a continuous scale from 1 to 10? Which could mean that one view has a rating of 7.321 and another of 7.893? Ok, even if we could come up with that kind of specificity (which I don’t think we can given the subjectivity of a view), how much actual dollar value would that difference make in one apartment vs. the other? These differences must be accounted for somehow, otherwise how will the model know how to adjust the weights for the “view” feature? Just for fun, try coming up with a mathematical algorithm that will quantify all views accurately and see what happens.
When I say “computationally suitable,” I mean how easy is it to determine the values that are used in these models and how much potential variance is there in each feature. If you have a lot of features that have a large range in their values, your models will also have a large output range, which leads to the third type of technical feasibility: sufficient accuracy.
If Amazon has a success rate of 60% for converting book recommendations to sales, that would probably be pretty good. But if you have an accuracy of 60% for the valuation of a property, not such a good thing. A 60% accuracy rate for a home or commercial valuation is not even usable.
This is why good, high-quality data allows better computationally suitable problems with smaller ranges in potential outcomes.
Again, there are entire series of books written on the technical aspects of AI, machine learning, and deep learning topics and I will expand on it in a later article, but hopefully this provided a different view on the relationship between data, models, and outcomes.
Execution Feasibility: Matching Resources to Complexity
If a potential project is determined to be value and technically feasible, you can then move on to execution feasibility. Execution feasibility addresses whether the organization has the expertise, funding, and time required to implement the proposed solution. Even technically feasible and valuable ideas may fail if the necessary resources are not available within the firm. It’s likely that Google can develop certain technologies that a mid-size real estate firm would not be able to develop successfully. This evaluation requires assessing both technical skillsets and domain expertise, as well as the ability to translate between them.
As AI applications increase in complexity, the capabilities required for a firm to execute successfully grow significantly. More advanced systems demand larger datasets, specialized engineering skills, and sophisticated infrastructure. Organizations must realistically evaluate whether they possess or can obtain these capabilities at a level of efficacy that will lead to success. Getting a “data science intern” for the summer is not sufficient. A mismatch between ambition and resources is a common cause of project failure.
Funding is another critical factor. Complex AI initiatives often require significant investment in data acquisition, infrastructure, and talent. Attempting to solve a large-scale problem with insufficient resources typically results in underdeveloped solutions that fail to deliver value. You wouldn’t attempt to build a $100 million dollar building with $10 million in total funding. Organizations should either align resources with the desired outcome or select projects that fit existing constraints.
Time is equally important. High-quality AI systems require iterative development, testing, and refinement. There is a substantial difference between building a tool that technically functions and one that performs reliably in production. Organizations must allow sufficient time for experimentation and improvement, particularly for novel applications.
Resource Matching and Organizational Discipline
Effective vetting requires matching project complexity with available resources. Organizations often approach AI initiatives by setting fixed budget and timeline constraints before defining the problem. This approach can lead to unrealistic expectations. Instead, firms should determine the requirements of a desired outcome and then assess whether they are willing to commit the necessary resources. Alternatively, if budget and timeline are fixed, the focus should shift to selecting projects that fit those constraints.
There are three paths to matching resources. First, if a firm has a set budget and a fixed timeline, then they should focus on finding projects that are feasible to complete in that time and on that budget. Second, if the outcome is the priority, then the firm should figure out what resources are needed and then allocate those resources appropriate. Too often, though, firms pursue the third path, which is trying to fit a specific project into a fixed budget and timeline. This leads to failure almost 100% of the time.
Real estate provides an intuitive analogy for this concept. Developing a high-rise building in a major urban market requires significant capital, expertise, and time. Few organizations would attempt such a project without the necessary resources. AI initiatives should be evaluated with the same discipline. However, because technology capabilities are less familiar, organizations often underestimate complexity and overestimate their ability to execute. Developing a structured vetting process helps bridge this gap.
Conclusion
Vetting AI initiatives across value, technical, and execution feasibility provides a systematic approach to improving success rates. Value feasibility ensures that projects address meaningful business needs. Technical feasibility confirms that sufficient data and structure exist to support modeling. Execution feasibility evaluates whether the organization has the resources required to implement the solution effectively.
By applying this framework, organizations can avoid chasing hype-driven initiatives and instead focus on projects that deliver real impact. A disciplined vetting process does not eliminate uncertainty, particularly for strategic applications, but it reduces risk and aligns expectations. Over time, repeated use of this framework improves organizational judgment and increases the likelihood that AI investments translate into meaningful operational improvements and strategic advantage.