[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-ai-feature-positioning-en":3,"blog-adjacent-ai-feature-positioning-en":30,"blog-related-ai-feature-positioning-en":65},{"id":4,"slug":5,"title":6,"excerpt":7,"content":8,"cover":9,"tone":10,"author":11,"publishedAt":12,"updatedAt":12,"readingMinutes":13,"featured":14,"tags":15,"category":19,"seoSettings":29},59,"ai-feature-positioning","Positioning an AI Feature","Treating a large model as a universal assistant usually produces features nobody uses. Start from a specific task.","\u003Cp>For the past two years nearly every client has asked whether AI can be added. Most of the time we suggest waiting and instead finding one specific, repetitive task with a high tolerance for error, then validating it internally first.\u003C\u002Fp>\n\u003Ch2>Three good starting tasks\u003C\u002Fh2>\n\u003Cp>Text structuring: turning meeting notes or ticket descriptions into structured fields that a human reviews.\u003C\u002Fp>\n\u003Cp>Information extraction: pulling key data from contracts, invoices and résumés to cut re-typing.\u003C\u002Fp>\n\u003Cp>Draft generation: support replies, product descriptions and weekly reports, so users do not start from a blank page.\u003C\u002Fp>\n\u003Ch2>Three situations to approach carefully\u003C\u002Fh2>\n\u003Cp>Direct automated replies to customers, where errors are expensive and a human fallback is mandatory.\u003C\u002Fp>\n\u003Cp>Money calculations and compliance judgement, where the model may assist but never decide.\u003C\u002Fp>\n\u003Cp>Tasks without a clear evaluation standard; if you cannot tell good from bad, do not start.\u003C\u002Fp>\n\u003Cp>An AI feature matters when it genuinely removes repetitive work from a specific role, not because the technology is advanced. Without that point, skip it.\u003C\u002Fp>","","slate","佳益方圆团队","2026-06-29T10:57:00+08:00",1,false,[16,17,18],"AI","Positioning","Adoption",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},2,0,"product-thinking","Product Thinking","Requirement analysis, user experience and product design methods, plus the thinking from business problems to product solutions.","lightbulb","blue","article",50,{},{"previous":31,"next":47},{"id":32,"slug":33,"title":34,"excerpt":35,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":36,"updatedAt":36,"readingMinutes":13,"featured":14,"tags":37,"category":41},39,"legacy-data-migration","Data Migration: Understand the Old Ledger First","Migrations rarely fail on technology. They fail because nobody can describe what the legacy data actually contains.","2026-07-01T10:57:00+08:00",[38,39,40],"Migration","Legacy","Delivery",{"id":13,"parentId":21,"slug":42,"name":43,"description":44,"icon":45,"cover":9,"tone":26,"kind":27,"sortOrder":46,"count":21},"engineering","Engineering","Hands-on engineering practices in architecture, performance optimization, AI integration and cross-platform delivery from our R and D team.","cpu",60,{"id":48,"slug":49,"title":50,"excerpt":51,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":53,"updatedAt":53,"readingMinutes":13,"featured":14,"tags":54,"category":58},79,"acceptance-dispute-retro","Retrospective: The Cost of Vague Acceptance Criteria","The system was finished and the client said it was not what they wanted. Every argument returned to one line: it was never specified.","indigo","2026-06-27T10:57:00+08:00",[55,56,57],"Retrospective","Acceptance","Requirements",{"id":59,"parentId":21,"slug":60,"name":61,"description":62,"icon":63,"cover":9,"tone":26,"kind":27,"sortOrder":64,"count":21},3,"project-retrospective","Project Retrospectives","Real project records from zero to one, covering problems, solutions, lessons learned and final outcomes.","clipboard-check",40,[66,75,85],{"id":28,"slug":67,"title":68,"excerpt":69,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":70,"updatedAt":70,"readingMinutes":13,"featured":14,"tags":71,"category":74},"grading-requirement-confidence","Grading the Confidence Behind Requirements","Treating requirements as facts is the most common cause of delay. Requirements differ in how reliable they are.","2026-10-15T09:00:00+08:00",[57,72,73],"Product","Risk",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":20,"slug":76,"title":77,"excerpt":78,"content":9,"cover":9,"tone":52,"author":11,"publishedAt":79,"updatedAt":80,"readingMinutes":13,"featured":14,"tags":81,"category":84},"vertical-product-rules","The Watershed for Vertical Products: Writing Industry Defaults into the System","Vertical is not a new industry label on a generic product. The real barrier is understanding and carrying the default rules that practitioners take for granted.","2026-10-09T10:00:00+08:00","2026-10-18T15:58:14.661+08:00",[82,83],"Industry Products","Product Design",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":86,"slug":87,"title":88,"excerpt":89,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":90,"updatedAt":90,"readingMinutes":13,"featured":14,"tags":91,"category":93},51,"mvp-boundary","Drawing the Boundary of an MVP","Minimum viable is not the fewest features; it is one complete business loop running end to end.","2026-10-03T10:13:00+08:00",[92,72,57],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21}]