By the time we finished mapping the work management market, our research deck had 89 slides.
Asana. Jira. Monday. ClickUp. Linear. Notion. Motion. Wrike. Smartsheet. The list kept going.
It often felt as if almost every feature we could think of already existed somewhere.
That should have been a good reason to walk away.
Instead, the more people we spoke to, the stranger the market looked.
Some teams had task managers, project managers, calendars, chat apps and dashboards. Work was still being managed through WhatsApp, Slack, email, spreadsheets, meetings and memory.
There were more tools than ever. People were still asking, “What is happening?”
That contradiction became Oyester.
From December 2025 to January 2026, we explored building a work management and task orchestration product from a different starting point.
The idea was not to make a prettier place to enter tasks.
It was to make entering and managing them less necessary.
The work happened somewhere else
Many task managers begin after someone has already done the difficult part.
A message has been understood. A request has been turned into an action. An owner has been chosen. A deadline has been agreed upon. The task is now neat enough to become a row in a table.
Real work does not arrive that way.
It arrives as a Slack ping. A line in an email. A promise made in a meeting. A comment in Figma. A WhatsApp message someone plans to remember later.
Someone then has to translate all of this into the official system.
And keep translating.
One team we spoke to had abandoned Trello because the board still needed a person to maintain it. Another tool worked better for them only when a task could be created from the place where the team was already talking. The proof of work became the update.
A project manager described an AI-generated weekly summary from an existing platform. It could count open and completed tasks. It could not turn the comments into a useful account of what had actually changed.
The dashboard was accurate about the database.
The database was not accurate about the work.
This was the problem we kept returning to. Work management tools were meant to reduce chaos, but they often created a second job: documenting the first one.
The task manager had become another task.
We started too broad
Our first instinct was predictable.
We tried to solve everything.
Tasks, projects, teams, roles, skills, bandwidth, recommendations, integrations and AI agents. We were thinking about how work could be split between humans and AI before we had made the basic task flow trustworthy.
The early product was broad and rough. That was useful because it made the problem visible.
If people did not want to update one status, giving them a more intelligent dashboard would not help. If a task was missing, every recommendation built on top of it would be confidently wrong.
So we began trying to make the first version smaller.
The sharpest version of the individual promise we eventually wrote down was:
Tell me what to do next, and get out of my way.
The first version we sketched would collect possible tasks from the tools where work already happened, place them in one trusted inbox and recommend only a few next actions. It would create a soft plan for the day, point out blockers and show progress without making the person fill another form.
For the manager, the promise was different:
Help work flow smoothly without chasing people.
The same information could show who was overloaded, what was stuck, which dependency might cause a delay and where priorities needed to change.
It looked like one product.
It had to keep two promises.
The manager wanted visibility. The person doing the work wanted relief.
If we served only the manager, the product could become surveillance with better design. If we served only the employee, it was unclear who would pay or get an entire team to use it.
The product had to create value for the person doing the work before it asked them to create visibility for someone else.
Automation has a trust problem
AI made the idea possible.
We believed it could read messy inputs and find useful structure. A meeting might become a few possible tasks. A long thread might suggest an owner, a deadline and a follow-up. Repetitive work could eventually be routed to an agent instead of another person.
But it could also get all of this wrong.
What happens when the system creates the wrong task?
What happens when it gives it to the wrong person, guesses the wrong effort or decides someone is underutilised because it cannot see half their work?
A false reminder is annoying. A false judgment about someone’s performance is personal.
We were excited by automatic allocation: understand the task, understand each person’s strengths and bandwidth, then send the work to the best human or AI agent.
The conversations made us more careful. Bandwidth is rarely a clean number. Creative work is difficult to estimate. Priorities change quietly. Some work is confidential. People can game a metric once it affects how they are judged.
Automation reduces effort only after people trust it.
Correcting the system was not a backup feature. It was part of the main experience.
People had to be able to correct it without having to maintain it.
Why all the existing tools were still not enough
It would be easy to say the large products had missed something obvious.
They had not.
Our conversations often disagreed with one another. One team wanted a Gantt chart. Another hated complicated views. One needed multiple tags and strict access controls. Another wanted no more than three strong features. A design team lived in Figma. A small startup was perfectly happy with a morning call and WhatsApp. A much larger company kept using Sheets because process mattered more than software.
Work is not one clean object.
That helped us understand why mature tools become complex. A lot of their complexity looked like accumulated compromise.
“Simpler” could not just mean fewer fields. It had to mean fewer actions required from the user.
The new angle was to stop treating manual input as the beginning of the system. Work already left a trail across communication, documents, meetings and code. If Oyester could understand that trail, the user could become a reviewer instead of a clerk.
It also changed who we thought the competition was.
The real competitor was not always Asana or Monday. It was the spreadsheet everyone understood. The WhatsApp group everyone checked. The manager’s memory. The habit of asking for an update in a meeting because it was faster than fixing the system.
Software was competing with behaviour.
In many of our calls, behaviour won.
A crowded market can still be unfinished
I used to think a saturated market meant the interesting work had already been done.
Oyester changed that.
A crowded market can mean there is no room left. It can also mean the problem is important enough that people keep trying to solve different parts of it.
The useful question is not only, “How many competitors are there?”
It is, “What are users still doing despite all of them?”
Across our calls, we heard about teams still chasing updates, copying work between tools, rebuilding context before meetings and guessing who had time.
We did not leave January with every answer. We were still unsure about the first user, the narrowest use case and who would pay. Automatic capture raised privacy questions. Allocation needed far more context than we first assumed. Switching from an existing system was expensive. A product that promised less admin still had to earn the right to see how a team worked.
That changed how I look at crowded markets.
Competition proves that the category exists.
Workarounds prove that the problem still does.