Negotiations is a complex subject, and certainly one that us engineer types normally don't get directly involved with. I had some exposure to this world early in my career, as an engineer for a small software house, getting involved in pre-sales support. My job was to get called into meeting and to say 'no'.
How this worked was that at a particular point in the sales cycle, the client would invariably ask a deep technical question (it was usually a tech from their side who had been brought along to the meeting for this very purpose). Our sales team would call on me, i'd turn up, hear the question, and my job was to say 'no' we couldn't solve that. I'd mention that we could do something close to what they had asked for, and maybe it was worth taking this discussion outside of the meeting. I'd swap cards with their tech, and we'd continue the discussion over the coming days.
This proved to be a very important part of the negotiations. They needed us to say no, our engineers and their engineers would start talking about implementation and how things would work together (where the boundaries were between systems). Their techs would give positive feedback to their management, and the deal would close.
Not sure I fully get it, but in this case you said "maybe"? Doing a workaround or even continuing to gather requirements is not really a "no", in my book.
I think maybe an example would be easiest. Let's say the client asked 'can your system respond within 10ms to requests?'. I'd say 'no it can't guarantee this'.
I'd then discuss how the system architecture couldn't give any hard latency guarantees, but that depending on the load and hardware they purchased we would generate different latency characteristics, say, 98% of requests processed within 10ms.
This would lead to an offline discussion and sharing some profiles for existing hardware configuration we'd tested, and maybe some estimates of the hardware costs to meet their requirements.
So I heard from the source material is its important to start with a "no" and then talk about how you can solve their problem with what you can do. In my book, that's not a "Maybe". Negotiators come in with a set of presumptions and its important to bust that bubble perceptually and then offer what you are capable of doing.
Comments
Negotiations is a complex subject, and certainly one that us engineer types normally don't get directly involved with. I had some exposure to this world early in my career, as an engineer for a small software house, getting involved in pre-sales support. My job was to get called into meeting and to say 'no'.
How this worked was that at a particular point in the sales cycle, the client would invariably ask a deep technical question (it was usually a tech from their side who had been brought along to the meeting for this very purpose). Our sales team would call on me, i'd turn up, hear the question, and my job was to say 'no' we couldn't solve that. I'd mention that we could do something close to what they had asked for, and maybe it was worth taking this discussion outside of the meeting. I'd swap cards with their tech, and we'd continue the discussion over the coming days.
This proved to be a very important part of the negotiations. They needed us to say no, our engineers and their engineers would start talking about implementation and how things would work together (where the boundaries were between systems). Their techs would give positive feedback to their management, and the deal would close.
Not sure I fully get it, but in this case you said "maybe"? Doing a workaround or even continuing to gather requirements is not really a "no", in my book.
I think maybe an example would be easiest. Let's say the client asked 'can your system respond within 10ms to requests?'. I'd say 'no it can't guarantee this'.
I'd then discuss how the system architecture couldn't give any hard latency guarantees, but that depending on the load and hardware they purchased we would generate different latency characteristics, say, 98% of requests processed within 10ms.
This would lead to an offline discussion and sharing some profiles for existing hardware configuration we'd tested, and maybe some estimates of the hardware costs to meet their requirements.
So I heard from the source material is its important to start with a "no" and then talk about how you can solve their problem with what you can do. In my book, that's not a "Maybe". Negotiators come in with a set of presumptions and its important to bust that bubble perceptually and then offer what you are capable of doing.