The product list was getting longer. We needed a baseline that worked from beginning to end.
The phrase in the working discussion was the baseline product. It meant the smallest complete version we wanted to make dependable before adding more paths around it.
One of the main paths involved a person's LinkedIn connections. The product needed to help somebody bring that professional context into Goodword and then move through the next steps without losing track of what had happened.
We had already worked on copy for connecting LinkedIn accounts in March. By June, the question was broader than a single screen. The connection step had to sit inside a usable sequence with clear states before, during, and after it.
There were many adjacent things we could build. Early products make it easy to treat every useful idea as immediate work. The baseline discussion put an order around the work instead.
The team looked first at the path that had to function as one product. Connect the source, understand the available context, and continue into the Goodword experience. Supporting features could follow once that path was stable enough to use.
The private source material includes implementation notes and internal prioritization. This article does not reproduce those details. It also does not describe any person's imported connection data.
The public-safe event is the decision to concentrate on a baseline. Goodword was moving toward a beta audience, and the core path needed to be understandable without a team member explaining every step.
That made the work partly technical and partly editorial. The integration needed to function. The state of the connection needed to be visible. The words around the action needed to match what the system was actually doing.
The team put that sequence first. We were not declaring the product finished. We were identifying the version that needed to work from beginning to end before the surrounding list grew longer.