Thinking is Cheap

01 Feb 2026 » Opinion

Imagine the following scenario. You have just purchased a plot with sea views. You are eager to build a house to start enjoying it. However, you want to save money and do not hire an architect to design the house. Instead, you go directly to the construction company. They ask for the blueprint, but you tell them that it is not needed, that they should just look at the houses in the neighborhood and build something similar. Would you do that? I am sure the answer is “no”. So, why do we see this approach so often in technology?

Execution is Expensive

While the situation with the house described above is completely imaginary, I have seen this in technology. It goes without saying that they tend to end in fiasco.

I was once assigned to a project, where the customer had already implemented the data architecture of the Adobe Experience Platform (AEP). Schemas and datasets had been created in the production sandbox, they were already loading data, and some destinations had been configured. With this part of the implementation done, they asked the business for use cases. To their horror, very few could be delivered with that implementation. The problem was that the IT department had implemented what they thought was the right design for the data, without ever asking the business team for their input.

After multiple discussions with this customer, we made the hard decision to reset the production sandbox. I actually clicked the button, I felt really bad. That probably was $500k (or more) going down the drain.

Unfortunately, this is not an isolated case; I still see this behavior in some of the engagements I have been part of. IT directors argue that a discovery and design phase is a waste of time and money, that it is just a “lift and shift” and they need to show value quickly. I have bad news for them.

Thinking is Cheap

While I am not in sales, I work closely with them. A typical hurdle they face when negotiating contracts with customers is that architects, business consultants, and digital strategists are expensive. I beg to differ. I am not going to dispute that our hourly rate is higher than that of a developer, but:

  • In a healthy project, the number of architect or strategist hours should always be significantly smaller than the total development time. We are in technology, not philosophy.
  • Fixing a mistake on a whiteboard or redoing an architecture diagram that does not support the use cases costs a fraction of having to redo an implementation that is not fit for purpose.
  • As I have explained multiple times, you must start with the why, and to find this why, you need to spend time thinking before you start developing.

I can understand the anxiety to show value. In my post Buy a Raspberry Pi, I explain how our customers expect a return on their investment when they buy enterprise-grade software like the Adobe Experience Cloud. However, this should not be an excuse to put the cart before the horse.

In summary, and based on my experience, I can confidently say that “thinking is cheap”.

 

Photo by Andrea Piacquadio



Related Posts