My Method
Strategy is only useful if it survives real execution and internal scrutiny.
My process is built for the German context based on:
- Clear decisions
- Credible proof.
- Systems that reduce rework.
Quick Summary
Key Facts
- Purpose
- Turn growth goals into decision ready priorities, executable briefs, and measurable proof.
- Approach
- Diagnose, Decide, Build, Prove.
- What I optimize for
- Clarity, credibility, and outcomes that hold up in stakeholder review.
- Typical proof
- Artifacts, measurement notes, before and after snapshots, and testimonials.
- Confidentiality
- Names and sensitive numbers can be redacted. The logic and system stay verifiable.
At a Glance
- Inputs: offer, ICP, funnel steps, current assets, performance data, constraints
- Outputs: decision log, priority plan, brief pack, cadence, measurement plan
- Working style: lightweight documentation, clear ownership, tight review loops
The 4 Step Loop
- Diagnose → identify the true constraint and its evidence
- Decide → choose tradeoffs, lock priorities, document what is excluded
- Build → convert strategy into briefs, QA standards, and cadence
- Prove → measure, learn, iterate, and update the decision log
Step 1: Diagnose
We start by finding the real constraint, not the most visible problem. The goal is focus:
what matters now, what can wait, and what should be removed.
What I look for
- Where demand leaks, where trust breaks, and where execution collapses
- Misalignment between offer, pricing, funnel logic, and proof expectations in Germany
- The single bottleneck that unlocks the next phase once fixed
Outputs
- Diagnostic snapshot: problem, constraint, evidence, risk, next step
- Constraint list: ranked by impact and feasibility
- Exclusion list: what we will not do in this phase to protect focus
Step 2: Decide
We make a small number of high quality decisions and document the tradeoffs.
This prevents scope drift and keeps teams aligned when new opinions show up.
Decision Rules
- If it cannot be measured, it is a hypothesis, not a plan
- If it cannot be explained in one page, it is not ready to execute
- If it increases complexity without increasing proof, it gets cut
- If it relies on “trust me,” it needs a proof mechanism
Outputs
- Decision log: what we chose, why, and what we rejected
- Priority plan: 3 to 5 priorities for the next phase
- Success definition: what must be true by the first milestone
Step 3: Build
Strategy becomes real when it turns into a system: briefs, standards, ownership, and a weekly cadence.
This is where execution stops relying on interpretation.
What gets built
- Brief pack: messaging hierarchy, offer, page structure, creative direction
- QA standards: claim proof checks, clarity checks, consistency checks
- Cadence: simple review points that catch issues early
- Ownership: who does what, by when, and what “done” means
Execution Loop
Input → Brief → Build → QA → Launch → Review → Iterate
Step 4: Prove
We run tight cycles. We keep what works. We kill what does not. We document why.
The goal is compounding learning, not activity.
What gets measured
- Leading indicators: attention and intent
- Conversion points: form, call, trial, demo, purchase
- Quality signals: fit, sales feedback, retention proxies when available
Proof artifacts
- Performance readout: what happened, why it happened, what we do next
- Updated decision log with outcomes and learnings
- Artifact trail: briefs, screenshots, examples, redactions if needed
Deliverables
- Diagnostic snapshot
- Constraint list with evidence
- Decision log
- Priority plan
- Brief pack
- Execution cadence
- Measurement plan
- Proof artifacts and iteration notes
Not every project needs every deliverable. The point is to use the minimum system that produces maximum clarity and proof.
Typical Cadence
| Phase | Focus | Primary outputs |
|---|---|---|
| Week 1 | Diagnose | Diagnostic snapshot, constraint list |
| Week 2 | Decide | Decision log, priority plan |
| Weeks 3 to 4 | Build | Brief pack, QA standards, tracking, launch readiness |
| Ongoing | Prove | Performance readouts, iteration backlog, updated decisions |
How this maps to my services
Same method, different emphasis depending on what you need most right now.
| Service | Best for | Typical outputs | Success signals |
|---|---|---|---|
| Commercial and Growth Strategy | Offer, pricing, funnel logic, and proof alignment before scaling effort | Diagnostic snapshot, constraint list, priority plan, decision log | Clear focus, fewer debates, faster approvals, better conversion logic |
| Execution Oversight | Keeping implementation aligned once work hits reality | Brief pack, QA standards, cadence, performance readouts | Less rework, consistent quality, faster iteration, stable delivery |
| Strategic Advisory | High stakes decisions that require stress testing in the German context | Decision log, scenario options, risk notes, alignment narrative | Fewer second guessing loops, cleaner stakeholder alignment, better decisions |
Confidentiality and Verification
When confidentiality matters, I anonymize company identifiers and sensitive numbers.
The work still shows decision logic, system design, and measurable outcomes at the level you are comfortable publishing.
What stays verifiable
- Constraints and tradeoffs
- Decision logic and priority structure
- Process and cadence
- Artifacts, redacted if necessary
- Results framed as ranges or relative change if needed
FAQ
How fast do we get to clarity?
Usually within the first week you will have a diagnostic snapshot and a ranked constraint list.
From there we lock priorities and move into build and proof.
What do you need from me to start?
Offer and pricing context, who you sell to, what assets you currently use, what has already been tried, and access to performance data if available.
If data is incomplete, we still start. We document assumptions explicitly.
Do you execute or only advise?
I can lead strategy, translate it into briefs and standards, and oversee execution so it stays aligned.
Execution can be done by your team, freelancers, agencies, or a mixed setup.
How do you prevent endless stakeholder loops?
By documenting tradeoffs early, setting decision rules, and using a decision log.
This turns opinions into accountable choices.
What if we are not sure about budgets yet?
Constraints are part of the diagnosis. We propose options that match the budget reality and protect proof quality.
How do you handle confidential projects?
Names and sensitive numbers can be redacted. Proof can be framed as ranges or relative change.
The goal is to keep the logic and system verifiable without exposing what should stay private.
Next step
If you would like to see how this looks in practice, go to the case studies. They are structured for quick reading, proof verification, and easy internal sharing.