Our Product Team Charter

← Journal 21-05-2026

I'm not really a fan of process. Or should I say, process for process's sake. That probably comes from my indifference to school life, and then working in various places where you end up spending more time adhering to a process than doing work — or, as silicon valley would put it, having impact.

I'm in a fortunate position: I've been trusted to run our product department however we feel works best as a team. I'm also very fortunate to work with a set of like-minded individuals who, at their very essence, want to get on with their job.

Therefore my main goal is simple: how can we enable that whilst having fun.

So as a starter for ten, we came up with the following plan (or charter, but that perhaps makes it sound a bit grandiose) — or best guess at how we would like to work.

This is very much influenced by this video, so feel free to take a watch, as it's probably much more insightful than what follows.

And apologies — it would be great if this was short, but it's not.

Purpose

We want a way of working that is fast, collaborative, and low-overhead — without unnecessary process.

1. Guiding Principles (Non-Negotiables)

We ship regularly Product work should move forward every week, ideally every day in some form.

We solve real problems Everything we build should link back to a clear user or business problem.

We measure impact Where possible, released work should have a way to measure whether it helped.

We enjoy the work The team should feel energised, trusted, and able to do good work together.

We collaborate early Product, design, and engineering work together throughout — not in separate handovers. In real terms, all work should be seen by at least two pairs of eyes from different disciplines.

2. Squad Ownership

The squad (Pete, PM, Noemie, engineer) decides how it works within these principles.

This is not a fixed process. We'll adapt as we learn.

3. Two Boards, Two Purposes

Feature Board in Jira

Used for planned product improvements and larger pieces of work.

Examples:

Dashboard redesign
Recommendations
Progress components
Navigation improvements

This board helps us focus on meaningful change.

Product is accountable for the order of the work — but decided in conjunction with engineering and design at the weekly catch-up.

BAU / KTLO Board in Jira

Used for day-to-day operational work.

Examples:

Bugs
Content fixes
Small enhancements
Support requests
Technical housekeeping
Keep-the-lights-on tasks

This board keeps reactive work visible without drowning feature delivery.

Product is accountable for the order of the work — but decided in conjunction with engineering and design at the weekly catch-up.

Both types of tickets need a tag so we can track the % split of work.

4. We Work in Kanban

Both boards use a simple Kanban flow.

Typical stages: Backlog → In Progress → In Review → QA/Test → Ready → Done

The goal is smooth flow of work, not ceremony.
We prioritise finishing work over starting more work.
Where useful, we may apply work-in-progress limits.
Engineering owns delivery flow, with support from the squad.

In Review — at this point, all disciplines review the work: engineering, product, and design.

5. Shaping Feature Work

Before feature work enters delivery, we should understand:

What problem are we solving?
Who is it for?
Why does it matter?
What does success look like?
What is the smallest useful version?

Usually this can be captured in a short 1-pager in JPD or a lightweight feature note. No heavyweight specs required.

The PM is accountable for this.

6. Managing BAU / KTLO Work

BAU work is triaged regularly and prioritised by urgency and impact.

Example approach:

Priority	Meaning
P1	Immediate attention
P2	Next available slot
P3	Scheduled when capacity allows

Urgent issues may interrupt planned work when genuinely needed.

The PM is accountable for priorities.

7. Collaboration Expectations

Product + Design + Engineering stay close

We avoid long handovers. That means:

Quick check-ins during delivery
Questions asked early
Design evolves during build
Trade-offs made together
PM available for decisions

Pull, don't wait

If blocked, raise it.
If unclear, ask.
If you can help, jump in.

Everyone is accountable for making this work.

8. Rituals (Lightweight)

Daily AM touchpoint

Short PM / Design / Engineering sync.

Focus:

What's moving?
Any blockers?
Any decisions needed?

Approach:

Walk the board from left to right
Check in with anyone who hasn't spoken — they're all good?

Weekly squad check-in (~30 mins)