Work Examples
See how an operating problem becomes a practical design.
These demonstrations show how JG structures workflows, responsibilities and measurement. They are illustrative examples, not client engagements or claims of achieved results.
Operating designs
From sales promise to delivery-ready work
A demonstration of the information, ownership and acceptance checks needed to move a sold engagement into delivery.
Demonstration · Workflow and control design
Explore the handoff →A weekly review that leads to decisions
An illustrative operating-review structure connecting a small set of measures to decisions, actions and owners.
Demonstration · Management reporting
Explore the review →Onboarding that checks readiness
A demonstration of how to move from a completed checklist to evidence that a new team member is ready to perform the work.
Demonstration · People and process
Explore the readiness plan →How we present evidence
We distinguish client engagements, prior founder experience, internal projects and demonstrations. A measured outcome needs a defined baseline, time period and source. Examples without that evidence describe the design and its intended use, rather than suggesting a result has been achieved.
Recognize a similar challenge?
A useful starting point is one real example of work that took longer, cost more or required more intervention than expected.
Demonstration: From sales promise to delivery-ready work
Demonstration · Workflow & Control Design
From sales promise to delivery-ready work.
An illustrative design for a service business where information can be lost between a signed agreement and the start of delivery. This is not a client engagement, an implemented client system or a measured-result claim.
Situation & operating problem
In this hypothetical situation, a sale is marked won before the delivery team has a complete scope, a named owner or a confirmed start date. The customer repeats information, delivery asks sales for missing details and the owner resolves the confusion.
Diagnosis to test
The working hypothesis is that the handoff has no shared definition of readiness. To test it, review a sample of recent engagements, compare agreed scope with handoff records and interview sales and delivery. Check alternative explanations such as unclear promises, staffing constraints or missing system access.
Scope & solution architecture
Design one handoff from accepted engagement to delivery kickoff. Commercial approval and delivery acceptance remain separate controls. A complete record alone does not confirm that the business has capacity to deliver.
| Checkpoint | Accountable role | Evidence required |
|---|---|---|
| Engagement accepted | Commercial lead | Accepted scope; exclusions; commercial terms |
| Delivery ready | Delivery lead | Named owner; capacity; dependencies; kickoff date |
| Customer introduced | Engagement owner | Introduction sent; next step and timing confirmed |
| Exception resolved | Relevant decision owner | Issue, decision, owner and due date recorded |
Implementation & tangible assets
Pilot the handoff with a small, agreed set of engagements before wider rollout. Create a readiness checklist, required CRM fields, an exception queue and a short handoff guide. Train both sides of the handoff and have the delivery owner approve the acceptance criteria. These are proposed components of this demonstration; no client rollout has occurred.
Outcome & measurement
The intended capability is a visible, owned handoff that delivery can accept or return for clarification. No achieved outcome is claimed.
- Baseline and follow-up: median and 90th-percentile time from acceptance to kickoff.
- Handoff completeness: records meeting every agreed requirement divided by handoffs reviewed.
- Rework: time spent correcting missing or inconsistent information.
- Customer experience: repeated-information requests and kickoff complaints.
Define timestamps, sampling rules and the measurement window before setting targets. Time released is capacity; it becomes cash savings only if expenditure actually falls.
Technology & future state
This control can begin in an existing CRM or a shared register. Automation is considered only after the readiness rules and ownership work in practice. The lasting capability is reliable coordination between sales and delivery, with exceptions visible before they become customer problems.
Demonstration: A weekly review that leads to decisions
Demonstration · Management Reporting
A weekly review that leads to decisions.
An illustrative management routine for a growing service business. The measures below are examples, not JG or client performance data.
Situation & diagnosis to test
The hypothetical business spends its weekly meeting collecting updates and revisits the same issues without resolution. The hypothesis is that reporting lacks common definitions and a clear decision owner. Check meeting notes, data sources and unresolved actions before adding another dashboard.
Design the decision before the display
Each measure needs a definition, source, refresh schedule and responsible person. Targets and escalation thresholds are set with the business after establishing the baseline.
| Measure | Decision it supports | Owner |
|---|---|---|
| Age of qualified opportunities | Which follow-ups need action? | Sales lead |
| Work due versus available capacity | What must be resequenced or staffed? | Delivery lead |
| Overdue customer commitments | Who will resolve the exception? | Engagement owner |
| Unresolved decisions and their age | What requires a sponsor decision? | Business sponsor |
Implementation & deliverables
Pilot a 30-minute review: confirm data quality, review exceptions, make decisions, assign owners and check prior actions. The demonstration consists of the decision table and review structure above. A client implementation would also require a KPI dictionary, source reconciliation and a controlled action log.
Outcome, metrics & learning
No result is claimed. Test whether preparation time falls, decisions are made sooner and actions close when promised. A shorter meeting is not success if unresolved customer or delivery issues increase. Technology can remain simple while definitions and habits are established.
Demonstration: Onboarding that checks readiness
Demonstration · People & Process
Onboarding that checks readiness.
An illustrative readiness plan for a new team member. This example describes an operating design, not an implemented employment program or a client result.
Situation & diagnosis to test
In the hypothetical business, new starters complete reading and system-access tasks but still depend on the owner for routine work. The working hypothesis is that onboarding measures task completion without testing job readiness. Review recent onboarding records and observe common work before deciding what training is missing.
Scope & readiness controls
| Stage | Readiness evidence | Owner |
|---|---|---|
| Access and expectations | Required access tested; role and escalation route understood | Hiring manager |
| Guided practice | Representative task completed with a coach | Role trainer |
| Independent work | Agreed sample completed to quality criteria | Process owner |
| Follow-up | Exceptions reviewed; further support agreed | Hiring manager |
Implementation & deliverables
Pilot with one role. Agree on task standards, create a practice example, name the reviewer and record readiness decisions. The demonstration above supplies the stage structure; a real implementation would require role-specific materials and appropriate HR review. Access control decisions should involve the relevant system or security owner.
Outcome, metrics & next steps
No measured improvement is claimed. Track time to independent performance, first-pass quality and avoidable escalations, while checking workload and employee feedback. Faster onboarding is useful only when quality and safe access are maintained. Use the pilot evidence to revise the role’s training and support.