FCOS Flow
Turning a warehouse capacity problem into a simple operational planning tool
Role: Product Builder / Operations Lead
Company: Picnic Technologies
Product: FCOS Flow https://fcos-flow.vercel.app/
Type: Internal Operations Tool
Domain: Logistics / Fulfillment / Workforce Planning
My involvement: Problem identification · Product definition · UX/UI · Workflow design · Technical implementation · Testing · Iteration
Status: Built and deployed as a working internal tool
01 — The Problem
Planning a shift shouldn’t require guesswork.
At Picnic’s fulfillment centers, Process Captains are responsible for keeping operations running smoothly throughout the shift.
One recurring challenge was understanding:
How many shoppers can the operation realistically support at a given point in the shift, and what should the team expect by the end of the shift?
This sounds simple.
In practice, capacity decisions depend on several moving variables:
- number of shoppers available
- current workload
- operational timing
- expected productivity
- remaining work
- shift-end expectations
- changes during the shift
The information needed to make these decisions wasn’t packaged into a simple planning workflow.
This created a familiar operational problem:
Captains had to spend time calculating and interpreting information instead of acting on it.
The opportunity
Rather than treating this as an operations-training problem, I looked at it as a product problem:
Can we turn the underlying capacity calculation into a simple tool that gives Process Captains an immediate answer?
That became the starting point for FCOS Flow.
02 — Understanding the User
The primary user wasn’t a product manager. It was the person running the operation.
The target user was the Process Captain working directly in the fulfillment center.
They operate in a very different environment from someone sitting behind a laptop.
They need to:
- make decisions quickly
- work with constantly changing operational conditions
- communicate expectations to shoppers
- understand whether the current workforce is sufficient
- identify potential capacity issues early
- manage shift-end expectations
That led to an important product principle:
The tool should reduce thinking required, not add another system to learn.
So I deliberately approached FCOS Flow as a lightweight operational utility rather than a complicated dashboard.
03 — From Operational Problem to Product Hypothesis
Instead of trying to build a complete workforce-management platform, I narrowed the problem down.
Hypothesis
If Process Captains can quickly calculate required shopper capacity and understand expected shift-end workload, they can make faster and more consistent operational decisions.
That immediately gave the product a focused job:
Input → Calculation → Decision
The user provides the relevant operational information.
↓
FCOS Flow performs the calculation.
↓
The tool translates the result into something the Captain can act on.
This was important because the product wasn’t intended to replace the Captain’s judgment.
It was designed to improve it.
04 — Product Scope
One of my biggest product decisions was what not to build.
There was a temptation to create something much larger:
- workforce management
- historical analytics
- performance dashboards
- employee tracking
- scheduling
- forecasting
- reporting
But none of those were necessary to solve the immediate problem.
So I kept the MVP focused on the core workflow:
FCOS Flow helps Process Captains:
1. Understand current capacity
→ How much shopper capacity is available?
2. Calculate expected workload
→ What does the current situation imply for the rest of the shift?
3. Identify the operational requirement
→ Are additional shoppers required, or is the current capacity sufficient?
4. Manage shift-end expectations
→ What should the team expect based on the current numbers?
That constraint made the product substantially simpler.
05 — Designing the Experience
The interface was designed around one question:
“What do I need to know right now?”
Rather than presenting users with a large operational dashboard, I structured the experience around the calculation itself.
The flow follows the user’s mental model:
Enter operational information
↓
Calculate
↓
See the result
↓
Understand the implication
↓
Take action
This is deliberately different from many internal enterprise tools, where users are often exposed to large amounts of raw operational data.
FCOS Flow focuses on decision-relevant information.
06 — UX Principles
I designed the experience around four principles.
1. Minimise cognitive load
The user is already managing a physical operation.
The interface shouldn’t make them manage the interface too.
2. Make the calculation transparent
The result shouldn’t feel like a black box.
Users should understand what the tool is calculating and why the result matters.
This is especially important for an operational tool because users need to trust the output.
3. Optimise for speed
FCOS Flow isn’t something a Captain should have to study.
It’s a utility.
The desired interaction is:
Open → Enter → Calculate → Act.
4. Design for the real environment
This isn’t a consumer app being used leisurely at home.
It’s an operational tool used during a busy warehouse shift.
That influenced the emphasis on:
- clear inputs
- obvious actions
- minimal navigation
- readable outputs
- low interaction overhead
07 — The MVP
The first version intentionally solved one narrow problem.
FCOS Flow
A lightweight web application that helps Process Captains:
- calculate shopper capacity
- understand workload expectations
- assess shift-end requirements
- make operational decisions faster
The product was built as an internal tool rather than waiting for a larger enterprise-system change.
That distinction is important.
Instead of:
Problem → business case → long roadmap → engineering queue → eventual solution
I used:
Get Hameed Bello’s stories in your inbox
Join Medium for free to get updates from this writer.
Problem → hypothesis → prototype → working product → feedback → iteration
That is the part of the project that best demonstrates my product-building approach.
08 — Building It
FCOS Flow was not simply a design prototype.
I built the working application.
The product was developed as a lightweight web application and deployed through Vercel.
The implementation allowed me to go from:
Operational problem
→
Product definition
→
UX
→
Business logic
→
Working application
→
Deployment
without needing to wait for a separate development cycle.
This was particularly valuable because I could test whether the idea worked in practice rather than asking stakeholders to evaluate a static mockup.
09 — Product + Technical Thinking
One of the most important parts of the project was translating operational knowledge into product logic.
A warehouse contains many variables that make sense to someone working there but aren’t necessarily obvious to someone designing a generic workforce tool.
Because I was working directly in the operation, I could understand:
- how Process Captains actually make decisions
- which inputs mattered
- which information was noise
- when the calculation was useful
- how the output would affect the next operational decision
That created a useful product loop:
Operational experience
→ Problem identification
→ Business logic
→ Product design
→ Technical implementation
→ Operational feedback
This is one of the clearest examples of how my experience at Picnic has influenced the way I build products.
10 — Testing the Product
Rather than treating the first version as finished, I approached it as an MVP.
The key questions were:
Usability
Can a Captain understand the tool without explanation?
Speed
Can the calculation be completed quickly during an active shift?
Accuracy
Does the tool produce the expected operational result?
Relevance
Does the result actually help the Captain make a decision?
Adoption
Would a Captain voluntarily use the tool instead of relying on manual calculations?
These questions became more important than adding additional features.
11 — What I Learned
Lesson 1 — Internal tools need product thinking too
Internal software is often treated as secondary to customer-facing products.
But an inefficient internal workflow can eventually become a customer problem.
In fulfillment operations, small inefficiencies can affect:
capacity → picking → completeness → availability → customer experience
So improving internal decision-making can have downstream customer impact.
Lesson 2 — Start with the decision, not the dashboard
A common mistake in operational software is starting with:
“What data can we show?”
I started with:
“What decision does the user need to make?”
That changed the product significantly.
Instead of creating another information-heavy dashboard, I created a focused decision-support tool.
Lesson 3 — Being close to the operation changes the product
Working inside the fulfillment center gave me something that traditional product discovery often struggles to reproduce:
continuous exposure to the actual workflow.
I could see:
- where friction occurred
- what people actually did
- where calculations were performed manually
- what information was missing
- how decisions were made under time pressure
That proximity shaped the product.
Lesson 4 — A small tool can be a meaningful product
FCOS Flow isn’t a massive enterprise platform.
And that’s exactly the point.
A product doesn’t need dozens of features to demonstrate product thinking.
The value came from:
identifying a real problem → narrowing the scope → building the smallest useful solution → putting it into practice.
12 — Impact
The strongest documented operational metric associated with my Picnic work is stock completeness, the record highest nationwide result in Germany.
13 — Why I Built It
The project changed how I think about Product Management.
Previously, I had mainly worked on products where the product-development process was:
customer → requirements → design → engineering → release
At Picnic, I experienced something different.
I was simultaneously:
the user
the domain expert
the problem identifier
the product thinker
the designer
and
the builder.
That created a much tighter product feedback loop.
It showed me that some of the best product opportunities aren’t necessarily discovered through a formal product roadmap.
Sometimes they’re visible inside the workflow itself.
14 — The Product Development Loop
The FCOS Flow process can be represented as:
***Image needed — -
15 — What I’d Build Next
If the tool were expanded, I would resist simply adding more features.
I’d first validate the next operational problems.
Potential directions could include:
Capacity history
Allow Captains to understand capacity patterns across shifts.
Forecasting
Use historical operational data to estimate required capacity.
Scenario planning
Allow a Captain to ask:
“What happens if I have 5 fewer shoppers?”
or:
“What capacity do I need to finish by X?”
Shift handover
Connect the calculation with shift handover information so the next Captain understands the current operational state.
Data integration
Eventually remove manual inputs where reliable operational data already exists.
But these would be follow-on hypotheses, not features I would automatically add.
16 — The Bigger Product Insight
FCOS Flow represents a broader philosophy I now bring to Product Management:
Don’t start by asking what software should we build. Start by understanding what decision or workflow is broken.
The technology comes afterwards.
In this case, the technology was relatively simple.
The harder part was understanding the operation well enough to know what should be built and what should be left out.
That is what makes FCOS Flow a useful example of my product approach
