How Do We Define Our Smallest Unit of Value?

One fundamental yet challenging questions in product development is:

“How do we define our smallest unit of value?”

This question sits at the crossroads of product strategy, flow efficiency, and organizational alignment. Defining this unit well is critical because it directly impacts cycle time, feedback loops, team autonomy, and ultimately, customer impact.

Drawing from flow science, product thinking, and systemic approaches, here’s what I think makes a smallest unit of value truly effective.

What Do I Mean by "Smallest Unit of Value"?

At its core, the smallest unit of value is the minimal increment of work that:

• Tests a clear hypothesis about product outcomes,
• Provides a quick way to communicate the actual value delivered,
• Helps learn what the next best steps are

It is not merely the smallest technical task, nor is it necessarily a user story as traditionally framed in agile. It’s the smallest slice that advances learning for the team and impact for the customers.

FIRST: The Lens from ProKanban.org

The FIRST acronym from ProKanban.org is a way to assess whether a work item is well-formed for smooth flow. It ensures that each item contributes to predictability, flow efficiency, and empirical process control.

This checklist helps teams create work items that are technically and operationally sound and ready for reliable flow through the system : The smallest unit of potential value that will generate an opportunity to learn !

To deepen the reflection, ProKanban.org also proposes a set of guiding questions, here are a few:

• Am I getting feedback at the earliest possible opportunity?
• Is this being split vertically?
• Do I think this can fit within our team’s cycle time SLE?
• Is all of this necessary right now?
• Is there a simpler way to do any piece of this?

These questions foster critical thinking about the true minimalism and value-focus of each work item before it enters the system.

Why It Matters: The Science of Small Batches

As Donald Reinertsen explains in The Principles of Product Development Flow, smaller batch sizes have many advantages. Here are the 10 benefits he lists :

1. Reduces queues and thus cycle time,
2. Reduces variability,
3. Accelerates feedback,
4. Reduces risk,
5. Reduces overhead,
6. Improves overall efficiency,
7. Improves motivation,
8. Reduces urgency,
9. Reduces slippage (or schedule growth),
10. Doesn’t lead to even larger batches

Some interesting benefits ! Which company wouldn’t love that?

What if there is an even smaller acronym to help you create the smallest unit of potential value? Something even more easy to remember? Here is what I came up with !

Introducing VIA : the pathway to fast learning

Why the acronym VIA ?

Obviously because it's even smaller than FIRST ! that is smaller and better than the well known INVEST acronym !

More seriously...

Because it’s not just an acronym, it's a word that resonates to the topic :

• “Via” (a Latin word for road) : symbolizes the pathway to progress

Your smallest unit of value is the route through which your product evolves and delivers learning and impact.

What do the different letters of VIA mean ?

While FIRST ensures operational readiness, I think that the VIA criteria go further and encompass the product hypothesis and outcome perspective.

Examples: VIA in practice

Counterexamples

Challenges that may arise and need to be considered

While seeking for the smallest unit of potential value, you need to be aware of the potential risks of slicing something too thin.

I consider the 2 main risks to be:

Context Switching: Smaller items can lead to increased WIP and context switching, which may compromise the flow. How do your workflow explicit policies ensure a controlled WIP? What policies need to be updated? What new policies can be put in place to ensure a controlled WIP and a minimization of context switching?

Transaction cost: A flow of smaller items will create the overall number of movements to get a bunch of items to done, which can introduce complexity and additional cost compromising the return on value. How can you reduce the transaction cost? How can your team ensure smooth and frequent integration without compromising quality and speed? How to not overload the customer with many frequent updates?

Addressing these challenges will help your team fully leverage the advantages of smaller, actionable items.

Conclusion: Define to Learn, Not Just to Deliver

In product development, value is always a hypothesis until validated by real-world feedback. The smallest unit of value should therefore aim to test those hypotheses as quickly and independently as possible.

By applying ProKanban.org’s FIRST principles and the guiding questions, and/or my VIA principles, you set your teams up for:

• Outcome oriented conversations,
• More predictable flow,
• And a fastest way to get to outcomes that matter.

Your smallest unit of value is your road to continuous discovery and delivery. Every step counts, take them wisely !

‍