In this chapter
Greenfield means building a product from the beginning. It does not mean the team has an empty calendar. Choose a small first result and the person who will accept it. We share basic lessons with One Man Army; here we add team work.
External team? Set the framework before work begins
On a project delivered with a software house, I learned that documentation, control of assets and knowledge transfer need rules from day one. Before the first task, prepare a documentation skeleton and identify company accounts and people on your side. Agree with the contractor on the materials to accept, key people's availability and an exit plan in the contract — how the collaboration will end and the work will be handed over.
See my five software-house lessons and the list to complete
Work through those lessons before starting delivery, then return to the steps below.
1. Prepare the tool
Each person completes a workshop trial. Agree which models and add-ons may be used. You do not need to change tools for the whole team.
2. Prepare a place for the project
Create the repository, identify the playbook and keep one plan. The project-preparation lesson has download packages and a prompt. Choose the scope you need, attach the package to the conversation and let the agent organise the files.
Also prepare Confluence documentation: a main page, the child pages you need and people responsible for their content. Record the known goal and scope; add subsequent agreements as you work. A second person should be able to find the goal, rules and next step without reading the entire chat. A Jira task should lead to the plan, and the plan to the task.
3. Say what you are building
With the person deciding about the product, agree the audience, problem, and scope of the first version. The idea-description prompt helps with the questions. Agreements go into the existing product description or product.md, the file that describes what is being made.
4. Agree behaviour and technology
Go through the user scenario, data, and connections to other systems. Check organizational standards first. When a new choice is needed, compare cost, maintenance, and who will be able to support it. The solution lesson guides this decision.
5. Show the first interfaces
Before building screens, show a visual prototype. Use the existing design system: shared elements and visual rules. If there is none, agree a small set. The interfaces lesson takes you from graphics to a clickable preview and corrections.
Agree who accepts the appearance. Record the accepted graphics and rules in the plan so that everyone doing the work has the same reference point.
6. Build one working slice
One person leads and another checks. Start with a task that crosses the scenario: screen, logic, and data. Show a demo, correct feedback, and check the result. As part of this, the agent completes the relevant Confluence pages: the rule, integration or behaviour that has just been created. A second person checks the description together with the change. Only then expand scope and parallel tasks.
7. Check the whole and release it
After a larger stage, give the change to an independent review by a stronger model in a fresh conversation. After an agreed refactor, check the new version. Before releasing, complete and check instructions needed to use and maintain it. Separately agree the release, message, and maintenance. In the following chapters, you will work through the task, demo and review, then the release. Choose the first task now; do not plan the whole product in detail immediately.