Key takeaways
- A personal user manual, also called a manual of me or personal operating manual, describes how you work, decide and give feedback.
- It doesn't replace a contract: scope, fees and liability stay in the contract, the manual governs how people deal with each other.
- The best time to send it is right after the first conversation and before the project starts, with a request to read it before the kickoff.
- The document acts as a filter: whoever doesn't fit notices before it gets expensive.
A personal user manual, also called a manual of me or a personal operating manual, is a short document that describes how you work, how you decide and how you give feedback. Felix Degeler, founder of Degeler Consulting (DC) in Vienna, sends such a document to every client after the first conversation and before the project starts. It doesn't replace a contract, it clarifies the expectations no contract covers.
In 2023 I wrote this document and didn't dare send it for half a year. My thinking: you don't send that to clients, too personal, too exposed. Today everyone gets it before we work together.
What is a personal user manual?
A personal user manual is an operating guide for working with a person: not a contract, not terms and conditions, but a description of working style, decision style, feedback culture and quirks.
The terms get mixed up. User manual, personal user manual, manual of me, personal operating manual: they all mean the same thing. I call mine personal terms of use for working with me as a person.
It describes how I work, how I decide and how I give feedback. And also what makes me who I am. The format is deliberately a user manual, not a brochure. It describes quirks instead of hiding them.
That's exactly what made me hesitate at first: who voluntarily sends a list of their quirks to someone they've only just met?
Why does a user manual land better than any contract?
Because it answers what a contract leaves open: how people deal with each other day to day. That creates clarity before the first friction arises.
The turning point came with a new client. I simply sent the document along and asked them to read it before we started. The reaction was better than to any contract, and the collaboration was clearer from day one.
A contract governs what happens when something goes wrong. Terms of use govern how people deal with each other so it doesn't get that far. Expectations that would otherwise only surface after weeks of friction are on the table from the first day.
How do I write a user manual for myself?
Structure your manual of me in six sections and answer a few guiding questions in each, in your own words. Here's how:
Section 1, How I work: When am I most productive? Do I prefer long focus blocks or short cycles? Do I need the big picture first or the details first? Do I prefer writing or talking?
Section 2, How I decide: Do I decide fast and correct later, or do I need time and documents? What must a decision paper contain so I can say yes or no? Who decides when in doubt?
Section 3, How I give and receive feedback: Am I direct or rather cautious? Do I want criticism immediately or bundled? In what setting, in writing, in conversation, one to one?
Section 4, How and when I can be reached: Which channel reaches me for urgent matters, which for everything else? How quickly do I usually reply? When am I deliberately unavailable? How I organise this for myself is described in time management is a system.
Section 5, What annoys me: Which behaviours reliably throw me off? Unclear briefs, meetings without a goal, silent changes of plan? This section is the most uncomfortable and the most valuable.
Section 6, What I need from you: What does the other side need to deliver so I can work well? Access, contact people, decisions by a certain point, open feedback when something doesn't fit?
Keep the document short enough that it actually gets read before the kickoff. Write the way you speak, not like a job ad. And revise it whenever a project has taught you something new about yourself.
How do I set expectations with new clients before a project starts?
Send your user manual right after the first conversation and ask them to read it before the start. That way your working style is settled before project pressure begins.
Timing matters. Before the first conversation the document looks like a condition for getting to know each other. After the kickoff it's too late, because the first misunderstandings have already happened.
In the kickoff a short follow-up question pays off: what surprised you, what do you see differently? The answers become the ground rules for that specific project. Who then carries responsibility for what, we settle with ownership instead of blame.
When is a personal user manual the wrong tool?
A personal user manual doesn't fit where formality is intended: in public tenders and in highly formalised corporate processes. There, prescribed documents count, and a personal document feels out of place.
In a tender, procurement scores against fixed criteria. A document about quirks doesn't feed into that score and can, at worst, look unprofessional. Better: bring it in after the contract is awarded, at the first working session.
It doesn't replace the contract. Scope, fees, liability, usage rights and data protection belong in the contract. The manual governs how people deal with each other, not rights and obligations.
And it isn't a free pass. Whoever describes their quirks takes responsibility for them instead of hiding behind a that's just how I am.
A filter for both sides
Since then the document goes out to everyone after the first conversation. Whoever gets on well with it, I work with brilliantly. Whoever doesn't, I'd rather not start with at all.
That sounds harsh, but it spares both sides the nasty surprise on day one. For any team: whoever describes how they work saves themselves many misunderstandings that would otherwise get expensive. Setting up collaboration clearly from the start is part of every project kickoff for us.
