[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-requirement-priority-en":3,"blog-related-requirement-priority-en":30,"blog-adjacent-requirement-priority-en":59},{"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},61,"requirement-priority","Prioritisation: The Loudest Voice Is Not the Most Important","Priority should follow reach and criticality, not the seniority of whoever asks.","\u003Cp>The most familiar scene in a project is the loudest person in the meeting getting their feature scheduled first. After launch it turns out only they use it, while a quiet department's real pain was never addressed.\u003C\u002Fp>\n\u003Ch2>Three dimensions to judge\u003C\u002Fh2>\n\u003Cp>Reach: a feature used by one person and one used by a hundred are not comparable.\u003C\u002Fp>\n\u003Cp>Blocking level: can the business continue without it? If there is a workaround, it can wait.\u003C\u002Fp>\n\u003Cp>Substitution cost: if a spreadsheet solves it today, do not build software first.\u003C\u002Fp>\n\u003Ch2>Make priority visible\u003C\u002Fh2>\n\u003Cp>Publish the requirement list and ranking on a shared board so everyone can see where their item sits and why.\u003C\u002Fp>\n\u003Cp>Review the ranking every two weeks. It can change with the business, but the reason must be stated rather than applied through pressure.\u003C\u002Fp>\n\u003Cp>The hard part of prioritisation is not the method, it is helping requesters accept the outcome. Transparency is the best explanation.\u003C\u002Fp>","","indigo","佳益方圆团队","2026-06-05T12:23:00+08:00",1,false,[16,17,18],"Requirements","Prioritisation","Delivery",{"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,{},[31,40,50],{"id":28,"slug":32,"title":33,"excerpt":34,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":35,"updatedAt":35,"readingMinutes":13,"featured":14,"tags":36,"category":39},"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",[16,37,38],"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":41,"title":42,"excerpt":43,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":44,"updatedAt":45,"readingMinutes":13,"featured":14,"tags":46,"category":49},"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",[47,48],"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":51,"slug":52,"title":53,"excerpt":54,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":55,"updatedAt":55,"readingMinutes":13,"featured":14,"tags":56,"category":58},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",[57,37,16],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"previous":60,"next":75},{"id":61,"slug":62,"title":63,"excerpt":64,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":65,"updatedAt":65,"readingMinutes":13,"featured":14,"tags":66,"category":70},41,"lightweight-code-review","Making Code Review Work in a Small Team","Review is not fault-finding. It is making sure a second person understands a change before it merges.","2026-06-07T12:23:00+08:00",[67,68,69],"Code Review","Team","Engineering",{"id":13,"parentId":21,"slug":71,"name":69,"description":72,"icon":73,"cover":9,"tone":26,"kind":27,"sortOrder":74,"count":21},"engineering","Hands-on engineering practices in architecture, performance optimization, AI integration and cross-platform delivery from our R and D team.","cpu",60,{"id":76,"slug":77,"title":78,"excerpt":79,"content":9,"cover":9,"tone":80,"author":11,"publishedAt":81,"updatedAt":81,"readingMinutes":13,"featured":14,"tags":82,"category":86},81,"third-party-api-change","Retrospective: A Third Party Changed a Field Silently","A partner upgraded their API, the response shape shifted quietly, and our system broke two weeks later.","cyan","2026-06-03T12:23:00+08:00",[83,84,85],"Retrospective","Third Party","Stability",{"id":87,"parentId":21,"slug":88,"name":89,"description":90,"icon":91,"cover":9,"tone":26,"kind":27,"sortOrder":92,"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]