[
  {
    "id": "w1-0-personal",
    "week": 1,
    "day": 0,
    "channel": "personal",
    "title": "Tôi muốn bàn điều gì về AI và delivery?",
    "audience": "CEO / CTO / người vận hành",
    "angle": "Định vị Minh qua câu hỏi đáng quan tâm, chưa kể thành tích chưa có.",
    "body": "I want to use this space to examine a practical question: how do we turn faster software creation into better work?\n\nMy role at CTC Smart Tech sits close to the conversation between business needs and technical delivery. The questions I want to explore here are specific:\n\nWho owns the outcome? What evidence tells us a workflow is improving? When does an external team help, and what must stay close to the business?\n\nI'll share working frameworks, questions worth asking, and reflections on how AI changes those decisions. Where an example is hypothetical, I'll say so.\n\nI hope this becomes a useful exchange with people building and operating software.\n\nWhat part of AI adoption is creating the most unresolved work for your team?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w1-1-company",
    "week": 1,
    "day": 1,
    "channel": "company",
    "title": "Bắt đầu bằng một workflow brief",
    "audience": "CEO / Operations / CTO",
    "angle": "Tài nguyên đầu tiên giúp khách mô tả bài toán.",
    "body": "A useful software conversation starts with a workflow people can describe.\n\nBefore selecting tools or a delivery team, write down six things:\n\n• The person doing the work.\n• The task they need to complete.\n• The current steps and handoffs.\n• The systems and data involved.\n• What a successful outcome looks like.\n• Who can accept the result.\n\nWe've prepared an editable Workflow Brief to structure that discussion. It includes a baseline, explicit exclusions and open questions, so uncertainty stays visible.\n\nUse it for one workflow first. If the outcome still cannot be described clearly, resolving that ambiguity is the next piece of work.\n\nThe template is available through the resource link below. Which field is hardest to complete in your organization?\n\nResource: https://sales.smarttechctc.io/resources/workflow-brief.md",
    "resource": "workflow-brief",
    "kind": "Nền tảng"
  },
  {
    "id": "w1-2-personal",
    "week": 1,
    "day": 2,
    "channel": "personal",
    "title": "AI làm thay đổi câu hỏi về năng lực",
    "audience": "CEO / CTO",
    "angle": "Quan điểm về khả năng giao việc, trách nhiệm và review.",
    "body": "When evaluating an AI-enabled team, I would ask about the work that surrounds the code.\n\nHow do they establish the expected behavior? Who reviews a change? What happens when a generated solution fails? Can another person run and maintain it?\n\nThose questions become more important as implementation gets faster. A large volume of output can create more decisions for the people responsible for accepting it.\n\nMy current view is that a useful delivery conversation should include review capacity, integration ownership and handover from the beginning.\n\nI would want to understand those constraints before discussing team size.\n\nWhat evidence helps you distinguish a team that builds quickly from one you can confidently hand work to?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w1-3-company",
    "week": 1,
    "day": 3,
    "channel": "company",
    "title": "Chọn hình thức hỗ trợ phù hợp",
    "audience": "CTO / Engineering manager",
    "angle": "So sánh phương án theo phạm vi và khả năng quản lý.",
    "body": "Choosing a delivery model is easier when the ownership boundary is clear.\n\nAn internal team may be the right choice when long-term context is central. Specialist support can help when an internal owner needs a defined skill. A managed workstream needs a boundary and an agreed way to accept the result. Discovery is useful when the next decision depends on resolving uncertainty.\n\nOur Delivery Options Worksheet compares these choices using onboarding effort, access requirements, review load, knowledge transfer and total cost.\n\nIt is a discussion tool, not a recommendation to outsource.\n\nThe editable worksheet is available through the resource link below. Start by naming the person who would accept the work, then compare the options with them.\n\nResource: https://sales.smarttechctc.io/resources/delivery-options.md",
    "resource": "delivery-options",
    "kind": "Nền tảng"
  },
  {
    "id": "w1-4-personal",
    "week": 1,
    "day": 4,
    "channel": "personal",
    "title": "Tuyển dụng là tín hiệu, chưa phải nhu cầu mua",
    "audience": "Sales / CEO / CTO",
    "angle": "Thể hiện cách nghiên cứu khách hàng có kỷ luật.",
    "body": "An open engineering role tells me a company is investing in a capability. It leaves several commercial questions unanswered.\n\nIs the work intended to remain internal? Is there a deadline? Could any part be separated cleanly? Would an external partner reduce work for the team, or add coordination overhead?\n\nWhen researching a company, I want to connect hiring signals with what its leaders say, what its product already does, and the partners it already works with.\n\nThat gives me a better question to ask. It still does not give me permission to assume a problem.\n\nI think a useful first conversation begins with a hypothesis the other person can correct.\n\nWhat assumption do service providers most often get wrong about your team?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w2-0-personal",
    "week": 2,
    "day": 0,
    "channel": "personal",
    "title": "Khi ai cũng có thể xây: ai chịu trách nhiệm?",
    "audience": "CEO / CTO / CPO",
    "angle": "Góc nhìn Nate–Alvin và phát biểu Replit; nguồn trong hồ sơ.",
    "body": "More people can build software. More people need a clear way to put it to work.\n\nA question from Nate B. Jones's conversation with Alvin Wang Graylin stayed with me: what do people do with intelligence when it becomes widely available?\n\nFor a business, I think the answer starts with the people closest to the work.\n\nA People leader knows where onboarding breaks down. A support team knows which questions keep coming back. An engineer knows which failures a successful demo can hide.\n\nReplit offers an interesting lens on this. Amjad Masad has written about agents operating across the company, with people retaining responsibility for important decisions. Luis Héctor Chávez has discussed finding patterns across user sessions to guide engineering work. Stacey La Torre has written about embedding intelligence into People decisions.\n\nI see a shared challenge across those perspectives: helping people turn what they know into systems that others can rely on.\n\nTake an internal employee assistant. Building the interface is one step. Someone still needs to decide which sources it can use, whose information it can reveal, what happens when an answer is uncertain, and who corrects it.\n\nThose decisions connect business value, technical reliability, and employee trust.\n\nThe measure I would want to see is simple: can the person using the system complete the task correctly, understand when to question it, and reach a responsible human when needed?\n\nAs software creation becomes more accessible, I expect that combination of ownership and judgment to become more valuable.\n\nWhat responsibility has your team had to make clearer as more people start building with AI?\n\n#AIAdoption #FutureOfWork #EnterpriseAI",
    "resource": null,
    "kind": "Gắn nghiên cứu khách hàng"
  },
  {
    "id": "w2-1-company",
    "week": 2,
    "day": 1,
    "channel": "company",
    "title": "Thỏa thuận vận hành cho công cụ AI",
    "audience": "CEO / CTO / CPO",
    "angle": "Bài Replit đã chuẩn bị + mẫu thỏa thuận dùng được.",
    "body": "Before an AI-built tool becomes part of daily work, give it a clear operating agreement.\n\nReplit's recent Databricks/Lakebase announcement brings application creation closer to governed enterprise data. It raises a practical question for teams adopting AI-built software: what must be agreed before people depend on it?\n\nAt Smart Tech CTC, our proposed starting point is one workflow, one owner, and a small set of checks everyone can understand.\n\nConsider an internal employee knowledge assistant. This is an illustrative example, not a customer case.\n\n1. Define the outcome.\nWhich task should employees complete more easily? Record the current time and manual handoffs before setting a target.\n\n2. Assign ownership.\nA business owner maintains the policy content. A technical owner maintains the application. Employees know where to report a problem.\n\n3. Define the boundaries.\nSpecify approved sources, access permissions, and situations that require a human response.\n\n4. Test the difficult cases.\nCheck outdated policies, conflicting documents, unanswered questions, and attempts to retrieve information the user should not see.\n\n5. Start with a limited group.\nReview successful tasks, corrections, access failures, and the work created for the people supporting the tool.\n\n6. Make an explicit decision.\nExpand, revise, or stop based on the results. Keep the decision and its owner visible.\n\nThis gives leadership a way to assess value, engineering a testable scope, and People teams a clear role in protecting the employee experience.\n\nAI can put creation in more hands. A shared operating agreement helps those hands work together.\n\nWhich of these six decisions is hardest to settle in your organization?\n\n#EnterpriseAI #AIEngineering #HumanInTheLoop\n\nAn editable AI Operating Agreement is available through the resource link below to help your team document these decisions.\n\nResource: https://sales.smarttechctc.io/resources/operating-agreement.md",
    "resource": "operating-agreement",
    "kind": "Gắn nghiên cứu khách hàng"
  },
  {
    "id": "w2-2-personal",
    "week": 2,
    "day": 2,
    "channel": "personal",
    "title": "Demo đã chạy: cần biết điều gì tiếp theo?",
    "audience": "CTO / Product",
    "angle": "Quan điểm về kiểm chứng trước khi mở rộng.",
    "body": "A working demo gives us a useful starting point. I would use the next conversation to ask what it has actually demonstrated.\n\nWhich inputs were tested? What conditions were assumed? What happens with incomplete data, revoked access or an unavailable dependency?\n\nThose questions help distinguish a promising idea from a workflow ready for repeated use.\n\nI would also ask who has authority to define the expected behavior. A test suite can be technically correct while checking the wrong business rule.\n\nMy preference is to agree a small set of representative scenarios with the people responsible for the outcome, then expand from the results.\n\nWhat is the first difficult scenario you add after a demo succeeds?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w2-3-company",
    "week": 2,
    "day": 3,
    "channel": "company",
    "title": "Ma trận kiểm thử có thể tái sử dụng",
    "audience": "CTO / QA / Engineering",
    "angle": "Tài nguyên kỹ thuật với expected behavior và nguồn bằng chứng.",
    "body": "A regression test is most useful when another person can understand why its expected result is correct.\n\nOur Regression Test Matrix records the workflow, fixture, preconditions, action, expected output, access boundary, owner and evidence.\n\nIt includes illustrative cases for revoked access, stale source data and a dependency timeout. Each example is marked NOT RUN. Replace it with your agreed behavior before using it.\n\nStart with the cases that would change a release decision. Assign an owner to resolve disagreements about expected behavior.\n\nThe matrix is available through the resource link below as an editable template. Which failure case belongs in every first version of your test suite?\n\nResource: https://sales.smarttechctc.io/resources/regression-matrix.md",
    "resource": "regression-matrix",
    "kind": "Nền tảng"
  },
  {
    "id": "w2-4-personal",
    "week": 2,
    "day": 4,
    "channel": "personal",
    "title": "Con người cần xuất hiện ở quyết định nào?",
    "audience": "CEO / CTO / CPO",
    "angle": "HITL cụ thể, tránh câu chung chung có người duyệt.",
    "body": "When a plan says “human in the loop,” I want to know which person, at which decision, with what information.\n\nA reviewer needs a clear trigger, evidence to inspect, authority to act and enough time to do the job. Otherwise, a review step can become a button people click to keep work moving.\n\nFor a small AI workflow, I would start with three moments: approving its boundaries, resolving uncertain cases and deciding whether the pilot should expand.\n\nEach moment needs an owner and a record of the decision.\n\nThe design question is how to make human judgment useful where it matters most.\n\nWhere does your current process ask for approval without giving the reviewer enough context?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w3-0-personal",
    "week": 3,
    "day": 0,
    "channel": "personal",
    "title": "Dữ liệu đáng tin bắt đầu từ ý nghĩa",
    "audience": "CPO / Data / Operations",
    "angle": "Nhìn dữ liệu dưới góc quyết định thay vì dashboard.",
    "body": "Before asking what an AI system can predict, I would ask whether the team agrees on what its data means.\n\nA field called “active employee,” “qualified lead” or “resolved ticket” can hide different definitions across systems. A technically clean pipeline can carry those disagreements all the way into a confident recommendation.\n\nFor decisions involving people, I would want the source, definition, limitations and correction process to be visible.\n\nThat work belongs in the conversation between domain owners and technical teams.\n\nMy view is that agreeing what a number means is already part of building the system.\n\nWhich metric in your organization needs the most explanation before someone can use it responsibly?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w3-1-company",
    "week": 3,
    "day": 1,
    "channel": "company",
    "title": "Checklist chất lượng dữ liệu",
    "audience": "CPO / Data / Operations",
    "angle": "Tài nguyên kiểm nguồn, freshness, định nghĩa và quyền sửa.",
    "body": "Use this checklist before relying on data in an AI-assisted workflow.\n\n1. Identify the decision the data will support.\n2. Record the source, owner and update frequency.\n3. Check missing records, duplicates and inconsistent identifiers.\n4. Agree metric definitions and known limitations.\n5. Document who can correct an error.\n6. Decide whether the data is usable, limited to a narrower purpose, or blocked pending remediation.\n\nOur editable Data Quality Checklist includes space for evidence and an owner for unresolved issues.\n\nIt is designed to support a joint review by business and technical teams. The template is available through the resource link below.\n\nWhich quality issue tends to surface only after a workflow is already in use?\n\nResource: https://sales.smarttechctc.io/resources/data-quality.md",
    "resource": "data-quality",
    "kind": "Nền tảng"
  },
  {
    "id": "w3-2-personal",
    "week": 3,
    "day": 2,
    "channel": "personal",
    "title": "Tính cả công việc mới do AI tạo ra",
    "audience": "CEO / Engineering / Operations",
    "angle": "Quan điểm đo giá trị ròng và effort review.",
    "body": "When assessing an AI pilot, I would count the work it creates as carefully as the work it saves.\n\nSomeone may spend less time drafting an answer but more time checking sources. A workflow may complete faster while increasing the support burden. A small team may gain useful capacity while taking on a new maintenance obligation.\n\nThose effects can still lead to a good decision. They need to be visible.\n\nI would compare task completion, corrections, review effort and user feedback using the same definitions before and after the pilot.\n\nWhat looks like success from one team's perspective should also make sense to the team that inherits the work.\n\nWhich hidden cost do you include in an AI pilot review?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w3-3-company",
    "week": 3,
    "day": 3,
    "channel": "company",
    "title": "Bảng nghiệm thu thử nghiệm",
    "audience": "CEO / CTO / Operations",
    "angle": "Scorecard quyết định mở rộng/sửa/dừng.",
    "body": "A pilot needs an agreed decision at the end.\n\nOur Pilot Scorecard records the baseline, the pilot group, successful and failed tasks, human corrections, support effort and user feedback.\n\nIt also asks what changed between the baseline and the pilot. Different task difficulty or user groups can make a simple before-and-after comparison misleading.\n\nUse the evidence to choose one of three outcomes: expand, revise or stop. Record the reason, the decision owner and the next review date.\n\nThe editable scorecard is available through the resource link below. Agree the evaluation criteria before the pilot starts, then keep the unresolved questions visible throughout it.\n\nResource: https://sales.smarttechctc.io/resources/pilot-scorecard.md",
    "resource": "pilot-scorecard",
    "kind": "Nền tảng"
  },
  {
    "id": "w3-4-personal",
    "week": 3,
    "day": 4,
    "channel": "personal",
    "title": "Cho đội ngũ quyền sửa công cụ họ dùng",
    "audience": "CPO / CTO",
    "angle": "Khả năng xây đi cùng feedback và trách nhiệm.",
    "body": "When employees can build tools for their own work, their knowledge becomes easier to turn into software.\n\nI think the next organizational question is how they participate after the first version ships.\n\nCan they report a misleading answer? Propose a change to a business rule? See who is responsible for a correction? Understand which changes require technical review?\n\nA feedback path gives people a way to improve the system they depend on. It also gives engineering better context about which problems matter.\n\nFor me, employee participation should continue through operation and maintenance.\n\nHow do the people using your internal tools influence what gets fixed next?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w4-0-personal",
    "week": 4,
    "day": 0,
    "channel": "personal",
    "title": "Bàn giao là một phần của sản phẩm",
    "audience": "CTO / Engineering manager",
    "angle": "Quan điểm về khả năng tự vận hành sau delivery.",
    "body": "I would judge a handover by what the receiving team can do without the original builder in the room.\n\nCan they set up the project? Run the tests? Explain the known limitations? Recover from a failed change? Find the person responsible for the data?\n\nThose are practical acceptance questions. They help make ownership real.\n\nIf a delivery proposal describes features in detail but leaves maintenance and transfer unclear, I would want that conversation earlier.\n\nThe value of an external team should include what remains usable when the engagement ends.\n\nWhat is the one handover requirement you now insist on because it was missing before?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w4-1-company",
    "week": 4,
    "day": 1,
    "channel": "company",
    "title": "Checklist bàn giao kỹ thuật",
    "audience": "CTO / Engineering manager",
    "angle": "Tài nguyên vận hành, rollback, người nhận và nghiệm thu.",
    "body": "A handover should let the next owner operate the work.\n\nOur Engineering Handover Checklist covers accepted scope, open issues, setup instructions, test commands, monitoring, rollback, access removal and maintenance ownership.\n\nA practical acceptance step is to ask the receiving team to run the setup and tests independently. Record what failed and resolve it before closing the handover.\n\nThe template also separates accepted work from known limitations, so an unresolved issue does not disappear inside a completion label.\n\nThe editable checklist is available through the resource link below. Which item is most often missing when work moves between teams?\n\nResource: https://sales.smarttechctc.io/resources/handover.md",
    "resource": "handover",
    "kind": "Nền tảng"
  },
  {
    "id": "w4-2-personal",
    "week": 4,
    "day": 2,
    "channel": "personal",
    "title": "Một thử nghiệm đáng dừng cũng có giá trị",
    "audience": "CEO / Product / CTO",
    "angle": "Tư duy quyết định dựa trên bằng chứng.",
    "body": "I would consider a pilot useful if it helps a team make a better decision, including a decision to stop.\n\nA narrow experiment can reveal that the data is unsuitable, the review burden is too high, or the workflow changes too frequently for the proposed approach.\n\nThe important part is recording what was learned and why it changes the next investment decision.\n\nThat requires a clear question before the pilot and agreed evidence at the end.\n\nI want delivery conversations to leave room for those outcomes. Otherwise, everyone has an incentive to call the experiment a success while the uncertainty remains.\n\nWhat evidence would make you stop a promising AI pilot?",
    "resource": null,
    "kind": "Nền tảng"
  },
  {
    "id": "w4-3-company",
    "week": 4,
    "day": 3,
    "channel": "company",
    "title": "Nhật ký quyết định cho tháng tiếp theo",
    "audience": "CEO / CTO / CPO",
    "angle": "Mẫu duy trì bằng chứng và ownership.",
    "body": "Keep the reasoning behind an AI workflow visible as it evolves.\n\nOur Decision Log records the date, workflow, decision, supporting evidence, assumptions, alternatives, owner and next review.\n\nAt a weekly review, ask what changed, what users struggled with and which repeated work should be removed. At the end of a pilot, use the same record to decide what to keep, change or stop.\n\nThis creates a shared reference when leadership, engineering and operational teams revisit a decision.\n\nThe editable template is available through the resource link below. Start with one current workflow and one decision that needs an owner this week.\n\nResource: https://sales.smarttechctc.io/resources/decision-log.md",
    "resource": "decision-log",
    "kind": "Nền tảng"
  },
  {
    "id": "w4-4-personal",
    "week": 4,
    "day": 4,
    "channel": "personal",
    "title": "Câu hỏi tôi muốn tiếp tục theo đuổi",
    "audience": "CEO / CTO / CPO",
    "angle": "Chốt chủ đề, mời đối thoại; không bịa kết quả sau bốn tuần.",
    "body": "The question I want to keep exploring is how organizations make good decisions when building software becomes easier.\n\nMy working framework has four parts: a useful outcome, reliable evidence, a named owner and a way to revise the system when reality changes.\n\nIt applies to customer-facing products and internal tools. It also changes how I think about the role of a service partner: the engagement should help a team make progress on a defined problem and leave them able to own the result.\n\nI'd welcome examples that challenge this framework.\n\nWhich part deserves a deeper discussion next: choosing the workflow, validating the result, transferring ownership or knowing when to stop?",
    "resource": null,
    "kind": "Nền tảng"
  }
]