Stakeholder Management & Customer Feedback Cycles

Software is built for people, and it succeeds only when the right people are informed, aligned, and involved at the right moments. This tutorial covers stakeholder management and the feedback cycles that keep a build honest.

Table of Contents

• Stakeholder Management
• Customer Feedback Cycles

Stakeholder Management

A stakeholder is anyone who is affected by or can affect the project. Stakeholder management is systematically identifying these people, understanding their interest and influence, and keeping them informed and engaged.

Why it is useful: Most failed projects fail politically, not technically. A stakeholder you ignored — a security team, a support desk, a finance controller — can quietly block a launch that was working fine.

Map Influence vs Interest

Plot each stakeholder on two axes to decide how much attention they need:

                HIGH INFLUENCE
   Keep satisfied              Manage closely
   (CISO, CFO)                 (Sponsor, customer IT lead)
   ---------------------+----------------------
   Monitor               Keep informed
   (other vendor teams)  (end users, support)
                LOW INFLUENCE
   ◄── LOW INTEREST ─────┼────── HIGH INTEREST ──►

• Manage closely: high interest, high influence — involve in every big decision
• Keep satisfied: high influence, low interest — update on changes, don't bury them
• Keep informed: low influence, high interest — tell them what's coming
• Monitor: low influence, low interest — occasional check only

Example: RACI for Key Activities

Simple explanation: RACI names the role each person plays in an activity. Responsible does the work, Accountable owns the outcome, Consulted gives input, Informed is kept in the loop. Filling this in kills the classic failure of "I thought they were handling it."

Best Practices

• Keep a living stakeholder list and update it as people and roles change
• Note each stakeholder's hot buttons and preferred channel (email, Slack, call)
• Over-communicate at the start of a project; pull back as trust builds
• Assign one main contact per stakeholder group so updates aren't chaotic

Customer Feedback Cycles

A feedback cycle is a recurring loop where the customer sees real progress, reacts to it, and their reaction shapes the next iteration. Shorter cycles mean less wasted work.

Why it is useful: Fixing a misunderstanding after two weeks of building costs days; catching it in a demo costs an hour. Feedback cycles are the cheapest correction mechanism you have.

The Loop

1. Demo the working software, not slides
2. Watch the customer use it and ask what surprised them
3. Log every piece of feedback
4. Triage it the same way you'd triage a change request
5. Close the loop: show next week that their feedback produced action

Example: Feedback Log

feedback = [
    {"date": "2026-08-25", "source": "Ops demo",
     "note": "Need bulk edit for a group of customers",
     "triage": "deferred to v2", "action": None},
    {"date": "2026-08-25", "source": "Ops demo",
     "note": "Export shows the wrong timezone",
     "triage": "accepted", "action": "Fix and ship by 08-27"},
]

for f in feedback:
    print(f"{f['triage']}: {f['note']}")

Simple explanation: Every comment gets logged and triaged, just like a change request. Note the difference: one piece becomes real work, the other is consciously deferred with a reason. That's what separates a feedback loop from a pile of opinions. And yes — this connects straight back to the change-request loop in the steering tutorial. Same brain, same rules.

Best Practices

• Demo working software every one to two weeks, even small bits
• Watch them use it and ask "what surprised you?" — that question surfaces assumptions
• Triage feedback consistently and tell the customer what was accepted, deferred, or rejected
• Never let feedback enter the build without the same scrutiny a change request gets