Summary of the article:

I. ☕️ Why Rethinking Meetings Regularly

II. 👀 What Our Feedback System Looked Like

III. 📊 How We Treated the Results

IV. 📋 How to Do This with Your Team?

☕️ Why Rethinking Meetings Regularly

Most product teams know the feeling: your calendar starts to feel more like a maze than a tool. Between syncs, cross-team check-ins, stakeholder updates, discoveries, demos, retrospectives, and planning sessions, it’s easy to lose track of what each meeting is for — and harder to find time for real work.

This isn’t unique to any one company or industry. As teams grow and squads multiply, meetings do too. And at some point, leaders begin asking the same questions:

• Do we still need all these recurring meetings?
• Are they still serving a clear purpose?
• Could some of them be async?
• How much time are we collectively spending here — and is it worth it?

Answering those questions, though, is easier said than done. Understanding the full meeting landscape of a 25+ person product team — involving over 40 regular participants — is no small task. We assumed we’d just pull data from calendars and map everything out. We tried tools like TimeNavi. We tried manually browsing Google Calendar events across squads. It all fell short.

Eventually, we landed on a simpler and more powerful solution: a shared spreadsheet. Discover the method to reorganize meetings in less than a day below.

👀 What Our Feedback System Looked Like

A simple spreadsheet for structured feedback

The idea was basic — but effective. Instead of trying to guess which meetings were useful, we asked people directly. We listed every recurring meeting across the product ecosystem and opened it up for feedback: each team could rate the perceived usefulness of a meeting, say whether it could be done asynchronously, and share feedbacks for reorganization.

And what we learned was surprising. Some meetings that seemed untouchable had lukewarm ratings. Others were valued by one team and not at all by another. Crucially, this wasn’t about whether a meeting was a ritual or not — we treated every recurring slot the same. If a meeting consistently received lower average ratings — especially across multiple teams — it signaled that something needed to be revisited.

Once a representative number of people had filled out the spreadsheet — with a rating, an async opinion, and sometimes a comment — we moved into analysis and reorganization. In the rest of this article, we’ll break down:

• What our feedback system looked like
• How we processed the results
• How to implement this framework

If you’re trying to clean up your team’s calendar and give people more space to focus, this approach might help you do it.

Understanding the value of recurring meetings isn’t just about asking people “Do you like this meeting?”. You need to understand who finds it useful, why, and whether it still serves its purpose across a growing, multi-squad product team.

We didn’t want to host another meeting to talk about meetings. We needed something:

• fast to fill (2–5 minutes per person),
• easy to set up and read,
• and open to the people who attend meetings — not just their managers.

We built a shared spreadsheet that every team member could contribute to. Simple, scalable, and surprisingly powerful.

Each meeting had its section. The rows captured structured input; the columns reflected each participant. Here’s what we tracked:

🧩 Rows in Each Meeting Table

• Team

We asked people to note their squad (Pedago, LX, Infra, NLX, Platform…). This helped highlight differences in how different teams experienced the same meeting.

• Person

Names weren’t about control — they helped us follow up, and encouraged people to be more thoughtful in their input.

• Perceived Interest

A dropdown from 1/5 to 5/5. This made it easy to scan scores and calculate average ratings for each meeting — and avoid the copy-paste issues of putting numbers in a separate cell.

• Could it Be Done Asynchronously?

Dropdown with Yes, No, or Sometimes. This field surfaced concrete opportunities to switch from live syncs to updates in Slack, Notion, or Loom.

• Feedback (if you want)

Open text. Some gave one-liners. Others wrote full suggestions. Either way, it gave context to the scores and helped us challenge or validate assumptions.

The goal wasn’t full participation, but a representative number of responses across squads. What helped was making it clear that only the input from people who contributed would be taken into account — a simple message that encouraged people to make their voice heard. Nearly everyone who filled it out also left a comment, confirming that when feedback is fast and meaningful, teams are more than happy to engage.

📊 How We Treated the Results

Once the spreadsheet was filled, the next step was to turn feedback into action, without overcomplicating the process.

We kept it simple:

• We calculated the average rating per meeting, using the dropdown scores.
• When needed, we looked at team-specific averages to spot differing experiences.
• We read through the open comments — which turned out to be the most useful part.

From there came the hard part: rethinking the structure of each meeting. We revisited the purpose, the attendee list, the format, and in some cases the frequency. The numbers gave us the direction — but the comments gave us the reasoning.

We focused first on the lowest-rated meetings, using team feedback to understand what wasn’t working — and what might be enhanced. What made the difference wasn’t just the data — it was that the feedback came from people who genuinely wanted things to improve.

📋 How to Do This with Your Team?

Here’s how to get started in under a day:

1. List your recurring meetings.
2. Create a spreadsheet with rows for:

• Team
• Person
• Perceived Interest (1–5 dropdown)
• Could be Async? (Yes/No/Sometimes)
• Feedback (optional)

1. Invite a representative number of people across teams.
2. Make it clear: only filled responses will be considered.
3. Review scores and comments.
4. Start with the lowest-rated meetings — rethink purpose, format, frequency, and attendees.
5. Announce new structure and start date.

Done. No extra tooling required.

“Why Are We in This Meeting Again?” A Framework for Rethinking Recurring Meetings was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

A more practical article today, let’s dive into some common metrics teams can use, their advantages and limitations. Take this article as a starting point of a practical discussion to set up the right metrics for your team that will ensure you consistently create value for the customers, the business and maintain a healthy team.

In the fast-paced world of agile development, sustaining high performance and ensuring product quality are crucial. And you all know by now (I hope):

You cannot optimize/improve what you do not measure.

Teams must rely on a variety of metrics to measure their efficiency, productivity, and overall health.

This article aims to provide a comprehensive but very quick overview of some key metrics used in various agile frameworks, serving as a baseline for teams to consider what is important and what should be measured. You probably shouldn’t measure ALL of them in the long-run and definite ly not just these, but I would suggest you start with something like this and iterate.

Agile Business Metrics

While agile teams often focus on project-specific metrics, it’s crucial to consider broader business indicators that align with the core agile principles of customer satisfaction, value delivery, and adaptability.

Customer Satisfaction Score (CSAT):

Measuring customer satisfaction through surveys or rating scales provides valuable insights into how well your product or service meets user needs. This metric helps teams prioritize features and improvements that directly impact customer experience.

• ✅ Direct feedback from customers
• ✅ Helps prioritize features
• ❌ Subjective and may not capture nuances
• ❌ Can be influenced by temporary emotions

Note: With the power of LLMs, it has become so much easier to analyse huge amounts of textual inputs, allowing CSATs and other indicators of the sort to dive deeper into qualitative feedbacks.

Net Promoter Score (NPS):

The NPS gauges customer loyalty and advocacy by asking how likely they are to recommend your product. A high NPS indicates strong customer relationships and a positive brand perception.

Editor’s note: I hate NPS, there it is, out in the open 😅 It is very bad measure as it is strongly dependent on cultural biases and would only make sense in a viral Product-Led Growth context, which is rarely the case of most products…

• ✅ Easy to implement
• ✅ Measures customer loyalty
• ❌ Oversimplifies complex sentiments
• ❌ May not reflect all customer experiences

Value Delivery:

Quantifying the value of features or tasks delivered to customers allows teams to measure their impact on business objectives. Value can be assigned monetary values, points, or scorecards.

• ✅ Aligns with business objectives
• ✅ Helps prioritize impactful features
• ❌ Challenging to define and measure
• ❌ Difficult for non-tangible aspects

Scrum Metrics

Scrum, one of the most widely adopted agile frameworks, emphasizes iterative development and adaptive planning. Here are some key scrum metrics to guide product managers and tech leads:

Sprint Burndown:

This metric tracks the team’s progress within a sprint, showing the amount of work completed against the remaining work.

• ✅ Provides visibility into progress
• ✅ Helps identify scope changes early
• ❌ May not reflect task complexity
• ❌ Changes in scope can distort the metric

Velocity:

Velocity measures the average amount of work a team can realistically complete within a sprint, helping to plan future sprints and set realistic expectations.

• ✅ Aids in sprint planning
• ✅ Sets realistic expectations
• ❌ Assumes consistent team and work complexity
• ❌ Can be misleading if not normalized

Escaped Defects:

Tracking the number of defects or bugs that reach production environments is crucial for identifying areas for improvement in testing and quality assurance processes.

• ✅ Highlights areas for quality improvement
• ✅ Helps improve testing processes
• ❌ Doesn’t capture defect severity
• ❌ Low count doesn’t guarantee quality

Kanban Metrics

Kanban, an agile methodology focused on visualizing work and optimizing flow, offers a different set of metrics for product managers and tech leads to consider.

Cycle Time:

Measuring the time it takes for a task to go from start to finish, including time spent on reopened issues, provides insights into process efficiency.

• ✅ Indicates process efficiency
• ✅ Helps identify bottlenecks
• ❌ Influenced by external factors
• ❌ May not reflect actual effort

Lead Time:

Lead time measures the total time a task exists, from creation to completion, capturing the impact of waiting times and bottlenecks.

• ✅ Captures end-to-end delivery time
• ✅ Identifies waiting time issues
• ❌ May not reflect team’s effort
• ❌ Can be influenced by dependencies

Throughput:

Throughput measures the team’s capacity to deliver completed work within a given time period, helping to identify bottlenecks and manage workload effectively.

• ✅ Indicates delivery capacity
• ✅ Helps manage workload
• ❌ Doesn’t account for work complexity
• ❌ May not reflect work value

Work in Progress (WIP):

Limiting the amount of work in progress can improve focus and efficiency.

• ✅ Improves focus
• ✅ Enhances efficiency
• ❌ Finding optimal limit is challenging
• ❌ Requires careful consideration of team dynamics

Engineering and Code Metrics

For teams practicing DevOps and continuous delivery, engineering and code metrics offer insights into the technical aspects of quality and productivity.

Defect Resolution Time:

The time taken to fix defects.

• ✅ Measures responsiveness to issues
• ✅ Helps identify bottlenecks in the resolution process
• ❌ Doesn’t reflect defect severity
• ❌ Can be influenced by external dependencies

Failed Deployments:

The number of failed deployments within a given timeframe.

• ✅ Indicates deployment process stability
• ✅ Helps identify process issues
• ❌ Doesn’t capture the severity of failures
• ❌ High rate may indicate deeper issues

Production Downtime:

Measures the time work is stalled due to issues in production.

• ✅ Highlights operational issues
• ✅ Critical for maintaining uptime
• ❌ Can be influenced by external factors
• ❌ Doesn’t capture root causes

Code Coverage:

Measuring the percentage of code covered by tests helps ensure thorough testing practices and identify areas with insufficient test coverage.

• ✅ Indicates test thoroughness
• ✅ Helps identify untested code
• ❌ High coverage doesn’t guarantee quality
• ❌ May not reflect test effectiveness

Defect Density:

Tracking the number of defects per 1,000 lines of code provides a quantifiable measure of code quality.

• ✅ Provides a quality benchmark
• ✅ Helps identify problematic areas
• ❌ Influenced by code complexity
• ❌ Doesn’t account for defect severity

Deployment Frequency:

Measuring how often code is deployed to production environments reflects the team’s ability to deliver value continuously.

• ✅ Indicates delivery frequency
• ✅ Helps gauge team’s agility
• ❌ High frequency doesn’t ensure quality
• ❌ May not reflect release value

Note: I have red lately many articles linking Product maturity to continuous deployment (hence, short deployment frequency). While I mostly agree that shorter cycles are usually better, I don’t the direct correlation can be made between the two as it strongly depends on the type of product (if there is hardware involved, legislations…)

Sustaining a Balanced Approach

While metrics provide valuable data-driven insights, we need a balance between quantitative measurements and qualitative feedback. Product managers and tech leads should prioritize metrics that align with their team’s specific goals, priorities, and challenges, while also considering the human aspects of teamwork and collaboration.

Effective metric tracking and utilization require a culture of continuous learning, experimentation, and adaptation. Teams should regularly review and adjust their metric focus to ensure they are measuring the right things at the right time. Additionally, cross-functional collaboration and open communication are essential for interpreting metrics accurately and driving meaningful improvements.

Remember, this article WAS NOT a complete guide of metrics, but a starting point for a discussion with your team/squad on how to measure value, quality, cadence and ultimately team health.

What metrics did I miss? Don’t hesitate to share in the comments 😉

Sustaining Metrics in Agile Teams: A Comprehensive Starter Guide was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Visual roadmaps are essential tools in product management — they align teams on direction and high-level milestones. At 42 School, with over 50 campuses already running and a dozen set to launch in 2025, we faced the unique challenge of revamping our platform while ensuring a smooth transition from the existing system.

To address this complexity, we combined a visual roadmap for macro milestones with a textual roadmap in Notion to add context, flexibility, and granularity. This hybrid approach helped us bridge high-level strategy with day-to-day execution. Here’s how a textual roadmap can complement a visual roadmap and better support product teams.

I. Where Visual Roadmaps Need Support

While visual roadmaps are invaluable for communicating high-level strategy and milestones, they often come with limitations that make day-to-day execution more challenging:

• No Filters or Custom Views: Visual roadmaps provide a static snapshot, lacking the ability to filter by team, priority, or dependency. This one-size-fits-all approach can leave important details obscured.
• Limited Context: Key information like documentation, blockers, and rationale for decisions often lives elsewhere, leading to disjointed communication.

• Cumbersome Updates: Keeping visual roadmaps up-to-date requires significant manual effort, especially as priorities shift.
• Information Overload: Adding granular details to a visual roadmap can make it cluttered and unreadable, defeating its purpose.

• Disconnected Rollout Planning: Critical rollout milestones often aren’t integrated into team-specific views, creating visibility gaps across squads.

These limitations prompted us to rethink our approach.

II. Why Textual Roadmaps Work in practice

In our case, we complemented the macro-level visual roadmap with a detailed textual roadmap in Notion. Here’s why this approach proved effective for our team and how it can work for yours:

1. Centralized Knowledge

Textual roadmaps serve as a single source of truth. By organizing milestones, tasks, and dependencies in a structured database, we eliminated the inefficiency of scattered updates and documents. Everything — from rollout milestones to meeting notes — lived in one place, accessible to all stakeholders.

2. Dynamic Updates and Filtering

Unlike static visual roadmaps, textual roadmaps are flexible. Teams could filter tasks by priority, owner, or deadline, creating tailored views for different needs. This adaptability made it easy to manage changing priorities without disrupting workflows.

3. Seamless Rollout Integration

One of the standout advantages was the ability to integrate rollout milestones alongside development tasks. This ensured that every deliverable was aligned with deployment timelines, reducing last-minute surprises and improving cross-team coordination.

4. Enhanced Collaboration

Notion’s built-in commenting and tagging features encouraged asynchronous collaboration. Teams could flag blockers, ask questions, and share updates directly within the roadmap, reducing reliance on meetings while keeping decision histories transparent.

By addressing the limitations of visual roadmaps, this method not only improved our alignment but also streamlined task management across squads.

III. How to Build an Effective Textual Roadmap

Here’s a step-by-step approach to creating a textual roadmap that improves efficiency and collaboration:

1. Define Milestones and Rollout Events

Start by listing key milestones and rollout events, such as a beta release, internal demo, or final product launch. These milestones act as anchors for your roadmap, ensuring all tasks align with overarching deadlines.

In our case, we added a text property to clearly label each milestone (e.g., “31/12 Release Day”). This allowed us to automate timelines later while keeping milestones clear and easy to reference.

2. Build a Database with Key Relationships

Create a database in Notion to capture all tasks and link them to milestones.

The following properties formed the core of our database:

• Milestone (text): The milestone for quick reference (e.g., “31/12 Release Day”).
• Milestone (date): The due dates for tasks based on milestone deadlines.
• Task/Need: A description of the task or deliverable.
• Owner: The individual or team responsible for the task.
• Dependencies: Links tasks to highlight dependencies, blockers, or iterations.
• Optional Properties: Additional fields based on team needs (e.g., “To Be Discussed”).

By structuring the database this way, we created a flexible, interconnected system that ensured every task was tied to the broader project goals.

3. Align Sizing Across Teams

Before assigning sizes to tasks, it’s crucial to align sizing definitions with all teams. For example, we standardized our sizing as follows:

• S: Tasks that take less than 1 week.
• M: Tasks that take 1–3 weeks.
• L: Tasks that take more than 3 weeks.
• ?: Tasks with unknown or unclear effort estimates.

This consistency ensured that all squads used the same criteria, making sizing discussions and timeline planning smoother.

Including a “?” size helped us flag ambiguous requirements early. For example, some features lacked clarity on the solution or dependencies, and sizing them as “?” highlighted areas that needed further exploration or explicit stakeholder input. This approach prevented delays and reduced guesswork later in the process.

4. Automate Timeline Creation

Once milestones and tasks were defined, we automated start dates and task durations using simple formulas in Notion, saving time and reducing manual updates. For example:

• Tasks linked to a milestone automatically inherited its deadline.
• Start dates were calculated by working backward from the milestone, based on task size.

This automation saved significant time and effort, especially when updating timelines as priorities shifted and allowed us to get a draft roadmap view without moving any bloc on our own.

5. Enable Tailored Views for Stakeholders

By combining visual and textual roadmaps, teams gained both a high-level overview and the granular details needed for execution. For example:

• Leadership View: Focuses on high-level milestones and overall progress.
• Squad View: Filters tasks by team or owner, helping squads prioritize their work.
• Rollout View: Highlights dependencies and milestones to track deployment readiness.
• Timeline view: Provides a visual overview of the roadmap and tracks progress over time.

These views ensure everyone sees the information they need without being overwhelmed by irrelevant details.

6. Optional Integrations for Enhanced Collaboration

This system can work on its own or be enhanced by linking to platforms like Jira, or Miro. For instance, development teams might link tasks to Jira tickets, while design teams use Miro for wireframes. Even in simpler setups, hyperlinks to external documents or tools can centralize context.

What We Learned

Textual roadmaps bridge the gap between high-level strategy and detailed execution: they add flexibility, granularity, and a centralized point of truth. By combining a visual roadmap for macro strategy with a textual roadmap for execution, we improved collaboration, alignment, and visibility across teams. This hybrid approach ensures product teams can navigate complex projects and rollouts with greater efficiency. Looking ahead, this hybrid approach positions our teams to manage future rollouts efficiently, ensuring both high-level alignment and executional clarity.

Bridging Visual and Textual Roadmaps for Product Teams was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

TL;DR: Modelling and simulating a system can help get insights on a product viability (even in contexts like education). Historically a complex task requiring a scientific and deep technical expertise, now thanks to genAI it can be used by anyone and we can get results in record time!

Editor’s note: This is an article based on the conference made on the 12th of December 2024 UX-Meet: AI Experience.

I. Introduction:

In the early days of my career, I spent countless hours as a Simulation Engineer at Volvo modelling complex systems — engines, turbos, aftertreatments — you name it.

Back then, we didn’t have the term “Data Scientist” (gosh, I am old, that word didn’t even exist at that time…). My tools were Matlab and Simulink… ah good old times 😝

Fast forward to today, and while my role has evolved significantly becoming the Product leader I am, my passion for the technical side of things is always there. I believe that retaining a deep understanding of the tech side is a great asset in the world of Product.

Recently, I faced a challenge that brought all these worlds — modelling, product discovery, and AI — colliding together. The challenge was centered around the infamous “it’s not possible” statement, a phrase I’m sure many of you are familiar with.

II. The Dilemma: Smith vs Keynes

Let me give you some context. At 42, we use an innovative approach called “peer-to-peer learning,” which relies heavily on projects and peer evaluations. Evaluations are crucial, but participation varies widely among students: some do a lot, some do the bare minimum, and others start strong only to drop off later. This variability poses a question: should we intervene in the evaluation system, or leave it to self-regulate?

To draw a parallel, this is akin to the debate in economics between laissez-faire and government intervention. On one hand, you have Adam Smith’s idea of the “invisible hand” in free markets, where the system regulates itself. On the other, you have Keynesian economics, which advocates for regulation to prevent market failures.

In our context the evaluation system is like an economic system… leaving the evaluation system to run on its own puts all the responsibility on the student, resulting in behaviors that are all over the place. Since our goal is educational, it seems obvious that we’d want some control to ensure that every student is engaged and learning, that the group advances together and reaches the final goal. But here’s the tricky part: setting up controlling rules often leads to the collapse of the system.

So how do we explore a solution for such a complex dilemma? The answer lies in modelling.

III. Modelling: A Discipline for Understanding Complex Systems

Modelling is a powerful tool used across various industries to simulate and understand complex systems. Whether in automotive engineering, finance, or even biology, modelling allows us to create a simplified representation of reality, enabling us to test different scenarios and predict outcomes without the high costs or risks of real-world experimentation.

Here is an example of modelling a very simple system: imagine a basket ball you hold in your hands. You release it: where will it be in 10 seconds? What would happend if you dropped it in sand vs the field’s floor?
One could 3D scan the ball, place hundreds of sensor around to measure all air fluctuation and run a numerical simulation for hundreds of hours with super-computer to try to get an accurate estimation.
Or… we could model the system in a much simpler way, making it accessible to compute. We need to simplify and take some shortcuts (like assuming there is no air friction, the ball is perfect sphere…), and voilà! you get an easily calculated approximation allowing you to simulate the behavior and test hypothesis… that’s modelling.

Back to 42, what I would have done in my past life, I would have fired up Matlab, built a code-based system to simulate consumer behavior in a macro-economic system, and run simulations to see if the system would collapse or not. But that was 2009.

Now, in 2024, I wondered — could AI help me build this system? And more importantly, could it do so much faster and more efficiently than I ever could?

Simplifying reality

This is an example of a current Holygraph, a visual representation of 42 cursus.

This represents the different connections between projects as a student progresses. As you can see this is highly non-linear and it is based on projects that would require a different amount of time from one student to the next.

Let’s make a BIG simplification by considering the cursus linear. Projects are like steps in a linear progression and require a fixed amount of time to be completed (the same for everyone), for example:

We cannot simulate a continuous system (at least not with reasonable calculation power) so we will make the system discreet. We will run a simulation calculation at every interval. We could simulate every second, every minute, every hour, but this would make the system really complex. Another BIG simplification: the simulation interval is 1 day, so only 1 thing can happen each day (we can assume that no event = the student is just working on the project).

Building the System

Now that we have the simulation parameters, let’s define the system rules.

Here’s what I came up with (and remember, modelling is all about simplifying reality to make calculations feasible while retaining the basic behaviors and principles to make predictions, keeping in mind that this does introduce some uncertainty):

• Turn-based System: Each turn represents a day (the simulation interval).
• Step-based Progression: Each step is a project requiring a predefined number of days to complete, the order is fixed and we can only move from one project to the next.
• Daily Evaluation: Every day, a user can choose to evaluate another student or not, depending on their profile, and only once per day.
• Points System: Evaluating earns the user 1 point (this is like our currency in the system, a token you earn and spend)
• User Profiles: We create different user profiles that will do the minimum evaluations, with varying probabilities of choosing to evaluate when given the chance beyond that (U1: 0% = will never evaluate beyond the bare minimum required, U2: 50% = will evaluate half of the times when they are given the chance beyond the minimum required, U3: 20% = same with 20% chance of evaluating)

Now we have the basic system.

We know there are behaviors we want to avoid, so we introduced some rules to prevent deviations or be able to control the system:

• Advance cost: To advance, a student must spend 3 evaluation points = this prevents students from not evaluating at all and moving forward, making it indirectly compulsory (I am not telling you that you have to evaluate, but you cannot move forward if you don’t).
• Zero Points Rule: If a student has 0 points, they are forced to evaluate and time doesn’t count for the step = this forces students no avoid dropping to 0 and keeping on eye on their credits
• Maximum Points Cap: there is a maximum of 10 points, after which points are no longer earned = to prevent hoarding once when it is “easy” and never evaluating again
• Decay Factor: everyone loses 1 point after 4 turns = to ensure consistent engagement
• Evaluation Availability: A student can only evaluate if there are enough peers at the same step to be evaluated = like in real life… if you go much faster than the rest of your peers or you lag behind, you cannot evaluate/be evaluated since you are alone in your step… you are “stuck” waiting.

Now we had a system and a set of rules.

But could we ask GPT-4o to model this system for us? You bet!

IV. AI to the Rescue

With a few prompts explaining the system, with the given rules, GPT-4o generated a neat Python code that could simulate exactly this system.

(I was thinking of including the code but I assume most of you don’t really care much 😅 I will put at the end of the article just in case and spare you the long scrolling to keep reading the article’s content)

The result?

What would have taken me days of programming in the past was done in no time! 🤯

And then I start thinking: maybe chatGPT-6 or 7 will in the future provide the formalisation, run the code, and perform all the analysis by just formulating the need… Amazing but scary: will anyone take the time to learn modelling and automation engineering if systems like these can do the job? And if so, who will know if the systems are right? Will we lose our capacity to understand the world because of our laziness? I am derailing a bit into the philosophical implications of genAI, let’s come back to this usecase 😅

So here are the results of running the simulation for 100 days.

Note: to run the code you can either install Python’s environment on your machine or simply use a service like Google colab and run it on the cloud (for free)

U1 Statistics:
Average Step: 8.00
Average Credits: 3.00
Average Reviews: 27.00
Average Wait Turns: 9.00
Minimum Step Reached: 8
Maximum Step Reached: 8

U2 Statistics:
Average Step: 9.00
Average Credits: 8.48
Average Reviews: 35.48
Average Wait Turns: 1.00
Minimum Step Reached: 9
Maximum Step Reached: 9

U3 Statistics:
Average Step: 8.91
Average Credits: 3.36
Average Reviews: 30.09
Average Wait Turns: 2.62
Minimum Step Reached: 8
Maximum Step Reached: 9

The code allowed us to play with the probabilities of evaluation, user quantities, number of turns, decay factor, and other parameters. We could easily simulate the behavior of this “economic” system under different conditions.

Does It Work?

It seems so! 🥳

After 100 turns (or even 1000), the different profiles ended up roughly at the same step/project, meaning no user was left behind and there was a pedagogical cohesion of the entire group, the system remained sustainable and controlled, reducing disparities and abnormal behaviors from users.

This is an approximation of course, but it already gives a good feeling on the sustainability of such a system.

There are many things to improve (by the time this article is published, I am sure I will have exponentially improved/complexified the simulation, I know myself, some things never change 😂). Here are some ideas at the time of writing:

• randomising step duration to account for different human learning speeds
• removing the basic current user strategy of having always at least 3 points (some real students are not that strategic in real life and will really leave it for the very last moment😝)
• randomising the probability of reviews for each student (not just by group)
• introducing expulsion rules
• Have more user profile types
• Include mechanisms to help students that are left behind
• …

V. Conclusion: The Future of Product Discovery

I’m genuinely amazed by the power of AI tools today. Fifteen years ago, I never would have imagined that the skills I honed in modelling automotive systems would one day be applied to Product Discovery in education. But here we are, blending the old with the new and opening doors to innovative solutions.

There are so many tools today to explore the adjacents. The adjacent possible and acceptable are already well covered: Figma, no-code (N8N, Nodered, Zapier, Make…)… But now it so easy to use modeling and simulation to explore the adjacent viable!

This is most likely not the final system we will be implementing at 42, but it gave precious insights:
“Yes, we can have a regulated system that maximizes pedagogical value for our students at 42!”
At least in theory 😅.

With the right tools, the possibilities of Product Discovery are endless.

Note: Of course, it helps that I have the skills to conceptualize the problem, reframe it, and tweak the resulting code. But the fact that AI tools now enable us to bridge the gap between discovery in complex systems and the world of modelling and simulation is nothing short of amazing.

What do you think? Have you tried using AI for modelling in your own product discovery processes? Share your thoughts in the comments below, and let’s continue the conversation!

Here is the code for those of you who are curious 😉

import random
import matplotlib.pyplot as plt

# Simulation parameters
INITIAL_CREDITS = 0
MAX_CREDITS = 10
ADVANCE_COST = 3
MINIMUM_USERS_TO_REVIEW = ADVANCE_COST * 3
REVIEW_GAIN = 1
DECAY_INTERVAL = 1000
DECAY_AMOUNT = 1
SIMULATION_TURNS = 100

# User counts
U1_COUNT = 33
U2_COUNT = 33
U3_COUNT = 34

# Step requirements
STEP_REQUIREMENTS = [9, 12, 10, 7, 14, 16, 5, 9, 14, 15]

# User behavior parameters: once they do the minimum required reviews (ADVANCE_COST), what is the probability of doing an extra review if they can?
U1_REVIEW_PROBABILITY = 0.0
U2_REVIEW_PROBABILITY = 0.5
U3_REVIEW_PROBABILITY = 0.2

class User:
    def __init__(self, user_type, review_probability):
        self.user_type = user_type
        self.review_probability = review_probability
        self.credits = INITIAL_CREDITS
        self.step = 0
        self.turns_in_step = 0
        self.total_reviews = 0
        self.total_wait_turns = 0
        self.total_stuck_turns = 0
        self.credit_history = [INITIAL_CREDITS]

    def can_review(self, users_at_step):
        return users_at_step >= MINIMUM_USERS_TO_REVIEW

    def advance(self):
        if self.credits >= ADVANCE_COST:
            self.credits -= ADVANCE_COST
            self.step += 1
            self.turns_in_step = 0
            return True
        return False

    def review(self):
        if self.credits < MAX_CREDITS:
            self.credits = min(self.credits + REVIEW_GAIN, MAX_CREDITS)
            self.total_reviews += 1
            return True
        return False

    def update(self):
        if self.credits > 0:
            self.turns_in_step += 1
        else:
            self.total_wait_turns += 1
        self.credit_history.append(self.credits)

class Simulation:
    def __init__(self):
        self.users = []
        self.turn = 0
        self.credit_histories = []
        self.total_stuck_users = 0

    def add_users(self, count, user_type, review_probability):
        for _ in range(count):
            self.users.append(User(user_type, review_probability))

    def run_turn(self):
        self.turn += 1
        step_counts = {step: 0 for step in range(len(STEP_REQUIREMENTS))}

        for user in self.users:
            step_counts[user.step] += 1

        for user in self.users:
            user.update()

            can_advance = user.turns_in_step >= STEP_REQUIREMENTS[user.step % len(STEP_REQUIREMENTS)]
            users_at_same_step = step_counts[user.step]

            if can_advance and user.credits < ADVANCE_COST:
                user.total_wait_turns += 1

            if user.credits < ADVANCE_COST and user.can_review(users_at_same_step):
                user.review()
            elif can_advance and user.credits >= ADVANCE_COST:
                user.advance()
            elif user.credits == 0 or random.random() < user.review_probability:
                if user.can_review(users_at_same_step):
                    user.review()
                else:
                    user.total_stuck_turns += 1
                    self.total_stuck_users += 1

        if self.turn % DECAY_INTERVAL == 0:
            for user in self.users:
                user.credits = max(user.credits - DECAY_AMOUNT, 0)

    def run_simulation(self, turns):
        for _ in range(turns):
            self.run_turn()
        self.credit_histories = [user.credit_history for user in self.users]

    def get_stats(self):
        stats = {
            "U1": {"avg_step": 0, "avg_credits": 0, "avg_reviews": 0, "avg_wait": 0, "avg_stuck": 0, "min_step": float('inf'), "max_step": float('-inf'), "count": 0},
            "U2": {"avg_step": 0, "avg_credits": 0, "avg_reviews": 0, "avg_wait": 0, "avg_stuck": 0, "min_step": float('inf'), "max_step": float('-inf'), "count": 0},
            "U3": {"avg_step": 0, "avg_credits": 0, "avg_reviews": 0, "avg_wait": 0, "avg_stuck": 0, "min_step": float('inf'), "max_step": float('-inf'), "count": 0}
        }
        for user in self.users:
            stats[user.user_type]["avg_step"] += user.step
            stats[user.user_type]["avg_credits"] += user.credits
            stats[user.user_type]["avg_reviews"] += user.total_reviews
            stats[user.user_type]["avg_wait"] += user.total_wait_turns
            stats[user.user_type]["avg_stuck"] += user.total_stuck_turns
            stats[user.user_type]["min_step"] = min(stats[user.user_type]["min_step"], user.step)
            stats[user.user_type]["max_step"] = max(stats[user.user_type]["max_step"], user.step)
            stats[user.user_type]["count"] += 1

        for user_type in stats:
            if stats[user_type]["count"] > 0:
                for key in ["avg_step", "avg_credits", "avg_reviews", "avg_wait", "avg_stuck"]:
                    stats[user_type][key] /= stats[user_type]["count"]

        return stats

def plot_credit_evolution(sim):
    plt.figure(figsize=(15, 10))
    for i, history in enumerate(sim.credit_histories):
        if i < U1_COUNT:
            color = 'red'
        elif i < U1_COUNT + U2_COUNT:
            color = 'green'
        else:
            color = 'yellow'
        plt.plot(history, color=color, alpha=0.5)
    
    plt.xlabel('Turns')
    plt.ylabel('Credits')
    plt.title('Credit Evolution for All Users')
    plt.legend(['U1 (Red)', 'U2 (Green)', 'U3 (Yellow)'])
    plt.show()

# Run the simulation
sim = Simulation()
sim.add_users(U1_COUNT, "U1", U1_REVIEW_PROBABILITY)
sim.add_users(U2_COUNT, "U2", U2_REVIEW_PROBABILITY)
sim.add_users(U3_COUNT, "U3", U3_REVIEW_PROBABILITY)
sim.run_simulation(SIMULATION_TURNS)

# Print results
results = sim.get_stats()
for user_type, data in results.items():
    print(f"\\n{user_type} Statistics:")
    print(f"Average Step: {data['avg_step']:.2f}")
    print(f"Average Credits: {data['avg_credits']:.2f}")
    print(f"Average Reviews: {data['avg_reviews']:.2f}")
    print(f"Average Wait Turns: {data['avg_wait']:.2f}")
    print(f"Average Stuck Turns: {data['avg_stuck']:.2f}")
    print(f"Minimum Step Reached: {data['min_step']}")
    print(f"Maximum Step Reached: {data['max_step']}")

# Print total stuck users
print(f"\\nTotal Stuck Turns Across All Users: {sim.total_stuck_users}")

# Plot credit evolution
plot_credit_evolution(sim)

Modelling the future of your Product thanks to AI. was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is IOTA ?

IOTA is a peer learning platform on digital skills for school kids from 3rd to 5th-grade (from CE2 to CM2 for the french system) that is being developed by 42 since 2021 in France and is backed by the French Ministry of Education. The platform is free and ready to use for teachers who often feel helpless when it comes to teaching these new skills.

By July 2024, IOTA expanded its reach both in France and internationally, involving 7,000 children and 350 classes across 54 French departments, including two overseas (Guadeloupe and French Guiana), and three countries abroad (Madagascar, Morocco, and Ivory Coast).

92% of the teachers who used the platform last year declared that they were eager to carry on the project that not only helps kids to develop hard skills such as programming or digital content creation but it also enables them to work on their human skills such as critical thinking, autonomy, perseverance, communication, listening and empathy.

IOTA targets children before adolescence to combat gender stereotypes in computer science and helps them develop a learning methodology focused on autonomy and collaboration, aligning better with the challenges of our society.

Research and impact measurement

After 3 years of experimentation, our research team composed of two education economists, Fanny Landaud and Camille Terrier, are currently working on the analysis of the projects’ data. Their findings will be released in early 2025 and will focus on the development of students’ digital and life skills, as well as changes in teachers’ educational practices.

Tackling societal issues

The situation in France is concerning. Statistics reveal a significant lag in digital transition and the increase of cyberbullying.

43% of French students have low or very low digital literacy levels according to the 2018 ICILS survey.

24% of French students from 11 to 15 have already experienced cyberbullying.

Digital education has been part of the school curriculum since 2016, but the digital divide continues to widen. There is a genuine need for ready-to-use educational resources to teach this broad field of skills to students and to raise their awareness of balanced and thoughtful digital use.

With teenagers spending an increasing amount of time online, these figures highlight the urgent need for education to foster digital literacy and safety.

IOTA aims to make a significant societal impact by reducing inequalities in access to digital education.

What’s next ?

The partnership with the French Ministry of Education is renewed for the 2024/2025 season, with the main objective of scaling up to reach 10,000 students across France !

Let’s bring IOTA to your kids’ schools

If you are a parent, you are probably struggling with the use of social networks or video games on a daily basis. You might not find the right words to explain to your kids how they should be using these tools but we can do it with IOTA in a fun way ! They will come to you then and teach you why you should not be on your phone all the time for sure. :)

Below, a few elements you can send to a school* or to a teacher :

• IOTA website
• Presentation kit
• Youtube page

*Only french public schools and private schools under contract with the ministry have a free access on IOTA

If you have any question, feel free to contact us : contact@projet-iota.fr

42’s mission extended to schoolkids with IOTA was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building a Product Organisation at 42: How We Stay Agile and Innovate

At 42, we’ve always believed in pushing the boundaries — whether it’s in how we approach education, the tools we build, or the teams that power our innovation. Over the years, 42 has evolved from a single, revolutionary school to a global network that champions free, inclusive, and peer-led learning. But with that growth comes a responsibility to ensure our structures and processes evolve in tandem, hence a shift toward a product organisation.

Let’s quickly explore some key theory about team organization and see how they’ve shaped the way we work at 42.

I. The Theory: Team Topologies and Why They Matter

Creating an effective product organization starts with understanding the structure of your teams.
There are many theories and frameworks, here is one of the most widely known: Team Topologies, by Matthew Skelton and Manuel Pais, outlines four fundamental team types that help modern organizations design systems for better collaboration, speed, and scalability.

1. Stream-Aligned Teams

Stream-aligned teams are focused on a specific flow of work, whether it’s a product, a set of features, or a user journey. These teams are designed to operate independently, meaning they can design, build, and release features without relying heavily on other teams.
In many ways, stream-aligned teams are the lifeblood of agile organizations, delivering value quickly and safely to users.

2. Platform Teams

Platform teams provide the internal services and infrastructure needed by stream-aligned teams to move quickly. They support other teams by offering tools, infrastructure, and environments that can be used on demand, minimizing dependencies. In an ideal setup, platform teams and stream-aligned teams interact minimally, with platform teams offering services that are self-serve and scalable.

3. Complicated Subsystem Teams

For certain technical challenges that require specialized knowledge, a complicated subsystem team is formed. These teams are experts in specific areas that a typical stream-aligned team may not have the depth to handle — such as complex algorithms, AI models, or high-performance computing. Their role is to ensure that these complicated pieces function seamlessly within the broader product.

4. Enabling Teams

Finally, enabling teams exist to bridge knowledge gaps for stream-aligned teams. Whether it’s introducing new technologies, sharing best practices, or guiding teams on specific challenges, enabling teams act as temporary mentors, helping their counterparts to upskill and adopt new tools or methodologies.

II. How We’ve Organized Ourselves at 42

At 42, we’ve applied the principles of team topologies to create a structure that allows us to stay agile, deliver value, and focus on user-centricity. Our squads are multidisciplinary, combining the expertise of product managers, UX designers, and developers, all working together to solve real problems and innovate. Each squad operates with autonomy, but their work is supported by a solid infrastructure that enables them to move fast.

1. Feature Squads: Our Stream-Aligned Teams

Our product organization is centered around stream-aligned feature squads. These squads are cross-functional and multidisciplinary, meaning they have everything they need to deliver value from start to finish.

• LX (Learning Experience) Squad: This squad focuses on the core learning journey, ensuring that students have a seamless, personalized experience as they progress through 42’s unique educational model. They manage everything from project libraries to evaluations, working on features that directly impact student outcomes.
• NLX (Non-Learning Experience) Squad: The NLX squad handles all non-pedagogical aspects of the platform — everything from the application process to administrative document management. Their goal is to streamline the behind-the-scenes operations, ensuring that both students and staff can focus on what matters most.

2. Platform Team

Our Platform Squad recently merged with the Infra Team to create a single, powerful support function. This team provides the backbone services, infrastructure, and tooling that enable the feature squads to focus on delivering value without being bogged down by technical hurdles. From managing CRMs to automating marketing processes, this support team ensures that the platform remains scalable and secure.

Together, these teams form the foundational support system that keeps our operations smooth and reliable. They offer services through an “X-as-a-service” model, minimizing the need for direct collaboration, which helps the feature squads maintain their speed and independence.

3. Complex subsystem team: v2v3

The v2v3 Squad has a broad knowledge and is the expert of the current system that has helped 42 thrive for the past 10 years.
They help key features that might not be in the target in the short term for neither LX nor NLX, move forward faster.

Once we reach a more stabilised scenario, this team will reintegrate the other stream aligned or platform teams.

4. Data and Pedagogy Teams: Specialized Expertise

Alongside our core feature and support teams, we have specialized teams focused on data and pedagogy:

• Data Team: This team provides crucial insights that inform product decisions across all squads. By managing our data warehouse and ensuring best practices in data analysis, they allow us to take a data-driven approach to product development, ensuring that we’re always making informed choices.
• Pedagogy Team: Responsible for ensuring that our educational content aligns with the latest pedagogical theories and market needs, the Pedagogy Team works closely with feature squads to redesign the learning journey and adapt our curriculum to future demands.

III. The Value Added

Why does this organizational structure work so well for us at 42? It’s because this approach is the only way to truly build a Product organization that thrives.

Have you heard about Conway’s law? The organisation and the system they support are tightly linked. If you want to do Product, your organisation must reflect it (hence my belief that Matrix organisation will always struggle to do Product, here are some article I wrote in the past: Agile Management VS Matrix Organisations and Decoupling organisations: the only way a product culture can thrive).

The value we bring revolves around three key pillars:

• Agility: Autonomy is at the core of our agile practice. Our squads can iterate rapidly, making decisions independently and adding value in complex, ever-changing environments. Using frameworks like the Cynefin model, we understand that not all problems have straightforward solutions, which is why we focus on iterative learning and adaptation particularly in a context like 42. This allows us to manage uncertainty and complexity effectively.
• UX: A design-thinking approach is crucial to how we explore both problem and solution spaces. Our multidisciplinary squads constantly interact with users to uncover pain points, validate ideas, and craft solutions that genuinely enhance the user experience. By emphasizing empathy and iteration in our process, we ensure that our product evolves in line with real-world needs.
• Data: Data lies at the heart of our decision-making process. We track meaningful metrics, leveraging data to inform every major decision. This ensures we aren’t just guessing what might work — we’re continuously learning from our users and refining our product based on hard evidence. The ability to track, measure, and analyze helps us focus on delivering maximum value both to the user and the business.

Together, these pillars — agility, UX, and data — create an organization that is not only adaptable and user-focused but one that continually delivers tangible value to our students, staff, and stakeholders.

By structuring ourselves in this way, we can stay ahead of the curve and ensure that 42 remains a leader in the ever-evolving landscape of education and technology.

Building a Product Organization at 42: How We Stay Agile and Innovate was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

💡 Test it yourself!

You can try out what I have described in this article by filling out this Tally form

You can also use this public template to start building yours

Tally is an incredible form solution. We use it every day to gather feedback from our users. Recently, I looked into how Tally could be integrated with our product, a Learning Management System for 20,000 students at 42.

We identified a few needs that Tally could address. One of them is a voting system where our pisciners — the participants in our immersive selection process known as the piscine — can upvote each other. This system helps us assess how collaborative and sociable each pisciner is.

But let’s be honest, an upvoting feature isn’t exactly where we can add the most value to our product. We need something that just works. Can it be a through a simple form? Well, keep reading and you’ll soon find out.

That’s when I started digging into the requirements we have for this system. Tally was the ideal solution for both our budget and feature needs. However, there were three requirements it didn’t cover:

1. Preventing a pisciner from voting twice.
2. Preventing a pisciner from stealing someone else’s vote.
3. Preventing non-pisciners from voting.

I could boil these down to one key need: authenticating each vote submission. Since each pisciner has an email address, I figured I could easily meet these requirements by sending a confirmation email upon submission, right?

Here’s the catch: Tally doesn’t offer this feature. And to be honest, not many form solutions do. Some even provide “official workarounds”!

So I ultimately decided to move forward with Tally because it was the best solution in many aspects. In this article, I’ll show you the most elegant solution I came up with to validate a respondent’s email address using Tally.

Concept and form structure

The same form will handle two things:

1. The vote of each pisciner (or in your case, the content of the form you want to authenticate)
2. A second submission, almost invisible, to confirm the vote and authenticate the submission

The form will be structured in five parts:

1. Welcome
2. Answer
3. Confirm your submission
4. Check your inbox (’thank you’ page)
5. Submission confirmed (’thank you’ page)

Here’s what will happen: the first time a user lands on the form, they’ll go through steps 1, 2, and 4.

We’ll then set up an email to be sent with a new link to the same form, so the user will go through steps 1, 3, and 5.

Send a unique link upon submission

Submission ID

Each time a form is completed, a submission is created with a Submission ID. You can view this Submission ID by clicking “Download CSV” from the “Submissions” tab in the admin panel. It’s a 6-character string.

We will use the Submission ID to create a unique link, which will be sent by email after submission for the user to validate their answer. In my example, the email will look like this:

Now, when the user completes the form, they receive an email with a link to the same form, including the Submission ID (which we called s) in the URL. Tally can capture this value as a hidden field.

When the user lands on the form for the second time, Tally will detect the s value and understand that it’s a confirmation of a submission, not the initial submission. Using Tally’s conditional logic, we will display pages 1, 3 and 5.

Keep in mind that by default, the next page appears when the user click “Next”. To ensure a controlled flow, I used the condition “s is empty / is not empty” on each page.

How to analyze the data?

Here’s how a complete submission looks like.

The initial submission contains all the information from your form. The second — almost empty submission (with s) — matches the initial submission.

Using Excel, Google Sheets, SQL, or any another solution, you can easily filter out unconfirmed submissions or confirmation submissions that don’t contain any data.

That’s it, your users can now fill out your form! They’ll then receive an email and click on the link inside to validate their submission!

Conclusion

When tackling user problems, it’s tempting to develop an in-house solution from scratch. But here’s the exciting truth: many of these daily challenges aren’t at the core of your business and can often be tackled more efficiently by leveraging existing solutions that are already out there.

Look for workarounds for any missing features — you might save up some time and learn a thing or two along the way!

💡 Test it yourself!

You can try out what I have described in this article by filling out this Tally form

You can also use this public template to start building yours

Validate a respondent’s email address in Tally was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

As part of a new project for Ecole 42, we worked with the product team to create a new Design System. But what is a Design System, and why did we decide to start from scratch? How can you convince your company, which is just starting out with a product approach, to use it ? We will answer all these questions in this article.

The aim of this article is not to explain in detail how to create a Design System, but to explain how it works, how it’s composed and how to manage its evolution.

Context

Today, 42 aims to revolutionize computer science and education with a unique model. This model is based on several criteria:

• Emphasizing inclusivity and the quality of higher education
• Allowing for free tuition fees
• Promoting peer learning
• Expanding a school into a global network with more than 50 campuses
• Orchestrating a complex computer system

In this vein, several user interviews were conducted, highlighting new objectives:

• Adapting the training to the future needs of the market
• Providing cutting-edge technologies to meet the needs of the next decade
• Improving the global experience through inter-campus collaboration and a common experience
• Emphasizing pedagogy and student success

The emergence of these different needs called for a renovation of the spirit of 42, leading to a reconfiguration of user interfaces. It is in this dynamic that we wanted to present to you the importance of a Design System.

What is a Design System?

A design system is a library of visual components but also codes to follow when designing a product. It’s a kit that will evolve over time. It offers a UX (User Experience) and UI (User Interface) reference for designers and developers.

• It facilitates the work of the concerned teams
• It can be designed using tools such as Figma, Sketch or Framer
• It includes what we used to call the ergonomic charter and/or the graphic charter.
• It allows for designing business applications, e-commerce sites, etc.

What does it consist of?

The content of the design system depends on the company’s identity, its ecosystem, and its needs. However, we can find common elements:

• Color palette and associated rules (Colors)
• Visual principle around typography (Typography)
• Iconography and imagery (Iconography)
• Grids to structure elements and spaces (Grids and Spaces)
• UI components and patterns (Component Library)
• Accessibility and user experience rules (Accessibility)
• Templates (Templates)

Before discussing these categories, it’s important to note a few points. In order to facilitate understanding among each of the teams, it’s necessary to use a common nomenclature. For example, when we use text sizes or spacing, it would be wise to use sm, md, lg, xl, etc. Similarly, for colors, we will use the color name followed by a number according to its intensity (see example below).

Colors

Colors have a crucial role in a Design System. Indeed, they will impact accessibility, the product’s identity, and its communication. The color palette can be thought of in different ways, but it is most frequently constructed as follows:

• Primary / main colors
• Secondary colors / color scale 1
• Tertiary colors / color scale 2
• Informative colors / success and errors

Typography

Each Design System is composed of a type scale, that is, a scale that allows listing the different typographies used (if there are several) and defining the categories (titles, subtitles, links, etc.), sizes, and text spacings. This also allows having a coherent, readable, and accessible product on different screen sizes.

Iconography

Iconography both supports your designs (buttons, information, successes, errors, etc.) and accentuates your brand’s identity. It’s important to maintain a similar size and weight (that is, thickness) to achieve consistent content.

Grids and Spaces

Grids are used to structure and align texts and objects forming components and layouts. The transition between each breakpoint will be much simpler with the help of a grid, making the responsive cleaner and pixel perfect. Additionally, spacings are added to maintain consistency between each element by defining precise rules.

Component Library

Generally, components are a grouping of everything we have previously mentioned in terms of UI (colors, typography, iconography, etc.). Let’s take a simple example of a button: its creation requires text, a color, spacing, an icon, and rounded edges if our identity demands it.

After creating a component, it is common to subsequently create variants. These are variations of the component that represent its different states. For example, a button can be primary or secondary depending on its importance, it can have different states (default, hover, click), a variable size, or even the possibility of having an icon or not.

Accessibility

Design Systems are the best solution to create accessible content for people with disabilities. Right from the initial stages of creating a product, it’s crucial to ensure that it is viable for everyone. This is probably the most important part of a Design System. We will discuss the rules and best practices to follow later on.

For further information on the subject:

L'avenir des design systems est dans l'accessibilité | Blog Figma | Figma Blog

Templates

Now that the Design System has been created, it’s time for the screens. However, this phase leads to numerous iterations, and the Figma space can become overloaded with a number of mock-ups. As a result, we need to ensure that the team can easily navigate through them.

To facilitate exchanges between teams, it is preferable to indicate the status of screens/pages (to be done, in progress, done, to be reviewed, etc.). Finally, it’s important to provide complete and precise documentation to deliver a final Design System to developers. This can take the form of a brief description of the flow, or annotations on the screens.

The purpose of templates is to meet these different needs: to order, simplify and facilitate the handover between designer and developer.

How a Design System works?

There are several key stages to follow, from the birth of the project to its completion:

1. Why do we need a Design System? What will it do?
2. Carry out UI audits and talk to the users concerned to understand their needs and frictions.
3. Look for solutions based on technological possibilities, budget, deadlines and priorities.
4. Choose a vocabulary (nomenclature) that is easy for the whole team to understand.
5. Build the Design System, iterate and test.
6. Bring the Design System to life to meet new user and team needs.

Accessibility in a Design System

Accessibility means ensuring that products meet the needs and expectations of people with disabilities. It means taking into account all human diversity in terms of ability, language, gender, culture, age, etc. This is why a step such as the Design System, which “introduces” the design of a product, is crucial.

Accessibility rules frequently include :

• Colors for everyone
• Text sizes readable on all types of screens (desktop, mobile, tablet, etc.)
• Keyboard compatibility
• Available audio interface and adapted media (subtitles, translations, etc.)
• Wording adapted and comprehensible to all, describing certain actions

However, there are over fifty of them, each with its own importance and impact on your product. So don’t hesitate to check out the page below, listing all the accessibility rules 🙂.

Web Content Accessibility Guidelines - Wikipedia

What future for a Design System?

The Design System has been conceived, finalized, organized and completed with various templates, and complies with accessibility rules. What’s next? The work has really only just begun, because a Design System never stops evolving.

We’ve realized that it facilitates exchanges between each team, but this must remain valid for the weeks, months and years to come. That’s why it’s important to keep a close eye on its evolution, not to define it as “finished”, but to continue feeding it, while clarifying it for future handovers within the team.

Last but not least, the Design System is intended to help its users (designers, developers, marketing managers, etc.). It is by improving it and taking into account the various needs that we can provide a product that best meets consumer expectations.

Glossary

1. What is a layout?
2. What is a breakpoint?
3. What is pixel perfect?

What is a Design System? was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

A game might exist to help you make learning fun and engaging, with a long-lasting impression! And if it doesn’t, how about gamifying the experience and creating one?

My fascination for the power of games and how they can transform learning led me to participate in Agile Games France. I attended a few annual editions, starting in 2012 in Nantes, and the most recent one in Valence in March 2024 that left me packed with insights and inspiration.

Agile Games France is an immersive two-day experience, with participants from a variety of backgrounds and experiences.

Throughout the day, participants have the freedom to choose which sessions they want to join, thanks to an approach called “Open Space” technology. These sessions can be anything from playing existing games to testing out unreleased ones, or even brainstorming new games designed for specific purposes and situations.

As expected with an Open Space event, there are a lot of things happening simultaneously, and one needs to make choices and embrace the “Two feet” rule.

Here is an overview of the sessions I observed, facilitated, and engaged in.

Mission anti sabotage

(facilitated by Alexandre Boutin, with the support of Emilie Esposito)

Players are teamed up and discover real-life-inspired sabotage scenarios that can plague any team or organization and throw a wrench in their progress.

By working together to unblock your team, you’ll hone your communication and collaboration skills, while learning anti-sabotage strategies.

Le jeu des prénoms

(facilitated by Moïra Degroote)

One of the best games I know to demonstrate the resource utilisation trap and a few Kanban practices.

Artistes et spécifieurs — express

(facilitated by Moïra Degroote)

Variations based on another of my favorite games (Draw the drawing game, by Alistair Cockburn), to experience the importance of feedback loops, communication, alignment on the vision, and iteration, in bridging the gap between vision and execution.

Agile Mind

(facilitated by Moïra Degroote)

Using a mechanism inspired from Master Mind board game, this game emphasizes the importance of short feedback loops.

Mind Maze

(facilitated by Zakaria Hzami)

This game explored cognitive biases, those mental shortcuts that can sometimes lead to flawed judgment, through 4 decks of cards (Standard, cyber, marketing, HR, DevOps).

Empathic

(facilitated by Kevin Chaput)

Participants develop empathy by being encouraged to step into the shoes of others and understand their emotions and needs.

Kevin adapted the game mechanics and emotion cards from the game Empathico, and created new cards to play this game in a professional context.

I also had a sneak peek at:

• Cadran d’Ofman (with Patrice Boisieau): exploring how to gamify the teaching or usage of this coaching tool
• Changer de perspective (apologies I forgot to write down who facilitated this): highlighting how, in a group, each person has their perspective on a situation, and there is no “right” or “wrong”
• Le mystère de la pyramide de Toutankhascrum (with Rebecca Carlier and Lilian Roche): Agile teamwork meets ancient Egypt! Use collaboration to solve puzzles and retrieve the treasure from the pyramid!
• Préjugés (with Alexandre Boutin): a board game exploring stereotypes and prejudice. We are still wondering if and in which settings it could be used, as we found that the topics are sensitive and require careful handling (even with friends).

At the end of the day and until late at night for a few of us 🥱, participants continue chatting and playing more casually.

I played at:

• Action! : use small artefacts like cubes representing people to mime situations
• Mantis : colorful and addictive card game, “to bank or not to bank”
• Moi c’est madame : learn and practice alternative reactions against common sexist situations

• Taco gateau chapeau cadeau pizza : simple and hilariously fast-paced card game.
• Space team : noisily fun and cooperative fast-paced card game

• Nouvelles contrées : cooperative board game using your own books as game material. It also provides a firsthand experience of the challenges of doing cognitive work and multi-tasking.
• PowerPoint karaoké : improvisation on slides

Agile Games France is a playground for not just exploring existing games, but also brainstorming and creating new ones specifically tailored to address challenges.

At 42, we tap into games or gamification techniques :

1. Internally, to facilitate workshops, team activities, training…

2. As well as part of the learning experience.

Beyond the professional side, Agile Games France fostered a vibrant community that’s become a source of friendship and support.

If you’re interested in exploring gamified learning or connecting with passionate individuals, I highly recommend attending an event like Agile Games France or incorporating some playful elements into your teaching.

As a starting point, follow Agile Games France on Linkedin, explore other participants’ experience reports, or pick a game to experiment from Agile Games France Wiki

Agile Games France: A Playground for Learning and Growth was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over the past decade, 42 has evolved from a single campus to a dynamic network of campuses worldwide. Founded with the vision of revolutionizing education, today 42 boasts a global presence, with numerous campuses dedicated to nurturing the next generation of tech talent.

As part of this growth, effective communication and engagement with our international community is crucial. How do we make Discovery easier, reaching our users faster? To support our mission, we aimed to build a comprehensive user tester database, a User Tester community. This would enable us to invite participants to UX workshops, gather invaluable insights, and continuously improve our offerings.

Here are some tips on how to achieve this.

What tools did we use?

1. Tally: Tally provided a highly customizable form building solution that enabled direct integration with Notion, automating the data capture process into our central database efficiently.
2. Notion: Serving as our centralized data repository, Notion allowed for sophisticated data management and organization, securely housing the information collected from global participants.
3. Slack: This platform was essential for distributing the Tally form across our extensive network, enabling instantaneous communication and coordination across 52 campuses.
4. Calendly: Facilitated the scheduling of UX workshops across multiple time zones by allowing participants to select suitable times via links automatically sent to their emails after form submission.
5. Gmail: Utilized to contact individuals who responded to the form, Gmail facilitated further communications, including the sharing of Calendly links for workshop scheduling, ensuring seamless interaction with participants by responding to their questions if needed.

A GDPR process

Ensuring GDPR compliance was a critical priority for us, particularly in terms of building a database that securely handles the personal data of our students and staff.

In collaboration with our Data Protection Officer (DPO), we carefully considered the most appropriate and reasonable data retention periods and implemented measures for data anonymization.

For instance, test data is anonymized after 6 months and completely deleted after 2 years to safeguard privacy.

Access to this sensitive data is strictly limited to ensure additional security. Currently, only a select group within our product team has access, which includes:

• 1 Chief Product Officer (CPO)
• 3 Product Managers (PM)
• 2 Product Designers

This approach helps us maintain a high standard of data protection and privacy in compliance with GDPR regulations.

Build an adaptative Tally Form

Objective: Develop a Tally Form that automatically customizes its questions based on the respondent’s role, ensuring relevance and efficiency in data collection.

Key Features:

1. Role-Based Questions: Begin with a fundamental question to identify the respondent’s role (e.g., staff, student, alumni). Tailor subsequent questions to address specific needs and gather relevant information for each group.
2. Dynamic Content: Use conditional logic to modify the form’s content in real-time based on previous responses. This ensures that participants only see questions that are pertinent to their specific circumstances.

Form flow

Tally form

One of the most important questions :

Who are you? (Staff, student,):

This helps to qualify our user testers in order to better target who to address for validating our hypotheses and gathering insights.

• Case of staff: We ask for their specialty/department because a staff member working in marketing does not have the same needs or professional knowledge as one in education.
• Case of student: We request the student’s login to track their progress in the 42 curriculum, and other interesting information such as their attendance, when they started at 42 school, etc.

Connect Tally to notion

Then, we wanted the results of the Tally form to be automatically incorporated into Notion Database. Tally allows for this, which is one of the reasons why we chose this tool. The seamless connectivity between these two platforms further enhances our workflow efficiency.

Tally integration panel

Here you can access the integration panel of Tally with Notion. We have mapped to ensure that each data received by the form is properly integrated into the Notion table.

Notion Database

Connexion explained

Reaching the audience

At 42, we have a Slack channel that brings together all the students and staff from the 52 campuses spread across 31 countries around the world.

We took advantage of this to send a message with the form in this channel.

Screenshot of slack message

Manage and suit multiple time zone with Calendly slots

At 42 school, campuses span various time zones. The aim was to identify time slots suitable for accommodating

Here are the campuses with the most significant time difference from Paris

• Australia — Adelaide (GMT+9:30, with a time difference of +7 hours from Paris)
• Canada — Québec (GMT-4, with a time difference of -6 hours from Paris)

Consequently, we devised multiple workshop schedules ensuring product team wouldn’t have to work late into the night, and would campuses be not disturbed by early morning activities at 5 am…

Send email to invite our userbase to workshop

According to our needs and the type of users we desire for our tests, we select and filter from our database what interests us.

Then, we send an email to this selection inviting them to the workshop

The fact that the CPO sent this message add more strength and credibility to our requests.

Conclusion

Workshop attendance results

The initiative to build a User Tester Database and plan regular UX workshops across the globe has been a transformative step for our organization

By utilizing tools such as Slack, Tally, Notion, and Calendly, we have effectively created a GDPR-compliant system that respects user privacy while engaging our community effectively. Our approach has not only streamlined the process of collecting and managing data but has also fostered a more collaborative and inclusive environment.

Moving forward, our focus will be on refining these processes and expanding our reach to include more diverse user groups and leverage the built community for more diverse initiatives.

We are excited about the future possibilities this initiative opens up and are committed to continuing our journey towards excellence in user experience design.

Don’t hesitate to clap and share this post if you think it can help someone around you build their first user tester community!

Workflow for recruiting a User Tester community around the world was originally published in Inside 42 on Medium, where people are continuing the conversation by highlighting and responding to this story.