There's a popular saying: either don't do it, or do it to a 100-point standard.
But after building AI products for a while, I'm increasingly sure of the opposite: obsessing over the 100-point product is often the first thing that makes a founder lose money. This week's three lessons — being stingy with costs, running the flow backwards, and keeping businesses isolated — come down to one sentence: build a 60-point product that doesn't lose money, doesn't overcomplicate, and doesn't strain you.
Lesson 1: The first lesson of AI products is being stingy
We've always said we don't build 100-point products. The same goes for features.
Take resume screening. What would the ideal state look like? Every resume is analyzed by the model individually, with a separate result. That's a textbook 100-point feature. But to reach that 100 points: an HR person screening 300 resumes needs about 310 requests. One full screening consumes 2,500 credits — roughly 2.5 yuan in revenue. That loses money to grandma's house.
To actually break even, we'd have to charge about 50 yuan. So ask yourself: what sucker pays 50 yuan for a one-time 300-resume screening?
So when building products, you have to be a bit stingy. Stingy isn't cheap — it's cost-driven: when I save money on my side, the customer can afford it on theirs. This is how we save money together with the customer.
Another example, still resume screening. In theory, we can parse any PDF format. But scanned documents require OCR, which dramatically increases overall cost. Text-based PDFs already cover 80% of resumes — consider that an unintentional lesson borrowed from DeepSeek. As for the remaining 20%: I've proven my capability, now it's the HR folks' turn to prove their budget.
And here's what you may not have noticed: once you start parsing scans, it looks like broader capability, but it actually drags the whole platform toward "document processing" — narrower and narrower, hurting the extensibility of the entire site. Customers whose needs are refined to that degree shouldn't be on a general platform anyway; they should be on custom solutions.
That's where our other business plugs in: on-premise deployment. The same capability, deployed at the customer's site, has a much better revenue-to-effort ratio than online. Online scales the volume; custom work scales the margin.
Not building the 100-point product isn't a lack of ambition. It's knowing how to do the math.
Lesson 2: Laziness is the first productive force
I have a belief: laziness is the product manager's first productive force.
Every product is solving a human desire, and laziness is the most legitimate product path. You don't want to go out to eat, so you order delivery. You don't want to read through a pile of results, so you use AI.
We took a detour when building resume optimization. Our first flow was: edit page → write the full resume → choose AI optimization → pick which AI optimization points to keep → write them back → print. We later changed it to: upload resume → AI auto-optimizes → fix whatever looks wrong → print.
Notice where it changed?
Before, it was "write, write, write" — write the resume, write the optimization points, write the edits. Now it's "click, click, click" — upload, pick, fix, print, done. And I also flipped my thinking: users come here for me to AI-optimize their resume. Why force them to confirm one by one which AI edits are good and which aren't? Just hand them the optimized result; whatever they don't like, they delete themselves.
This logic applies even more in an era where AI products are popping up everywhere: clunky products always get replaced by simpler ones. It's not about having more features. It's about the user having to do less.
Lesson 3: The money you make fastest may be the money you lose fastest
I currently have another project, powered by Claude, that brings in meaningful income. But I've never synced it with the users of my other business line.
Someone might ask: users already trust you — wouldn't moving them over earn you another income stream? Logically, yes. But on my side, that only works between similar projects. Say two of your businesses both target the workplace: heavy audience overlap, moving them over is efficient. But what if one is food and the other is workplace? The audiences overlap — plenty of workplace people love food — but your capabilities don't carry over. The two businesses are two separate skins. Move them over early and the revenue comes fast. But what you took from somewhere, you can lose from the same place.
We run multiple product lines to avoid putting all eggs in one basket. But if you make ten baskets and then tie them all together with rope — when they fall, how is that different from one basket?
So my principle is business isolation. I run multiple lines to spread risk, not to concentrate it in a new way.
Never over-trust your own product. "My product can't have negative PR!" "I just built a small tool, what negative impact could it have?" — the moment luck appears, that's where the crack shows.
Does that mean zero connection is allowed? Not at all. Look at the old business's carrier — if you have a traffic-driven news site that makes money from ads anyway, and it happens to run an ad for another product of yours, users have no idea you're the same developer. That's the safest kind of connection: two subsidiaries that don't actively link, but yours is still my customer.
The takeaway
These three lessons are actually one worldview: do the math soberly, instead of building products on emotion.
Being stingy with costs is doing the math between "features" and "revenue." Running the flow backwards is doing the math between "what you think users want" and "what users actually want." Business isolation is doing the math between "short-term money" and "long-term risk."
Before, the biggest fear in a startup was not having enough money. Now, with AI products, the easiest mistakes are: the product is too bloated, the flow is too convoluted, the ambition is too big. And all three of those are quietly taking money out of your pocket.
60 points isn't a lack of ambition. 60 points is, after doing the math, leaving your energy for what actually matters.
Top comments (0)