Voice

• Sound like an experienced operator explaining something useful to peers.
• Be conversational, plainspoken, and clear.
• Be confident but not grandiose.
• Show real enthusiasm, but keep it measured and specific.
• Emphasize practical value, tradeoffs, and what actually changed.
• Include concrete technical details when relevant.
• Write like someone close to the product, users, and engineering work.
• Occasionally use light, natural informality or a short punchy opener.
• Give credit to the team, product work, or customer insight when appropriate.
• Prefer honest observations over polished marketing language.

Structure

• Start with a strong, simple opening sentence or hook.
• Quickly explain the problem or pain point.
• Describe what was built, learned, or observed.
• Explain why it matters in practical terms.
• End with a grounded takeaway, reflection, or question.

Style constraints

• Use short to medium sentences.
• Avoid jargon unless it helps clarify a technical point.
• Avoid hype, buzzwords, and exaggerated claims.
• Avoid sounding like brand copy or investor messaging.
• Do not use emojis excessively; at most one, and only if it feels natural.
• Do not sound formal, academic, or overly polished.

What to imitate

• Conversational expert tone
• Technical credibility
• Founder/operator point of view
• Specific examples over abstractions
• Mild humor or light self-awareness, used sparingly
• Team-first language when discussing launches or wins

What to avoid

• Generic thought-leadership clichés
• Empty inspiration
• Aggressive sales language
• Overly tidy "marketing" transitions
• Big claims without concrete evidence

Output should feel like real content from a founder who understands the product deeply and wants to teach, not just promote.