Lessons for Product from the Factory Floor
The thing about working as a Product Manager in a company that has two factories and a supply chain team is that you learn a lot about visibility and responsibility.
- Every day at 8 a.m. the Team Leads at the factory report on shipped orders, late orders, whether or not they have met their targets and why.
- When a Customer is unsatisfied and the order has to be re-printed the matter isn’t considered closed until a culprit and a reason are identified and recorded.
- On the factory floor a quick look around is enough to know what everyone is doing. Everyone knows what success looks like.
In our product team we don’t…
- Set hard deadlines for feature releases.
- Have a route for the path from idea to feature to release as clearly defined than the path of a 3D printed model from order placed to order shipped.
- Report daily on whether or not we have met our goals.
- Have performance metrics that are as consistent or clearly defined.
There are good reasons for why all those things are true. But there is as much potential for waste in the less clean-cut world of product as there is for creativity and improvement.
The big difference between 3D printing a model and releasing a feature is how clearly you can see both the goal and the path to it.
When an order is placed on Shapeways the team in the factory knows what material the customer wants their model in and when they promised to get it to them. Payment comes in advance. They can take for granted that they are working on the right thing at the right time — the challenge for them comes in the execution.
That isn’t something we can take for granted in product.
But there is a lot we can learn from the teams in our factories who focus primarily on execution.
1) Don’t work on too much at once.
In our factories the ultimate goal is single-piece flow. If you have a box of 10 models to polish and can only polish one at a time then while you work on the first one the other 9 are idle inventory. They might as well not have gotten to you yet because every minute they sit in a box with no work being done on them is a minute that no value is being added to them.
Pursuing single-piece flow means reducing idle inventory. Never have a design left for weeks waiting for a front-end engineer to have bandwidth. Never have a line of code written but not released because another task got pushed in front of the developer at the last minute.
It also has two useful side-effects. It provides crystal-clear visibility into what is being worked on and where. And it provides a constant sense of achievement — models move very fast through a single-piece flow.
Granted — it is important not to go after single-piece flow too dogmatically. Not all process steps in the tech team or in the factory move equally fast, and different features require different resources. So ultimately you need a buffer — a bit of idle inventory waiting to make sure the busiest ICs are never left without something to do. Having the whole company work on only one feature at once almost certainly means some valuable resource is being underused.
But the principle is a valuable one. A tech, design & product team of around 25 people working on 2 or 3 substantial features at once will move much faster than a team working on 10 or 15.
2) Define process steps
Imagine a factory where each team member decides for themselves — without any set structure — what process steps a part should go through and when. If you’re solving for the fastest route to bankruptcy that isn’t a bad way to get there.
The need to define process steps sounds painfully obvious but explicit is better than implicit.
Of course — not all features are the same and constant improvement is essential so there should be corresponding flexibility built in to the system. But that doesn’t mean there shouldn’t be any system at all.
The benefit of this for the software team is a much clearer understanding of what stage a feature is in at a particular moment in time. Its good to throw out suggestions for fundamentally different approaches when first considering a feature. It is less helpful to have those discussions after a pull request has been sent. Making clear which stage a feature is in at a given point in time provides a useful framework for defining what questions are being asked and how best to answer them.
These are the process steps for features we’ve come up with — like everything else, it’s still a work in progress:
3) Define the input and output of each step
Defining the input is necessary to set a standard for what you accept from the previous step. The quality of output is usually limited by the quality of input so that is a good place to start. By defining the output, you set a standard to hold yourself to before bothering the team responsible for the next step.
To take an example from the process steps above — the input for step 3 should be spec-able components coming from product to tech. If the components are well enough defined for the relevant tech team to confidently estimate how long executing will take in weeks, then the input is good enough for this step. If there isn’t enough definition for — say — a front end developer to have a high-level but clear path to execution in mind and be confident that their estimate will be accurate to the nearest week then they shouldn’t accept the input from product.
Putting an estimate on a component that isn’t well enough defined is roughly the same as polishing a badly mangled model coming from the previous production step on the factory floor. You’re adding no value and in fact making things worse by increasing the amount of time before the defect is identified and resolved.
4) Break each step down into smaller chunks to minimize lead time and maximize touch time
Dependencies — where your work on a part or a feature can only be started once mine is done — are at best a fast handover but more often than not they are the cause of delays. We have different words for it — blocked, waiting for input, needs review — but one way or another each dependency increases the risk that lead time goes up and touch time — the time spent actively working on a model or feature — goes down.
An example from a feature we’re working on now is the combination of Sets and Variants. Sets are intended to allow a user to sell multiple models as a single product — a necklace together with a pair of earrings. Variants are to allow different versions of a single product — several sizes of a ring.
After an initial estimate, it looks like one is easier to solve than the other but we have often referred to the two together as one feature. By decoupling them we can begin work on Variants before we have a clear solution on how to provide Sets, offering one tool to our Shop Owners as early as possible rather than waiting to offer two at once.
5) Production isn’t a one-way street
A lot of work is done in the factory to develop and improve controls which make sure parts only move on to the next step in production when the previous step has been completed successfully.
However — movement in the opposite direction of information, questions, complaints and parts is and should be free, fast and unrestricted.
Potential improvements, concerns and any other possible form of feedback — including but not limited to the throwing of office supplies at product managers — should always be flowing from whoever is working on a model or feature to those responsible for the previous steps.
The natural rhythm of a factory floor will always be a much more consistent beat than that of a product team. But we are both engaged in the pursuit of making things — physical and digital — of high quality that people will love to use.
On studying and developing lean methodology, many in the software world are surprised to discover that manufacturers have been implementing the same principles for decades. By constantly learning from how the teams in our factories define and improve their process I hope we can avoid those sorts of surprises going forward.
