The Problem-First Mandate: Why Your Smart Building Strategy is Backwards
The smart building industry has a fundamental addiction: solutionism. We are obsessed with new technologies—the latest AI platform, the slickest dashboard, the most advanced sensor—before we have a clear-eyed understanding of the problems we are trying to solve. This “tech-first” approach is the single greatest cause of failed projects, wasted capital, and the widespread disillusionment felt by facility teams today.
We ask, “How can we use AI in our buildings?” when we should be asking, “What is the most expensive, recurring, and painful operational issue we have, and is technology the right tool to fix it?”
This backward strategy is the reason the PropTech graveyard is full of elegant solutions for problems nobody had. It’s why so many expensive platforms become “shelf-ware,” abandoned by the very teams they were meant to help. To break this cycle, we need to flip the script. We need to adopt a Problem-First Mandate.
The Four Steps of a Problem-First Strategy
A problem-first approach isn’t complicated, but it requires discipline and a willingness to listen to the people on the ground. It can be broken down into four simple steps.
Step 1: Interview Your Operators The truth of your building’s performance doesn’t live in a spreadsheet; it lives in the daily experience of your facility management team. Before you even think about technology, shadow your lead building operator for a day. Ask them simple questions:
- What was the first fire you had to fight this morning?
- What is the most common tenant complaint you receive?
- If you had an extra hour in your day, what would you do with it?
The answers will reveal the real, high-friction challenges that are consuming time and resources—the problems worth solving.
Step 2: Quantify the Pain Once you’ve identified a recurring problem—like a chiller that constantly trips or simultaneous heating and cooling in a specific zone—you need to put a number on it. Intuition isn’t enough; you need a business case. Work with your team to calculate the true cost of that single issue over a year. Include:
- Wasted energy costs
- Maintenance labor hours
- Vendor/contractor dispatch fees
- Cost of replacement parts
When you can say, “This one fault is costing us $15,000 a year,” you move from complaining about a problem to justifying a solution.
Step 3: Map the Workflow Now, map the journey of that problem from detection to resolution. How is a fault currently identified? Who gets notified? What is the process for creating a work order and dispatching a technician? This exercise will almost always reveal significant bottlenecks and communication gaps—inefficiencies that no amount of flashy technology can fix on its own.
Step 4: THEN Find the Tech Only after you have identified a high-priority problem, quantified its financial impact, and understood the workflow around it should you begin to look for technology. With this clarity, your evaluation process changes completely. You are no longer distracted by a vendor’s long list of features. Your only question is: “Does this tool solve my specific, quantified, high-value problem in a way that fits our existing workflow?”
Practical Application: A Problem-First Checklist
To put this into practice, here is a simple checklist of questions to ask before you sign any new technology contract. If you can’t answer these with confidence, you are likely falling into the “tech-first” trap.
Problem Validation:
- Have we spoken directly to the on-the-ground operators who will be using this tool?
- Can we clearly articulate the top 1-3 operational problems this technology is supposed to solve
- Have we quantified the annual cost (in dollars and/or hours) of not solving these problems
Workflow Integration:
- Does this tool integrate with our existing CMMS and work order systems
- Will this tool require our team to learn a new, separate login and interface for their daily tasks?
- Have we accounted for the time and resources needed for training and change management?
Vendor Scrutiny:
- Can the vendor provide a clear, data-backed case study from a building with a similar operational profile to ours?
- Is the vendor’s primary value proposition based on solving a deep operational problem, or is it based on a flashy user interface for executives?
This mandate shifts your strategy from speculative tech adoption to surgical problem-solving. It ensures that every technology investment is directly tied to a known, validated, and financially significant operational challenge. It’s a simpler, more effective way to build a truly smart building—one that works not just in a sales presentation, but in the boiler room.