Foreword

We wrote this to make our way of working crystal clear: what we do, who does what, and how we move. It’s not a new process or extra ceremony. It’s a simple frame so we can ship value fast, learn, and repeat. This sits on top of our quarterly Objectives, Initiatives, and Tasks (OITs) in a simple, repeatable sprint rhythm.

We’re a product team. We start with the problem, not the tech. We live in the tension between user needs, business impact, and the smallest increment that proves we’re right (or wrong) fast. Design, decisions, and data matter as much as code. Technology is the tool, not the point.

Everybody in the team is expected to think like product people: understand the experience we’re aiming for, the metric we want to move, and how we’ll know if it worked.

The PM sets direction and context. Design shapes the experience. Data frames what to track and what we learned. Day-to-day calls happen in the team; we pull in PM/EM only for scope, risk, or cross-team impact.

Small increments are the muscle. If an idea is good, we should put a thin slice in front of users quickly (flagged if needed and possible) and read the result. For that, every increment ships with the tracking needed to read it.

Learning in public beats polishing in private.

Autonomy is how we keep speed. If something’s unclear, we time-box the spike, make the call, and move. Our lean working agreement definitions exist to make this faster, not slower.

While we ship, our guardian lane keeps quality steady without derailing momentum.

Start with the problem. Ship the smallest slice.

Measure. Decide. Repeat.

Working Agreement

1) Purpose & North Star

Deliver reliably and autonomously through small increments shipped to production.
Emphasis: validation over iteration, limited WIP, predictable outcomes > velocity.

2) Operating Principles

1. Ship real increments to production early/often.
2. Optimize for learning; validate in short cycles.
3. Limit Work In Progress (WIP) to maintain flow.
4. Team makes day-to-day calls; involve PM/EM only for scope, risk, or cross-team impact.
5. Document only what scales; keep it lightweight.

3) Roles and Responsibilities (lightweight version)

Micro decision map

4) Product Development Lifecycle Overview

• Quarterly Objectives, Initiatives, and Tasks (OITs) → Epic roadmap.
• Epic Execution Loop (lean)
  1. Shaping and refinement → align on requirements and next increment goal.
  2. Handoff to Product Engineer (owner).
  3. Optional spike (1–3 days) if unknowns/assumptions block execution.
  4. Break down features/tasks (in refinement or during the sprint).
  5. Build (design + engineering collaboration; instrument agreed data tracking).
  6. High ownership verification loop where reported issues are properly addressed.
  7. Controlled rollout release when possible (flag/limited).
  8. Impact review (1–2 weeks post-release).

Verification Responsibilities

• Engineers validate in real scenarios and edge-cases.
• Design reviews UI details and overall UX quality, main focus in happy path.
• Data ensures success-metric events fire in staging/prod.
• Product steps into the user’s shoes and stress tests the experience.

Clarifications

• Requirements definition: it’s an iterative collaborative process between all stakeholders.
• Design: participates in shaping; provides happy-path UI + key edge states.
• Spike: only when needed, time-boxed; otherwise go straight to build.
• Tracking: success metric chosen in shaping; verified before rollout.

5) Readiness

A Story/Feature/Epic is ready to start when we have:

• One-sentence goal and expected outcome.
• Clarity over the first smallest increment we will ship.
• Known unknowns/assumptions captured (spike if needed, 1–3 days).

While working we will:

• Note key dependency (if any).
• Add references (design/example if available, decision log/observability notes if relevant).

How we apply it:

• Alignment happens live in refinement/planning; no approvals/checklists.
• If clarity is thin, we start with a spike and adjust scope via trade-off rules (see §7).

Principle: prioritize speed and clear direction over excessive standardization and long requirement lists. The core principle is to standardize only what accelerates our progress.

6) Done

A Story/Feature/Epic is done when we have:

• Code completed + reviewed.
• Deployed to production (behind a flag or limited rollout).
• Observability implemented (logs/metrics/traces; alerts when relevant).
• Tests proportional to risk; happy path + primary error path verified.
• Design QA completed on the happy path + key states.
• Data verifies success-metric events work properly.
• Rollout plan documented; Jira status updated.

Note: depending on the work size not all the items in the list will apply.

7) Increments & Trade-Offs

• Increment: Something deployable to production that can be exposed to customers or used to validate learning. It does not imply direct impact on the customer experience.
• Trade-offs led by Product Engineer, with PM + EM input:
  • Reduce scope
  • Swap lower-value work
  • Spill to next sprint
• Sprints are not extended.

8) Planning, Estimates & Spikes

• Spikes allowed, generally 1–3 days.
• Estimation: Fibonacci story points, determined by team.
• When new information invalidates estimates → PE initiates trade-off discussion.

9) Technical Decisions

• Logged in lightweight Decision Log (Google Doc) when relevant.
• Architecture Decision Record (ADR) optional for architectural questions.
• If PM/Design unavailable → engineers decide + move → validate later.

10) Analytics & Impact

• Each Epic defines a primary success metric (+ optional guardrails).
• Data partner defines tracking spec; Product Engineers implement.
• Impact review held 1–2 weeks after release.
• Led by Product Engineer w/ Data + PM.

11) Communication & Ceremonies

• Ceremonies: refinement, planning, daily, demo, retro.
• Slack + Jira for visibility.
• Internal demos led by engineering.

12) Clarifications and Conflicts

Clarifications happen within 24h to unblock execution. If the decision map doesn’t resolve a disagreement, PM mediates scope/design conflicts; EM mediates technical ones. Escalations are same-day; once decided, we commit and move.

13) Exceptions, Bugs & WIP

• Guardian role maintains bug/ops lane (~1 FTE per sprint).
• Hotfixes may bypass this workflow.
• Work In Progress Epics are intentionally limited to maintain flow.

These are defaults, not mandates. If you’re deviating, note why and share with the team.

Product Engineering

“Product Engineer” isn’t a new role, it’s a mindset. It means owning the full lifecycle: discovery, build, release, and learning. Not just the code.

The work varies. Some weeks are coordination-heavy: defining specs with PM and Design, triaging feedback, planning what comes next. Other weeks are heads-down: technical design, shipping, debugging, deploying. Both are the job. The balance shifts depending on where we are in the Epic lifecycle.

You’re expected to understand the problem you’re solving, the experience we’re aiming for, and how we’ll know if it worked. Code is the tool. Outcomes are the point.

This doesn’t change levels, titles, or how we hire. We still look for strong technical skills, problem-solving ability, and ownership. “Product Engineer” just makes explicit what we already expect: engineers here own the whole problem, not just the implementation.