Factory Coordination: one place to plan the factory’s work
At Machina Labs, the factory team was preparing for growth. My core internship project was to work out whether existing software could support production coordination or whether we should build our own.
Separate factory workstations become connected in one shared view of the work. The equipment and activity are illustrative, not actual factory routing or automated production.
I led discovery, evaluated 17 vendors, and developed the recommendation, PRD, and phased roadmap. I also built a working V0 with Claude Code and deployed it on an internal server.
Start with the scheduler’s work
I mapped how projects moved through planning and production, combining interviews with time spent shadowing people on the factory floor. I spoke with technicians, robotics process engineers, technical project leads, the Master Scheduler, and other operational stakeholders.
The Master Scheduler was moving between tools to piece together the information needed to plan work. Keeping those tools current was inconsistent, so figuring out which information to trust was part of the job.
I initially thought we would need a sophisticated scheduling algorithm or AI. Speaking with the scheduler changed my first priority: bring the information together in one workspace. I left automatic scheduling and complex resource management for later.
Work out what was worth building
Buying had a clear appeal: it could help sooner than building and maintaining something ourselves.
I looked at how well the options could handle changing production needs and schedules. I recommended an internal product because it would give us more control over that fit and room to add capabilities as the operation evolved. I saw that flexibility as a reason to invest over time.
Engineering time was a real constraint. I proposed starting with the core work people already did, then expanding in phases. The longer-term recommendation also called for reusing capabilities in existing manufacturing software to speed up development.
The CEO approved the direction, and the PRD and phased roadmap were approved.
Build a useful first version
I built V0 solo with Claude Code and deployed it on an internal server. Someone could define a project, create production units, schedule them on a Gantt chart, and see relevant work handoffs.
The workflows stayed manual. I wanted the first version to cover the repeating work people needed to do before adding scheduling intelligence.
V0 was standalone and did not connect to the manufacturing execution system, or MES. I also made wireframes for later versions that explored bringing in information from the MES and filling it in automatically. Those integrations remained future designs.
Put it in front of users
I demoed the MVP to the lead mechanical engineer and technical project leads. They responded positively to the core workflow and asked about other capabilities. The project leads also suggested changes to how information was presented.
The demos were encouraging, but I don’t know whether the tool became part of daily operations or how it affected production.
What I’d do differently
This was my first product-strategy project with such an open starting point. Next time, I’d focus initial discovery more tightly on user interviews, make the strategic recommendation sooner, and get to a working MVP earlier.