The product needed a three-person design conversation before more development.
The immediate subject was the user journey. We had working software and a growing list of ideas. We needed to decide which screens and moments were important enough to define before more development.
Early products can move fast and still become hard to explain. One feature is added for a demo. Another is added for a test. Soon the path through the product reflects the order things were built rather than the way a person expects to use them.
The design conversation was meant to pull those pieces together.
The product was still operating under an earlier working identity. The public company would later be Goodword. The name is less important here than the work. We were trying to make relationship software feel useful without making people feel like entries in a sales system.
That required more than colors and type. What does a person see first? What information do we ask them to connect? When do recommendations appear? What happens when there is nothing new to show? How does somebody understand why a person is being suggested?
The private notes include designs and internal product choices that are not needed in this article. The safe record is the order of operations.
We could keep adding code and clean up the path later. Or we could stop, map the journey, and make the main decisions visible before development continued.
Mapping the journey also gave us a shared object to review. A screen could be placed in sequence, discussed with the states before and after it, and changed without first rebuilding the application.
I wanted the second option. I sent the note, asked the group to meet, and framed the work around the screens and transitions a person would actually use.
The next step was a design session, not another feature request.