Intro to Tian Pan​

Hi, there 👋!

I am a software engineer who has spent the last decade building Internet services — as an individual contributor, engineering leader, founder, and investor. I split my time between writing code, writing notes, and occasionally writing checks.

If you are…

• 👔 an investor or entrepreneur → I'm open to cofounder and CTO conversations in areas where I have genuine operating context (FinTech, Decentralized Identity, SaaS, developer tools, community-building technologies).
• 😛 a founder raising seed capital in crypto / Web3 / dev-tools / finance infrastructure → I invest in a small number of cases per year, typically alongside other operator-investors. Reach out with a short thesis.
• 🕵️‍♀️ an employer or recruiter → I am selective about my time; please lead with the problem space and team rather than the comp band. I'm most engaged by technical founder teams and by roles with real operating scope (Senior Staff / Principal / CTO).
• 👩‍💻 a software engineer or engineering manager trying to level up → most of what I would tell you in a 1:1 is already written here on TianPan.co (see the Notes section) or at 10x.pub community.
• ❓ curious about what I'm building or thinking
  • Building in spare time → stargately.com, beancount.io
  • Writing in English → tianpan.co
  • 中文写作 → 硅谷io

The best ways to reach me are Telegram (t.me/puncsky) or email (tian.pan at outlook.com). I read everything; I respond to messages that are specific, well-framed, and low-effort to reply to.

What is TianPan.co (and 硅谷io)?​

TianPan.co is my working notebook on what I've come to call startup engineering — the overlap of software engineering, product development, go-to-market strategy, and capital allocation that determines whether a technology business actually works. 硅谷io (guigu.io) is the Chinese sibling site with parallel content.

The notes have accumulated over many years of writing things down after I learned them, usually because I wanted to remember the why more than the what. Some of the material is original analysis; some is my restatement of other people's ideas in a form I find easier to apply. I try to be explicit about the difference.

The notes cluster around four questions I keep coming back to:

1. Product. What does it take to build a product that's 10x better than the incumbent — not 2x, not "better in these four ways," but genuinely 10x across the dimensions customers actually weigh? See the 9x Effect, MMRs, neutralizers and differentiators, and What is a market?.
2. Team. How do you hire, structure, and lead a team that solves genuinely hard technical problems without collapsing under its own weight? See Stages of company building, Bozo management, and Good to Great.
3. Customers. How do you move a product from early adopters to mainstream users without losing the thing that made it work in the first place? See Simon Sinek's Golden Circle, CAC/LTV/PBP, and Engineering and product templates.
4. Capital. Where are the high-value businesses and how do you get access to the equity in them, whether through operating a role, founding one, or investing in one? See Investment memo template and the Investment memos section.

If you want a single entry point, browse the blog for long-form posts.

Principles I operate by​

Four classical Chinese phrases that shape how I approach work:

• 见贤思齐 (See the wise and emulate them): Learning is hard; finding the right people to learn from is harder. Use externality — the signal from who succeeds and why — to sharpen your sense of cause and effect.
• 惟精惟一 (Refined and singular): Precision operations and deliberate subtraction are the only way to break through. Doing one thing extraordinarily well beats doing many things decently.
• 神通广大 (Vast and far-reaching powers): Cultivate a differentiated advantage, then build distribution broad enough to compound it.
• 长期主义 (Long-termism): Accumulate long-term advantage, build user trust, and do the hard-but-right thing. Moats come from persistence, not cleverness.

How I write​

A few principles that shape what ends up on the site:

• If a note doesn't have an original take, I try to either add one or leave the note out. The internet already has plenty of restated frameworks; what I find useful in my own notes is the part where I say "this is where the received wisdom is wrong, or incomplete, or only works in these conditions."
• I try to name failure modes explicitly. Most good frameworks are easy to understand and hard to apply, and the difference between the two is usually a specific failure mode that wasn't named. I try to name them.
• I link across notes when concepts depend on each other. The goal is that if you arrive at any single note, there's a short chain of links to everything else on the site that informs it.
• I update notes when I change my mind. Dates in the frontmatter reflect the original publish date, but the content sometimes evolves.

Thanks for reading.