Part 022 — Meaningful Demos, Honest Progress, and Review Anti-Patterns

Positioning

Tidak semua product value memiliki UI yang mudah didemokan.

Enterprise teams sering mengerjakan:

• API;
• event;
• migration;
• reliability;
• observability;
• security;
• performance;
• architecture;
• deployment capability;
• and operational tooling.

Tantangannya adalah menunjukkan progress secara jujur tanpa:

• membuat stakeholder melihat detail teknis yang tidak relevan;
• menyamarkan incomplete work;
• atau mengklaim value yang belum tersedia.

Core thesis: demo yang bermakna menunjukkan perubahan capability, evidence, dan consequence—bukan sekadar layar atau code.

1. Demo as Evidence, Not Performance

Tujuan demo adalah membantu inspection.

Bukan:

• membuat team terlihat berhasil;
• menunjukkan semua ticket;
• atau menghindari pertanyaan sulit.

A meaningful demo answers:

What can the system or user do now?
What evidence proves it?
What remains unsupported?
Why does it matter?

2. Visible versus Invisible Work

Visible work

• UI;
• workflow;
• report;
• configuration.

Invisible work

• API;
• event;
• data migration;
• idempotency;
• observability;
• security;
• performance;
• deployment;
• and architecture.

Invisible work still has observable consequence.

3. Demonstrating Backend Work

Backend work can be demonstrated through:

• API request/response;
• state transition;
• event payload;
• contract test;
• trace;
• audit;
• downstream effect;
• and failure handling.

Avoid showing code unless the audience needs it.

4. Backend Demo Narrative

Problem:
Previous behavior:
New capability:
Evidence:
Failure behavior:
Business/operational impact:
Known limitation:

5. Demonstrating API Work

Show:

• actor or consumer;
• request;
• response;
• validation;
• error semantics;
• compatibility;
• and observability.

Weak API demo

A terminal call without context.

Strong API demo

Shows how consumer behavior becomes possible or safer.

6. Demonstrating Event Work

Show:

• producer action;
• event;
• consumer reaction;
• correlation;
• duplicate/out-of-order behavior;
• and compatibility evidence.

Event existence alone is not value.

7. Demonstrating Data Work

Possible evidence:

• migration report;
• before/after data;
• validation query;
• reconciliation result;
• rollback/containment;
• and lineage.

Do not show sensitive production data improperly.

8. Demonstrating Reliability Work

Reliability work is demonstrated through failure.

Examples:

• dependency timeout;
• retry;
• idempotency;
• fallback;
• circuit protection;
• and recovery.

Narrative:

Before:
Failure caused duplicate order.

After:
Duplicate request is detected and one order is created.

Evidence:
Trace, metric, and test.

9. Demonstrating Observability Work

Show how a real question can now be answered.

Example:

Why is this order stuck?

Evidence:

• status;
• trace;
• metric;
• correlation ID;
• alert;
• and runbook.

Avoid demoing “we added logs” without diagnostic outcome.

10. Demonstrating Security Work

Security work can be shown through:

• denied action;
• no data leakage;
• audit event;
• role behavior;
• tenant isolation;
• and security test evidence.

Do not expose sensitive exploit detail to inappropriate audience.

11. Demonstrating Performance Work

Show:

• baseline;
• workload;
• percentile;
• result;
• and trade-off.

Example:

Before:
p95 = 4.8s at 100 concurrent requests

After:
p95 = 1.9s under same workload

Avoid cherry-picked average.

12. Demonstrating Architecture Work

Architecture value should be shown through capability.

Examples:

• independent deployment;
• lower change scope;
• contract isolation;
• safer migration;
• faster test;
• or reduced blast radius.

Diagram can support explanation, but consequence is primary.

13. Demonstrating Platform Work

Platform work may show:

• self-service deployment;
• environment provisioning;
• pipeline speed;
• rollback;
• or standard observability.

Show a developer or team outcome.

Not only infrastructure components.

14. Demonstrating Test Work

Test work has value when it:

• catches known failure;
• protects contract;
• shortens feedback;
• or increases release confidence.

Demo:

• failure before fix;
• test detects it;
• fix passes;
• pipeline evidence.

Avoid treating test count as value.

15. Demonstrating Migration Work

Migration demo should cover:

• scope;
• source;
• target;
• validation;
• mismatch;
• rollback/containment;
• and remaining stages.

A migration script that runs is not enough.

16. Demonstrating Documentation or Supportability

Show:

• support can answer question;
• runbook enables recovery;
• release note clarifies behavior;
• or onboarding time reduced.

Documentation value is in use.

17. Partial Work

Partial work can be shown if status is explicit.

Possible labels:

• prototype;
• spike result;
• internal milestone;
• integrated but not released;
• pilot-only;
• incomplete Increment.

Do not call all of them Done.

18. Demoing a Spike

A spike demo should show:

• question;
• method;
• evidence;
• conclusion;
• remaining uncertainty;
• and decision unlocked.

The output is learning.

19. Demoing a Prototype

Clarify:

• what is simulated;
• what is real;
• what is disposable;
• and what question is being tested.

Do not let prototype quality imply production readiness.

20. Demoing an Internal Milestone

Examples:

• contract agreed;
• environment available;
• architecture decision complete.

State:

• why it matters;
• what it enables;
• and why it is not yet product value.

21. Demoing Pilot-Only Capability

Show:

• target tenant;
• rollout control;
• metrics;
• known limits;
• and expansion criteria.

This supports evidence-based rollout.

22. Honest Status Vocabulary

Use precise terms:

23. Demoing Failure

A strong demo may intentionally show failure.

Examples:

• invalid permission;
• dependency timeout;
• duplicate request;
• incompatible event;
• and rollback.

This proves resilience and expected behavior.

24. Demoing Known Limitations

Use:

Supported now:
Not supported:
Risk:
Workaround:
Next decision:

This improves trust.

25. Demo Storytelling

A useful narrative:

Actor
-> Problem
-> Trigger
-> New behavior
-> Evidence
-> Failure behavior
-> Outcome

Keep technical detail tied to decision.

26. Choosing the Audience Depth

Product audience

Focus on behavior and outcome.

Technical stakeholder

Add contract, architecture, and risk.

Operations/support

Add diagnosis and recovery.

Security/compliance

Add control and evidence.

One demo may use layers.

27. Demo Layers

Layer 1:
Business behavior.

Layer 2:
Quality and operational evidence.

Layer 3:
Technical implementation detail if needed.

Start with Layer 1.

28. Demo Data

Demo data should be:

• representative;
• safe;
• understandable;
• and reproducible.

Avoid:

• real customer data without approval;
• unrealistic happy-only data;
• or data that hides edge behavior.

29. Demo Environment Reliability

Before Review:

• deploy correct version;
• verify dependency;
• prepare fallback evidence;
• and confirm feature flags.

But do not over-rehearse away real limitations.

30. Recorded Evidence

For remote or unstable environments, recorded evidence may support.

But it should not replace live inspection when live behavior is the key question.

State when evidence was captured and under what conditions.

31. Demo Failure during Review

If live demo fails:

• do not hide;
• explain observed state;
• use logs/evidence;
• determine whether failure reveals product issue or demo setup issue;
• and capture follow-up.

A failed demo can still create valuable inspection.

32. Performative Demo Anti-Patterns

Happy-path theater

Only perfect path.

Mock masquerading as integration

Dependency not real.

UI bias

Backend value ignored.

Code tour

Audience cannot infer outcome.

Dashboard vanity

Metric without question.

Slideware architecture

No evidence.

Partial work inflation

Internal milestone called Done.

Rehearsal concealment

Known limitation omitted.

33. Invisible Work Value Translation

Use this chain:

Technical change
-> System capability
-> Risk or flow impact
-> Product/business consequence

Example:

Contract test
-> detects incompatible event change
-> prevents coordinated production failure
-> protects order processing continuity

34. Engineering Work and Product Backlog

Invisible work should still have:

• problem;
• consequence;
• scope;
• acceptance evidence;
• and outcome.

Demo becomes easier when backlog item was framed well.

35. Demoing Technical Debt Reduction

Weak:

We refactored the service.

Strong:

Approval rule evaluation now has one source of truth; the two defect-prone duplicated paths were removed, and the next rule variation requires one change instead of three.

Evidence:

• code path;
• test;
• defect risk;
• and change impact.

36. Demoing CI/CD Improvement

Show:

• before/after feedback time;
• failure detection;
• automated rollback;
• or deployment steps removed.

Example:

Pipeline time reduced from 28 to 14 minutes.
Contract failure now appears before deployment stage.

37. Demoing Observability in Context

Use a realistic scenario.

Customer reports stuck order.
Support searches correlation ID.
Dashboard shows failed transition.
Trace identifies timeout.
Runbook defines retry.

The value is diagnostic capability.

38. Demoing Reliability with Chaos or Simulation

Use controlled failure injection if safe.

Examples:

• timeout;
• duplicate message;
• unavailable dependency;
• and slow response.

State test environment and limitations.

39. Demoing Compatibility

Show:

• old consumer with new producer;
• new consumer with old producer;
• version matrix;
• contract result;
• and fallback.

Compatibility is especially important for enterprise integration.

40. Demoing Security without Risk

Show control outcome, not sensitive exploit detail.

Examples:

• denied access;
• audit;
• masked data;
• role boundary.

Coordinate with security policy.

41. Senior Engineer Operating Model

Before Review

• frame technical work in consequence terms;
• choose evidence;
• validate limitations;
• and avoid jargon-first narrative.

During Review

• be precise about readiness;
• show failure behavior;
• explain risk;
• and separate current capability from future option.

After Review

• capture feedback;
• update technical backlog;
• and record rollout/architecture decision.

Guardrail

Never exaggerate progress to protect team image.

42. Worked Example: Order Observability

Technical work

• correlation IDs;
• state-age metric;
• terminal reason;
• support dashboard.

Demo narrative

1. A quote is submitted.
2. Downstream order stalls.
3. Metric detects age threshold.
4. Alert fires.
5. Support opens dashboard.
6. Trace identifies failing dependency.
7. Runbook provides next step.

Outcome

Diagnosis without database access.

43. Worked Example: Event Compatibility

Technical work

Add optional approval metadata.

Demo

• old consumer processes event;
• new consumer reads metadata;
• contract tests pass;
• trace shows both paths;
• flag controls producer.

Outcome

Incremental rollout without coordinated deployment.

44. Worked Example: Partial Migration

Status

Pilot tenant migrated; full migration incomplete.

Honest demo

• migration report;
• validation;
• mismatch handling;
• rollback;
• remaining tenants;
• and expansion criteria.

Do not claim full migration.

45. Demo Checklist

Context

• Problem clear?
• Actor clear?
• Outcome clear?

Evidence

• Real behavior?
• Relevant quality evidence?
• Failure behavior?
• Operational evidence?

Honesty

• Mock disclosed?
• Limitation disclosed?
• Release state accurate?
• Partial status accurate?

Decision

• Feedback question clear?
• Next decision clear?
• Backlog impact captured?

46. Process Smells

• backend work never reviewed;
• technical work shown only as code;
• demos always happy path;
• mock dependency undisclosed;
• no known limitation section;
• and stakeholders equate deployed with released.

47. Internal Verification Checklist

Demo convention

• What does the team usually demo?
• Are backend/invisible changes expected?
• Are partial items allowed?
• What vocabulary is used for readiness?

Evidence

• Are traces, metrics, contract tests, and migration reports available?
• Can supportability be demonstrated?
• Are performance baselines stored?
• Is operational evidence part of DoD?

Environment

• Which environment is used?
• Are mocks disclosed?
• Is data safe?
• Is demo reproducible?

Review expectations

• Do stakeholders expect UI only?
• Can technical work be explained in product terms?
• Is feedback captured?
• Are limitations welcomed or penalized?

48. Practical Exercises

Exercise 1 — Translate technical value

Take five technical tasks and write the capability-risk-outcome chain.

Exercise 2 — Backend demo

Design a five-minute API or event demo without code tour.

Exercise 3 — Failure demo

Choose one resilience behavior and show controlled failure.

Exercise 4 — Honest status

Classify a current feature as implemented, integrated, validated, releasable, deployed, released, or adopted.

Exercise 5 — Migration review

Create a demo plan for one partial migration stage.

49. Part Completion Checklist

You are done if you can:

• demonstrate backend and invisible work;
• distinguish partial work from Done Increment;
• translate technical work into consequence;
• show reliability, observability, performance, security, migration, and compatibility evidence;
• disclose limitations;
• and avoid performative demos.

50. Key Takeaways

1. Demo is evidence, not performance.
2. Invisible work has observable consequence.
3. Code is rarely the best stakeholder evidence.
4. Partial work must be labeled precisely.
5. Failure behavior is worth demonstrating.
6. Reliability and observability should be shown in context.
7. Architecture value must connect to capability.
8. Honest limitation improves trust.
9. Senior engineers translate technical work into product consequence.
10. Internal demo expectations must be verified.

51. References

Conceptual baseline:

• The Scrum Guide.
• General product demonstration, technical communication, reliability, observability, and continuous delivery practices.

These concepts do not describe internal CSG processes.