Sefism Forward Deployed and Solutions Engineering Cheat Sheet

What this cheat sheet is

The Forward deployed and solutions engineering cheat sheet is a quick-revision book for engineers moving into customer-facing engineering. It sits alongside the Forward deployed and solutions engineering roadmap and follows the same ten chapters, but instead of lessons it gives you short, scannable concepts: what each thing is, why it matters, and the mistake people make with it. Use it to compare the roles, run discovery with a ready question bank, structure a demo, check an integration before it ships, deploy AI at a customer and plan your way into the role.

Three editions, one per role

The sheet comes in three editions that match the roadmap's role choice: Forward deployed engineer, Solutions engineer and Sales engineer. Each edition has 10 chapters and 73 concepts. The concepts are shared; what changes is the framing at the top (shipping inside a customer's systems, designing how a customer adopts a product, or the technical half of a sale) and one of the rules of thumb, which reminds solutions and sales engineers to keep coding every week so the skill does not fade.

Chapter by chapter

1. The roles compared. Forward deployed, solutions and sales engineers side by side: when each works in the customer journey, what it produces and how it is measured. It includes Palantir's "one customer, many capabilities" framing, the split between pre-sale and post-sale work, adjacent roles such as implementation and technical account management that often lead in, and a realistic picture of a typical week.

2. Core engineering you still need. The base you lean on every day: a glue language you are fast in, SQL on someone else's data, HTTP and REST, Git in a customer's repository, cloud basics, debugging systems you did not build, and reading logs and traces. The pitfalls are practical, such as trusting a column called status that means three things in three systems, or asking for broad admin access to move faster.

3. Discovery and the customer's problem. What discovery is for, the critical business issue behind the technical symptom, a discovery question bank, a stakeholder map (champion, economic buyer, security, sponsor), the current-state workflow, measurable success criteria, scoping with an out-of-scope list, and technical discovery of systems, data, access and compliance.

4. Integrations, APIs and data plumbing. API authentication, webhooks and their signature checks, rate limits, retries and idempotency keys, pagination, data mapping and ETL, single sign-on with SAML, OIDC and SCIM, sandbox environments, security review questionnaires and an integration checklist to settle before go-live.

5. Fast prototypes and demos. The difference between a proof of concept, a pilot and a rapid prototype, a demo structure that starts with the result, Peter Cohan's "do the last thing first" principle from Great Demo!, a demo environment with a reset script and a recorded backup, and short recorded demos for stakeholders who were not in the room.

6. Writing and presenting to non-engineers. Answer first (the Pyramid Principle), solution design documents, executive summaries, weekly customer status updates, whiteboarding an architecture with the customer's systems in the centre, handling objections, and handover documentation built as you go rather than from memory in the final week.

7. AI deployment at a customer. Retrieval-augmented generation, chunking, embeddings and re-ranking, agents and tool use, MCP servers for customer systems, evaluations built from the customer's real cases, guardrails against prompt injection, human-in-the-loop review, and cost and latency in tokens, with the levers that bring them down.

8. Travel, on-site work and pressure. Working on customer infrastructure within their change process, customer confidentiality (including not pasting customer data into a personal AI tool), incidents with the customer watching, escalation paths, scope creep, saying no with options, and a sustainable pace.

9. Getting into the role. Reading a posting for coding, travel and quota signals, writing a deployment case study, internal moves, the typical shape of hiring loops, practising discovery and demos out loud, and how pay is structured, including on-target earnings for sales engineers and why OTE should not be compared with a base salary as if both were certain.

10. Growth paths. Field-to-product feedback with evidence, the specialist track, moving back to product engineering, moving into product management, leading a field team and the founder path.

Each chapter also points to library resources to go deeper, such as The Mom Test and Doing Discovery for discovery, OAuth 2.0 Simplified for integrations, Great Demo! for demos and The Minto Pyramid Principle for writing.

Rules of thumb in the sheet

The sheet closes with short rules worth remembering, including:

• Ask about the problem and its cost before you show anything.
• Write success criteria down and get them agreed before you build.
• Show the result first in every demo; the steps come after, and only if asked.
• Never promise a feature or a date you do not control.
• Start security review and SSO in week one, not the week before launch.
• Build evals from the customer's real cases, not examples you made up.
• Leave every customer able to run what you built without you.

A glossary of 42 smaller terms sits alongside the concepts, so acronyms like OTE, SCIM or POC are one search away.

How to use it with the roadmap

• Revise after each stage. When you finish a roadmap stage, read the matching chapter and check you could explain each concept to a colleague without notes.
• Before a customer call or a hiring loop round. Chapters 3 and 5 work as a checklist before a discovery call or a demo; chapter 9 is a quick refresher before you speak to a recruiter.
• While building. Keep chapter 4 open during integration work and chapter 7 while you build a RAG or agent workflow; the pitfalls are the bugs you are most likely to hit.
• When reading postings. Chapter 1 and chapter 9 help you decide whether a posting is really forward deployed, solutions or sales work.

Inside the roadmap, topics link straight to the concepts in this sheet that cover them, so you can jump between the lesson and the quick reference.

How it works on Sefism

Everything on Sefism is free to learn from. The public cheat sheet page shows every chapter title, with the first chapters open to read. Keeping the sheet uses credits and opens every chapter in the member area; if you add the Forward deployed and solutions engineering roadmap to your dashboard, its cheat sheet comes with it. New members get starting credits and the first roadmap is free. Create a free account to start, and if a concept does not click, ask Tauseef a question.

Related on Sefism

• What does a forward deployed engineer do, and is it a good career?
• What is the difference between a forward deployed engineer, a solutions engineer and a sales engineer?
• Is a sales engineer or solutions engineer job a step down for a software engineer?
• Retrieval assistant for university regulations, a project that exercises chapters 3, 5 and 7 together.

Common questions

What is the difference between a solutions engineer and a sales engineer? In the sheet's terms, a solutions engineer designs how a customer will adopt a product and works before and after the sale, while a sales engineer is the technical partner of an account executive during a sale. Titles vary by company, so read the responsibilities, not the title.

Is this a replacement for the roadmap? No. The roadmap teaches each topic with explanations, checks, milestones and resources; the cheat sheet is for revising and for keeping open while you work.

Which edition should I pick? The one for the role you are aiming at. The concepts are the same in all three, so switching later costs nothing.