All posts
The software factory needs to become a product factory
A software factory answers whether something can be built. Product teams need to know what to build and whether it worked. That loop is product work, and it should be built for the PMs, designers and ops who do it.
Ben Ong
October 16, 2026
product-development
ai-agents
A loop of five cards, Signal, Plan, Build, Review and Learn, around three product people on an orange halftone background
Coding agents can now take a well-described change and turn it into a pull request. Put them behind a pipeline with sandboxes, tests, previews and review, and you have a software factory.
That's real progress. But it answers a narrower question than most product teams are asking. A software factory answers "can we build this?" The question PMs, designers and ops start their day with is "what should we build, and did it work?"
We think the software factory has to grow into a product factory. And the people who run a product factory aren't only engineers. They're the product people who sit closest to customers.
A software factory measures output
Look at how software factories are judged today: tasks completed, pull requests merged, time from ticket to deploy. Those are output measures. They tell you the machine is running.
They don't tell you whether anyone used the feature, whether onboarding got easier, or whether the account that asked for it renewed.
Product teams are judged on outcomes. When the factory only tracks output, product people end up where they were before agents. They write a ticket, hand it over, and wait to find out what came back.
Faster builds move the bottleneck to product decisions
When building took weeks, slow product decisions were hidden behind a slower build. When an agent can produce a working change in an afternoon, the slow part is deciding what the change should be and learning whether it was right.
That work belongs to product people. A PM knows which customer problem is worth solving. A designer knows the states and edge cases a user will hit. Ops and support know where today's workflow breaks. Sales knows what a lost deal asked for.
If that knowledge reaches the factory as a one-line ticket, the agent fills the gaps with guesses. The code can pass every test and still solve the wrong problem.
What a product factory adds
A product factory keeps the software factory's machinery and wraps a loop around it:
- Signal. Start from evidence, such as customer conversations, support themes, product usage and competitor launches.
- Plan. Turn that evidence into a plan the team can read and an agent can act on. It covers the problem, the intended behavior, what must not change, and how the team will know it worked.
- Build. Agents implement the plan in an isolated environment on the real codebase.
- Review. Product people check the change in a live preview. Engineering reviews the code and approves the merge.
- Learn. After the change ships, the team checks whether customers used it and whether the outcome moved. That evidence feeds the next plan.
The software factory is steps three and four. The product factory is the whole loop. The steps that turn one into the other, signal, plan and learn, are product work.
Built for product people, not handed to them
Most software factory setups are built for engineers to operate. Product people appear at the edges. They file the request at the start and look at the result at the end.
A product factory has to put them in the middle. In practice that means:
- Product people can start and shape work in plain language, without a terminal or a local development environment.
- The plan is visible and editable by everyone involved, so a designer can catch a missing empty state before it becomes code.
- Previews run on the real product, so a PM reviews working behavior instead of a mockup.
- Outcome evidence sits next to the plan, so the team decides what comes next from data instead of from whoever argued loudest.
This doesn't remove engineering from the loop. Engineers set the guardrails, own the architecture and approve every merge. Product people take on more of the work only they can do well, and they arrive at review with a better change.
Signals still need judgment
A product factory isn't an autopilot that reads a dashboard and ships features. A competitor launch is a reason to investigate, not a spec to copy. A drop in a funnel doesn't say which release caused it. A loud request might matter to one account and no one else.
Product people are trained to make those calls. The factory's job is to put the evidence in front of them when they plan, and to carry their decisions into the build intact.
Where LightSprint is today, and where we're going
Today, LightSprint gives PMs, designers and ops a shared cloud workspace on the team's real codebase. They describe a change in plain language, work on the plan together, and check the result in a live sandbox preview. Builders propose changes and view previews. Approvers, usually engineers or leads, review and merge through the team's existing approval controls. Work can start where teams already are, in Slack, Linear or Jira. That covers plan, build and review.
The next step is closing the loop. We want the signals product teams already watch, like usage data from tools such as PostHog and Amplitude and changes in the competitive market, to inform the next plan instead of living in a separate tab. You can do this directly by connecting MCPs in LightSprint and asking what to build in LightSprint, but we're making that experience 10x smoother.
If you want the stage-by-stage view of how product people take a change from idea to production today, read The Product Builder SDLC.
The factory should serve the people deciding what to build
Every team will soon have access to a software factory. The difference will be what goes into it and what the team learns from what comes out.
That's product work. The factory should be built for the people who do it.