You built the platform, but data scientists still run their own scripts and ask colleagues how to deploy. Another capability will not help until the supported route makes their work easier. Start with Scout24's interviews and notebook prototype, then Netflix's distinction between removing operational work and hiding useful information. Lemonade and Mercado Libre show why convenient defaults need room for experienced users, and why a platform need not absorb every useful service. Interos makes standards actionable instead of another support ticket. Wolt turns documentation and user contributions into part of the product. Finish at Stitch Fix with evidence of adoption and pain removed. These accounts date from 2020 to 2023; their value is the reasoning behind the interfaces, rather than a shopping list of tools.
Why first: Elesin starts with people who were already working around slow notebook environments. Interviews and a working prototype gave them a reason to switch. Scout24's experience establishes the first job: discover which work users actually want removed before deciding what the platform should hide.
Why second: Removing tedious steps should not remove choices data scientists need to keep. In Goyal's Netflix account, users choose their modeling tools while Metaflow removes container and data-transfer work. It still exposes what happened in a run, so the simpler workflow remains possible to debug.
Why here: Lemonade narrowed its framework too far. Shilon describes the move from an open interface to a restricted one, then support for both, with extra responsibility for custom work. This tests Goyal's argument for freedom against an actual redesign. A Slack bot also puts routine operations where users already work.
Why here: Mercado Libre found another way to allow different workflows. Mansilla describes moving from rigid dataset and training entry points toward checkpoints and artifacts that different pipelines could share. After Lemonade's custom route, this offers a different boundary: agree on what needs checking without prescribing every step a user takes.
Why here: A platform need not absorb every useful service. De la Torre's earlier Mercado Libre account shows how Fury Data Apps could use another team's data infrastructure without taking it over. The flexibility in Mansilla's account extends here from individual workflows to services that other teams already run.
Why here: An interface check is only helpful if the user can act on its failure. Haaga describes Interos automating its standards while treating confusing errors and unnecessary rules as platform problems. After connecting services through common interfaces, the practical test is whether an engineer can correct a mistake without waiting for the platform team.
Why here: Self-service needs continuing work after the interface ships. Batifol describes Wolt's getting-started guides, regular feedback and users sharing examples. Inviting users to contribute fixes extends Haaga's aim of helping people unblock themselves, so the platform team is not the only place to find an answer.
Why last: Krawczyk asks what evidence adoption work leaves. Stitch Fix built abstractions with an initial partner team and watched team adoption, deployed services and user feedback. His difficulty isolating time saved is useful restraint after Wolt's account of community work: a growing model count alone cannot show whether the platform removed anyone's pain.