The problem with planning inside your tools

Most tools are good because they are opinionated about a specific kind of work.

Linear is good because it understands product and engineering execution. Notion is good because it gives you a flexible place to think, write, and organise. Calendars are good because they are built around events and time commitments. Airtable is good because it makes structured lists and pipelines easy to shape. Motion is useful because it makes scheduling feel less manual. Apple Notes and paper are good because they are immediate, personal, and low-friction.

The problem starts when you try to plan your whole week inside any one of them.

We spent about three years trying different systems and configurations for planning work. Sometimes that meant a Notion workspace with planning pages, project databases, and review templates. Sometimes it meant Linear cycles and issues. Sometimes it meant Apple Notes or a piece of paper on the desk. Sometimes it meant Motion rearranging tasks around the calendar. Sometimes it meant a Hobonichi planner, where the week had a physical shape and planning felt more like a ritual than an admin task.

Each system worked for a while. Each one also broke down in a slightly different way.

The thing we eventually realised was that the tools were not really the problem. The problem was that each tool made one kind of work more visible than the others. If we planned inside Linear, engineering work became the centre of the week. If we planned inside Notion, the week became too flexible and too easy to reshape. If we planned inside the calendar, tasks started pretending to be events. If we let scheduling become too automated, we lost some of the feedback that comes from placing work into the week ourselves. If we planned on paper, the ritual felt good but the system became disconnected from the actual backlog.

The issue was not that any of these tools were bad. The issue was that weekly planning is its own context.

Planning inside a tool changes what feels important

Every tool has a worldview.

Linear sees work as issues, projects, cycles, priorities, and statuses. That is exactly why it works so well for product and engineering teams. It gives product work a clean path from idea to ticket to implementation to completion.

Notion sees work as pages, databases, documents, blocks, and relations. That makes it good for thinking, writing, collecting, and experimenting with structure.

Calendars see work as events. They are good at showing when something happens, who is involved, and how time is committed.

Motion sees work as tasks that can be placed into available time. That makes scheduling easier, but it also changes the relationship between planning and decision-making.

Paper sees work as whatever you put in front of yourself. It is good for focus, immediacy, and personal ritual.

None of these perspectives are neutral. They shape what you notice. They shape what you forget. They shape what feels urgent, what feels real, and what gets carried forward.

That matters when you are planning a week, because a week rarely belongs to one domain. Especially if you are a founder or builder, the week might include product, marketing, sales, fundraising, hiring, writing, operations, support, finance, research, and personal admin. Each one might already have a good tool attached to it, but the actual question of the week is not “what is in Linear?” or “what is in Notion?” The question is “what matters now?”

That is a different context.

To-do lists were immediate, but too personal

The simplest system we tried was the to-do list.

Apple Notes, scraps of paper, quick lists at the start of the day. These still work well for solo execution. There is something very hard to beat about writing five things down and crossing them out. It is fast, direct, and personal in a way most software is not.

The issue is that personal lists do not scale into shared planning very well. A list can help one person decide what to do next, but it does not explain why something matters, what project it belongs to, how it relates to other people’s work, or what should happen if it does not get done.

A to-do list is good at capture. It is not enough for coordination.

This became more obvious as our work spread across domains. A list might contain “follow up with X,” “fix onboarding bug,” “rewrite pricing,” and “update deck,” but those tasks do not really belong to the same kind of time. Some require deep focus. Some require context from another tool. Some depend on another person. Some are really placeholders for bigger decisions.

The list made the work visible, but it did not make the week coherent.

Notion was flexible, until we needed structure

Notion was the next obvious place to try.

The flexibility is genuinely useful when you are still figuring out what your day-to-day work looks like. You can start with a blank page, add a table, turn it into a board, connect it to projects, create templates, add notes, embed docs, and slowly discover the shape of the system.

That was useful for a while. It gave us room to experiment.

The problem was that once we knew the rhythm we wanted, the flexibility became a liability. We were no longer trying to discover whether planning, tasks, routines, and reviews mattered. We knew they did. At that point, keeping everything in a flexible workspace meant we were constantly maintaining the system instead of using it.

Pages drifted. Templates changed. Reviews became inconsistent. Planning docs accumulated. We could always adjust the structure, which was useful in theory, but tiring in practice. It meant the system was always slightly negotiable.

That negotiability is fine when you are exploring. It is not ideal when you need a reliable weekly loop.

The other problem was that Notion made it too easy to mix long-term thinking with day-to-day execution. Strategy docs, project notes, task lists, research, review templates, and operating plans could all live in the same space. That sounds convenient, but it often meant we were wearing too many hats at once.

We would open a page to decide what needed to happen this week and end up rethinking the quarter. Sometimes that was useful. Most of the time, it made execution heavier than it needed to be.

Linear was sharp, but not the whole week

We still use Linear.

Linear is great for building software. It gives engineering work a sharp shape: issues, cycles, projects, priorities, ownership, status, and a clear path from ticket to completion. When the job is to break product work down, assign it, build it, and get through tickets, Linear is very good.

A lot of MONOid is influenced by Linear. The clarity, the speed, the opinionated structure, the low-friction creation of work, and the sense that good software should make the state of work easier to understand.

But not all work is engineering work, and not everyone thinks in tickets.

This became clearer when working with people outside engineering: marketers, operators, designers, collaborators, and anyone whose work is organised more around schedules, campaigns, review windows, content calendars, launches, and deadlines. Linear can represent that work, but it does not always feel natural for it.

The time component was the missing piece for us. A marketer might need to think in terms of a launch rhythm. A founder might need to balance fundraising, product, writing, hiring, and customer work in one week. A designer might need review cycles and production blocks. These things can become tickets, but they do not always feel alive inside a ticketing system.

Linear is excellent for product execution. The week is broader than product execution.

That is the distinction we kept coming back to. MONOid is not an attempt to replace Linear. It is an attempt to take some of the principles we admire in Linear and apply them to a different unit: the week.

Calendars were good for events, not tasks

The calendar was another tempting place to plan the week.

At first this makes sense. A calendar has time. It shows the shape of the day. It shows where meetings are. It makes constraints visible. If the problem is that tasks need to happen in time, then putting tasks on the calendar feels logical.

But we kept running into the same issue: calendars are good for events, not tasks.

An event has a fixed time. A meeting happens at 2pm. A call has attendees. A deadline exists outside of you. A task is different. It might need a certain kind of energy, a certain amount of context, or a certain relationship to other work. It might move. It might need to be broken down. It might belong to a project or a routine rather than a fixed slot.

Once the calendar becomes the place for everything, it gets harder to tell what is actually fixed. Tasks start competing visually with meetings. The calendar becomes full, but not necessarily realistic. A day can look productive while being almost impossible to execute.

We wanted time awareness, but we did not want every task to pretend to be an event.

Motion automated the wrong part

We also tried Motion and other AI scheduling tools.

The appeal was obvious. If tasks need to happen in time, then an AI scheduler sounds like the right answer. Give it the tasks, give it the calendar, and let it find the slots. In theory, this removes a lot of manual planning.

It helped in some ways, but it also clarified something for us: scheduling is not just admin. Scheduling is part of decision-making.

When you place work into a week, you learn things. You see that the plan is too ambitious. You notice that all the maker work has been pushed into the worst parts of the day. You realise that one meeting breaks the afternoon. You see that a task you keep rescheduling probably needs to be cut, clarified, or turned into something smaller.

That feedback matters because it keeps you close to the real constraints of the week.

The problem was not that Motion scheduled badly. The problem was that we did not want the most important part of planning to be abstracted away. Finding a free slot is useful, but deciding whether the task belongs in the week is the real work.

That distinction matters to us. We are not trying to build software that automates your decision-making. We are trying to build software that makes the decision-making surface clearer.

Without a weekly planning ritual, automated scheduling can make you more reactive. Tasks keep moving around. The calendar fills up. The system finds space, but you may not have had the harder conversation with yourself: what should matter this week, what kind of time does the work need, and what should not be done at all?

For us, the point is not just to put tasks into empty slots. It is to stay close enough to the week to understand it: where the pressure is building, where maker time needs protecting, where manager time needs containing, and where the plan has become unrealistic.

Paper planners had the ritual, but not the system

The closest thing emotionally was probably the handheld diary.

Hobonichi-style planners were especially useful because they made the week feel real. A good paper planner gives the week a shape. It creates a ritual around planning and reflection that most software misses. You can see the week at a glance, make commitments, write notes in the margins, and build a rhythm that feels connected to the actual passage of time.

That mattered more than we expected.

Planning is not just information management. It is also a ritual. It is a moment where you ask what matters, what can realistically happen, and what needs to be carried forward. Paper is good at making that moment feel intentional.

The problem was that it required too much manual work. There was no source of truth for backlogs. There was no easy way to pull tasks in from where work already lived. There was no simple way to connect reviews back to projects. There was no way to sync with increasingly agentic workflows. And once something was written down, it was either fixed on the page or had to be rewritten somewhere else.

The diary had ritual. It did not have enough system.

Weekly planning needs its own space

The pattern across all of this became clear. To-do lists had immediacy. Notion had flexibility. Linear had executional clarity. Calendars had time awareness. Motion had scheduling automation. Paper planners had ritual.

We did not want to throw those qualities away. We wanted a weekly layer that could borrow from all of them without becoming trapped inside any one of them.

When you are planning, the context should be planning. Not product, marketing, operations, fundraising, admin, or whatever an automated scheduler can fit into an empty slot. When you are reviewing, the context should be reviewing. Not the tool where the work originally lived.

That is the core thesis behind MONOid: the week should be a real object. Not just a calendar view, a task list, a project board, an automatically generated schedule, or a planning doc, but a place where projects, tasks, routines, and reviews can come together across domains.

Execution and strategy need to stay connected, but separate

Another distinction we kept returning to was the difference between long-term thinking and day-to-day execution.

These two things need to be connected, but they are not the same kind of work. Long-term thinking asks what you are building toward, what matters this quarter, what bets you are making, what kind of company you are trying to become, and what should be stopped. Day-to-day execution asks what needs to happen today, what should move forward this week, what is blocked, what needs review, and what should be carried forward.

When these collapse into the same space, execution gets heavy.

We tried this in Notion. It was flexible enough to hold everything: strategy docs, project notes, task lists, reviews, operating plans, and random thoughts. But because everything could live together, the boundaries between modes became blurry.

That made it too easy to be in the wrong mode at the wrong time. You could be trying to execute and suddenly find yourself redesigning the whole strategy. You could be trying to plan the week and end up editing an old positioning document. You could be trying to review what happened and instead start creating more tasks.

We do think execution needs to be connected to long-term strategy. Otherwise, work becomes busywork. But the connection needs to be calm. When you are executing, you should know that the task in front of you compounds toward something larger, but you should not have to reopen the whole strategic question every time you start work.

For longer-term planning, we use WyrdOS at wyrdos.app. MONOid sits closer to the ground. It is about the day-to-day and week-to-week execution layer: what matters now, what should happen this week, what needs review, and what should carry forward.

The week is the missing layer

A day is often too reactive. A quarter is often too abstract. The week sits in the middle.

A week is long enough to make meaningful progress, but short enough to review honestly. It is also the unit people already use when they ask what they are doing next. The week naturally holds intention, execution, and reflection together.

For us, the week became the place where strategy had to become believable. Not final, not perfect, but believable enough to act on.

That is why we think weekly planning deserves its own space.

The week should help you decide what matters across domains. It should let you pull work from the tools where it already lives. It should let you place work inside routines, because different kinds of work need different kinds of time. It should make review easy enough that you actually do it. And it should help you carry forward what still matters without manually rebuilding the entire context every Monday.

This is the part we could not find in the tools we were already using.

What we currently think

Planning inside your tools makes the tool’s context too powerful.

That is useful for domain-specific work. Linear should make engineering feel sharp. Notion should make thinking flexible. Calendars should make events visible. Motion should make scheduling easier. Paper should make thoughts easy to capture.

But the week has a different job. It has to hold the awkward middle layer between strategy and tasks: what matters now, what can realistically happen, what needs review, and what kind of time the work actually needs.

That is the space we are exploring with MONOid.