State of the proof
What this is not
It is not an outsourced product team. The mandate puts operators inside the client's organisation to hold the practice and hand it back; it does not take the product function away and run it elsewhere.
It does not cover interface design. UX, UI and the design system live in the Design expertise, and "product design" as a phrase belongs there — this page is about what gets built and whether it worked, not how it looks and behaves.
It is not a transformation programme. Product applies a capability inside an organisation that already runs. When the destination is the organisation itself — bringing a function back in-house, scaling one platform across markets — that is a Programme, and it has a different shape and a different exit.
Product discovery
Deciding what deserves to be built: opportunity framing, user evidence, and the arbitration that kills a good idea with no market.
Discovery decides what deserves to be built, which is the only decision on this page that cannot be recovered from later. A team can ship a well-built feature nobody needed; no amount of delivery quality repairs that.
The work frames the opportunity as a problem with a size — who has it, how often, what it currently costs them — and then goes looking for the evidence that would make the framing wrong. Customer conversations, usage data, and the smallest experiment that could settle the question. The output is a decision with its reasoning attached, so the next person to ask "why are we building this" gets an answer rather than a roadmap.
It includes killing things. A discovery practice that has never stopped a funded idea is not producing evidence, it is producing justification, and the difference shows up two quarters later in a feature nobody uses.
Bought when the roadmap is full and the outcomes are flat, or when a new bet is large enough that being wrong about it would cost a year. It is the wrong purchase when the problem is well understood and the constraint is throughput — discovery in front of a decided scope adds a phase and no information.
Product delivery
Turning a decided scope into a shipped increment on a cadence the business can plan against.
Delivery turns a decided scope into something a user can reach, on a cadence the business can plan against. The cadence is the point: a team that ships unpredictably forces every other function to hedge, and the cost of that hedging is larger than the engineering it protects.
The work is the mechanics — slicing work so each piece is independently valuable, sequencing against real dependencies rather than optimistic ones, and making the state of play visible without a status meeting. Where the blocker is the shape of the team rather than its practice, the mandate says so: a squad that cannot ship without three other teams is a structural problem, not a process one.
What is handed over is a team that plans and ships without the operator in the room, plus the small number of rituals worth keeping. The measure is predictability against commitment, taken before the mandate starts so the change can be shown rather than asserted.
It is the wrong entry point when the team already ships reliably and the difficulty is knowing what to ship. That is discovery.
Product quality
The gates a release passes before it reaches a user, and the ones it passes afterwards.
Quality is the set of gates a release passes before it reaches a user, and the ones it passes afterwards. Both halves matter: pre-release testing catches what was anticipated, and production signal catches what was not.
The work establishes what "good enough to ship" means for this product in particular — a medical platform and a marketing site do not share a bar — and then makes that bar automatic. Test strategy across the pyramid, the checks that run on every change, and the ones deliberately left manual because automating them costs more than the risk. Then the other side: error budgets, the alerts that mean something, and a rollback path someone has actually used.
The deliverable is a team that can ship on a Friday. That is not a slogan: it is a measurable state, and it is reached by making the cost of a mistake small rather than by making mistakes rare.
Bought when releases have become events, when the same class of defect keeps returning, or when a compliance regime is about to require evidence the team does not currently produce.
Product improvement
Post-launch work driven by measured behaviour rather than by the loudest stakeholder.
Improvement is the work after launch, driven by measured behaviour rather than by the loudest stakeholder. Most products spend more of their life here than in their build, and most organisations resource it as an afterthought.
The work starts by instrumenting the outcome the product is supposed to move, not the clicks around it, and by establishing a baseline before anything changes. Then it runs a loop: a hypothesis with a number attached, the smallest change that tests it, and a decision to keep, revert or investigate. Reverting is a normal outcome and is recorded as one.
Two failure modes get named early. The first is optimising a local metric while the outcome stays flat — engagement rising while retention does not. The second is running experiments too small to conclude anything, which produces the appearance of rigour and none of the substance.
Bought when a product has users and no learning loop, or when a roadmap is being argued from opinion because nobody has the evidence to settle it.
Product engineering
The engineering practice a product organisation runs on, from architecture to the delivery pipeline.
Most product failures are not decision failures — the bet was reasonable and it never arrived intact. This werk owns the distance between a decision and a shipped, instrumented increment.
Discovery handover and delivery cadence rebuilt inside product mandates; reported as part of the transformation rather than published as a standalone engagement.
Event taxonomies and funnel reporting wired at build time on mandate; the analytics result is published, the instrumentation practice behind it is not.
Internal platforms run with adoption metrics and a roadmap inside platform mandates; no case published on the internal-product discipline itself.
How it is bought
Any expertise can be bought in six forms: fixed price, time and materials, short placement, long placement, permanent placement or named seat. Each specialty carries the forms that suit it.
Questions
- How is this different from Product & design?
- Product & design decides what is worth building — discovery, research, experience and the design system. This werk is accountable for whether it ships: team shape, cadence, instrumentation and the platform the teams build on. They are usually bought together and they answer to different questions.
- Is this agile coaching?
- No. A cadence is an output, not the point. The point is that a validated bet reaches production with its telemetry attached, and that the team that built it can read the result. Ceremony without that loop is theatre.
- What is honestly not proven here?
- The internal-platform-as-product discipline. It is held by named operators inside platform mandates; no published case is sold on the adoption work in its own right.
- Who should not hire this werk?
- An organization that wants throughput without changing who decides. If the roadmap is set outside the teams that deliver it, a new cadence just makes the queue faster to observe.