solutions-playbook-builder
Agent: Solutions Engineering Manager
L2 solutions engineering manager (1x) responsible for technical buyer signal extraction and solutions playbook development.
Department ethos: ideal-sales.md
Tool policy: allowed-tools.yaml
Skill Description
Builds the solutions engineering playbook including technical discovery questions, POC criteria, demo frameworks, and technical qualification standards that SEs execute consistently.
When to Use
- When the SE team has no standardized playbook and technical discovery quality varies across reps.
- When onboarding new SEs who need a structured framework for technical engagement.
- When POC win rates are low or POC scope creep is consuming SE capacity without proportional deal closure.
Workflow
- Technical Discovery Framework: Build a structured technical discovery question bank organized by evaluation phase: environment assessment (current stack, integration requirements, security constraints), use case validation (primary workflows, edge cases, scale requirements), and decision criteria mapping (must-haves, nice-to-haves, dealbreakers). Deliverable: technical discovery question bank with phase tags.
- POC Criteria Definition: Define POC entry criteria (minimum deal size, qualification score, executive sponsor confirmed), scope boundaries (maximum duration, feature set, success metrics), and exit criteria (pass/fail thresholds, decision timeline commitment). Deliverable: POC qualification and scoping framework.
- Demo Framework: Build demo frameworks for each buyer persona: technical evaluator (architecture, APIs, integration), business buyer (outcomes, ROI, workflow), and end user (UX, daily workflow). Define demo environment requirements and setup procedures. Deliverable: persona-specific demo frameworks with environment specs.
- Technical Objection Library: Document common technical objections with evidence-based responses: security concerns (certifications, architecture), scalability questions (benchmarks, reference architectures), and integration complexity (API documentation, pre-built connectors). Deliverable: technical objection library with proof points.
- Competitive Technical Analysis: Create technical comparison matrices against the top 3 competitors covering architecture, performance, integration ecosystem, security posture, and deployment model. Include "trap questions" SEs can use to expose competitor weaknesses. Deliverable: competitive technical matrices with trap questions.
- SE Engagement Model: Define when and how SEs engage in the deal cycle: stage-gate entry points, time allocation per deal tier, and escalation criteria for complex technical requirements. Deliverable: SE engagement model with capacity guidelines.
- Assembly and Review: Assemble all components into a navigable playbook. Review with VP Sales and 2 senior SEs. Incorporate feedback and publish with a quarterly update cadence. Deliverable: complete solutions engineering playbook v1.0.
Anti-Patterns
- Demo-first engagement: Allowing SEs to jump into demos before technical discovery. Why: demos without discovery produce generic presentations that do not address the prospect's specific technical concerns; this wastes SE time and fails to differentiate.
- Unbounded POCs: Running POCs without predefined scope, success criteria, or time limits. Why: unbounded POCs become free consulting engagements that consume SE capacity without correlating to deal progression; prospects use them to delay decisions.
- One-size-fits-all demos: Using the same demo for technical evaluators, business buyers, and end users. Why: each persona cares about different things; a deep API demo alienates business buyers while a high-level overview fails to satisfy technical evaluators.
- Building without SE input: Creating the playbook from management perspective without incorporating what top-performing SEs actually do in technical engagements. Why: SE workflows have nuances (deal room dynamics, live troubleshooting, technical credibility building) that management prescriptions miss.
Output
On success: Produces a complete solutions engineering playbook containing technical discovery framework, POC criteria, demo frameworks, technical objection library, competitive technical matrices, and SE engagement model. Delivered to the SE team with an enablement session scheduled.
On failure: Report which playbook section could not be completed (e.g., insufficient competitive technical data, no POC outcome data to inform criteria), what was attempted, and what inputs are needed.
Related Skills
1---2name: solutions-playbook-builder3description: This skill builds the solutions engineering playbook including technical discovery questions and POC criteria. Use when asked to create SE enablement materials, define POC standards, or document technical qualification criteria. Also consider when SEs lack standardized technical discovery frameworks. Suggest when SE win rates diverge significantly across the team.4---56# solutions-playbook-builder78## Agent: Solutions Engineering Manager910L2 solutions engineering manager (1x) responsible for technical buyer signal extraction and solutions playbook development.1112Department ethos: [ideal-sales.md](../../../../departments/sales/ideal-sales.md)13Tool policy: [allowed-tools.yaml](../../../../allowed-tools.yaml)1415## Skill Description1617Builds the solutions engineering playbook including technical discovery questions, POC criteria, demo frameworks, and technical qualification standards that SEs execute consistently.1819## When to Use2021- When the SE team has no standardized playbook and technical discovery quality varies across reps.22- When onboarding new SEs who need a structured framework for technical engagement.23- When POC win rates are low or POC scope creep is consuming SE capacity without proportional deal closure.2425## Workflow26271. **Technical Discovery Framework**: Build a structured technical discovery question bank organized by evaluation phase: environment assessment (current stack, integration requirements, security constraints), use case validation (primary workflows, edge cases, scale requirements), and decision criteria mapping (must-haves, nice-to-haves, dealbreakers). Deliverable: technical discovery question bank with phase tags.282. **POC Criteria Definition**: Define POC entry criteria (minimum deal size, qualification score, executive sponsor confirmed), scope boundaries (maximum duration, feature set, success metrics), and exit criteria (pass/fail thresholds, decision timeline commitment). Deliverable: POC qualification and scoping framework.293. **Demo Framework**: Build demo frameworks for each buyer persona: technical evaluator (architecture, APIs, integration), business buyer (outcomes, ROI, workflow), and end user (UX, daily workflow). Define demo environment requirements and setup procedures. Deliverable: persona-specific demo frameworks with environment specs.304. **Technical Objection Library**: Document common technical objections with evidence-based responses: security concerns (certifications, architecture), scalability questions (benchmarks, reference architectures), and integration complexity (API documentation, pre-built connectors). Deliverable: technical objection library with proof points.315. **Competitive Technical Analysis**: Create technical comparison matrices against the top 3 competitors covering architecture, performance, integration ecosystem, security posture, and deployment model. Include "trap questions" SEs can use to expose competitor weaknesses. Deliverable: competitive technical matrices with trap questions.326. **SE Engagement Model**: Define when and how SEs engage in the deal cycle: stage-gate entry points, time allocation per deal tier, and escalation criteria for complex technical requirements. Deliverable: SE engagement model with capacity guidelines.337. **Assembly and Review**: Assemble all components into a navigable playbook. Review with VP Sales and 2 senior SEs. Incorporate feedback and publish with a quarterly update cadence. Deliverable: complete solutions engineering playbook v1.0.3435## Anti-Patterns3637- **Demo-first engagement**: Allowing SEs to jump into demos before technical discovery. *Why*: demos without discovery produce generic presentations that do not address the prospect's specific technical concerns; this wastes SE time and fails to differentiate.38- **Unbounded POCs**: Running POCs without predefined scope, success criteria, or time limits. *Why*: unbounded POCs become free consulting engagements that consume SE capacity without correlating to deal progression; prospects use them to delay decisions.39- **One-size-fits-all demos**: Using the same demo for technical evaluators, business buyers, and end users. *Why*: each persona cares about different things; a deep API demo alienates business buyers while a high-level overview fails to satisfy technical evaluators.40- **Building without SE input**: Creating the playbook from management perspective without incorporating what top-performing SEs actually do in technical engagements. *Why*: SE workflows have nuances (deal room dynamics, live troubleshooting, technical credibility building) that management prescriptions miss.4142## Output4344**On success**: Produces a complete solutions engineering playbook containing technical discovery framework, POC criteria, demo frameworks, technical objection library, competitive technical matrices, and SE engagement model. Delivered to the SE team with an enablement session scheduled.4546**On failure**: Report which playbook section could not be completed (e.g., insufficient competitive technical data, no POC outcome data to inform criteria), what was attempted, and what inputs are needed.4748## Related Skills4950- [`technical-buyer-signal-extractor`](../technical-buyer-signal-extractor/SKILL.md) -- Provides technical buyer signal data that informs playbook content.51- [`sales-playbook-builder`](../../../sales/sales-manager/sales-playbook-builder/SKILL.md) -- The sales counterpart playbook that aligns with the SE playbook on qualification and process.52- [`proof-of-concept-runner`](../../../sales/solutions-engineer/proof-of-concept-runner/SKILL.md) -- Executes POCs using the criteria and frameworks defined in this playbook.