PrestaShop

<h3>TL;DR</h3><p>PrestaShop Marketing with Google connects merchants to Google Merchant Center, Google Ads, and free Shopping listings. The main blocker was a complex, multi-account onboarding that caused drop-off before merchants reached the feed. We reduced that friction, grew the user base to 16,000+ merchants, hit 300K in annual growth.</p><h3>The Problem</h3><p>PrestaShop merchants could list products on Google, but the path required navigating outside the back office. Before reaching the product feed, a merchant had to:</p><ul><li><p>Connect PrestaShop account</p></li><li><p>Create or connect a Google account</p></li><li><p>Configure a Google Merchant Center account, one per shop</p></li><li><p>Set up a compliant product feed with attributes Google requires</p></li><li><p>Connect a Google Ads account</p></li></ul><p>Most merchants did not know this before starting.<br>Many left mid-flow to read Google's external documentation.<br>The module existed but onboarding was bad.</p><p><strong>How might we</strong> reduce the number of steps and decisions a merchant must make before their first product goes live on Google?</p><h3>Discovery</h3><p>I led discovery with merchant interviews, mixpanel &amp; looker funnel data, NPS scores, and Hotjar session recordings.</p><p><strong>Drop-off happened before step three</strong><br>Merchants were leaving the six-step flow before reaching the product feed. Most did not understand what a Merchant Center account was or that they needed one per shop.</p><p><strong>Merchants left the product to find answers</strong><br>Session recordings showed users opening new tabs mid-onboarding. The interface did not explain what each account was for or what to do if they did not have one yet.</p><p><strong>Feed compliance was invisible</strong><br>Merchants had no clear view of which products were failing Google's requirements or why. The feed showed a status but gave no next action.</p><p>These findings expanded scope. The work shifted from feature delivery to rethinking the full onboarding funnel and adding feed health visibility.</p><h3>Process</h3><p>Our team worked in squads with OKRs. Each quarter, we built opportunity trees linked to chapter goals, mostly revenue. Weekly syncs with Google partners kept us aligned on feed specs and API changes.</p><p>My role shifted from Product Designer to Product Manager during this project. I took on scoping, roadmap decisions, and merchant research while continuing to own end-to-end design.</p><h3>The System</h3><p>Configuration Flow</p><p><strong>Purpose:</strong> Guide a merchant from zero to a connected, synced store in one linear flow. <strong>User goal:</strong> Connect all required accounts and understand what each one does. <strong>Product goal:</strong> Reduce drop-off before the product feed step.</p><ul><li><p>The flow had three named steps: PrestaShop account, data sharing, and Google accounts.</p></li><li><p>Each step showed a clear status: completed, in progress, or blocked.</p></li><li><p>Google account, Merchant Center, and Google Ads each had a dedicated connection card with a visible status badge.</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1ddczfhvd542c368vkhpgc.jpg"><div class="image-overlay"></div></div></div></div><p>Product Feed</p><p><strong>Purpose:</strong> Show merchants the health of their catalog before and after sync.<br><strong>User goal:</strong> Know how many products are live, pending, or failing, and why.<br><strong>Product goal:</strong> Reduce support tickets related to feed status.</p><ul><li><p>Three PrestaShop-side statuses: selected, compliant, non-compliant.</p></li><li><p>Four Google-side statuses: approved, pending, expiring, disapproved.</p></li><li><p>Sync steps appeared as a timestamped timeline.</p></li><li><p>Target countries, languages, and active filters were visible at a glance.</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1de6ijht8k3w8ffsmwdr62.jpg"><div class="image-overlay"></div></div></div></div><p></p><p>Product Feed Settings</p><p><strong>Purpose:</strong> Let merchants configure what gets sent to Google and how.<br><strong>User goal:</strong> Set shipping, attribute mapping, product filters, and sync schedule without leaving PrestaShop.<br><strong>Product goal:</strong> Ensure the feed meets Google's requirements before the first sync runs.</p><ul><li><p>Attribute mapping covered Description, GTIN, MPN, and Brand.</p></li><li><p>Sync ran up to four times per day.</p></li><li><p>A summary step showed all settings in one view before saving.</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1ddjyyhs2q3wafgipc71pd.jpg"><div class="image-overlay"></div></div></div></div><h3>Design System Contribution</h3><p>Components built for this module were shipped to PrestaShop's shared design library. This included status badges, multi-step indicators, and feed health cards. These were adopted by other module teams. I was one of the main contributors to the design system during this period.</p><p>Screenshot 2026-05-11 at 16.47.06.png</p><h3>Outcomes</h3><ul><li><p><strong>14,000+</strong> merchants using the module at handoff</p></li><li><p><strong>300K</strong> in annual growth reached</p></li><li><p>Monetization launched in mid 2023, responding to a company-wide push to generate revenue from core modules</p></li></ul><p><em>The hardest constraint was not the design. It was the dependency. Every decision touched Google's API rules, Merchant Center requirements, and PrestaShop's own data model &amp; legacy code. Managing that three-way constraint, while keeping the merchant experience at the center, was where most of the real work happened.</em></p>

Product Management

Product Owner

PrestaShop — Marketing Module — 2021 to 2024

Botify

<h2>TL;DR</h2><p>Botify's enterprise clients were losing organic traffic to SEO incidents they found too late, sometimes days after the damage was done. I led design from alpha to general availability on AlertPanel, a monitoring system covering 9 SEO signal categories across millions of URLs. The product shipped in 6 months, onboarded 25+ enterprise clients at launch, and became an essential part of Botify suite.</p><h2>The problem</h2><p>Enterprise websites break in small, quiet ways. A bad deploy can mark 33,000 pages as non-indexable. A misconfigured robots.txt can block Googlebot from an entire checkout flow. A server issue can silently degrade Core Web Vitals across 12,000 URLs. None of these feel critical in the moment. But weeks later, organic traffic is down 18% and no one can explain why.</p><p>Botify's clients had strong crawl analytics and log file analysis. What they did not have was an early warning system. Problems stayed hidden until someone noticed a metric had moved. By then, the window to fix it had already closed.</p><p><strong>How might we</strong> give enterprise SEO teams a system that catches incidents early, sends them to the right person, and helps them act fast?</p><h2>Discovery: 25 teams, 6 months</h2><p>The PM and I ran discovery with 25+ enterprise SEO teams over six months. Our CSM team gave us the contact list: clients already using Botify's crawl and log tools who had shown interest in incident monitoring. We organised and ran every session ourselves, all remote via Zoom.</p><p>Three things came up in almost every conversation:</p><p><strong>Alert fatigue was already a problem.</strong> Teams with homegrown monitoring scripts were getting too many alerts. The high rate of false positives had trained them to ignore notifications, so real issues got missed. Whatever we built had to be accurate before it was broad.</p><p><strong>No one knew who owned an incident.</strong> When something broke, SEO teams saw the symptom and engineers owned the fix. There was no shared way to track it. The system needed to create a common language for incidents, not just send a notification.</p><p><strong>Thresholds were the hardest part.</strong> "Alert me when something goes wrong" is not useful. What counts as wrong changes by site, by page type, by time of year. Teams needed to set their own rules, without writing SQL or filing an engineering request.</p><p>These three insights shaped the MVP. We focused on:</p><ul><li><p>Pre-configured alerts for the most common SEO failure types</p></li><li><p>An incident ownership model with clear status tracking</p></li><li><p>A self-serve Alert Builder for custom rules</p></li></ul><h2>Process</h2><p>We worked in two-week sprints with regular design reviews. Each sprint, I brought work in progress to the full team (PM, ML engineers, backend/fronend engineers) before moving to higher detail. Those sessions drove the key decisions: what to build first, what to push back, and what discovery had changed.</p><p>Two questions shaped the early structure of the product:</p><ul><li><p><strong>Feed or dashboard as the main view?</strong> We built both. The dashboard for leadership and high-level tracking. The feed for daily alert work.</p></li><li><p><strong>How to show severity without creating more noise?</strong> A "Critical" alert had to feel urgent, but not so frequent it lost meaning over time.</p></li></ul><p>The answers gave us the core structure: Dashboard, Alerts, Incidents, Monitor, with Alert Builder and Analytics as supporting tools. Each screen was tied to a specific need found in discovery.</p><h2>The system</h2><p>AlertPanel launched as eight connected screens, each designed for a specific type of work.</p><h3>Executive Dashboard</h3><p>The starting point for SEO leadership. One screen answers three questions:</p><ul><li><p>How healthy is the site right now?</p></li><li><p>What is actively broken?</p></li><li><p>Has anything gotten worse since yesterday?</p></li></ul><p>The site health score is a single number backed by 9 signal categories. We kept it simple: the score, the trend, and one click to see the breakdown. The incident list below shows only the four most critical open issues. The goal was to create focus, not anxiety.</p><p></p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d35yihp3y3wbn0hlwhgaq.jpg"><div class="image-overlay"></div></div></div></div><h3>Alert Feed</h3><p>The main working view for SEO analysts. Every active alert in one place, filterable by category, sorted by URL impact.</p><p><strong>User goal:</strong> Understand the scale of each alert before deciding what to work on next.</p><p><strong>Product goal:</strong> Make severity and impact readable in under three seconds per card, without needing to open the detail view.</p><p>Each card shows:</p><ul><li><p>Severity badge and category tag</p></li><li><p>Date and a short description</p></li><li><p>A sparkline showing the trend over time</p></li><li><p>Number of URLs affected</p></li><li><p>Affected page segments</p></li></ul><p>The sparkline was added late, based on something we heard in discovery: analysts wanted to know if a problem was growing or leveling off before they escalated it.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d3ezyhp6u3wbnfwel1cf5.jpg"><div class="image-overlay"></div></div></div></div><h3>Incident Timeline</h3><p>The handoff screen between SEO and engineering. An incident is what an alert becomes when a team decides it needs to be tracked through to resolution.</p><p>The key design question was ownership. We looked at a few models:</p><ul><li><p>Auto-assignment based on category</p></li><li><p>Team-level tagging</p></li><li><p>Manual assignment with a named owner</p></li></ul><p>We went with the simplest option that worked for most teams: a named owner, a status, and a time counter that makes slow resolution visible.</p><p>Status flow: Open, Investigating, Resolved. No extra states. Duration shown in hours, because anything counted in days had already been open too long.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d3qk0hq163wdnan2lcarm.jpg"><div class="image-overlay"></div></div></div></div><h3>Real-time Monitor</h3><p>A live view of signal health across all 9 SEO categories. Built to sit on a second screen while an engineer works on something else.</p><p>Each category card shows:</p><ul><li><p>Current status: healthy, warning, or critical</p></li><li><p>A small trend chart</p></li><li><p>Number of active anomalies</p></li></ul><p>We chose a grid over a list so you can count the red cards at a glance without reading every label.</p><p>The event log at the bottom tracks all activity in the last 24 hours, including resolved alerts. A monitor that only shows problems trains people to expect bad news. Showing resolutions gives teams a sense of progress.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d40trhsp442c3eafraafm.jpg"><div class="image-overlay"></div></div></div></div><h3>Alert Builder</h3><p>The self-serve tool for creating custom alert rules. The most complex screen to design and the one that went through the most changes.</p><p>The challenge: enterprise SEO teams needed to set rules across any metric in Botify's data, with segment targeting and custom thresholds, without SQL and without asking engineering for help.</p><p>We built a 5-step flow: Metric, Threshold, Segments, Notifications, Review. Each step covers one decision. No step needs knowledge of the next.</p><p>The metric categories (Crawl, Indexing, Performance, Rankings, Traffic) came directly from discovery. We grouped every alert request heard across 25 sessions into these five categories, then checked the structure with three client teams before locking it in.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d4cpfhshk42d2hudq1jfp.jpg"><div class="image-overlay"></div></div></div></div><h3>Alert Analytics</h3><p>A view for SEO managers to check if their alerting setup is working.</p><p>Four top-level numbers:</p><ul><li><p>Mean time to resolve</p></li><li><p>Alert volume over 30 days</p></li><li><p>False positive rate</p></li><li><p>Average resolution time</p></li></ul><p>Below that: volume by severity over time, alert frequency by category, MTTR trend, and a list of recurring incidents.</p><p>The false positive rate card was added during beta, at the request of three enterprise clients. They wanted to know when their thresholds were set too low and creating noise, before it caused the same alert fatigue we had found in discovery.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d4jahhsep3wbyeni5acly.jpg"><div class="image-overlay"></div></div></div></div><h3>Notification Routing</h3><p>Where teams set up which channels receive which alerts, and how escalation works.</p><p>The routing matrix covers nine categories across three channels (Slack, Email, PagerDuty). That is 27 toggle decisions. We tested two approaches:</p><ul><li><p>A flat table of toggles per category and channel</p></li><li><p>A rule-builder with conditions</p></li></ul><p>The table was faster for the people who would actually use this screen: experienced SEO operators who needed to set it up once and move on.</p><p>The escalation policy came directly from a discovery session with an enterprise SRE team who had built similar logic in PagerDuty and wanted it inside the product. The flow we landed on:</p><ol><li><p>Notify immediately via Slack and Email for Critical alerts</p></li><li><p>Escalate to PagerDuty on-call after 15 minutes if not resolved</p></li><li><p>Notify via Email for Warnings after 1 hour</p></li></ol><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d4vmdhq2o3wap7gmg5zo4.jpg"><div class="image-overlay"></div></div></div></div><h3>Settings</h3><p>Crawl schedule, URL scope, robots.txt monitoring, and contact preferences.</p><p>One fix that had a clear impact: clients were setting crawl frequency without knowing that crawler speed and crawl window together determined how many URLs would actually be covered per run. We added an inline note that calculated this for them in real time: "Based on your crawler speed, we will crawl a maximum of 7,200 URLs per run." This cut a recurring type of support request from clients who had set up the tool incorrectly.</p><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1d55qzhsp442d23qig1z1k.jpg"><div class="image-overlay"></div></div></div></div><h2>Design system contribution</h2><p>AlertPanel was built alongside a broader Botify design system effort. Because the product is built around urgency and status communication, it needed a lot of patterns that did not exist in the shared library yet.</p><p>I contributed 40+ components, including:</p><ul><li><p>Alert state variants</p></li><li><p>Severity colour tokens</p></li><li><p>Incident card structure</p></li><li><p>Monitoring tile patterns</p></li><li><p>Sparkline specifications</p></li><li><p>Routing matrix interactions</p></li></ul><p>Every component was built to WCAG AA standards with usage notes for the wider design team. Building into the shared system from the start meant anything validated in AlertPanel was immediately available across other Botify products.</p><h2>Outcomes</h2><p>AlertPanel shipped from alpha to general availability in 12 months.</p><ul><li><p><strong>500M+ URLs</strong> monitored across Fortune 500 client sites at launch</p></li><li><p><strong>25+ enterprise clients</strong> onboarded at GA, including Nike, Atlassian, L'Equipe, and LaFourchette</p></li><li><p><strong>40+ design system components</strong> shipped to Botify's shared library</p></li></ul><p><em>The hardest design problem on this project was not the dashboard or the Alert Builder. It was figuring out what "wrong" means for a site with millions of URLs, before you have enough data to know. The answer was to start with pre-configured alerts for the most common failure types, give teams the tools to adjust from there, and treat false positive rate as a product metric from day one.</em></p>

Product Designer

Botify — AlertPanel SEO Incident Intelligence — 2020 & 21

Studapart

<h2>TL;DR</h2><p>Studapart had a retention problem: landlords found a tenant and never came back. we redesigned five core surfaces to close that loop, connecting ad listing quality directly to search ranking and giving landlords visible reasons to return. ARR grew from 600K€ to 1.3M€ in 12 months.</p><h2>The problem</h2><p>Studapart's product worked for tenants. Students found housing.<br>The business problem was on the supply side: landlords posted a listing, filled it, and left. There was no second listing, no ongoing engagement, and no platform reason to return.</p><p>Every new revenue required a brand new landlord.</p><p>On the tenant side, search results had no quality signal. Tenants contacted everyone. The landlords most likely to re-list got no visibility advantage over landlords with incomplete, low-effort listings. The product rewarded nothing and retained no one.</p><p>Our analysis of 50K+ monthly sessions via Hotjar and Amplitude confirmed that friction was not concentrated in one place. It ran across the full landlord journey, from listing creation through to post-booking.</p><p><strong>How might we</strong> design a landlord experience that creates clear, repeatable reasons to return, and connect landlord quality directly to the outcomes tenants care about?</p><h2>Discovery findings</h2><p>I ran 30+ user interviews across three groups: tenants, landlords, and university dormitory admins managing institutional listings. Sessions were organised in rounds, moving from exploratory to validating as patterns emerged.</p><p>Five findings shaped the scope of the redesign.</p><p><strong>Landlords had no feedback after publishing.</strong><br>Once a listing went live, there was no signal about performance. No views, no quality score, no ranking position. Landlords had no reason to log back in and no way to know whether their listing was working.</p><p><strong>Listing creation lost momentum at two points.</strong><br>Drop-off spiked at the photos step and the availability step. Both required effort. Neither gave visible progress or confirmation that the effort was worth it.</p><p><strong>Response time was unmanaged and slow.</strong><br>Average landlord response time was over <strong>14 hours</strong>. Tenants were contacting multiple landlords at once. The first to reply converted. Landlords had no tools to reply fast and no visibility into how their response time compared.</p><p><strong>Tenants could not self-qualify before clicking.</strong><br>Search cards had no availability date, no landlord type, and no quality signal. Tenants clicked listings that did not match their timeline. Response rates were low because contact intent was low.</p><p><strong>Dormitory admins were underserved.</strong><br>University dormitory admins managed listings through a back-office interface that was not fit for purpose. Their needs were distinct from individual landlords and required separate consideration.</p><p>These findings tightened the scope. We prioritised the landlord retention loop first: quality score, dashboard, and listing creation. Tenant-side search improvements came second, tied directly to the landlord quality model. Messaging was the third workstream.</p><h2>Process</h2><p>We worked in 2 week sprints. Each week opened with a product/tech sync to align on priorities, review what was in progress, and flag blockers from engineering.</p><p>Design moved in three stages:</p><ul><li><p>Research and synthesis</p></li><li><p>Wireframes for structure and flow</p></li><li><p>High-fidelity for visual design and component decisions</p></li></ul><p>I ran design reviews with the two designers I was mentoring.<br>Reviews were used to pressure-test decisions before moving to the next stage.</p><p>The key process decision was sequencing. We did not redesign all five surfaces at once:</p><ul><li><p><strong>First:</strong> Landlord dashboard and listing creation wizard, because those two surfaces determined whether landlords would produce high-quality listings</p></li><li><p><strong>Second:</strong> Search ranking and listing detail, because they depended on quality data existing</p></li><li><p><strong>Third:</strong> Messaging, because response time improvements required the listing quality model to be in place first</p></li></ul><p>This order meant every surface we built had real data to work with by the time it shipped.</p><h2>The system</h2><h3>Search Results</h3><p><strong>Purpose:</strong> Help tenants find relevant listings quickly and give quality landlords better visibility.</p><p><strong>User goal:</strong> Identify listings worth contacting before clicking through.</p><p><strong>Product goal:</strong> Reduce low-intent contact requests and surface landlords with high quality scores.</p><ul><li><p>Search ranking weighted by landlord quality score, making the dashboard score directly consequential</p></li><li><p>Availability date shown at card level to eliminate timeline mismatches before the click</p></li><li><p>Landlord type badges (Propriétaire / Particulier / Résidence étudiante) help tenants self-qualify</p></li><li><p>Star rating visible on each card before opening the listing</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1cx4cbhmu13wci3pb4f8m3.jpg"><div class="image-overlay"></div></div></div></div><h3>Listing Detail</h3><p><strong>Purpose:</strong> Convert tenant interest into a booking request.</p><p><strong>User goal:</strong> Confirm the listing matches their needs and contact the landlord with confidence.</p><ul><li><p>Sticky right-rail with price, key details, and "Demander une visite" CTA visible throughout the scroll</p></li><li><p>Landlord trust block: response rate, response time, and global rating as three scannable numbers</p></li><li><p>Neighbourhood pricing map giving tenants price context before reaching the CTA</p></li><li><p>Surface, floor, type, and availability date grouped above the description</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1cyd9phnp23wbnedaocqiw.jpg"><div class="image-overlay"></div></div></div></div><h3>Landlord Dashboard</h3><p><strong>Purpose:</strong> Give landlords a clear reason to return after their first rental and show them exactly what to do next.</p><p><strong>User goal:</strong> Understand how the listing is performing and know what to improve.</p><p><strong>Product goal:</strong> Increase second-listing rate and overall ad quality across the platform.</p><ul><li><p>Quality score (0 to 100) linked directly to search ranking, making improvement rational and visible</p></li><li><p>Three ranked improvement tasks with direct edit links, no analytics, only actions</p></li><li><p>Pending tenant requests with expiry countdowns creating visible urgency to respond</p></li><li><p>Payment timeline in the right rail giving landlords a financial reason to return regularly</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1cxzvxhqwn42c32n0l8ik7.jpg"><div class="image-overlay"></div></div></div></div><p>The score and the ranking connection were the central design decision in the project. Without that link, the dashboard would have been a reporting tool. With it, improving the listing became directly tied to getting more bookings.</p><h3>Listing Creation Wizard</h3><p><strong>Purpose:</strong> Reduce drop-off across a six-step listing creation flow.</p><p><strong>User goal:</strong> Publish a complete, accurate listing without losing progress or getting stuck.</p><ul><li><p>Six steps in sequence: Le bien, Photos, Tarifs, Disponibilité, Conditions, Publication</p></li><li><p>Progress bar across the top giving spatial orientation throughout the form</p></li><li><p>Pre-populated date options anchored to the academic calendar: Immédiate, 1er septembre, 1er octobre, 1er janvier</p></li><li><p>Live summary strip at the bottom of the availability step confirming selections in plain language before advancing</p><p></p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1cy67hhqil3wcf15tr6322.jpg"><div class="image-overlay"></div></div></div></div><p>The date presets addressed the highest drop-off step directly. Landlords targeting students did not need to think about dates. They selected the relevant rentrée option and moved on.</p><h3>Messaging</h3><p><strong>Purpose:</strong> Reduce the time between a tenant's first message and a landlord's first reply.</p><p><strong>User goal:</strong> Reply to new tenant enquiries quickly, without navigating away from what they were doing.</p><p><strong>Product goal:</strong> Bring average response time from 14 hours down to under 5 hours.</p><ul><li><p>Three one-tap quick replies covering the most common opening responses, placed above the input field</p></li><li><p>Email notifications sent to landlords on new messages, reducing reliance on in-app check-ins</p></li><li><p>Listing photo, title, and price pinned at the top of each thread so landlords with multiple listings never lose context</p></li><li><p>Tenant status badge visible in the conversation header</p></li></ul><div class="image-container"><div class="image-row-wrapper"><div class="image-wrapper"><img src="https://cdn.collective.work/cmp1cya70ho4b3wap3vhv80ng.jpg"><div class="image-overlay"></div></div></div></div><p>Quick replies and email notifications worked together.<br>Quick replies reduced the effort of responding once a landlord opened the app.<br>Email notifications reduced the time before they opened it.</p><h2>Outcomes</h2><ul><li><p><strong>1.3M€ ARR</strong> reached within 12 months, up from 600K€ — a 116% increase</p></li><li><p><strong>50K+ sessions</strong> analysed via Hotjar and Amplitude to identify friction and prioritise fixes</p></li><li><p><strong>60%</strong> of the quarterly roadmap directly shaped by data from those sessions</p></li><li><p><strong>2 designers</strong> hired and grown from junior to mid level during this period</p></li><li><p><strong>+30% conversion</strong> improvement across the funnel, attributed to three compounding changes:</p><ul><li><p>Higher listing completion rates from the wizard redesign</p></li><li><p>Better search-to-request conversion from quality-ranked results</p></li><li><p>Improved landlord activation from the dashboard quality score loop</p></li></ul></li></ul><p><em>The 30% figure reflects the combined effect of changes across the funnel. Granular per-screen tracking was not in place at this stage. The three factors above are the most plausible explanations based on where friction was highest before the redesign.</em></p><h2>Reflection</h2><p><em>The hardest problem was not designing the dashboard or the wizard. It was deciding to connect the quality score to the search algorithm. That decision had product, engineering, and commercial implications that went beyond the design brief. Pushing for it required making the case to the PM and engineering lead before a single screen was designed. The lesson: the most important design decisions are often the ones made before Figma is opened.</em></p>

Studapart — Proptech Marketplace 2018 to 2020

Full Stack Development

Product Analytics

Senior Product Manager & Designer

Founder

– managed product growth for 25M+ users across 70 countries

Senior Product Manager

Senior Product Designer

Product Designer, Lead

Founding Product Designer

– 6 months of working with people around the world, learning SQL & Excel to analyze performance metrics, customer behavior, and sales data at Jumia.ma, leading e-commerce platform in Morocco at the time.

Yassine Abouzaid

Senior Product Manager & Designer

À propos

Expérience de travail

Founder

Senior Product Manager

PrestaShop

Senior Product Manager

Senior Product Designer

Product Designer

Product Designer, Lead

Founding Product Designer

Data Analyst, Intern

Formation

Ecole Du Louvre

Noé

IMT Atlantique

University of California San Diego

Université Hassan II

Licences et certifications

Full Stack Development

Product Analytics

Portfolio

PrestaShop — Marketing Module — 2021 to 2024

PrestaShop

Botify — AlertPanel SEO Incident Intelligence — 2020 & 21

Botify

Studapart — Proptech Marketplace 2018 to 2020

Studapart

Talents

Recruteurs

À propos