github/infisical
1
0
Fork 0
mirror of https://github.com/Infisical/infisical.git synced 2026-01-09 07:28:09 -05:00
Code Issues Packages Projects Releases Wiki Activity

doc: added section about sales approval

Browse Source
This commit is contained in:
Sheen Capadngan
2025-07-17 03:31:58 +08:00
parent d6c2789d46
commit 01c6d3192d
1 changed files with 9 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
company/documentation/engineering/how-to-write-design-doc.mdx
View File

@@ -33,6 +33,7 @@ Every feature/problem is unique, but your design docs should generally include t
- A high-level summary of the problem and proposed solution. Keep it brief (max 3 paragraphs).
3. **Context**
- Explain the problem's background, why it's important to solve now, and any constraints (e.g., technical, sales, or timeline-related). What do we get out of solving this problem? (needed to close a deal, scale, performance, etc.).
- Consider whether this feature has notable sales implications (e.g., affects pricing, customer commitments, go-to-market strategy, or competitive positioning) that would require Sales team input and approval.
4. **Solution**
- Provide a big-picture explanation of the solution, followed by detailed technical architecture.
@@ -76,3 +77,11 @@ Before sharing your design docs with others, review your design doc as if you we
- Ask a relevant engineer(s) to review your document. Their role is to identify blind spots, challenge assumptions, and ensure everything is clear. Once you and the reviewer are on the same page on the approach, update the document with any missing details they brought up.
4. **Team Review and Feedback**
- Invite the relevant engineers to a design doc review meeting and give them 10-15 minutes to read through the document. After everyone has had a chance to review it, open the floor up for discussion. Address any feedback or concerns raised during this meeting. If significant points were overlooked during your initial planning, you may need to revisit the drawing board. Your goal is to think about the feature holistically and minimize the need for drastic changes to your design doc later on.
5. **Sales Approval (When Applicable)**
- If your design document has notable sales implications, get explicit approval from the Sales team before proceeding to implementation. This includes features that:
- Affect pricing models or billing structures
- Impact customer commitments or contractual obligations
- Change core product functionality that's actively being sold
- Introduce new capabilities that could affect competitive positioning
- Modify user experience in ways that could impact customer acquisition or retention
- Share the design document with the Sales team to ensure alignment between the proposed technical approach and sales strategy, pricing models, and market positioning.