Technical Proposal Guide

How to prepare and present technical proposals (开题会) effectively.

Terminology

• 开题 / 开题会: The formal term for technical proposal meetings
• Kickoff / Kick-off: Used informally in daily communication
• Proposal: Used in formal emails and documentation titles

Language Conventions

• Documents: Primarily in Chinese; English is rare
• Technical terms: Keep English terminology (API, database, cache, etc.)
• Emails: Use “proposal” in subject lines and formal references

Purpose

A technical proposal meeting serves three goals:

1. Demonstrate understanding - Show your grasp of project background, objectives, and scope
2. Present solutions - Propose options with cost-benefit analysis and recommend a technical approach
3. Identify risks - Analyze challenges and potential blockers

Serve Your Audience

The meeting is for your audience, not yourself. Common mistakes:

Anti-pattern	Example	Why it’s wrong
Chronicle	”I had 3 meetings with product about X, Y, Z…”	Process details don’t help the audience understand the solution
Storytelling	Extended personal journey narratives	Brief anecdotes can lighten mood, but keep them short
Monologue	Assuming everyone knows your domain	Always establish context - don’t assume shared knowledge

Structure

Proposals have two parts: Business and Technical.

• Small/medium projects: Single meeting covering both (aim for ~1 hour)
• Large/complex projects: Separate business and technical meetings

Agenda

Business Proposal

Requirements Analysis

What does product want?

1. One-sentence summary first:

   Partner API: Allow partners to access and modify client data under advisors via our API.

2. Then expand with wireframes/mockups as needed

Business Motivation

Why are we doing this?

• Customer value: What pain points does this solve for advisors/partners?
• Company value: Revenue opportunity? Cost reduction?

Understanding motivation lets you evaluate whether the proposed solution is the best path to the goal.

Technical Proposal

Technical Requirements Analysis

Quality target: “Maintenance-free for 1-2 years”

Analyze what’s needed to support the business requirements:

• Scale projections (1-2 year horizon): RPS, endpoint count, data volume
• Resource needs: Frontend work, infrastructure changes
• Code reuse: Can existing modules/packages be reused, modified, or extended?

When reusing existing code, enter the original author’s context - understand their original goals and constraints.

Solution Options / Architecture Design

Technical architecture to support requirements:

• Database strategy (shared vs. separate, read replicas)
• Code organization (monorepo vs. new package)
• Infrastructure changes (capacity, storage)
• Schema changes

Challenges and Risks

Common risk categories:

Risk Type	Example
Timeline pressure	Hard business deadline requires aggressive phasing
Architecture gap	Current architecture can’t support requirements, needs refactoring
Dependencies	High coupling with other modules, requires coordination

Timeline

Estimate ETA based on available resources and parallel commitments. Identify if phasing is needed.

Q&A

The proposal meeting is not a technical discussion session. Avoid implementation details. If you’re pasting code, you’ve likely gone off track.

Optional: Preamble

Help audience enter your context:

• Key terminology
• Current state of relevant products/modules

Preparation

Think About Business and Product

Don’t just do what product asks. Instead:

1. Understand the why - Solve the underlying problem, not just the stated request
2. Challenge requirements - Seek the company-optimal solution, not team-optimal
3. Own your understanding - Don’t be a tool of product/sales

Enter the Original Author’s Context

For modifications to existing modules:

1. What problem was the original author solving?
2. Reverse-engineer their cost-benefit analysis from the current design
3. Evaluate if the original architecture is still appropriate for current business needs

The “1-2 year maintenance-free” standard applies to modifications too. You own the code you touch.

Challenge Unreasonable Situations

Speak up if you see:

• Local optimization vs. global optimization
• Unbalanced cost-benefit
• Inconsistency with existing patterns
• Solutions that shift costs to others

English Pronunciation

1. Pronounce technical terms correctly
2. Prepare pronunciations before the meeting
3. Use phonetic notation in your document if needed

Document Quality

The Ultimate Goal

Your proposal should demonstrate:

• Comprehensive research - You’ve investigated the topic thoroughly
• Thorough thinking - You’ve considered edge cases and trade-offs
• Clear ownership - You own this topic and can guide the discussion

The goal is to get attendees to buy in to your analysis and recommendation.

Storytelling and Logic

A good proposal document has:

Quality	Description
Narrative flow	Each section leads naturally to the next
Logical rigor	Problem statement is tight and well-reasoned
Focused scope	Keeps readers on track, prevents tangents
Engaging structure	Draws readers into the content

What to Present vs. Discuss

• Present with confidence: Areas where you’ve done thorough analysis
• Open for discussion: Uncertainties, trade-offs, or decisions that benefit from group input

Most of the meeting should be you presenting. Discussion should be targeted and purposeful.

Presentation Style

Be Concise

Summarize in one sentence. Example:

Project goal: Send reminder emails 45 days before billing for all subscriptions.

Why: The previous “Stripe webhook” approach can’t apply to current billing cycles. Stripe won’t change their logic, so we need a new solution.

Structure Your Narrative

Use bullet points, not prose. Example:

Three risk areas:

1. Edge case handling
2. Cache consistency
3. Large data migration

Structure in Notion = headings + bullet lists.

Sources

• 📢 如何开题 - Original RightCapital proposal guidelines