<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Product Thinking on Bruce on AI Engineering</title><link>http://www.heyuan110.com/tags/product-thinking/</link><description>Recent content in Product Thinking on Bruce on AI Engineering</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 31 Jan 2026 22:00:00 +0800</lastBuildDate><atom:link href="http://www.heyuan110.com/tags/product-thinking/index.xml" rel="self" type="application/rss+xml"/><item><title>22 Thinking Frameworks That Turn Vague Ideas Into Clear Requirements</title><link>http://www.heyuan110.com/posts/ai/2026-01-31-thinking-methodologies-guide/</link><pubDate>Sat, 31 Jan 2026 22:00:00 +0800</pubDate><guid>http://www.heyuan110.com/posts/ai/2026-01-31-thinking-methodologies-guide/</guid><description>&lt;p&gt;&amp;ldquo;Build me a user management system.&amp;rdquo;&lt;/p&gt;
&lt;p&gt;You hand that sentence to an AI, and it spits out a pile of code. You open it up and it is nothing like what you had in mind. Or you spend thirty minutes explaining requirements to a colleague, only to discover you were talking about completely different things.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;The problem is not that the AI is not smart enough, or that your colleague is not cooperating. The problem is that the requirement was too vague.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>Delete Before You Optimize: 3 Product Thinking Rules for Solo Developers</title><link>http://www.heyuan110.com/posts/ai/2026-01-30-product-thinking-delete-first/</link><pubDate>Fri, 30 Jan 2026 10:30:00 +0800</pubDate><guid>http://www.heyuan110.com/posts/ai/2026-01-30-product-thinking-delete-first/</guid><description>&lt;p&gt;What is the most common mistake people make when building products?&lt;/p&gt;
&lt;p&gt;It is not building too little. It is &lt;strong&gt;building too much&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;After years of building products, the biggest trap I fell into was not shipping bad features — it was spending weeks polishing a feature that should never have existed. This kind of &amp;ldquo;productive waste&amp;rdquo; is especially deadly for solo developers and solopreneurs. We do not have a big company&amp;rsquo;s resources to absorb mistakes. Every day spent on the wrong thing is a day we cannot get back.&lt;/p&gt;</description></item></channel></rss>