Maybe we don’t have a productivity problem. Maybe we have a context problem.
I used to think being organized was mostly about having the right system. A good board, clear priorities, a calendar that actually reflects reality, tasks written down instead of kept somewhere in your head, all the things that are supposed to make work feel manageable. And to some extent, that’s true. But the more I’ve looked at how people actually work, especially freelancers, solopreneurs and people juggling several projects or clients at once, the more I’ve started wondering whether we’re trying to solve the wrong part of the problem. Because most work doesn’t begin as a task. It begins as an email from a client, a comment in a document, something mentioned during a call, a Slack message sent late in the afternoon, a WhatsApp message you tell yourself you’ll remember later, a file shared without much explanation or a tiny request added almost casually at the end of another conversation. Somewhere between all of those things and the actual work, someone has to make sense of it, and usually that someone is you.
We talk a lot about productivity, task management and prioritization, but most productivity tools start at a point where the messy part has already happened. You open the tool and create a task, give it a title, add a due date, assign it to a project and maybe decide how important it is. Everything looks nice and structured. But before you can do any of that, you first have to understand what the task actually is. You have to read the message, work out whether the client is asking for a change or simply sharing feedback, remember which version they are referring to, connect it with something discussed during a meeting two days earlier, find the relevant file and decide whether “sometime this week” actually means Thursday because they have a presentation on Friday. Only then can you create the neat little task. That process may take thirty seconds or ten minutes, but it happens over and over again throughout the day, and I think we underestimate how tiring it is. Not because any individual step is particularly difficult, but because it constantly forces you to switch context and keep small pieces of information active in your head.
This is also why someone can have a beautifully organized project management system and still feel overwhelmed. The system itself may be perfectly fine. The problem is that it only contains the things that successfully made it into the system in the first place. The email you forgot to turn into a task isn’t there. The small thing a client mentioned during a call isn’t there. The feedback sitting in a Google Doc isn’t there. The voice message you planned to listen to again isn’t there. So when you open your task manager and see twelve tasks, you don’t necessarily have twelve tasks. You have twelve tasks that were captured. Everything else still lives in the surrounding communication, in files, in conversations and sometimes just in your memory. That distinction feels subtle until something important gets missed, and then suddenly it becomes the entire problem.
There’s also a strange point where a productivity setup itself becomes another thing you have to manage. You might use Gmail for client communication, Slack for one project, WhatsApp for another, Google Drive for files, Notion for notes, a calendar for meetings and something like Trello, Asana or ClickUp for tasks. Every tool makes sense individually, but together they create a new job: keeping everything synchronized in your head. Where was that feedback? Did I already add this to the board? Was the new deadline mentioned in email or during the call? Which file is the latest one? Did I reply to that client or only think about replying? At some point the problem stops being “How do I organize my tasks?” and becomes “How do I make sure nothing disappears between all the places where work happens?” That feels like a much more interesting problem because it isn’t really about productivity in the traditional sense. It is about maintaining context.
Client communication makes this particularly obvious because clients rarely communicate in neat task-manager language. They don’t usually write: “Task: Update landing page copy. Deadline: Thursday. Priority: High. Project: Website launch.” They write something more like: “Hey! We had another look at the page and I think the headline still feels a little too formal. Could we try something friendlier? Also maybe the second section should mention the new offer. We have a meeting on Friday so it would be amazing if we could see something before then.” For a human being, there is quite a lot of structure hidden inside that message. There is probably a task, maybe two. There is a deadline. There is context. There might even be an implicit priority. But none of that becomes structured work until somebody interprets it. Which means we spend a surprising amount of time manually translating communication into action, and because this translation feels small and happens in little fragments throughout the day, we rarely count it as work.
That has changed the way I think about productivity a little. Maybe the biggest improvement isn’t always helping people complete tasks faster. Maybe it’s reducing the amount of mental effort required to understand what needs attention in the first place. Less remembering, less copying, less searching, less “I know there was something else…” and less opening five different apps just to reconstruct what happened with one client. If you could reduce that layer of invisible administrative thinking, work might feel significantly calmer even if the actual number of tasks stayed exactly the same. The benefit wouldn’t necessarily be that you suddenly complete twice as much work. It might simply be that your brain no longer has to act as the integration layer between every tool you use.
This is also where I find AI more interesting than another productivity chatbot. There’s obviously a lot of AI being added to work tools right now: chat with your workspace, generate a project plan, summarize a document, create tasks from a prompt. All of that can be useful, but I’m more interested in something slightly less spectacular and maybe more practical - AI that quietly helps connect messy communication with structured work. Something that notices that a client message contains an action, recognizes a deadline, understands which project the conversation belongs to, connects a new request with previous context or helps surface something before you forget it exists. Not another place where I have to ask AI what to do, but something helping me notice what already needs to be done. To me, that feels much closer to the real friction in day-to-day client work.
Of course, we might be completely wrong, and that’s exactly what we’re trying to find out. It’s very easy to fall in love with a problem once you’ve spent enough time thinking about it. You start noticing examples everywhere. Every forgotten email becomes evidence, every frustrated freelancer becomes validation and every messy workflow looks like proof that your theory is right. That’s dangerous because there’s a big difference between a problem people recognize and a problem they care enough about to actually change their behavior. So before making too many assumptions, we’re trying to understand how people really manage this today. How does work reach you? What usually gets lost? What do you still copy manually? Which tools genuinely make things easier, and which ones mostly create another place you need to check?
We’re working on a product called Hyzo around some of these ideas, but right now I’m much more interested in whether the problem itself is real than in convincing anyone that we already have the answer. So we put together a short discovery survey for freelancers, solopreneurs and people working across multiple client projects: https://tally.so/r/ODy8q8
And if surveys aren’t your thing, I’d love to hear your answer to just one question here: Where does most of your work come from before it becomes a task? Email, Slack, meetings, WhatsApp, comments in documents, your own notes - or does everything already flow perfectly into one system and this entire theory is nonsense?
The last answer might actually be the most useful one.
This is such a relatable post. The administrative burden of translating a casual client message or a Slack thread into a structured task is totally overlooked. The idea of using AI to bridge that context gap rather than just building another chatbot is really refreshing! Great perspective.
mine mostly arrives mid-thread, as a reply to something already in motion. the email vs slack split never predicted anything for me though. what predicted it was whether a thing showed up self-contained or as a fragment that only makes sense against an earlier conversation.
self-contained survives bad capture. fragments get lost with good capture, because you save the message and the part you actually needed was why it mattered.
if it's useful for the survey: ask people to open something they saved two weeks ago and say whether they still know why they kept it. the ones they can't are usually the mid-thread ones.
That’s a really good distinction: self-contained vs. mid-thread feels much more useful than thinking in terms of channels. And I love the “open something you saved two weeks ago” test. It gets straight to whether the context actually survived, not just whether the message was captured. I’m definitely stealing that for our discovery questions :)
This makes me think the real problem is not just capturing tasks, but preserving the context behind them. A task can tell you what to do, but not always why it matters, what was already tried, or what constraints came from earlier conversations. That context is often what gets lost between tools.
Yes, exactly. Sometimes the task itself is the easy part - it’s the little bits around it that matter most. Why the client asked for it, what changed, what was already discussed, what not to repeat. Once that context gets scattered, even a simple task can become surprisingly hard to pick up again.
Exactly. That “why” is often the first thing that disappears, even though it can be the most important part when someone picks the work up later.
Most of my work already starts as a task. The gap appears at the other end: the work gets finished in Claude Code, but the result never flows back, so the board has context when the task is assigned and loses the truth when the task is completed. I have started thinking of task capture and task reconciliation as the same problem in opposite directions. Are you looking only at the intake side, or also at the return path after the work happens?
This is a really interesting inversion of the problem. We’ve been thinking mostly about the path from communication → task, but you’re right that task → work → updated source of truth is essentially the same context problem in reverse.
I don’t think we should look only at intake. If the task says one thing while the actual work has already moved somewhere else, the system becomes stale again. When you finish something in Claude Code, what would you ideally want to flow back automatically: the result itself, a summary of what changed, decisions made along the way, or all of it?
What I keep coming back to is that most task managers assume the task is already the source of truth. But in reality, the source of truth is often the conversation that created it.
The interesting question for me is: how much of that original context do we actually need to preserve for a task to still make sense two weeks later?
Curious how others here think about that.
The translation layer you're describing is the part nobody counts as work but everyone is doing. I tracked where my time actually went across a full quarter in a sales role: the "work out what the client actually asked" phase consumed more hours than the delivery work itself. Sometimes 2-3x more.
The bit about the task manager only containing what successfully made it in is the sharpest framing I've seen for why organized people still miss things. You can have a perfect system and still have 30% of your actual obligations living in WhatsApp, a half-remembered call, and a shared doc nobody followed up on.
One thing I'd push on: the harder problem might not be detecting tasks but preserving the original context around them. "Update the landing page" is not the same task as "update it because the client finds the headline too formal and they're presenting Friday." Without the metadata, the task exists but frequently gets done wrong.
Which causes more downstream problems in the workflows you're seeing: things that never become tasks at all, or tasks that exist but lost their original meaning?
As a general rule, I'm a big fan of the fact that a lot of “productivity issues” are actually “context issues”. ~
A task might be easy to write on a To-Do list, but difficult to accomplish when the pertinent emails, decisions, files, and conversations are in various locations.
The segment on "setting the context to work" rings particularly true. Then it takes 20 minutes to get back into the state where you know what to do.
I also believe there is a difference between taking in information and linking information. Most tools are fairly decent at storing messages, tasks and notes. The more difficult part is knowing which pieces go with which pieces when you need them.
I think it is a much more useful way to consider productivity than "doing more in a day"!
Really resonates — especially the "second job" of keeping everything synced in your head. That's the exact pain I hit running a small SaaS, and what finally helped was letting an LLM agent watch my inbox and docs, then surface what actually needs action instead of expecting me to capture everything. It closes the capture gap at the source rather than relying on memory. Curious: have you tested any approach that captures context at the source, or do you think that just moves the sync problem up a level?
So true—context switching is a productivity killer. I've found that capturing every random thought immediately helps. I use Taskai on my Android to dump tasks from chats and notes so they don't clutter my brain while I'm working.
We solved this in the MSP world 20 years ago with a rule that still works: nothing is real until it hits the ticket queue, no matter which channel it came from. The discipline was never the tool, it was forcing every request through one intake point. Your AI angle makes sense, but I'd test whether people trust the machine to decide what counts as a task, because that is where I'd expect adoption to stall.
That’s a really useful comparison. In a way, maybe the AI opportunity is not to invent a new workflow, but to remove the discipline tax from an old one. “Nothing is real until it hits the queue” works if everyone consistently follows the rule. The interesting question for me is whether the system can make that happen without asking people to change how they communicate. And I agree that trust is probably the harder part. Missing a task is bad, but confidently creating the wrong one could be worse.
I’d be curious: in your MSP experience, would you have trusted a system that automatically created tickets as long as it showed you the source and made correction easy, or would you still want a human to confirm every new item?
One failure mode I’d test early is what happens when the available context disagrees with itself.
Real client work often looks like:
Monday: “Let’s ship A.”
Wednesday Slack: “Actually, switch this to B.”
Friday: the old Google Doc still says A.
If a system collects all three and produces one clean summary, it can create something worse than missing context: confidently wrong context.
I’d avoid treating context as one accumulated blob.
For every extracted decision or constraint, I’d preserve at least:
source, timestamp, confidence, and whether a newer piece of evidence superseded it.
When two credible sources conflict, I’d rather have Hyzo explicitly surface:
“These instructions conflict — B appears newer”
than silently decide which version is true.
There’s also a useful validation test here. Take real tasks where requirements changed during the project, wait two weeks, then ask:
“What is the current instruction, and can you show why?”
The metric wouldn’t be how much context Hyzo captured. It would be how often the user reconstructs the current state correctly without following a superseded instruction.
Have you encountered contradictory or superseded context yet in the discovery interviews?
This is such a good failure case.
“Confidently wrong context” is probably worse than missing context, because at least missing context creates uncertainty. A clean summary can create false certainty.
I also really like the idea of treating decisions as separate pieces with provenance rather than constantly collapsing everything into one canonical blob. Source + timestamp + superseded-by feels much closer to how real work actually evolves.
And your validation test is excellent. “Can the user reconstruct the current state correctly?” is a much more meaningful metric than “how much did we capture?”
We have seen requirements changing mid-project, but I don’t think we’ve been probing contradictory sources explicitly enough yet. I’m adding that to the next discovery conversations.
Curious about one thing: when A and B conflict, would you want the system to infer that B supersedes A when the evidence is strong, or always ask you to confirm the change?
I think the context problem is very real. For me, the difficult part isn't always remembering the task itself, but remembering why I needed to do it and what happened before it.
I can write "fix this page" on a task list, but a few days later I still need to find the conversation, screenshot, file, or previous decision that explains what "fix" actually meant.
I also don't think another tool automatically solves this. Every new tool can become another place where context gets stored. That's why your idea of connecting existing communication to the work is more interesting to me than simply creating another task manager with AI.
For my own work, context comes from a mix of my notes, conversations, screenshots, files, and things I notice while working. Getting those pieces connected is definitely harder than making a to-do list.
Yes, the “why” is the part I think traditional task systems lose most easily.
“Fix this page” is technically a task, but without the conversation, screenshot, previous decision or constraint behind it, it’s barely useful a few days later.
And I agree about the risk of adding another tool. If the user has to manually move all that context into one more place, we haven’t really solved much.
What I’m increasingly interested in is whether the system can keep those pieces connected automatically, so when you come back to the task later, the reason behind it is still there.
Out of curiosity, which piece do you lose most often in practice: the original conversation, the visual reference, or the decision that led to the task?
I can lose any kind of that. Thometimes I need much time to find a context to start do a task.
Honestly, this is the part I keep getting stuck on. The whole promise of "solving context" falls apart the moment it depends on people diligently feeding another tool. Most won't, and the ones who do will resent it. So you haven't removed the burden — you've just handed it to someone else and called it a feature.
The version I actually believe in flips that. The person shouldn't be the one doing the bookkeeping at all. The system watches, records, and stitches things together on its own, and it only surfaces something when there's a real fork in the road — a choice a human genuinely needs to weigh in on. Everything else stays invisible.
That shift, from "help people track context" to "make context something they never have to think about," is where the real leverage is.
Yes, I think that’s the line. The moment the user has to remember to maintain the context layer, the product has already failed part of its job. What I find especially interesting in your framing is the “real fork in the road” part. Because maybe the goal isn’t to automate every decision, but to make the system quiet by default and only interrupt when human judgment actually adds value.
That feels like a much better design principle than “capture everything and show everything.” The hard question then becomes: how does the system know what deserves to interrupt you?
"Twelve tasks that were captured" is the line that lands - the same thing happens in finance ops, where the books look clean because they only contain the receipts that made it into the inbox. What's helped my team is treating capture as its own job with an owner and a single intake channel, so translating a vague client aside into a real task isn't done twelve times a day by whoever read the message. The part I'm still unconvinced AI solves is the judgment step, like knowing "sometime this week" means Thursday because of Friday's presentation - that's relationship knowledge, not text in a thread.
The point about productivity tools only managing work after the messy part has already happened really resonates. I think the real challenge is often capturing context and turning scattered communication into clear action. Curious to see whether AI can solve that without creating yet another tool people have to manage.
That’s exactly the tension I keep coming back to. If solving the context problem means asking people to maintain one more system, we’ve probably just moved the problem somewhere else.
The interesting version for me is one where the system does most of the capturing and connecting quietly in the background, and the human only steps in when something actually needs a decision.
I’m curious, what would make something like that feel like “one more tool” to you versus something genuinely invisible in your workflow?
One thing this discussion made me realise: a lot of you experience this problem very differently. If you’re a freelancer or run a small client-service business, we’re currently researching how this looks in real workflows. We have a short survey here: https://tally.so/r/ODy8q8 No sales pitch - I’m genuinely interested in what breaks between communication and getting the work done.
That's something simple yet difficult. Because people always get confused productivity with time management.
The distinction between context loss and productivity loss is useful because the remedy changes. In my own product work, I’ve seen people add automation to a workflow whose real bottleneck was that a decision lived in someone’s head. Before adding another tool, I’d log the last five moments where work stalled and label each one: missing information, unclear ownership, or too many handoffs. If most are information gaps, a context layer is the right product; if they’re ownership gaps, another workspace won’t fix it. Your “open something saved two weeks ago” test is a strong discovery prompt because it checks whether the why survived, not just whether the message was captured. I’d be curious whether your interviews reveal “I can’t find the answer” or “I have to ask the same person again” more often—those sound similar but imply very different retention loops.
I really like separating information gaps from ownership and handoff problems. We probably risk grouping all three under “context” if we’re not careful, and that could make the problem look bigger than the part we can actually solve.
Your “I can’t find the answer” vs “I have to ask the same person again” distinction is particularly interesting. Have you noticed one of those happening materially more often in your own work?
You put "this entire theory is nonsense" on the menu, so here's the partial version. I don't think the number of places is the pain, and I doubt the channels question will separate anyone from anyone.
My own notes sprawl across dozens of files, and I keep declining the standard advice to consolidate them. A big reorganize is scope creep wearing a hygiene costume: merging and re-clustering feels productive and produces nothing. What I run instead is a patrol for exactly two poisons. Which of these is current, and I can't find the thing. A file causing neither is allowed to stay messy. Sprawl was fine. Ambiguity wasn't.
I'd point that at your own gap between recognizing a problem and caring enough to change behaviour. Agreement doesn't tell you which one you're getting. Some people agreeing here have probably been bitten; others may just think the framing is right. Both write the same comment. "Where does most of your work come from" has the same shape: everyone can answer, and the answers probably won't sort those two apart.
recal_jackson's open-something-you-saved-two-weeks-ago test is the one here that can fail, and I'd argue it's stronger than the explanation attached to it. The misses get read as mid-thread fragments, but the test doesn't need that to be the cause. It registers that the context didn't survive for one person, whatever the cause. What I'd add is the price tag: when they can't say why they kept it, what did that cost, and when.
That gives you a disqualifier, which discovery usually lacks. If someone's work is scattered across every channel in your list but neither poison has bitten them this month, they're probably not who you build for yet.
All of this is one person's read. Those two poisons are the ones in my own work, which has no clients in it. Someone holding four client deadlines may well have a third I've never met.
I think the “price tag” is the part I was missing here. We’ve been asking where things get lost, but not consistently asking what happened because they got lost. Those are very different levels of pain.
And your disqualifier is uncomfortable in a useful way: someone can have an objectively chaotic workflow and still not have a problem worth solving. I’m going to test that distinction in the next conversations. Out of curiosity, when one of your two “poisons” does bite, which one tends to be more expensive: not knowing what’s current, or not being able to find the thing?
When I was working at Meta, we had something called SecondBrain and MetaClaw that seemed to handle this pretty neatly. Basically all documents in our gdrive, all conversations in gchat, and greppable codebase were available to the agents to condense, filter, and store as needed. It avoided having to hold a lot of content in the head across all the chats, documents, etc.
That’s fascinating, especially because it sounds much closer to a context layer than a traditional task system.
Do you remember what made SecondBrain/MetaClaw actually useful day to day? Was it mostly being able to retrieve something without remembering where it lived, or did it actively surface context before you went looking for it? That distinction is something we’re thinking about a lot.
My answer: most work starts as an interruption, not as a task. The expensive part is deciding whether a message is actionable, whether it belongs to an existing thread, and whether it deserves attention now. If I were validating this, I would ask people to show the last 5 things that became tasks, then trace where each one originally appeared. That should expose the real workflow better than asking which task tool they use.
“Most work starts as an interruption” might actually be a better framing than the one I started with :)
And I really like the last-five-tasks exercise because it avoids asking people to describe their workflow from memory. I suspect the reconstructed path would be much messier than the workflow people think they have.
Have you used that kind of backwards tracing in your own discovery work?
Really resonates. The "your brain is the integration layer between every tool you use" line is exactly what I've been circling around.
I build Qrush Vault, a free desktop prompt manager, and I saw the same thing happen with prompts specifically. People don't lose prompts because they lack a place to store them — they lose them because prompts arrive from all directions: a chat you had yesterday, a paste from a blog post, a version someone shared in a group chat, a tweak you made in a hurry. By the time you want to reuse that one prompt that worked, the context around it is gone: which project it was for, which model version, what it even did.
The fix that actually worked wasn't a better task manager. It was removing the "remember where I put this" step entirely — every prompt lands in one place the moment you save it, tagged by project, with version history so you always know which one actually worked. Same principle as your point: stop making the human be the index.
One thing I'd add to your list: it's not just where work lives — it's also where the good versions of things live. Version history is the quiet hero of context. Nobody remembers "the email before last", but a diff does.
“Stop making the human be the index” is a great way of putting it. And version history adds another dimension I hadn’t really addressed in the post: sometimes you can find the right thing, but not the right state of the thing. Do you treat versions themselves as context in Qrush Vault, or mostly as a history you can fall back to when something goes wrong?
Really resonates. The "your brain is the integration layer between every tool you use" line is exactly what I've been circling around.
I build Qrush Vault, a free desktop prompt manager, and I saw the same thing happen with prompts specifically. People don't lose prompts because they lack a place to store them — they lose them because prompts arrive from all directions: a chat you had yesterday, a paste from a blog post, a version someone shared in a group chat, a tweak you made in a hurry. By the time you want to reuse that one prompt that worked, the context around it is gone: which project it was for, which model version, what it even did.
The fix that actually worked wasn't a better task manager. It was removing the "remember where I put this" step entirely — every prompt lands in one place the moment you save it, tagged by project, with version history so you always know which one actually worked. Same principle as your point: stop making the human be the index.
One thing I'd add to your list: it's not just where work lives — it's also where the good versions of things live. Version history is the quiet hero of context. Nobody remembers "the email before last", but a diff does.
I’ve been noticing this exact problem in customer support too. A lot of the difficulty isn’t handling the request itself, but having the right context when it comes in.
This hits home. I spent months building elaborate Notion templates and automated workflows, thinking the friction in my work was a lack of structure. Eventually, I realized I was just spending 30% of my day 'managing the system' rather than doing the actual work because the context was scattered across five different channels. I stopped trying to force everything into one rigid board. Instead, I started keeping a single 'daily scratchpad' where I log every incoming request, email, and slack nudge in real-time. If it doesn't have the context of where it came from and why, it doesn't get a task card. It’s significantly reduced the time I spend just trying to remember what a specific file or comment was even for.
Your scratchpad is really interesting because it sounds like you ended up building a manual version of the layer I’m describing: capture first, keep the “where” and “why”, structure it later.
What I’m curious about is where that system still breaks for you. Is the scratchpad now enough, or do you still have moments where something never makes it into it in the first place?
For me, a lot of client work starts in messages rather than directly in a project management tool. Email, WhatsApp, and Fiverr messages are probably the biggest sources, and the tricky part is remembering to turn those conversations into actual tasks with deadlines. Sometimes the request is clear in the conversation but gets buried once new messages come in. I definitely relate to the problem you’re exploring with Hyzo.
I’ve also been working on educational content at at Physics Fundamentals, where keeping track of content ideas, updates, and publishing tasks across different platforms can become challenging.
This is very close to the workflow we’re trying to understand. Especially the part where the request was perfectly clear when you read it, but disappears simply because the conversation keeps moving.
When that happens, do you usually notice because you remember it yourself later, because the client follows up, or only when the deadline gets close?
The part that landed for me is that most tools start after the messy work is already done. Turning a vague client message into a real task is the actual job, and it is pure context stitching, not prioritization. I have the same pattern when shipping software. The board looks clean while the inbox, call notes, and half remembered decisions are where the fatigue lives. A useful system would capture that raw signal first, with the source attached, and only force the neat task shape after the meaning is settled.
Sublime perspective. Context overrides raw execution every single time. True leverage belongs to those who control the signal architecture. 👑🛡️
This is a much better way to frame the productivity conversation. A lot of what looks like procrastination or lack of focus is really the cost of constantly rebuilding context—switching between Slack, email, meetings, docs, tickets, and dozens of browser tabs just to remember what we were trying to accomplish in the first place. We keep adding productivity tools, but every new tool can become another place where context gets fragmented. The real breakthrough may not be helping people work faster, but helping them preserve context: what was decided, why it was decided, what changed, and what needs attention next. Reduce the cognitive cost of reconstructing that story, and productivity becomes a natural outcome rather than something we have to constantly optimize for.
The framing I'd add is that context isn't one thing — there's the context you can write down and the context you can't. Tool-switching cost is the visible half and the one everyone measures, but the expensive part is usually reconstructing why you made a decision three weeks ago. That never lived in any tool, so no amount of consolidation recovers it.
Which one are you pointing at? A tool can hold the first kind. I'm less sure anything holds the second.
That’s a really useful distinction. I think we’re mostly pointing at the first kind - context that exists somewhere, but gets separated from the task as work moves between tools. But the second kind is probably the harder and more interesting problem. Maybe the goal isn’t to “capture” all of it, but to preserve enough of the trail around a decision that reconstructing the why later becomes much easier.
Do you find that missing context is usually genuinely unwritten, or was it there at some point and just became impossible to find?
Mostly genuinely unwritten, I think, and for a structural reason: the moment you're deciding something is the moment you have the least idea which parts will matter later. You write down what you chose because that's the output. The three options you rejected in the first ten seconds never become text at all, because rejecting them felt like nothing at the time.
The findable-but-lost kind does exist and it's the more tractable half. A decision buried in a Slack thread was written, and search is a real fix for that.
But there's a case in between that I keep hitting. The context was written, it's findable, and it's now misleading — the note says "going with X for now" and doesn't say the "for now" expired six weeks later when a constraint changed. It reads as current. Preserving the trail helps only if the trail also records that it went stale.
Does your framing treat a stale note as recovered context or as a different failure?
Also, I'm on X as @ark_y_k if you're there — easier than tracking each other through IH threads.
I think stale context is a different failure - and probably a more dangerous one.
Missing context tells you “I don’t know.” Lost context tells you “I know this exists somewhere.” But stale context tells you “I know the answer” when you actually don’t anymore.
That makes me think recovery alone isn’t enough. A useful context layer would somehow need to understand when a decision was conditional, notice when the underlying constraint changed, and at least question whether the old decision is still valid. Which is obviously much harder than search.
Your “for now” example is a really good one. I’m going to steal that distinction for our discovery questions :)
And yes, I’m on X - I’ll find you there. Much easier than excavating increasingly deep IH threads 😄
Your point about preserving context rather than just capturing tasks really clicked with me. I have a practical solution I’d love to show you and potentially prototype around this problem.
What’s the best way to reach you?
Thanks! Feel free to DM me here on IH :)
I don't think IH has direct messaging between users. Do so you have X, Instagram, or an email I can reach you at?
The distinction between captured tasks and work still stuck in communication is spot on. One test I'd add: save the source message and one sentence about why it matters when you create a task. If that takes more than 20 seconds, capturing the task is probably the bottleneck. That's part of why I built DictaFlow: saying the task and its context is often faster than turning a messy Slack thread into neat fields, and you won't have to reconstruct the reason two days later.
I really like the 20-second test. It makes me wonder if the goal shouldn’t be “capture all context automatically”, but rather make adding the missing bit of context almost effortless. If you had to pick one, what usually matters more in practice: preserving the original source, or adding that one sentence about why it matters?
The context problem framing feels more useful than the usual “use a better task manager” advice. A task can be perfectly organized and still be wrong or incomplete if the context that produced it is scattered across five different places. The interesting product question is whether Hyzo can reliably reconstruct that context without creating another inbox people have to manage.
Yes, I think that’s exactly the risk. If a tool is supposed to reduce mental overhead, but ends up becoming another place to check and maintain, it probably makes the problem worse, not better. That’s the line I keep thinking about too: what would make something like this feel quietly helpful rather than like another inbox in disguise?
That’s the part I’d be most interested in understanding better. I’d be happy to continue the conversation by email — what’s the best email to reach you on?
Happy to keep it here for now - would be curious to hear your thoughts on that question.
That makes sense. I think the key question is whether Hyzo can make the context available at the moment it’s needed without asking the user to actively maintain another system.