What is define your output types knowledge work taxonomy?

Example: You are a product manager who has been in the role for three years, and if someone asked you what your job produces, you would probably say something vague like "I make sure the product gets built." But when you sit down and actually catalog the tangible outputs you created last quarter, the list is startlingly specific: fourteen product requirement documents, sixty-three Slack messages that constituted decisions (buried in threads, never recorded elsewhere), nine slide decks for stakeholder presentations, four competitive analyses, one quarterly roadmap, twenty-two Jira tickets with acceptance criteria, and roughly two hundred email replies. You produced seven distinct output types, each with different quality requirements, different audiences, and different shelf lives — but you had never named them, never distinguished between them, and never asked whether the distribution of effort across them was correct. You spent more hours on slide decks than on the requirement documents that actually drove engineering work. You made sixty-three decisions via Slack messages that were effectively invisible to anyone who was not in the thread at the time. Naming your output types does not change the work. It changes your awareness of the work — and awareness is the prerequisite for optimization.

This concept is part of Output Systems in the How to Think curriculum.