标签：#strategy

The MVP was a great idea that got misused. "Minimum viable product" was meant to be the smallest experiment that tests a hypothesis. In practice it became an excuse to ship something broken and call it strategy. The minimum lovable product — MLP — is the correction: the smallest release that people actually want to use, not just tolerate. Knowing which one you need is a scoping decision, not a philosophy. The difference in one line An MVP asks will they use it at all? An MLP asks will they love the part we built? The MVP tests demand with the roughest possible artifact. The MLP narrows scope but polishes what remains until it's genuinely good. Both are about doing less. They disagree on where the "less" goes — fewer features versus rougher features. Why the bar has risen When users had few alternatives, a rough MVP could win on novelty. Today almost every category is crowded, and people judge a new product against the polished tools they already use. A janky first impression doesn't read as "early" — it reads as "not for me," and they don't come back. In a saturated market, lovability is the viability test. When an MVP is still right Ship a true MVP when the core question is demand, not quality: You're genuinely unsure anyone wants this at all. The audience is early adopters who tolerate rough edges for access. You can learn what you need from a small, forgiving group. Speed to a signal matters more than the strength of the signal. Here, spending weeks polishing something nobody wants is the expensive mistake. When to reach for an MLP Choose an MLP when demand is fairly clear but the market is competitive: Users have real alternatives and will compare you to them. Your differentiation is the experience — feel, speed, design. First impressions are hard to reverse. Word of mouth depends on delight, not just function. Scope narrow, finish deep The trap with "lovable" is treating it as license to add features. It's the opposite. Pick fewer things and finish them complet

I used to think AI search readiness was just SEO with a new name. It's not. The more time I spend on this, the clearer the distinction becomes. The core difference Traditional SEO optimizes for ranking in a list of links. You want to be the #1 blue link on Google for "best project management software." The user clicks through to your page, you get the traffic, you monetize. AI search optimizes for being the source of an answer. When someone asks Perplexity or ChatGPT "what's the best project management software?", the AI reads multiple sources, synthesizes an answer, and cites the ones it used. The user may never click through. The fundamental units are different: SEO operates on pages and rankings AI search operates on facts, claims, and citations You can be #1 on Google for a keyword and never appear in a single AI-generated answer. And you can be cited in AI answers without ranking in the top 10 for anything. What still matters Some things carry over from SEO: Technical quality — Fast pages, HTTPS, crawlable content. AI crawlers care about this just like Googlebot. Clear content structure — Headings, lists, tables. Well-structured content is easier for AI models to parse. Internal linking — AI crawlers follow links like any other crawler. Good information architecture matters. Backlinks from authoritative sources — Being cited by Wikipedia, academic papers, and major publications signals trust to AI models just like it does to search engines. What matters for AI search that barely matters for SEO A few things that are critical for AI search but don't move the needle much for traditional rankings: LLMs.txt / LLMs-full.txt — These files don't affect your Google ranking at all. But they give AI models a clean, structured map of your site. I've seen sites with great LLMs.txt files get cited more consistently than sites with better backlink profiles but no AI-readable summary. Structured data for disambiguation — In SEO, schema markup helps with rich snippets. In AI s

Your AI is making your content invisible. Not because it writes badly. Because it writes safely . Ask ChatGPT to summarize an article and it will produce a polished, agreeable précis that offends nobody and surprises nobody. The output is technically accurate and completely forgettable. The problem is structural: most people prompt their AI to confirm what an article says, not to find where it fights with the crowd . The result is a feed full of content that agrees with other content, in increasingly fluent prose, at exponentially increasing volume. If you want to be read, you need to stop prompting for summaries and start prompting for conflict. Why Agreement Is the Fastest Path to Obscurity There is a reliable body of research behind why contrarian content performs. Jonah Berger and Katherine Milkman's widely cited study, "What Makes Online Content Viral?" ( Journal of Marketing Research , 2012) , found that content evoking high-arousal emotions — anger, awe, anxiety — is significantly more likely to be shared than content that merely informs or reassures. Agreement is a low-arousal state. Surprise and contradiction are not. This is not a trick to manufacture outrage. It is a structural observation: the human brain is wired to pay attention to pattern breaks. An article that says "AI is changing content creation" registers as noise. An article that says "AI is making content creation worse, and here's the data" registers as a signal worth attending to. The distinction matters because the mechanism is cognitive, not emotional. You are not trying to provoke readers. You are trying to interrupt the predictive pattern they've built from reading a hundred similar articles before yours. The Problem With Generic AI Summarization When you ask an LLM to "summarize this article" or "give me the key takeaways," the model optimizes for coverage and balance. It is trained on human feedback that rewards thoroughness and penalizes controversy. The output tends to be accurate, ne

"Fractional CTO" has become the title people put on their LinkedIn profile when "senior developer" doesn't sound senior enough. I play this role for some of my clients, so I have opinions about what it actually means — and what it doesn't. The confusion isn't just semantics. If you hire the wrong thing under this label, you pay consulting rates for work that a good contractor would have done better. The Problem with the Label The term covers a surprisingly wide range of people and arrangements. At one end, you have experienced technical leaders — people who have actually run engineering organizations, made architectural decisions that constrained companies for years, hired and let go technical staff, and owned the consequences. At the other end, you have developers who decided their day rate felt more justifiable with a fancier title. Both call themselves fractional CTOs. The market hasn't sorted this out yet. The reason it matters: these are fundamentally different services with different prices, different deliverables, and different risks. Mixing them up is how companies end up paying €200/hour for someone to help them choose a JavaScript framework. What a Real Fractional CTO Actually Owns Owns is the operative word. Not "advises on." Not "contributes to." Owns. Technical architecture decisions. When you're building a system that will handle real volume, real users, and real money — the decisions made in the first few months constrain everything that follows. What database, what caching strategy, how the services are separated, where the complexity lives. A fractional CTO makes those calls and stakes their reputation on them. They're not writing a report about options. They're deciding. Tech stack and vendor selection. When a vendor pitches you something, someone needs to evaluate it who has seen enough vendors to know which ones are overselling. When a developer suggests a library, someone needs to know whether it's the right tool or just the tool that developer