Build the one workflow that would tell you whether the product is worth continuing, and put everything else on a later list. That includes the parts that feel attached to it. Most of the work is in that second sentence.
What counts as a workflow in an MVP?
A workflow is a sequence a user starts and finishes. Someone books an appointment. Someone reads an article.
It has a beginning, an end and a result you can point at.
A feature is smaller. A calendar view, a reminder email. Features hang off workflows.
A thin slice of every workflow gives you a dozen half-built things and no sequence a user can finish. One complete workflow gives you something to put in front of a real person next week.
When we plan a first release with a founder, we ask for one sentence: a person does this and gets that. If it takes two sentences, there are two workflows.
Why does everything feel connected to the first release?
Because it is connected. Draw the product on a whiteboard and you can run a line between almost any two boxes. Booking touches payments, reminders, history and staff schedules. Content touches accounts, search and review.
Seeing the lines, a founder concludes the boxes ship together. A line only says the two will need to talk at some point. It does not say when.
In practice the connection usually runs one way. The first workflow needs a stand-in for the second. The stand-in can be crude: a hardcoded list, a form that emails a person, a spreadsheet someone checks every morning.
Crude is fine here. You are finding out whether the first workflow works, and a stand-in is enough to find that out.
How do you choose between two workflows, like content and booking?
Petitarian is a veterinary platform with content and booking workflows. Both are real products on their own. A founder in that position has to decide which one carries release one, and the other waits.
This post does not cover what Petitarian chose. It uses the platform to show the choice, because the questions are the same whichever way it goes.
Four questions help:
- Which workflow would tell you to stop if it failed?
- Which one can you run by hand for the first users?
- Which one needs the other to exist at all?
- Which one gives you something to learn from in the first month of real use?
Write one line of answer for each workflow. If one of them wins three of the four, that is release one. If it splits two and two, take the one you can learn from fastest.
If content goes first, booking gets a stand-in: a contact form that emails someone who answers it. If booking goes first, content gets a few pages written by hand with no publishing tool behind them. Either way the second workflow is deferred, with a place on the list.
What goes on the later list?
Everything that is not part of the one workflow. Write each item with the reason it moved and what would bring it back.
An entry looks like this: reminder emails, moved because someone can send them by hand while volume is low, back when sending by hand takes more than an hour a week.
Give every entry a trigger. Without one, the later list is a pile nobody looks at.
A trigger can be a number of support emails about the same thing, or a customer who offers to pay for it.
How do you stop the later list from creeping back in?
When someone asks to add something to release one, ask what comes out. If nothing can come out, it goes on the later list.
Review the list after the release has real usage, not before. What you wanted in week two and what users ask for in week six are different lists.
When a deferred workflow does get built, it gets its own domain team with its own data model, API and tests. That keeps it from tangling with release one, which by then has users and should stay stable. Adding it does not mean piling more people onto one backlog.
What does a one-workflow release still need?
It has to finish for real. Real data, real users, and a way for you to see what is happening.
That means login, a basic admin view, error logging and someone reachable when it breaks. Those belong to release one because without them you cannot tell whether the workflow works.
Payments need a decision. If the workflow ends with someone paying, take a real payment in release one. If it does not, leave billing out.
What if one workflow feels too small to show anyone?
It will feel small. A single workflow with a stand-in behind it looks thin next to the product in your head.
Judge it by whether a user can finish it and whether you learn something. The number of screens does not matter. A person who books, reads or pays and gets the result has used a product.
Tell early users what is coming later. A short note on the page is enough. The ones who want the later list will say so, and that tells you what to build next.
FAQ
How many workflows should an MVP have?
One. If two depend on each other so tightly that neither works alone, build the smaller one fully and use a stand-in for the other.
What if an early customer asks for the second workflow?
Put it on the later list with their name next to it. That gives you a real demand count when you review the list.
How do I know I have cut enough?
Describe release one in a single sentence where a person does something and gets a result. If the sentence needs a second 'and then', cut again.
If you want to see how we lay out a first release against a later list, there is a sample roadmap.