I generally agree. This is why I think the home construction analogy for software might do more harm than it does good. If you go with the building constructio

I generally agree. This is why I think the home construction analogy for software might do more harm than it does good. If you go with the building construction analogy then the UX is just as much the architecture as it is the paint, floorings, materials etc. Even in the housing market, the same building plan does not work for your entire market. It depends on if you're developing software that is more of a tool addressing a well understood and pervasive problem, as opposed to a service or solution where you're trying to adapt to the varying needs of a broader market. If you build like a house you might have plans that meet the needs of a few customers but you're going to have to re-design the house for the next set of customers. Software is generally more of a continuously developed service that needs to adapt as problems, jobs and markets change -- houses don't have to do this. But I agree, "UX" first can work if it's iterated in small cycles continuously and the technical knowledge is involved in understanding the jobs and problems rather than the requirements and specifications.