A lot of software projects start too late in the process.

The team begins with screens, database tables, APIs, or a list of features. Those things matter, but they are not the best place to start. Before deciding what to build, it is better to understand how the work actually happens.

  • Who starts the process?
  • What are they trying to accomplish?
  • What information do they need?
  • Who else gets involved?
  • What can go wrong?
  • What decisions need to be made?
  • What rules always have to be followed?

Those questions usually reveal more than a feature list.

Start with the real workflow

When I am trying to understand a product or business process, I like to map it in plain language.

  • Not as a technical diagram.
  • Not as database models.
  • Not as a polished product spec.

Just the real flow:

Person -> does something -> with some information
System -> responds -> with some result
Another person -> reviews or decides -> what happens next

For example, in a training or company knowledge product, the workflow might look like this:

  • Admin uploads a company policy.
  • System processes the document.
  • Employee asks a question.
  • System searches company knowledge.
  • System gives an answer with sources.
  • Manager reviews gaps or outdated content.
  • Admin updates the source document.

That simple story tells you a lot.

  • You can see the actors.
  • You can see where information changes hands.
  • You can see where the software helps.
  • You can see where trust, review, and permissions matter.

Why this matters

If you skip this step, it is easy to build the wrong abstraction.

  • You might build a document upload feature before understanding who owns the document.
  • You might build a search feature before understanding what counts as an approved source.
  • You might build an admin screen before understanding what decisions the admin actually makes.
  • You might build permissions around job titles instead of the real responsibilities people have.

The result is software that technically works, but does not fit the business.

Good software usually comes from understanding the work first, then designing the system around it.

What to look for

When mapping a workflow, I am usually looking for a few things.

Actors

Who is involved?

This could be a customer, admin, employee, manager, driver, advisor, compliance person, or support person. The names matter because they reveal how the business thinks about the work.

Actions

What does each person or system do?

Uploads, approves, reviews, assigns, asks, answers, schedules, pays, rejects, updates, confirms, archives. These often become features, commands, or services later.

Information

What information moves through the process?

Documents, job details, customer records, policy answers, payment status, location data, notes, files, messages, approvals. This often points toward the core entities in the system.

Rules

What always has to be true?

  • Only certain users can approve.
  • Some jobs require photos.
  • Some answers need citations.
  • Some documents need review before they are published.
  • Some changes need an audit trail.

These rules are often more important than the screens.

Breakdowns

Where does the current process fail?

This is where the product opportunity usually lives.

People may be using spreadsheets, text messages, memory, duplicated documents, stale PDFs, or manual follow-up. The breakdowns show you where software can actually help.

Turning workflow into software

Once the workflow is clear, the software design gets easier.

For example:

Admin uploads policy

could lead to:

  • Role: Admin
  • Feature: Document upload
  • Entity: PolicyDocument
  • Event: DocumentUploaded
  • Background job: Document indexing
  • Permission: can_upload_documents

Another example:

Manager reviews unanswered questions

could lead to:

  • Role: Manager
  • Feature: Question review dashboard
  • Entity: KnowledgeGap
  • Event: QuestionUnanswered
  • Workflow: Review and update source material

The point is not to overcomplicate things. The point is to let the real work shape the software.

The mistake to avoid

The mistake is building around the first technical idea instead of the actual business process.

A feature request might sound simple:

We need an AI knowledge base.

But the real workflow might be:

  • Employees need current answers from approved company material.
  • Managers need to see where people are confused.
  • Admins need to update source material when answers are missing or outdated.
  • The company needs confidence that answers are traceable to real sources.

That is a very different product.

It is not just chat. It is source management, search, permissions, review, feedback, and trust.

A practical way to use this

Before building a new feature, write out the workflow in plain language.

Use this format:

Who does what, with what information, in what order?

Then ask:

  • What happens next?
  • Who else is involved?
  • What can go wrong?
  • What has to be true?
  • Where does the process break today?
  • What would make this easier, faster, or clearer?

If the team cannot answer those questions, it is probably too early to design the database or argue about the UI.

The main lesson

Understand the workflow before building the software.

It keeps the team from building the wrong thing too early. It also makes the eventual product simpler, because the design is grounded in how the work actually happens.