Work2gether AI Operations
When building is cheap and operator time is the scarce resource, automating operations belongs in the first version, not after product-market fit.
What I built
Early on, I had to face a practical question: if I was going to run Work2gether AI on my own while also doing other work, what would it take for the business to run without me in the loop?
The answer was to automate the operational work that normally comes much later, once a product has traction and a team to run it. I built two sets of flows, mainly in n8n:
Sign-up, onboarding and engagement. A visitor signs up on the website, their email is validated, and a trial user is provisioned securely through the product's public API. From there, an automated sequence takes over: two weeks of onboarding emails that walk new users through the product, followed by nurture emails that build on what came before ("A quick recap from your AI Coach. We previously talked about...").
Discovery before users. A workflow collects questions managers post in a large management community on Reddit and stores them in a database. A second step uses an AI model to score how well each question fits the coach's domain, with a written reason for each score. The best matches become real-world input for testing and improving the coach.
What it revealed
Designing for "no operator" changed what counted as the first version. In classic MVP thinking, onboarding automation and systematic discovery come after you've proven the product. Here, they were a precondition for running it at all. Once building is cheap, that sequencing assumption no longer holds.
You can learn from users before you have many. Real questions from real managers gave me a steady stream of problems to test the coach against, long before usage data could. The scoring with written reasons made it quick to review, rather than another pile of input to sort manually.
Automation handles the people who arrive. It doesn't make them arrive. The flows worked, but the number of trial users stayed small. That's honest evidence about the limits of this approach: it removes the operator bottleneck, not the distribution one. It also means the engagement flow has run with too few users to say much about its effect.
What it means for a product organization
Much of the usual sequencing (build the product, find traction, then automate operations) comes from the cost of building. When that cost drops, operational flows like onboarding, nurturing and discovery become part of product design rather than something another team adds later.
That raises an ownership question. In most organizations, these flows sit across product, marketing and customer success, often with handoffs between them. When one person can design all of them as a single system, it's worth asking whether they should still be split across functions, or owned closer to the product.
It also changes when learning can start. Product organizations often wait for usage data before running real discovery. Public conversations where your users already are can provide a continuous learning loop from day one.
What I'd test next
Running the same kind of flows in a team where product, marketing and customer success each have a stake, to see who ends up owning them and whether they stay one system. And with enough users, measuring what the onboarding and nurture sequence actually changes.
Read more
- How We Created Learning Loops Without User Data (on LinkedIn)
- Related: Work2gether AI
See the other things I've built to test how AI changes product organizations.
Back to Fieldwork