Fiuto: automated research for product direction and feature delivery

Context

The first two arcs took one feature from design to production. This third arc moves upstream, to the research that decides which feature enters the design and build pipelines in the first place. The run below follows a weekly research routine inside the coding agent as it surfaces a gap I had already accepted, insights that could not be shared, and one agent conversation as it turns that gap into two Linear projects, an initiative and the start of a build pipeline, with the corrections I had to make along the way.

Where direction comes from

The step has five parts in this run, and each is a place where the choice can go wrong.

1. Reading the competitive landscape and the sector trends, and writing a synthesis that can be picked up later, since impressions in one person’s head cannot be handed to an agent or a colleague.
2. Checking the products the synthesis names, because a product page describes an ambition and the product itself is often more limited, and a roadmap built on the page will chase a feature the competitor does not have.
3. Choosing the one finding that should change the roadmap this week, because a report contains more than a team can act on.
4. Asking what that finding implies for your own product, including the related work you have not noticed, since the first answer will usually be the smallest visible change and the real scope sits behind it.
5. Writing the result into the tracker as projects, with the threads that need more investigation parked separately, so that planning starts from a defined scope.

A researcher, a product manager and whoever owns the roadmap usually split these between them. In the run below the routine does the first, I do the second and third, and the agent does the fourth and fifth with me correcting it.

01The pipeline

Research in the /build and /ux families and the weekly routine

Research sits in two places. The /build and /ux orchestrators from the earlier articles each carry a research agent that runs before planning or design, briefed against my audience: designers, user experience managers, researchers and product owners, and small teams without the budget for a specialist researcher or a designer who also manages research. Both already live in Lovable, Replit, Notion and Linear, which set their expectation of how a product should feel. Usability and accessibility practice are the floor; the brief is written against what the audience uses every day, which in my experience produces designs that need fewer iterations. The second place is a routine called Best Practices, which runs weekly in the background with no feature attached.

The report is mine to check against the products before anything is taken from it, and two moments after that are mine as well: the choice of which finding becomes the week’s direction, and the split of the agent’s reading of it into projects before any is planned.

02The session

What is in this video

That week the Best Practices routine had reported on UserTesting, Maze and Sprig, in the markdown file with the landscape and the synthesis, which I read for things I did not know and then check. The section on UserTesting had read as alarming; when I opened the product it read as marketing speech about something more limited. Maze pitches the full research loop I intend to close as well. Sprig is strong and targets an enterprise market that is not mine.

I normally take one idea from each report. This week it was one I had already half decided against. Users could share a study and a launch, and insights, the analysis generated from a launch’s results, was a fairly complete feature, but an insight could not be shared with anyone. The competitive review made collaboration part of the loop I needed to complete before launch, so I gave the markdown file to an agent and asked what was missing.

The agent’s answer was a public toggle, which was the smallest part of the work. The useful part was the rest of the response, what I had missed from the data. First, parity for the MCP server, the interface that lets an external coding agent drive Fiuto: I had not updated it in a while and several app features were missing from it. Then continuous discovery, which to me is two separate projects. Three further items I did not investigate, because they read as postcards for later; sharing and the MCP were the two I needed before launch.

Two projects and one initiative are what I ask the agent to write into Linear: sharing and collaboration for insights, to full parity with studies and launches; MCP parity and the improvements I had been considering; and an initiative holding the last items for a separate agent to investigate and break into projects later.

Both projects are ready as they stand, so at 7:50 I open a new agent, paste the link to the sharing project and start /build with the instruction to follow the full pipeline, research included: the kickoff pass looks at the specific feature where the report looked at the landscape.

10 min Watch on Loom

A pipeline this long is worth it because the result at the end can be called shippable, though I review it after QA, code health and the UX pass. The agent’s first answer was too small: a toggle, where the work was parity across three objects. The three items left in the initiative carry no elapsed time; the recording ends at the build kickoff, before a separate agent investigates them, so how long that took is not in this session. The feature research step inside /build now runs as a targeted pass by default, after the brief is agreed and before planning, with one market lens chosen first and a rule that every finding has to change a decision in the plan or it is cut; the result is stored beside the project in Linear as Research: <feature> with its sources.

Conclusion

The finding was a sharing gap I had already accepted, and trusting it took opening three products the report named and reading the agent’s answer past its first line. That check sits between two research passes worth keeping apart: a landscape routine on its own schedule, which gives you a weekly reason to reopen settled decisions, and a feature pass that runs only once a feature is chosen, which keeps the planning agent from working off the whole landscape. Neither pass replaces opening the competitors’ products, and neither will size the work for you.