Product development

Documents & Artifacts

Kanban board

The Kanban board is the main tool of communication between stakeholders and the different product development units.

The Kanban board is owned by the product management team.

Engineers are responsible for maintaining cards on the Kanban board once they have pulled them into the backlog. Stories are always assigned when they are in progress, but never while they are in the backlog.

All work that is done in either product, design or engineering should be reflected on the board. Stakeholders may have tickets on the board too.

Priorities or urgencies are sorted top to bottom.

New feature tickets

New features are the result of analysis or research, based on user demand. The product and design teams own the requirements engineering and conception of new features. They are responsible for creating tickets that are ready to be pulled into the backlog.

OKR initiatives

Strategic initiatives are developed with a department and prioritized in close coordination with an objective owner. Those initiatives could be features and also research tasks, surveys, content work and more.

They are prioritized over anything else to ensure the success of our OKRs.

OKR initiatives should be in line with our long-term product vision.

OKR initiatives are usually tracked in a separate lane on the Kanban board.

Growth opportunity

Anything that can help a department (not only product related) to improve their performance and the performance of our business. They should be accompanied by metrics, their current state, and the projected state after the implementation of the growth opportunity.

E.g: Feature A will boost KPI B from 10% to 20% and will increase revenue by 10%.

Growth opportunities should align with our long term product vision.

Depending on the complexity those opportunities might be developed in small increments prioritizing value delivery.

Growth opportunities are owned by a stakeholder and prioritized via the stakeholder meeting. The product team is responsible to ensure that the ticket is ready to be pulled into the backlog.

Operational hiccups

Operational hiccups are issues that disturb a stakeholders operation or hinder their ability to exercise their responsibilities. They usually require some kind of technical support or facilitation and should have some level of urgency similar to bugs.

Operational hiccups are owned by a stakeholder and prioritized via the stakeholder meeting. The product team is responsible to ensure that the ticket is ready to be pulled into the backlog.

Bugs

Bugs are owned by the engineering team as they affect the platform’s stability.

Bugs must have some kind of urgency. They are not prioritized by product, but triaged by engineering, based on what bug will kill our business first. Triage is handled by a designated senior engineer. Bugs are assigned to an engineer at all times but can be reassigned.

A bug ticket should have an average resolution rate of less than a week and no more than two weeks.

Bugs may be closed or converted into a technical debt ticket, if there is no longer a high urgency and no impact on the stability of the platform. Updates on bug tickets, especially closure without resolution, need to be communicated with product proactively.

Tech debt

Engineering leads are responsible for the stability of the platform and the development velocity, and consequently for when and what technical debt needs to be handled.

Work on technical debt must always be proactively communicated with the product team and documented in a ticket. Tech debt tickets must be pulled into the backlog in a refinement meeting, as they bind resources and take up significant space in the engineering backlog.

Platform announcement Slack channel

Product, Design, Engineering, and Content team members post every change to go live on the platform into the Slack channel #platform-announcements. This channel serves as a changelog for all employees and should include every change to the platform’s experience, e.g.

new features,
bug fixes,
content updates,
etc.

Meetings & Collaboration

Agile principles

Make work visible.
Meaningful & actionable conversations.
Don’t ask for permission. Decisions are made, where the work is done.
Regularly reflect on how we work together.

Stakeholder meetings

Stakeholder meetings are held weekly to discuss the product roadmap, upcoming features, and any blockers that need to be resolved or questions that need to be answered. It is the best path to discuss new ideas and to align on the product’s direction. The product manager will relate work to the OKR progress and stakeholders will come prepared with issues/ideas and data, adding their topics to this document: Stakeholder Meeting Platform

The meeting is led by the Product Manager and attended by key stakeholders and an engineering lead.

Refinement meetings are held weekly and are the handover point from the product team to the engineering team. The product manager presents problems, opportunities, and priorities to the engineering team. Engineers ask questions and either pull the issue into the backlog or push it back to the product team for further refinement.

The meeting is led by the product manager and attended by the product and engineering team.

Dailies

Dailies are held daily and are the heartbeat of the team (engineering, content, product). They are used to update the team on the progress of ongoing tasks and blockers. Standups are not for problem-solving, but for identifying issues that need to be solved later during the day.

Dailies are led by the respective team lead going through the Kanban board and attended by the entire team and, optionally, by people who have been closely working with the respective team.

Retrospectives

Retrospectives are held every month with the engineering, product and design team. Stakeholders may join optionally or can be invited if they have been highly involved with a project.

Review

We have a continuous development and deployment process and therefore no regular review meeting. However, reviews are an integral part of the development process. Engineers are responsible to include key stakeholders or product into the solution building and review process.

We strictly prioritize closing open work over everything else. Therefore, reviewing and supporting ongoing projects is expected to be done within a business day.

Client-facing features may require a scheduled deployment coordinated with our clients by CSM.

Development Kick-Off

To prevent ticket ping pong, a kick-off is an optional short meeting, that can be scheduled by an engineer when they pick up new work. Its discussion should be reflected in the ticket. We aim for great tickets, but sometimes we miss.