Harness Se

Default: Demo-Led (if not specified by user).

Methodology Selection Guide

Section 2: Development Methodology

Select based on deliverable type and engagement stage:

Default: Use-case-first for demos, Environment-first for POCs.

Generator First-Action Table

Section 3: Verification Strategy

Technical Validation Verification

Default for all sales engineering projects. The evaluator verifies each level is addressed.

Demo Readiness Verification

The evaluator MUST verify demo readiness before delivery:

Section 4: Deliverable Verification

Primary Deliverables

Supporting Deliverables

Governance Deliverables

Section 5: Evaluation Criteria (Sales Engineering Profile)

The 4 primary criteria for the sales_engineering domain profile. The evaluator MUST use these anchors for consistent scoring across sprints.

demo_completeness (0-5)

technical_validation (0-5)

solution_documentation (0-5)

integration_clarity (0-5)

Section 6: Sprint Contract Checklist Templates

Pre-built checklists for common sales engineering deliverable types. The generator includes the relevant checklist(s) in each sprint contract. The evaluator uses them as acceptance criteria.

Standard Contract Checks

These are the minimum required checks for every sales engineering sprint. Check IDs map to the 4 sales engineering evaluation criteria.

For Demo Deliverables

• All buyer-stated use cases mapped to demo steps
• Demo script has clear transitions between scenarios with talking points
• Timing plan fits within allocated presentation slot (with buffer)
• Demo environment validated and data seeded before delivery
• Fallback scenarios documented for top 3 likely failure modes (network, data, feature)
• Competitive differentiators highlighted at natural points in the flow
• Follow-up action items template prepared for post-demo capture
• Customer environment data (if used) handled per data classification requirements
• No customer production data in demo environment without explicit authorization

For POC Deliverables

• Success criteria defined in writing and agreed with buyer before POC starts
• Success criteria are measurable (not subjective "it works well")
• Environment requirements documented and validated before execution
• POC timeline defined with milestones and evaluation checkpoints
• Results documented against each success criterion with measured evidence
• Gap analysis included if any criteria not fully met, with mitigation options
• Recommendation provided (proceed to purchase / modify scope / stop)
• Customer data used in POC classified and handled per agreement
• POC environment decommissioned or data purged after evaluation per customer requirements

For Solution Design Deliverables

• Architecture diagram shows all system components and their relationships
• All integration points specified with protocol, authentication, data format
• Data flows documented including direction, frequency, and volume estimates
• Non-functional requirements addressed (performance targets, security, scalability, availability)
• Deployment model specified (cloud, on-premises, hybrid) with justification
• Sample API payloads provided for key integration points
• Risk assessment included for technical implementation risks
• Customer environment data and architecture details classified as confidential
• No customer infrastructure details shared outside authorized team

For Technical Comparison Deliverables

• All buyer evaluation criteria listed with product response for each
• Evidence type specified per criterion (demo, documentation, reference, POC result)
• Honest gap assessment included (not just strengths)
• Competitive positioning documented without disparaging specific competitors
• Scoring methodology explained if self-assessment scores provided
• Competitive intelligence sourced from public information only

Sales Engineering Anti-Patterns

These trigger automatic score penalties when detected by the evaluator:

Security Considerations

Domain-specific security guidance for sales engineering deliverables. Applies when data_sensitivity in spec.md is anything other than none.

Data Sensitivity:

• Customer environment data (architecture diagrams, network topologies, security configurations) obtained during technical discovery or POC must be classified as confidential
• POC data sets containing customer production data must be handled per the customer's data classification policy; synthetic data preferred over production data
• Performance test results revealing customer infrastructure capacity must not be shared outside the authorized engagement team

Access Control:

• Solution design documents containing customer-specific integration details must be restricted to the SE team and authorized project stakeholders
• POC environments with access to customer systems must use dedicated credentials with minimum necessary privileges; credentials must not be stored in code or shared documents
• Demo environments must be isolated from customer production systems; no persistent access retained after engagement concludes

Confidentiality:

• Customer architecture details and integration requirements must not be referenced in other customer engagements or marketing materials
• Competitive bake-off results, scoring, and evaluation criteria shared by the buyer must be treated as confidential per the engagement terms
• Technical discovery notes containing customer pain points, system limitations, or security vulnerabilities must be restricted to the account team