Product discovery kit

Launching product practice in a team that isn’t used to it is a real challenge. Where do you start? Which rituals should you put in place? How do you slice features? We’re sharing our kit, the one we use ourselves and have tested with several teams. It’s concrete, practical, and it really works.

Essential rituals

1. Daily stand-up (15 minutes max)

When: Every morning at a fixed time (e.g. 9am)

Format: Everyone answers 3 questions:

• What did I do yesterday?
• What am I doing today?
• Any blockers?

Golden rule: No technical discussions during the stand-up. If needed, take a separate slot. The goal is synchronisation, not problem-solving.

2. Retrospective (every 2 weeks)

When: At the end of the sprint (or every 2 weeks)

Format: 3 columns on a board (physical or digital)

• What went well: What do we keep?
• What didn’t work: What do we change?
• Concrete actions: What do we do differently?

Duration: 1 hour max. The important thing is to have concrete actions at the end, not just discussion.

3. Planning poker (to estimate features)

When: Before each sprint, to estimate new features

How:

1. Everyone estimates complexity (1, 2, 3, 5, 8, 13 points)
2. Reveal all at the same time (to avoid bias)
3. If estimates differ a lot, discuss why
4. Re-estimate until you have consensus

Tip: Start simple. Points aren’t days, just a relative unit. A 5‑point feature is more complex than a 2‑point one, that’s all.

Continuous discovery

Why continuous discovery?

Discovery is understanding the problem before solving it. And it should be continuous, not just at the start of the project. Needs evolve, users change, the market moves. You need to adapt.

Discovery tools

1. User interviews (30 minutes)

• When: Before developing a new feature
• Who: 3–5 representative users
• Questions to ask:
  • What problem are you trying to solve?
  • How do you solve it today?
  • What frustrates you the most?
  • What would save you time?
• Tip: Don’t ask what they want—ask what they do. Actions speak louder than intentions.

2. Problem mapping

Before thinking solution, map the problem:

• Who has this problem? (persona)
• When does this problem occur? (context)
• Why is it a problem? (impact)
• How do they solve it today? (workaround)

Once the problem is well understood, solutions become obvious.

3. Rapid prototyping

Before development, test the idea:

• Figma / Sketch: For interfaces
• Landing page: To test interest (e.g. with Google Ads)
• Wizard of Oz: Simulate the feature manually to test the concept

The goal? Validate the hypothesis before investing development time.

Feature slicing

The golden rule: one feature = one value

Each feature must deliver measurable user value. If you can’t measure the impact, the feature is too broad or unclear.

How to slice a big feature?

Example: “Notification system”

Bad slicing:

• Notifications backend
• Notifications frontend
• Notifications tests

Good slicing:

• Email notification when a user signs up (value: confirm sign‑up)
• In‑app notification when a message arrives (value: respond quickly)
• Push notification for urgent events (value: alert in real time)

Each feature can be delivered independently and brings immediate value.

Feature description format

For each feature, document:

• Problem: What problem does it solve?
• Solution: How do we solve it?
• Value: Why is it important?
• Metric: How do we measure success?
• Acceptance criteria: When do we consider it done?

Prioritisation

Impact / Effort matrix

To prioritise, place each feature on a matrix:

• High impact / Low effort: Do first (quick wins)
• High impact / High effort: Plan (major projects)
• Low impact / Low effort: Do if you have time
• Low impact / High effort: Avoid (or rethink)

The "Now, Next, Later" rule

Organise your backlog into 3 categories:

• Now: What we do this sprint
• Next: What we do next sprint
• Later: Everything else (review regularly)

It prevents getting lost in an endless backlog and forces decisions.

Pitfalls to avoid

• Trying to do everything at once: Start with one ritual, test it, then add others gradually.
• Copy-pasting methods: Adapt rituals to your team. What works for one team won't necessarily work for another.
• Forgetting to measure: If you don’t measure impact, you won’t know if it works.
• Neglecting communication: Product practice is communication first. Communicate regularly with your team and users.

In summary

Launching product practice is a process, not an event. Start simple, test, adapt. The rituals we propose are starting points, not absolute rules. The important thing is to start and iterate.

Need help? If you want us to help implement these rituals in your team, don’t hesitate to contact us. We’ll be happy to help!