From Feature List to Workflow: A Better Way to Start a Software Project.
By Arsene Merci Hategekimana, Product Lead
A software brief often begins with a solution: a portal, an app, a dashboard, or a new platform. But starting with the interface can hide the real problem. If the underlying workflow is poorly understood, teams can end up building unnecessary features, awkward permissions, missing important edge cases, and creating rework later.
Before deciding what to build, understand the work the software is meant to support. Who starts the process? What information do they need? Who makes the next decision? What happens when something is missing, late, duplicated or disputed? Those details shape the product just as much as its screens do.
Start with a real task, not a feature list
Choose one important task and describe it from beginning to end. Keep the description concrete: “A staff member records a request, a manager checks it, and the requester learns what happens next” is more useful than “we need an approval dashboard.”
Then ask the people involved to walk through a recent example. What did they do first? What information did they look for? Where did they wait, repeat work or ask someone for help? A recent example tends to reveal the actual sequence of work more clearly than a broad description of how the process is supposed to work.
Make decisions and hand-offs visible
For each step, note who is responsible and what they need in order to proceed. Identify the points where a person makes a choice, hands work to someone else, or needs to correct information.
A simple map can use four columns:
Request arrives
Person or role: Requester or intake team
Information needed: What is being requested, and by whom?
Decision or next hand-off: Is it ready to review?
Request is checked
Person or role: Reviewer
Information needed: Required details and relevant context
Decision or next hand-off: Approve, return for more information, or redirect?
Work is assigned
Person or role: Responsible team
Information needed: Priority, owner, and due context
Decision or next hand-off: Who takes the next action?
Outcome is shared
Person or role: Requester and team
Information needed: Current status and decision
Decision or next hand-off: What should happen next?
Use this as a starting template, then adapt it to the language and roles used by the people who do the work. Replace it with the language and roles used by the people who do the work.
Include the exceptions
A map that only shows the ideal route is incomplete. Ask what happens when required information is missing, two people submit the same request, priorities conflict, an approver is unavailable, or a decision needs to be revisited.
Not every exception belongs in the first release. The goal is to make exceptions visible so the team can decide which ones the product must handle now, which can remain manual, and which need a policy decision before development begins.
Turn the map into product decisions
Once the workflow is clear, use it to shape the first version:
- What must the product record? Capture only information needed to move the work forward or explain a decision.
- Who needs to see or change each item? Clarify roles and hand-offs before designing permissions.
- What does “done” mean? Agree on the outcome a person should be able to recognise.
- What can stay manual for now? A person handling a rare exception may be safer than building a complex rule before the policy is settled.
- How will the team learn whether it helps? Choose a practical signal—such as fewer repeated data-entry steps or clearer ownership—and establish a baseline before making improvement claims.
These questions do not replace design or engineering. They give both a shared problem to solve and a way to discuss trade-offs before implementation hardens them into the product.
A small, useful next step
Take one workflow that causes recurring confusion or delay. Ask two or three people who experience it to describe a recent instance separately. Compare the steps, note where their accounts differ, and mark the decisions and exceptions that still need an owner. The disagreements are useful: they show where the process is not yet shared or clear.
A focused map helps separate the problems software can solve from the ones that need clearer processes or policies. It is a practical starting point for deciding whether software is appropriate, what it should support first, and what the team needs to clarify before building.
At Imperium, we work across product strategy, design and engineering. If you are considering a product or platform, bring us the workflow you want to improve—not only the feature list. Tell us what you are building, and we can start by understanding the work.