Panel Prep

Nicky Decision Board

This version is organized around decision quality: how to answer under pressure when the role is explicitly the interface between the partner business and IT.

Requirements translation
Data reality checks
MVP pressure
AI governance
Partner readiness
Salesforce credibility
Why Projects Get Stopped

Primary blocker: the company thinks you are putting proprietary data into a public LLM and losing control of it.

  • Security and privacy objections.
  • Low trust in model accuracy.
  • Non-deterministic output.
  • Weak prompting or bad workflow design.
  • Departments raising red flags: Legal, Finance, IT, Sales, Success Management.

Role Frame

I translate business intent into requirements IT can build and the business can trust.

Best Sentence

A requirement is not complete until it has been validated against real data and written as a testable scenario.

Interview Trap

If you design for the perfect path, production data will embarrass you in UAT.

What Nicky Wants

Structured thinking, not AI theater.

Scenario 1

30 Days to 10 Days

Prompt: Design an AI-enabled partner onboarding workflow across PRM, CRM, and support systems, with limited engineering capacity and imperfect data.

What to cover Current pain, target architecture, 30/60/90, risks, success metrics
MVP fight Everyone claims their step is essential, you decide what gets partners productive fastest
Best answer shape: define partner-ready, isolate real blockers, automate high-volume low-risk steps first, and keep high-risk decisions controlled.
  • Automation candidates: repetitive re-keying, routing, missing-field checks, status summaries, task generation.
  • Technical starting point: capture data once, validate centrally, then push to three to five systems through APIs, workflow automation, config, or middleware.
  • Quantum leap conditions: parallelize non-blocking steps, remove historical baggage, centralize status, reduce manual entry, tighten approvals.
  • Communication: leadership gets MVP tradeoffs, engineering gets precise field mappings, Partner Success gets workflow change and handoff impact.

Scenario 2

Requirements Failed in UAT

Prompt: The team delivered exactly to written requirements, but the system failed because zero-value customer orders still needed partner payment.

This was not mainly a coding failure. It was a requirements validation failure.
Stakeholder interviews described the process. Data sampling would have revealed the truth.
  • What went wrong: the process was modeled on the clean 20 percent instead of the messy 80 percent.
  • How to prevent it: sample real records early, inspect outliers, map field logic, define exceptions, and draft acceptance criteria with tests.
  • What Nicky was pushing on: can you catch what stakeholders forget to mention?
  • Correct stance: yes, test scenarios should be written at the same time as requirements so the edge cases are visible before UAT.

80 / 20 Lesson

The failure mattered because it was not a minor bug. The team had to rewrite the system and lost six weeks because stakeholder interviews were treated as truth without sampling the actual company data.

  • Perfect-scenario design ignored common exceptions.
  • Zero-value orders exposed the hidden payment rule.
  • Data reality should have been checked before build.

Success Measures

  • Operational: 30 to 10 days, event-by-event stage tracking, time per hurdle, engagement analytics.
  • Human: partner feedback loops, qualitative experience, evidence the partner understands purpose and next steps.
  • AI: deterministic outcomes, monitored quality, data accuracy, and maintained business trust.

Close With

Best framing: I help the business move faster without losing control, because I validate assumptions against data, translate them into buildable requirements, and put testing beside design instead of after it.