Negotiation Strategy and Tactics Questions

Direct answer

I would not fight the customer's changing needs; I would put a change-control mechanism around them so each new request has a visible path: capture it, size it, price it, decide it. Contractually that means a clearly defined baseline scope, a change-request clause with a price and schedule impact assessment, and an agreed phased delivery plan. Process-wise it means one intake channel, a regular governance meeting, and a transparent backlog. The customer stays happy because requests are welcomed and answered fast; they just stop being free and invisible.

Contractual changes

Scope creep is uncontrolled growth in what a project must deliver without matching changes to time, cost or resources. A change order is a signed amendment that adjusts scope, price and schedule together. A SOW (statement of work) defines deliverables for a project. A baseline is the agreed starting scope that every later change is measured against. A rate card is a pre-agreed price list for extra work. Acceptance criteria are the written tests a deliverable must pass to count as done. A spike is a short, time-boxed investigation to learn how big or risky something is before committing.

1. A baseline in the SOW: list in-scope deliverables, explicit out-of-scope items, and assumptions (for example "up to three integrations").
2. A change-request clause: any request outside the baseline needs a written request, an impact assessment within a set time (say five business days), and a signed change order before work starts.
3. A contingency or flexibility pool: a pre-agreed number of hours or a budget (for example 10% of project value) that can be drawn without a full renegotiation, so small requests do not cause friction.
4. Rate card: pre-agreed rates for extra work, so pricing a change is not a new negotiation.
5. Acceptance criteria and sign-off milestones: tie payments to accepted deliverables, which stops the target from drifting.

Process changes

• One owner on each side for change requests, one intake form.
• A weekly or bi-weekly change board (a short governance meeting, 30 minutes, where both sides review and decide on requests) that reviews the backlog, sizes each item and decides: do now, do in a later phase, or decline.
• A visible backlog (prioritised list of requested work) the customer can see, so "unspecified" requests become specified ones.

Strict specs versus iterative reality

Rigid specs reduce disputes but break when the customer genuinely learns as they go. Pure iteration welcomes change but makes cost unbounded. My recommendation is a middle path: fix the next phase tightly, keep later phases outlined but not committed. To persuade the customer: "Let us lock phase one firmly so you get a working result on a known date. We keep phases two and three flexible, and each is re-scoped with you at the start, with a price attached." The customer gets a say; I get a boundary.

Mid-contract architecture change request

Suppose the customer asks, halfway through, for a different architecture (say moving from batch processing, where data is handled in scheduled bulk runs, to real-time processing, where it is handled as it arrives). Options:

I would recommend the spike, then phased. Communication: to the customer, "Here is the effect on cost and date of each option, and my recommendation." Internally, to my manager and delivery lead, the margin and capacity implications before I commit anything, so nobody learns of a commercial consequence after the customer does.

Worked example (illustrative)

Project: $300,000, 6 months. Customer requests unspecified reporting features. I size the first at 80 hours at a $150 rate card (assumed) = $12,000. With two engineers each giving 40 hours a week, 80 hours is one week of delay. The change board offers: (a) approve with a change order, (b) defer to phase two, (c) swap for a lower-value item of equal size. If the contract has the 10% contingency pool from above, 10% of $300,000 = $30,000, which is 200 hours at $150. Option (a) can then be paid from the pool with no new negotiation, leaving $30,000 - $12,000 = $18,000 (120 hours) for later requests; once the pool is gone, every further request needs a change order. Choosing (c) keeps the date and price, which customers often prefer. In words: "I can fit the reporting features if we swap out the dashboard theming work, which is the same size. The date and the $300,000 price stay as they are. Would you like to make that swap, or shall I price it as an addition?"

Pitfalls

• Saying no repeatedly damages the relationship; saying "yes, and here is what it costs and when" does not.
• Verbal approvals are where creep hides. Nothing starts without a signed change.
• Watch for goodwill drift (free small favours that accumulate until they are expected). Track them and show them at review time.

Direct answer

I sort terms by asking what happens if I do not get each one. If the consequence is a legal, security or operational failure, it is non-negotiable. If it moves value for both sides in different amounts, it is tradeable. If it costs me little and the other side values it, it is a cheap give. Then I test the sorting with the people who own the risk before I sit down.

The three buckets

That is 4 + 4 + 3 = 11 terms. Non-negotiables are defined by consequence (regulatory exposure, security, interoperability, recovery), not by how strongly someone feels. A stakeholder's "must have" often turns out to be a preference when asked: "what happens if we cannot get this?" Example: engineering says 99.99% uptime is a must have. Asked what happens at 99.9%, they work out it is about 8.8 hours of downtime a year instead of about 53 minutes, and that credits and a fast fix cover it for a non-customer-facing system. It moves to tradeable.

Scoring method

For each term, estimate (a) what it costs me to give, and (b) what it is worth to them, each on a 1 to 5 scale agreed with finance. Cheap for me and valuable to them is a give. Costly for me to give and worth little to them is something to hold back, since it buys nothing in a trade; the mirror image (cheap for them to give and valuable to me) is what I ask for. Costly for both is where the real bargaining happens. Worked scores (assumed): reference or logo use costs me 1 and is worth 4 to them, so it is a give. Quarterly review cadence: cost 1, worth 2, also a cheap give. Payment terms: cost 3 (cash timing), worth 4, tradeable. Unit price: cost 5, worth 5, the real bargaining. Term length: cost 3 (lock-in), worth 5, a strong trade for price.

Learning their sort on a discovery call (an early fact-finding conversation with the other side before formal negotiation)

Ask: "If one thing had to be right at signing, what would it be?", "Which terms have approvals you cannot change?", "What has gone wrong in previous deals like this?" Their answers tell you which of their asks are real constraints and which are opening positions.

Validating the sort internally

1. Draft a one-page sheet: term, bucket, reason, the walk-away point (the line below which I leave without a deal).
2. Hold a short review with legal, security, finance, the engineering lead and the executive sponsor (the senior person who can settle disputes). Ask each: "what would make you reject this deal?" and "what could you live with?"
3. Challenge every non-negotiable with the consequence test; move preferences to tradeable.
4. Get the sponsor to sign off the walk-away list so I do not have to re-ask mid-negotiation.

Pitfalls

Too many non-negotiables leaves no room to trade; hiding the list from legal and security until late; giving away cheap items for free instead of in exchange for something.

Direct answer

I treat it as a negotiation about interests, not dates: the two weeks is Product's position, six weeks is Engineering's estimate, and neither is the real interest. I would find out why two weeks (a customer demo, a contract promise, a competitor) and what the minimum useful outcome is, then offer options that change scope, sequence or risk, and agree the plan in writing with acceptance criteria.

Key negotiation points

1. What is driving the date? A hard external deadline is different from a preference.
2. How confident is the estimate? Ask Engineering for a range and the biggest unknown, not one number.
3. What is the minimum viable subset of each feature that delivers the outcome? Agree acceptance criteria for each in words a tester can check.
4. Technical debt: if shortcuts are taken, say what they are, write the paydown ticket, and agree when it will be done, so debt is a conscious loan. A shortcut is, for example, hard-coding a value that should be configurable, or skipping automated tests for a feature: it ships sooner but every later change to that code costs more, like interest. The paydown ticket would read "add tests and make the value configurable, 3 days, scheduled for the sprint after launch."
5. Capacity: adding people late rarely speeds up a project (onboarding and coordination cost); check what other work competes.
6. Who decides trade-offs if the plan slips? Agree in advance.

Options on the table (illustrative estimates: F1 = 1.5 weeks, F2 = 2 weeks, F3 = 2.5 weeks, total 6)

Check: 1.5 + 0.5 = 2 weeks; remaining F2 is 1.5 weeks, so 2 + 1.5 = 3.5; then F3 2.5 gives 6. The numbers add up to the original six weeks, so Option B gives early value without pretending the total effort shrinks.

How we reach agreement

In the conversation: "Help me understand what happens on day 14 if only feature 1 is live." If the answer is a demo to one customer, Option B or C probably satisfies the interest.
PM: "We need all three on day 14."
Engineering lead: "All three is six weeks. What does the customer need to see?"
PM: "Feature 1 working, and some sign that 2 and 3 are coming."
Engineering lead: "Then feature 1 plus the core of feature 2 by day 14, rest of 2 at week 3.5, feature 3 at week 6. Can you accept that and a re-estimate after week 1?" I would recommend B if the deadline is real and C if the thin versions still meet the goal. Then I write up a half-page plan: features and acceptance criteria per milestone, the debt ticket, a checkpoint at the end of week 1 to re-estimate, and the named owner who may change scope.

A lightweight framework for any product-versus-engineering trade-off

Ask four questions: (1) what outcome and by when, and why? (2) how sure are we of each estimate? (3) what can be cut, sequenced or staged? (4) what risk are we accepting, and who signs for it?

Trade-offs and pitfalls

• Agreeing to the date and quietly absorbing the gap damages trust the next time estimates are given.
• Splitting the difference (4 weeks) without changing scope just creates a different missed date.
• If the two-week date is a promise to a customer with penalties, the conversation changes: scope or resources must move, and leadership may need to decide.

Direct answer

With three or more parties the main differences from a two-party negotiation are that coalitions form, that a deal needs every necessary party, and that one party can block. So I prepare by mapping each party's interests, alternatives and power, find which combinations could make a deal, and manage the process: who talks to whom, in what order, and with what proposals. I look for trades that cost one party little and are worth a lot to another, because that is the only way partly conflicting interests are reconciled.

Prepare

1. Map the parties. For each: what they want (interests, not positions), their best alternative to a negotiated agreement (BATNA), what they can concede, and who can veto.
2. Find the ZOPA, the zone of possible agreement, which is the range where a deal would beat every party's alternative. In a multi-party case, check each party in turn: does the draft package beat that party's alternative? If yes for everyone, a zone exists for all; if one party's alternative is better than any package I can afford, the zone exists only for a subset and I build around that party (see the example below).
3. Differences in value. Look for items valued differently by different parties (timing, risk, brand, volume). Those are the tradeable items.
4. My own position. My alternative, my priorities, and what I give for what.

Worked example (illustrative)

A software upsell (selling more to an existing customer) where three groups at the customer want different things: procurement (the buying department that negotiates price and contract terms) wants a lower price, the power users want more features and training, and the chief information officer (CIO) wants security and a single vendor. A single "price" negotiation will fail because the price is only procurement's concern.

Package: a 3-year term and price cap (procurement), included training and early access to the features users want (power users), and a security addendum plus a consolidation plan (CIO). Each party gets its main concern, and what I give costs me less than a price cut would. With assumed numbers: a three-year base of $300,000 ($100,000 a year) and a 10% unit price cut costs me $30,000. Instead, a 3% yearly cap against my normal 7% rise costs me $321,490 - $309,090 = $12,400, training is 20 hours at $120 loaded cost = $2,400, and the security addendum and plan is 40 hours at $150 = $6,000. The package costs about $20,800, roughly $9,200 less than the price cut, and it meets three different needs. For a like-for-like basis: the cap is costed against a normal 7% yearly rise, so the price cut should be too. A 10% cut on the $321,490 I would otherwise have billed is $32,149, so the package is about $11,349 cheaper on that basis, and the ranking does not change. ZOPA test for procurement: their alternative is a rival quote of $310,000 over three years, and our capped total of $309,090 is below it, so the deal is inside their zone. If the CIO's alternative were stronger than anything I could offer (they would rather stay with a rival), the zone would exist only for procurement and the power users, and I would build the deal around those two and bring the CIO in on better terms.

Manage the process

• Sequence. Meet the parties separately first (to learn real interests), then bring the shared proposal together. Start with the party that can block most and cares least about price: here the CIO, who holds a budget veto and cares about security, not price.
• Avoid sides. Do not let two parties lock into a coalition (an alliance of two against the third); keep proposals whole, so nobody can cherry-pick (take the parts they like and drop the parts that were the price of them).
• Shuttle and test. Shuttle means carrying proposals between parties one at a time instead of meeting all together. Test a proposal privately ("if the CIO's needs were met, would you support this?") before the joint session.
• Concession order. Concede early on items that cost me little and that unlock someone's support; hold the item that costs most until the end, and trade it only for a commitment.
• Keep a visible record of what is agreed so a party cannot reopen it.

Trade-offs and pitfalls

• Each side-conversation can create the suspicion of secret deals; be transparent about the process even if not about positions.
• A deal that satisfies everybody superficially but leaves one party unconvinced will fail in implementation. Check support (will they actively help make it work?), not just consent (will they not object?).
• What would change my call: when one party's alternative is very strong, I may build a deal with the other two first and add the third on better terms.

Direct answer

I would not sign a flat $2.5M for three years on day one. I would structure it as a staged commitment: a short pilot against written success criteria, a smaller firm commitment, milestone-based releases of the rest, and exit terms that let us leave without being trapped. The terms I rank highest are, in order: the pilot and its exit rights, payment tied to milestones, price caps and usage floors that limit what we can be forced to pay, service-level agreements (SLAs) with real remedies, and data portability. Together these make the vendor carry part of the risk.

Terms: committed-usage discount is a lower unit price in exchange for promising to buy a minimum volume. A usage floor is the minimum we must pay for. A pilot and a PoC are the same thing here: a short, limited trial before the main commitment. A tranche is one instalment of the total payment. Non-cancellable means we cannot cancel and must pay regardless. An anchor is the first, ambitious position that the final deal is pulled toward. A price cap limits how much prices can rise at renewal. A PoC (proof of concept) is a limited trial to test that the product works for our case. SLA means service-level agreement, with service credits (refunds) if missed. TCO means total cost of ownership (the full cost of buying and running the product over its life). I assume the business case already produced the three value scenarios below, and here I use only those numbers.

Step 1: Know our walk-away (the point at which we leave the deal) and their incentives

Before negotiating I work out my BATNA (best alternative to a negotiated agreement): the next-best vendor, building in-house, or staying with what we have. I also work out what the vendor wants: a headline contract value, committed revenue, a reference logo (a named customer they can show to other buyers), and a good quarter-end (closing deals before their sales period ends). Those are things I can trade (multi-year commitment, a public case study) in exchange for risk-sharing terms.

Step 2: The structure

1. Paid pilot (60 to 90 days) with written success criteria (for example: query latency, data from three source systems loaded, 20 named users active, accuracy checks agreed). If the vendor demands non-cancellable annual fees for a PoC, I push back: pilot fee capped, credited in full against the later commitment if we proceed, refundable or terminable if criteria are missed.
2. Staged commitment. Phase 1 firm, phases 2 and 3 released by milestones.
3. Milestone-based payments: each tranche paid only when its milestone is accepted in writing.
4. Price caps and floors: annual price increase capped (for example 5% a year); usage floor set at a level we are confident to reach (say 70% of forecast), with a rollover of unused volume; a true-up (a later adjustment for actual use) only upward at the agreed unit price. Worked example (the $2.5M is the total over the three-year term): forecast 100,000 units over the whole term at $25 is $2.5M, about 33,000 units a year; a 70% floor means we pay for at least 70,000 units over the term ($1.75M) even if we use only 50,000, which protects us from paying for the full forecast if adoption disappoints. With a rollover, the 20,000 unused units are credited to next year. If we use 120,000, the true-up charges the extra 20,000 at $25, with no penalty rate.
5. Performance SLAs: availability target, support response times, with service credits and a right to terminate for repeated misses.
6. Data portability and exit: our data remains ours, exportable in an open format (one that other software can read, not a vendor-only file type) at any time, with transition help for a fixed number of days at agreed rates, and a termination-for-convenience right (the right to end the contract without having to show a fault) after year 1 with a declining exit fee (a charge for leaving early that falls each year).
7. Outcome-linked incentives: part of the fee depends on a measured result we both define.
8. Vendor KPIs and compliance: key performance indicators (measures such as ticket resolution time) reviewed quarterly, with reporting duties, audit rights for security and data ownership, and milestones written into the contract, not into an email.

Step 3: Compare fixed, success-based and hybrid pricing by downside exposure

Assumptions (illustrative): a three-year, $2.5M proposal. Value we realise over three years under three scenarios: worst $1.0M, expected $4.0M, best $6.0M. "Net" means value realised minus what we pay (internal implementation cost left out).

Arithmetic: success-based worst is 35% x $1.0M = $0.35M, raised to the $0.5M floor; expected 35% x $4.0M = $1.4M; best 35% x $6.0M = $2.1M (under the $3.0M cap). Net = value minus payment: $1.0M - $0.5M = +$0.5M; $4.0M - $1.4M = $2.6M; $6.0M - $2.1M = $3.9M.

Reading it: fixed fee has the largest downside (we lose $1.5M if the product disappoints). Hybrid cuts the worst case from -$1.5M to -$0.5M and costs nothing in the expected and best cases. Pure success-based looks best for us on every line, which is why a vendor will usually refuse it or want a high floor and a clear measurement rule. My recommendation: ask for the hybrid and open with success-based as the anchor (the ambitious first position) to pull the final deal toward the hybrid. The three scenario values come from the pilot results, reference customers' reported results and our own adoption forecast; I would test them with the vendor's own case studies.

Step 4: Present best, expected and worst commercial scenarios to win concessions

I show the vendor three consumption scenarios for the commitment. "If we reach the best case, you earn $X and we expand; if worst, we still pay the floor." This helps win a committed-usage discount and better payment terms (net 60, meaning invoices are due 60 days after receipt, or milestone-based instead of annual in advance), because the vendor can see the revenue it gets in exchange.

Step 5: Terms that matter most to me, ranked

Items 1 to 5 protect us most; item 6 matters less and is the first to trade away.

1. Pilot with written success criteria and exit rights.
2. Milestone-based payment.
3. Usage floor and rollover, and price caps.
4. SLAs with service credits and termination rights.
5. Data ownership, portability and exit assistance.
6. Outcome-linked incentives and KPI reporting.

Pitfalls

Defining success loosely ("improved insight"); signing the pilot's annual fee as non-cancellable and then being locked in; a usage floor above realistic demand; forgetting data export costs; negotiating price while ignoring exit. What would change my ranking: a regulated workload would move data portability and security terms to the top.