Dustin DeVan’s argument on the Bricks & Bytes round table was that corporate RFPs specify the output instead of describing the problem, which assumes the buyer already knows the best solution. If they did, they would have built it. Patric Hellermann’s counterexample was defense procurement, where operators specify performance and let engineers work out how. The same logic applies to robotics: write the automation roadmap before you go shopping for robots.
The rant started from an ordinary place. Patric and Martin had been picking at why large organizations struggle to direct AI across a business, and Dustin said he had been thinking about writing a blog on the standard RFP process. Then he did not write it, he just said it.
His charge is that an RFP tells vendors what the software should do. Which sounds reasonable until you follow it through. Specifying the solution assumes you already know the best one. And if a company genuinely knew the best solution, it would already be making the change rather than running a procurement exercise to find someone to implement its guess.
What a proper RFP looks like, in his version: here are the issues and inefficiencies inside our organization that we know we can correct. Show us how you would solve them. Show us what value you would be in course correcting. He then said nobody does this. Zero. Never got one.
The candy store problem
A CEO sees an output, wants the output, and never asks how it gets made
Dustin had a specific case in mind, though he would not name the contractor. He knew where the RFP had originated: the CEO had seen something at a pitch he attended for a client and wanted that output. Not a similar capability. That output.
What did not get asked is the interesting part. Why can our own team not produce this? What sits underneath it? How are these actually built? None of it. The procurement became a checkbox exercise on whether a vendor could deliver pretty pictures.
Patric’s summary was that this is about as informed as taking a child to a candy store. I want that lollipop.
Dustin then extended the point to public work, and it is the cleanest explanation of a familiar failure. A public client says it wants a building fully designed and specified. There has been no preconstruction process, so nobody has surfaced the constructability problems or the procurement calendar. The contractor gets handed the result and change orders their way through it. The alternative starts from objectives: what are you trying to accomplish, what pricing options exist, what procurement strategy actually delivers this on time.
Stop focusing on saying it has to do this or it has to do that. Show us how you get us to the finish line.Dustin DeVan, founder of Ediphi, on the Bricks & Bytes round table
Why the defense industry gets this right
Generals specify performance, bureaucrats specify features
Patric’s counterexample was one the show has raised before. For all its flaws, defense procurement often has the better instinct, because the requirement is written as performance under conditions. Rounds per minute. Operating in Arctic temperatures. Then the engineers work out how.
Dustin picked it straight up. The client does not know how to build the aircraft. They specify what it needs to be capable of, then say go, and the competing designs come back. Patric’s caveat is the important half: it goes wrong precisely when people who are not in the field get to define the requirements. If you are buying a helicopter-deployable four wheeler for a special forces unit, you do not ask someone in a suit.
Patric then closed a loop that had been running through the whole conversation. Corporate procurement does this because the people writing the requirements often do not understand their own product or process well enough to describe the problem. In an organization of 70,000, how many really know the product? In a startup, it is usually close to everyone.
That connects to something we found in the Revizto research earlier this year. Technology integration remains the top challenge across AEC, and coordination failure has climbed to the third biggest driver of rework, which we unpacked in Construction’s Coordination Problem Is Now a Budget Problem. Buying more specified tools into a coordination problem tends to produce more coordination problems.
Get the procurement takes your vendors would rather you did not read
Weekly analysis for construction execs, ConTech founders, and AEC investors who want the mechanics, not the marketing.
Join 3000+ ReadersThe same mistake, now with robots
Write the automation roadmap before you go shopping
Patric argued the opportunity here is even larger in robotics than in software, because the buying behavior is identical and the capital commitment is heavier. Companies survey what robotics already exists in the market and try to find a fit. Worth doing, he said, because occasionally there is one perfect match you should know about.
What is missing is the other half. Write your automation roadmap. His recommended method is jobs to be done: take a spreadsheet onto the job site, select a task area, break it down, and get granular. His example of the right granularity was almost comically specific. You need to open the door. That is the level at which a solution actually gets built, so that is the level you should be writing at.
Owen’s read back was that firms are trying to force an existing robot into an organization instead of looking at the organization, finding the specific problem, and going after a solution for that. Square peg, round hole. Dustin’s addition was that very few companies are open to adjusting their organization for what the market has. They want the market to adjust to them, and they do not entertain the possibility that the market might have a better idea than their current practice.
What a problem-led RFP actually contains
Five sections that change the responses you get back
Dustin’s closing observation is the reason this rarely happens. Running a problem-led process requires admitting the organization has problems, in writing, to a room of outside vendors. That is a cultural ask, not a procedural one. Martin named culture as the blocker and Dustin agreed, while pointing out this is not a construction disease. It runs across every large corporation in every industry.
| Dimension | Conventional RFP | Problem-led RFP |
|---|---|---|
| Starting point | A specified output the buyer has already seen somewhere | A measured inefficiency the buyer wants corrected |
| Who writes it | Procurement, briefed by an executive sponsor | The practitioners living with the problem, supported by procurement |
| What vendors compete on | Feature checklist coverage and price | Approach, understanding of the problem, and evidenced outcome |
| Evaluation basis | Does it do the listed things | Does it move the baseline metric, and can that be measured |
| Typical failure mode | Buys a tool that reproduces an existing process, faster | Requires the organization to change alongside the tool |
| Robotics equivalent | Shopping for available robots and finding a use for them | Jobs-to-be-done roadmap, then sourcing against specific tasks |
Dustin’s argument is that it assumes the buyer already knows the best solution, and if they did, they would be implementing it rather than procuring it. Specifying the output turns the exercise into a checkbox on whether a vendor can reproduce something the buyer saw elsewhere, which forecloses better approaches before anyone has proposed one. The alternative is to define the problem set precisely and let the market compete on how to solve it. This is a view he expressed on the show from direct experience with RFPs he has received, rather than a published framework.
Because performance requirements written by people who use the equipment describe conditions rather than features. Patric’s examples were rounds per minute and operation in Arctic temperatures, with the design left to the engineers. Dustin extended it to aircraft procurement, where the client specifies capability and competing designs come back. Patric was explicit that the model breaks down when people removed from the field write the requirements, which is exactly the failure he sees in corporate procurement. The comparison is illustrative rather than a claim that defense procurement is efficient across the board.
Patric’s recommended method is jobs to be done. Take a spreadsheet onto the job site, pick a task area you want to automate, and break it into discrete jobs at a granular level. His illustration of the right granularity was a job like opening a door, because that is the specificity at which a robotic solution actually gets designed and built. He was clear this should complement, not replace, a survey of existing market offerings, since occasionally there is a product that fits a need precisely and you should know about it before commissioning anything.
Patric’s argument is a governance one. Without leadership able to direct AI deployment across the business strategically and tactically, firms fall back on distributed innovation, which sounds appealing but means each silo optimizes only for its own local maximum. That assumes each silo has people who both know how to use AI and understand their own process well enough to improve it, which is a generous assumption. The result is heavy token spend without transformational effect. The wider research supports this shape: Microsoft’s 2026 Work Trend Index found most employees applying AI at the edges of existing workflows rather than in redesigned ones. (Source)
The adjacent evidence is reasonably strong. Revizto’s 2026 survey of more than 2,000 AEC practitioners found the firms getting returns from automation were the ones targeting specific repetitive tasks that consumed coordination time, rather than buying broadly. DPR’s innovation approach, which we covered previously, requires every initiative to map to one of five defined problem areas, an explicit guard against chasing technologies without a problem attached. On the failure side, research into stalled AI pilots consistently identifies scoping designed to impress a steering committee rather than solve a workflow as a leading cause. (Source)
Run one procurement the new way rather than rewriting the whole policy. Pick a process with a known, irritating inefficiency, get the practitioners to write the problem statement, measure the current state before you approach anyone, and ask vendors to propose an approach instead of confirming a feature list. Compare the responses you get against your last conventional RFP on a similar scope. The cultural obstacle Dustin identified is real, so a single contained pilot is easier to authorize than a policy change, and gives you internal evidence for the argument. (Source)
Related Articles
Construction’s Coordination Problem Is Now a Budget Problem
KP Reddy Co. Launches Embedded AI Transformation Practice for AEC Firms
SoftBank’s $100B Robotics Bet: Why Roze AI Wants to Build the Data Centers AI Runs On
Revizto: Bridging the Gap 2026
Microsoft Work Trend Index 2026 analysis
Why most enterprise AI fails, and what works
Why enterprise AI pilots never reach production
Forbes: AI Productivity’s $4 Trillion Question
