Goose Group

The judgment behind our work: where we start, what we protect, what we ask of an experiment, and what we consider a useful contribution. This reading edition draws from the live Goose Group Smaak package, rather than summarizing the website essays.

Philosophy

Start from the customer’s customer. Every recommendation traces to the end customer. Before advising anything, map where value creation and revenue creation sit for this client. They are adjacent, not overlapping. Protect the value side. Optimize the operations side. The distinction matters because optimizing workflows risks removing what creates value — a restaurant makes money on alcohol but creates value through ambiance and hospitality.

The client already knows the answer. They know their business better than we do. Surface their implicit knowledge, operationalize their judgment, hand it back in a form that compounds. We bring outside perspective and pattern recognition — not answers they couldn’t reach. This matters because lasting change comes from inside; imposed solutions get rejected.

Bottom-up human enablement. Start with the people closest to the work. Amplify their judgment, reduce friction, and make their contribution easier to use and govern. The point is not to remove people from the work or flatten expertise into cheaper output.

Build the smallest useful thing. Prove value before investing more. A bounded working artifact teaches more than a large plan when it reaches real users and examples. Capabilities beat abstract systems. The appropriate timebox depends on access, risk, and workflow complexity; the invariant is that the artifact must create evidence for the next decision.

Find champions, create culture. Innovation is a verb. People at all levels have ideas — they need guidance and permission, not a mandate from the top. Find the person who’s been saying “we should try this” for months. Help them try it. One win opens their eyes to what’s next.

Taste as infrastructure. AI without encoded judgment is commodity. Taste is structural: philosophy + constraints + output standards + behavior. Companies that encode it differentiate. Those that don’t compete on price. This matters because LLMs optimize for average — differentiation lives at the edges.

Factory thinking. Build the factory, not the product. Features depreciate. Capabilities compound. The investment is “build the substrate that makes solving future problems cheaper.” We make tools that help us make tools.

Useful, not done. Ship something useful today. Improve it tomorrow. 1.01^100 = 2.7x. Stop waiting for done.

Technology: boring is good. PostgreSQL over trend. Simple is maintainable. Convention over configuration. If you can’t debug it at 2am, it’s too clever.

Value over efficiency. Aim at value first; efficiency tends to come when you do value well. Sometimes the point of the work genuinely is efficiency — that’s fine, but even then, aim at value as you build. Self-checkout saved labor cost and destroyed basket size because nobody named what the shopper got out of it. The discipline isn’t “never optimize for efficiency.” It’s “never optimize for efficiency without naming what the customer — or the employee at the end of the chain — gets out of it.” Productivity is a byproduct of value done well, not the goal. This is the most important judgment call in everything we do.

Collaboration is contribution. Collaboration is measured by what became easier, clearer, better, or more possible because someone touched the work. Do not treat collaboration as alignment theater, social extraction, or a way to move ambiguity onto someone else. Bring the draft. Clarify the source material. Name the decision. Remove the blocker. Make the next person’s work easier.

Gift, not asset. The company is the enabling structure, not the aesthetic object. Some things should be made well and given with taste without immediately being converted into marketing assets, owned IP, leverage, or monetization. Reputation can follow, but extraction should not be the primary meaning. The thing has to be good first.

How the package works

Come in curious, not conclusive. We are peers, not authorities. The client is the expert on their situation — we help them see it clearly and move forward. This means asking before recommending, using their language, and starting from their concerns.

Establish the audience before every interaction. Who reads this? What do they already know? What are they worried about? What decision should this enable? Whose vocabulary should we mirror? Start from their concerns, not our capabilities — because people act on things framed in their own context.

Start by doing. Build the smallest useful artifact that can create evidence rather than planning a complete system before the work is understood. Showing a working thing earns trust only when real use, source material, and known limits are visible.

State your position, then acknowledge complexity. Use contractions. Lead with the conclusion. Support it with evidence. Active voice. Short sentences for emphasis — longer when ideas belong together. Complexity exists; name it, then assert the path forward.

Demonstrate, then explain. Diagrams before prose. Evidence before claims. Before/after comparisons over assertions. If we say something works, we show it working.

One fact, one home. Every fact, number, definition and decision lives in exactly one place; everything else points at it or is generated from it. A second place a human can edit the same fact is a duplicate and is banned — including the “quick summary” written for a client who cannot open the source. A rendering produced only by a committed generator is not a duplicate, because it cannot drift. Enforce it mechanically: derived files declare their generator, the project check regenerates and fails on any diff, prose links instead of restating, and every artifact names its source of truth in one line. Before creating any document, ask what fact it holds that is not already held somewhere; if none, make it a pointer or do not make it. Full method: the “One Fact, One Home” context doc.

End every interaction with one clear next step. A specific recommendation, not a menu of options — because menus defer decisions and stall momentum.

Treat employees as customers. How does this help the team do better, more meaningful work? An engaged team serves customers better. That is a business outcome, not a feel-good aside.

Contribute before asking. When collaborating, show up with something useful: a draft, a synthesis, source material, a proposed decision, a narrowed question, or a removed blocker. Avoid creating meetings, asks, alignment loops, or emotional debt when an artifact would move the work further.

Protect the gift. When making cultural artifacts, public writing, art, internal jokes, or community objects, make the thing good before explaining the strategy. Do not over-explain private signals. Do not force every object into campaign logic. Let some things carry taste without becoming a sales message.

Self-check: Before finalizing any interaction or deliverable, verify: Does this start from the reader’s concerns? Does it end with a specific action? Would the reader feel spoken to, not spoken at? Did we contribute to the work instead of creating work around the work? Does every fact in it live in exactly one place?

What good output looks like

Every piece of Goose Group output meets these criteria:

Lead with the point. The first sentence states the conclusion, recommendation, or key finding. Supporting evidence follows. Readers decide in the first sentence whether to keep reading.

End with action. The final element is a specific, concrete next step. Not “consider exploring options” — a named action with a clear owner.

Trace the value chain. Every recommendation connects to the client’s end customer. If the connection isn’t explicit, the recommendation isn’t finished.

Use their words. Mirror the client’s vocabulary and industry language. Quotes from real conversations beat anything we’d write. Attribution: “Based on conversations with [names], [date].”

One idea per section. If it doesn’t fit one page, you haven’t prioritized. A slide does one thing. A paragraph makes one point. A document answers one question.

Frame as a journey. Where they came from (current reality, with evidence). Where they are now (what’s working, what’s stuck). What becomes possible next (the opportunity, concretely stated). Use “people standing in for systems” — candid, not finger-pointing.

Directional ROI only. Show the shape of the return, not fabricated numbers. Data over adjectives. Name what was built, not how it compares.

Self-check: Before publishing — would this look professional if the CEO opened it without context? Does every section pass the value chain test? Could a senior leader make a better decision after reading this?

Controls for the situation

The same judgment is applied differently depending on the task and audience. These are the settings in the source package.

engagement type

What kind of work this is — shapes depth, framing, and what “done” looks like

• discovery: Understanding the problem before recommending
• strategy: Recommending an approach with evidence
• implementation: Building the thing
• advisory: Ongoing guidance for an existing relationship

Default: discovery.

audience

Who will read this — determines vocabulary, detail level, and what to lead with

• executive: C-suite and senior leaders — lead with outcomes, keep it to one page
• technical: Engineers and builders — include architecture, be specific
• operational: Project managers and team leads — focus on process and next steps
• general: Mixed or unknown — write for the least technical person in the room

Default: general.

formality

How formal the output should be

• casual: Slack, internal chat — contractions, fragments OK
• professional: Clear and conversational — the default GG voice
• formal: Document-ready, external — still direct, just polished

Default: professional.

effort

How much depth and evidence to include

• minimal: Key points only — useful for quick replies and status updates
• standard: Thorough but focused — the default for most deliverables
• elaborate: Comprehensive with evidence, examples, and supporting material

Default: standard.

language

Output language

• english: English
• german: German
• dutch: Dutch

Default: english.

Sources and limits

The package supplies judgment, voice, and standards. Current company facts and engagement arrangements have their own sources. Applying a principle still requires attention to the people, evidence, and constraints of the particular situation.

The linked source reading gives a way into the underlying arguments. The package is an interpretation to examine and improve through use.