[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-approval-flow-design-en":3,"blog-adjacent-approval-flow-design-en":30,"blog-related-approval-flow-design-en":67},{"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},57,"approval-flow-design","Approval Flows: Do Not Turn Organisational Problems Into Software Problems","Overlong approval chains usually reflect unclear authority, not poor workflow design.","\u003Cp>When clients ask for an approval workflow, the request is usually to follow the existing policy. Drawing that policy as a diagram often reveals a step with five approvers, none of whom know what they are checking.\u003C\u002Fp>\n\u003Ch2>Three questions first\u003C\u002Fh2>\n\u003Cp>What is each step judging? If nobody can answer, the step is probably ceremonial.\u003C\u002Fp>\n\u003Cp>Who fixes a rejected item? Many flows stall after rejection because nobody owns the revision.\u003C\u002Fp>\n\u003Cp>How does an urgent case move? Without an exception path, the business routes around the system and the system becomes decorative.\u003C\u002Fp>\n\u003Ch2>What software can do\u003C\u002Fh2>\n\u003Cp>Structure the decision: require a reason category instead of free text, so frequent issues can be counted.\u003C\u002Fp>\n\u003Cp>Support delegation and transfer for leave and role changes, which beats adding more approval levels.\u003C\u002Fp>\n\u003Cp>Keep a complete approval history for later review and audit.\u003C\u002Fp>\n\u003Cp>An approval flow mirrors organisational rules. When the rules are muddled, software amplifies the muddle rather than resolving it.\u003C\u002Fp>","","indigo","佳益方圆团队","2026-07-23T16:31:00+08:00",1,false,[16,17,18],"Approvals","Workflow","Product Design",{"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":49},{"id":32,"slug":33,"title":34,"excerpt":35,"content":9,"cover":9,"tone":36,"author":11,"publishedAt":37,"updatedAt":38,"readingMinutes":13,"featured":14,"tags":39,"category":42},9,"tech-open-day-2026","Tech Open Day: Explaining Architecture Decisions to Customers","We opened an internal architecture review to customers and explained every trade-off in language they could understand. It is part of building long-term trust.","teal","2026-07-24T16:30:00+08:00","2026-10-18T15:58:14.758+08:00",[40,41],"Tech Open Day","Customer Communication",{"id":43,"parentId":21,"slug":44,"name":45,"description":46,"icon":47,"cover":9,"tone":26,"kind":27,"sortOrder":48,"count":21},4,"team-culture","Team and Culture","Company events, tech sharing, team building and hiring culture that show the daily life of the Jiayifangyuan team.","users",30,{"id":50,"slug":51,"title":52,"excerpt":53,"content":9,"cover":9,"tone":54,"author":11,"publishedAt":55,"updatedAt":55,"readingMinutes":13,"featured":14,"tags":56,"category":60},77,"compressed-schedule-cost","Retrospective: The Cost of Compressed Testing","To hit a client's opening date we cut testing from three weeks to one, then spent six weeks fixing production.","slate","2026-07-21T16:31:00+08:00",[57,58,59],"Retrospective","Schedule","Quality",{"id":61,"parentId":21,"slug":62,"name":63,"description":64,"icon":65,"cover":9,"tone":26,"kind":27,"sortOrder":66,"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,[68,78,87],{"id":28,"slug":69,"title":70,"excerpt":71,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":72,"updatedAt":72,"readingMinutes":13,"featured":14,"tags":73,"category":77},"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",[74,75,76],"Requirements","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":79,"title":80,"excerpt":81,"content":9,"cover":9,"tone":10,"author":11,"publishedAt":82,"updatedAt":83,"readingMinutes":13,"featured":14,"tags":84,"category":86},"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",[85,18],"Industry Products",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21},{"id":88,"slug":89,"title":90,"excerpt":91,"content":9,"cover":9,"tone":26,"author":11,"publishedAt":92,"updatedAt":92,"readingMinutes":13,"featured":14,"tags":93,"category":95},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",[94,75,74],"MVP",{"id":20,"parentId":21,"slug":22,"name":23,"description":24,"icon":25,"cover":9,"tone":26,"kind":27,"sortOrder":28,"count":21}]