I was watching TV after dinner when I heard my phone buzz on the table.
So, like clockwork, I picked it up to check. I had a new email.
It was from Daniel (not his real name), a potential client I’d spoken to the week before. I’d just wrapped up some discovery work for his firm and sent him a proposal.
I was actually surprised at how quickly he responded. I had been planning to follow up too. Anyway, I was proud of this proposal. I had done my research, explored what was possible and believed the tool we were about to build would be good for both of us. It would improve his workflow, and I sure could use the money. Him replying this quickly sounds like good news.
So, I opened the email.
Daniel thanked me for all the work, but they had decided not to proceed.
I’d like to tell you my heart sank, but really, I just locked my phone and continued watching TV.
The TV kept playing, I think I went through two or even three episodes and I couldn’t tell you what was on them. My mind was elsewhere. I was trying to figure out what had gone wrong.
Hi, I’m Braden
I help teams be more efficient in the AEC Industry, then share stories about it here. I also have courses, guides and scripts as part of CodedShapes Pro
Check it out if that sounds like you.
If you’re new to CodedShapes, welcome! You might enjoy these:
Got a workflow in mind ? Let’s build it together.
The discovery went really well
After a few back-and-forth emails, we’d finally made it to a call.
Only five minutes in, we were already riffing on ideas for automating his current preliminary design process. We were on the same wavelength too. I was finishing his sentences, or so it felt. He’d even been using Claude to help him out. But he just couldn’t get Claude to talk to the engineering program. So, I didn’t need to convince him about automation. He was already a strong proponent of it.
The biggest problem we identified was that his team was spending too long cleaning and redrawing the architect’s input before they could begin designing. When they finally produced some structural advice, the plans would change and they would have to start all over again. The loop from architect to structural advise was too manual and too long.
So, to help, Daniel wanted to take a floor plan from an architect, pass it through some kind of staging area for the engineering inputs, then produce a preliminary analysis model. We’re talking about dragging a file, filling in a form and getting an analysis model out of it.
I could already picture the workflow, and as we riffed on ideas, he seemed ready to start. So, the call ended with me requesting sample files to iron out all the details of this workflow. To put pen to paper.
Two out of five
I spent the next couple of days researching Daniel’s engineering program, working out what its API would let me do and prototyping the workflow.
It turned out that two of the five things he wanted to automate weren’t supported. Maybe there was some hacked way around it, but the API didn’t support them. So, I sent Daniel a quick email with an update, a few images of the prototype and how I envisioned the tool working. I also explained that I would continue with the proposal because we could still solve three of the five things.
He didn’t reply, so I treated that as permission to continue. No news is good news, I told myself. Plus, the call and emails had gone so well that I assumed Daniel just wanted to start.
I spent the day writing up the proposal. I worked through the costing, finalised the workflow, documented the tool requirements and defined how we would test it. By the end, I had written a proposal for something I could build and truly believed would be useful.
So, I sent it off, believing we were about to change how his firm worked. Well, then I got that email.
Asking for feedback
The morning after the rejection, I read the email a couple ten more times, hoping it would tell me what I had done wrong. Maybe there was a hint, a line, something I missed while being too excited to deliver.
The call had gone so well and the proposal seemed so clear. What in the world happened?
After staring at the same email for far too long, I still had no explanation. No hint of what had gone wrong. I could almost cite you the email from memory.
So, I decided to ask Daniel.
The worst thing that could happen was that he wouldn’t reply. So, I drafted something and sent it.
To my surprise, Daniel replied.
He was generous enough to give me some honest feedback. Which was when I found out that those two things the API didn’t support were actually the critical features for the automation. The remaining three would have improved his workflow, but his existing process handled them well enough. He couldn’t justify paying for something that he already did decently. It just wasn’t painful enough.
I’ve written before about how to know whether a workflow is actually worth automating. I failed to ask the question again after the scope changed. I had been comparing my proposal with the friction in his workflow. Daniel was comparing it with an existing process that already worked and cost him nothing new. Why would he pay for something only slightly more refined?
I should have pushed for clarity
The feedback helped, but I still felt blindsided. In the moment, it felt like I’d done nothing wrong. The call felt aligned, and the tool felt valuable.
The problem was that I didn’t stop to think when we got new information. I overlooked the fact that a change in scope meant less value for Daniel.
I had already argued that it takes two people to build the right thing, yet I kept pushing through on my own after getting new information. Yes, Daniel didn’t reply to my first email, but I should have followed up or insisted on another call. I should have asked:
Given those limitations, is the remaining workflow still valuable enough for you to pursue?
That would have saved me the time I spent writing a proposal for a scope Daniel no longer valued. It might also have led us to another way around the limitations, or a different workflow we could have explored together. I can’t know. What I do know is that I should have waited until the workflow was clear and agreed on.
Technically, everything went well. I understood the problem, the workflow and its limitations. I didn’t understand which parts mattered enough for Daniel to pay to change them.
I’ve learnt my lesson. Next time the scope changes in any meaningful way, I’ll get back on a call before I open the proposal document. If we can’t agree that what remains is still worth pursuing, there is no proposal to write yet.
Thanks for reading
Subscribe to CodedShapes to get more articles like this delivered to your inbox
Work with me: https://codedconstructs.com/contact/
Guides, Courses and Scripts : https://www.codedshapes.com/p/scripository