The seven principles of the Yes Please Framework
These are the seven beliefs that make the work possible. I lean on them when a session gets ambiguous and I have to make a call. They also travel home with you after the engagement, because the most useful thing about a principle is that it works without me in the room.
01. Start with the pain, not the platform.
Every engagement starts with a recurring workflow that costs more time, energy, or attention than it should. Conversations about which tools people use come after the conversations about how people work.
Warning sign. If the first 20 minutes are spent on which tool to use rather than what work hurts, you are already in the wrong conversation.
02. Solve a specific thing before zooming out.
Build something that works for one thing before talking about the bigger system. The first running artifact is what creates the appetite for personal OS, team integration, or org-level work.
Warning sign. If you are pitching a bigger system before something at the workflow level has actually shipped, you are getting ahead of yourself.
03. Fit the brain, not the framework.
The system has to match how this specific person or team actually thinks, what they are responsible for, and what tools they have access to. There is no canonical OS to install. There is only the one designed for them.
Warning sign. If two engagements at the same level produce systems that look interchangeable, you have stopped designing for the person and started installing a template.
04. Built with you, not for you.
The install happens in the room together. You set up your environment, name your fields, and run the first execution alongside me. The install step is part of the engagement, not a follow-up email.
Warning sign. If the engagement ends with a doc you still have to "implement when you have time," nothing has actually been installed.
05. Capability transfer is the contract.
The promise is not a working system. The promise is a working system you understand well enough to maintain it, extend it, and teach the next person on your team how to use it. If you cannot rebuild it, the engagement failed.
Warning sign. Two weeks after handoff, can you walk a colleague through how the system works without notes? If not, the capability never really transferred.
06. Lowest viable beats most complete.
Always design for the smallest version that solves the actual problem. Add only what the work demands. Resist the temptation to design the full system on day one.
Warning sign. If something is in the v1 system without a real, observed pain behind it, it should not be there yet.
07. Find the rules before you play.
Every system gets built inside constraints that do not move. Tools the company has standardized on. Security and compliance rules. Things this person or team is simply not allowed to change. Before you redesign anything, find those edges. The freedom is inside them.
Warning sign. If the v1 system needs a tool you do not have, a permission you cannot get, or a workaround you are not allowed to do, you skipped this step.