Define your output types

You do not know what your work produces

Ask a software engineer what they produce, and they will say "code." Ask a manager what they produce, and they will say "results" or "alignment" or something equally vague. Ask a consultant what they produce, and they will say "recommendations."

All of these answers are wrong. Not because they are inaccurate, but because they are incomplete to the point of uselessness.

The software engineer also produces architecture documents, code reviews, technical specifications, Slack messages that constitute design decisions, onboarding documentation, incident postmortems, and meeting notes that shape the direction of the team. The manager produces hiring briefs, performance reviews, strategic memos, budget proposals, and hundreds of micro-decisions communicated through email threads that no one will ever re-read. The consultant produces slide decks, interview guides, data models, workshop facilitations, and relationship artifacts that exist only as trust in another person's mind.

Each of these is a distinct output type. Each has different quality requirements, different audiences, different time horizons, and different value profiles. But almost nobody names them. Almost nobody maintains an explicit taxonomy of "these are the kinds of things my work produces." And without that taxonomy, you cannot do anything systematic about output quality, output allocation, or output improvement.

This lesson gives you that taxonomy. Not a universal one — there is no single classification scheme that works for every role. Rather, a method for developing your own, grounded in what you actually produce.

Why output types matter: the Drucker distinction

Peter Drucker, in his 1967 book "The Effective Executive," drew a line that has shaped management thinking for six decades: the difference between efficiency and effectiveness. Efficiency is doing things right. Effectiveness is doing the right things.

Applied to output, this distinction is devastating.

You can be extraordinarily efficient at producing a particular output type — polished slide decks, thorough meeting notes, meticulous email responses — while being ineffective because that output type is not the one that creates the most value. The manager who spends four hours perfecting a weekly status update while deferring the strategic memo that would redirect the team's entire quarter is efficient and ineffective simultaneously. They are doing the wrong thing very well.

But here is the problem: you cannot evaluate whether you are doing the right things if you have not named what the things are. You need a taxonomy before you can prioritize. You need to see the categories before you can ask which categories deserve the most effort.

Drucker also observed something specific about knowledge workers that makes this even more critical. In manual work, the task defines the output. A bricklayer's output is laid bricks. The output type is singular and obvious. But in knowledge work, the worker must define their own output. No one hands you a list of the seven types of things your role produces. You have to discover it, name it, and then decide how to allocate your finite time across those types.

This is the work that most knowledge workers never do.

The six universal output categories

While every role produces a unique mix, research across organizational science, project management, and knowledge work consistently identifies six fundamental categories. These are not the only way to slice the space, but they are a reliable starting framework that you can customize.

1. Documents. Persistent written artifacts intended to inform, instruct, or record. Memos, reports, specifications, proposals, analyses, plans, guides. Documents have a shelf life — they are meant to be referenced after creation. Herbert Simon, in his 1947 work "Administrative Behavior," argued that organizational memory lives primarily in documents, not in people's heads. The documents your organization produces are its institutional knowledge. When you write a product requirements document or a strategic brief, you are not just communicating a decision — you are creating a node in the organization's knowledge system.

2. Decisions. Choices communicated to others that constrain or direct future action. This is the output type most people overlook entirely, because decisions often do not feel like outputs. They feel like moments. A decision happens in a meeting, in a Slack thread, in a hallway conversation — and then it evaporates. But Herbert Simon won a Nobel Prize in Economics largely for demonstrating that decision-making is the central activity of management. In his model, organizations are decision-making systems. The quality of the organization is the quality of its decisions. If decisions are your most important output type, and you are not treating them as outputs — not recording them, not structuring them, not evaluating their quality — you are neglecting the most consequential thing your work produces.

3. Artifacts. Tangible things that are used by others as inputs to their own work. Code, designs, templates, models, spreadsheets, prototypes, configurations, databases. Artifacts differ from documents in that they are functional rather than informational. A document tells you something. An artifact does something, or enables someone else to do something. The Project Management Institute's PMBOK Guide (Project Management Body of Knowledge) calls these "deliverables" — the verified products, results, or capabilities produced by a project. In knowledge work, artifacts are often your most durable outputs. The template you create today may be used by hundreds of people for years.

4. Communications. Messages intended to coordinate, inform, or influence in real time. Emails, Slack messages, presentations, verbal updates, phone calls. Communications differ from documents in their time horizon. A document is meant to persist. A communication is meant to act — to move someone from one state to another right now. The distinction matters because the quality standards are completely different. A document that is 80% complete is a draft. A communication that is 80% clear is a failure, because the recipient acts on what they understood, not on what you meant.

5. Analyses. Structured evaluations that reduce uncertainty for a decision-maker. Competitive analyses, market research, data investigations, risk assessments, option comparisons. Analyses are a specific subtype that deserves its own category because they have a unique quality criterion: they must reduce uncertainty, not just describe the landscape. An analysis that tells you "there are three options" without helping you choose between them has not completed its function. Amazon's "working backwards" process, as described by Colin Bryar and Bill Carr in their 2021 book "Working Backwards," emphasizes that every analysis should begin with the decision it is meant to inform. Define the output (the decision) first, and then work backwards to determine what analysis is required to make that decision well.

6. Feedback. Evaluative responses to other people's work that shape its quality and direction. Code reviews, document comments, design critiques, performance assessments, peer reviews, approval decisions. Feedback is an output type that most people experience as an interruption rather than a contribution. But when you review a colleague's code and catch a critical bug, or when you comment on a strategy document and identify a flawed assumption, you are producing output that is potentially higher-value than anything you created from scratch that day. Andy Grove, in "High Output Management," argued that a manager's output is the output of their organization. The primary mechanism by which a manager influences organizational output is feedback — shaping the work of others through evaluation, coaching, and course correction.

Building your personal taxonomy

The six categories above are a starting point, not a destination. Your actual output taxonomy will be more specific and more useful.

The key is specificity. "Documents" is a category. "Technical specification documents," "quarterly business reviews," and "client-facing proposals" are output types. The difference matters because each has a different audience, a different quality bar, a different time investment, and a different value profile.

David Allen, in "Getting Things Done," drew a critical distinction between projects and next actions. A project is an outcome that requires more than one step. A next action is the single physical, visible activity that moves a project forward. Allen's insight applies directly to output types: the useful level of specificity is the level at which you can distinguish the effort, audience, and quality standard.

If two output types require the same effort, serve the same audience, and meet the same quality bar, they are the same type for practical purposes. If they differ on any of those dimensions, they are different types and should be named separately.

Here is a practical process for building your taxonomy:

Step one: catalog. Spend thirty minutes reviewing everything you produced in the past two weeks. Open your sent email, your document history, your messaging app, your project management tool, your code repository — every system where your work output lives. List every tangible thing you created or substantially contributed to.

Step two: cluster. Group the items by similarity. Do not force them into the six universal categories. Let the clusters emerge from the actual data. You might find that "emails to clients" and "emails to internal stakeholders" feel like fundamentally different output types — different tone, different depth, different purpose. If they feel different, separate them.

Step three: name. Give each cluster a short, specific name. Not "emails" — that is too broad. Not "client-facing external email communications regarding project status updates" — that is too narrow and too long to remember. Aim for two to four words that uniquely identify the type: "client status updates," "design specifications," "sprint decisions," "peer code reviews."

Step four: validate. Test your taxonomy against the past month. Can you classify everything you produced? Are there orphan outputs that do not fit any category? If so, you are missing a type. Are there categories with only one or two items? If so, consider whether it is truly a distinct type or a variant of an existing one.

Step five: count and weigh. For each type, estimate two things: how much time it consumed last month, and how much value it created. Value is subjective, but you know the difference between the output that moved the needle and the output that checked a box. The gap between time invested and value created is where you will find your optimization opportunities — and that is the subject of lessons to come.

The invisible output types

Some of the most important output types are the ones you are currently not producing. Absence is diagnostic.

If you produce no documents, your decisions and analyses are trapped in conversations and ephemeral messages. Institutional knowledge is not forming. Anyone who joins your team after the fact has no record of why things are the way they are.

If you produce no explicit decisions, your organization is running on implicit consensus — which means different people have different understandings of what was decided, and misalignment compounds silently until it explodes in a missed deadline or a shipped feature that no one wanted.

If you produce no analyses, your decisions are driven by intuition and anecdote rather than structured evaluation. Sometimes intuition is right. But without analysis as a distinct output type, you have no mechanism for distinguishing informed intuition from lucky guessing.

If you produce no feedback, you are consuming other people's review capacity without reciprocating. Your colleagues are shaping the quality of your work while you passively consume theirs.

The taxonomy is not just a list of what you do produce. It is a diagnostic tool for what you should produce but do not.

Output types have different half-lives

Not all outputs are created equal in durability, and the half-life of an output type should influence how much effort you invest in it.

A Slack message deciding the color of a button has a half-life of hours. It matters right now and will be irrelevant by Friday. A technical architecture document has a half-life of months or years. It will be referenced by engineers you have not yet hired. A quarterly strategic memo might shape decisions for the next three months.

The mismatch that kills productivity is investing long-half-life effort in short-half-life outputs, and short-half-life effort in long-half-life outputs. The engineer who spends an hour crafting the perfect Slack message about a trivial implementation detail while dashing off a sloppy architecture document in twenty minutes has the allocation exactly backwards.

Once you have your taxonomy, annotate each output type with its approximate half-life:

• Hours to days: Operational communications, status updates, quick decisions
• Weeks to months: Sprint plans, project analyses, tactical decisions
• Months to years: Strategic documents, architectural artifacts, process designs, key hiring decisions
• Years to indefinite: Foundational code, organizational policies, published research, training materials

The half-life does not determine how much time you spend on an output — many factors influence that. But it should influence how much care you invest in durability, clarity, and structure. An output that will be read once can tolerate roughness. An output that will be referenced for two years needs to be clear to a reader who has no access to your context.

Your Third Brain: AI as output type analyst

AI is particularly useful at three specific points in the output type definition process.

Pattern recognition in your output history. If you export or paste a list of your recent outputs — titles of documents, subject lines of emails, names of artifacts — AI can help you identify clusters you might miss. You are inside your own work and may not notice that "client proposals," "vendor evaluation memos," and "partner briefing documents" are all variants of the same output type (external-facing persuasive documents) even though they feel different in the moment. Ask the AI to suggest groupings and see if the categories it proposes reveal patterns you overlooked.

Taxonomy refinement. Once you have a draft taxonomy, describe it to the AI along with your role and responsibilities. Ask it to identify output types that are common for your role but missing from your list. The AI draws on patterns across millions of descriptions of similar roles, and it can surface the blind spots — the output types you produce but do not recognize as distinct, or the output types you should produce but have been neglecting. This is not a replacement for your own judgment. It is a second perspective to stress-test your taxonomy.

Half-life estimation. For each output type in your taxonomy, describe the typical audience and purpose, and ask the AI to estimate the useful life span. You may discover that something you treat as ephemeral — say, meeting notes from a strategic planning session — actually has a much longer useful life than you assumed, and deserves correspondingly more care in how it is structured and stored.

The boundary is the same as always: AI can identify patterns in the data you provide and suggest categorizations based on broad knowledge. But only you know which outputs actually created value in your specific context. The taxonomy is yours to build. AI accelerates the construction.

The portfolio view

Once you have your taxonomy, you gain something powerful: a portfolio view of your output.

Just as an investor manages a portfolio of assets with different risk profiles, return potentials, and time horizons, you manage a portfolio of output types with different effort requirements, value profiles, and half-lives. And just as an investor periodically rebalances — selling assets that are over-weighted and buying assets that are under-weighted — you can rebalance your output portfolio.

The product manager who discovers they are spending 40% of their time on communications and 5% on decisions might conclude that the portfolio is misallocated. The engineer who discovers they produce zero documentation might realize they are building technical debt in institutional knowledge. The consultant who discovers that 80% of their output is slide decks might question whether presentations are really the highest-value vehicle for their insights.

The portfolio view does not tell you what to change. It tells you what to examine. It transforms a vague sense of "I'm busy but not productive" into a specific, diagnosable map of where your effort is going and what it is producing.

From taxonomy to standards

Here is what you now have: a named, specific list of the types of output your work produces, annotated with approximate time investment, value assessment, and half-life.

Here is what you do not yet have: a definition of what "good" looks like for each type.

A decision that is made quickly but communicated ambiguously might be worse than no decision at all. A document that is thorough but unreadable serves no one. An artifact that works but is unmaintainable creates debt that someone else will pay.

Each output type in your taxonomy needs its own quality standard — a clear, concise definition of the minimum bar that output must clear before it ships. That is the next lesson. The taxonomy you built today is the scaffolding that quality standards will hang on tomorrow.

Name what you produce. The names make the invisible visible. And what is visible can be improved.

---

Sources:

1. Drucker, P. F. (1967). The Effective Executive: The Definitive Guide to Getting the Right Things Done. Harper & Row.
2. Simon, H. A. (1947). Administrative Behavior: A Study of Decision-Making Processes in Administrative Organizations. Macmillan. (4th edition, 1997, The Free Press.)
3. Allen, D. (2001). Getting Things Done: The Art of Stress-Free Productivity. Penguin Books.
4. Grove, A. S. (1983). High Output Management. Random House.
5. Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide). 7th edition. PMI.
6. Bryar, C., & Carr, B. (2021). Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin's Press.
7. Drucker, P. F. (1999). "Knowledge-Worker Productivity: The Biggest Challenge." California Management Review, 41(2), 79-94.