How a question about churn became an MVP that generated R$800K in revenue in its first month.
Mid-year, churn rose 10–20%. The obvious reaction would have been defensive. Leadership asked a different question: how do we turn this risk into an opportunity?
The answer wasn't about retaining more, it was about capturing better. Customers' problem wasn't lead volume. It was visibility.
We could have built everything. That was exactly the risk.
I ran a competitive analysis instead of starting discovery from scratch, to understand how the market already solved this problem. I mapped which concepts made sense to adapt and validated the strategy with the team. I used MoSCoW to separate the essential from the nice-to-have and prioritized 3 features for the MVP (lead import, lead handling, and a management dashboard), leaving advanced reports and event dashboards out of scope. I structured the stories with business context, not just technical requirements. I validated scope and priorities with stakeholders and stayed with the team through go-live.
Analyze competitors instead of starting discovery from scratch.
WhyBuild on what the market had already validated about this problem, instead of rebuilding that learning from zero.
ImpactA concrete foundation to adapt concepts to our context, validated with the team before writing a single story.
Prioritize 3 features for the MVP and leave the rest out.
WhyThe most urgent problem was real-time visibility and traceability; advanced reports and event dashboards were nice-to-haves, not critical for launch.
ImpactMVP delivered within the 2-month deadline, focused on what actually solved the customer's pain point.
Launch directly with real users, during live events, with no controlled testing phase.
WhyWith the event calendar fixed, the decision was to accept the risk of validating in production, reinforcing support and monitoring as a contingency plan.
ImpactProduction incidents came up and support was heavily engaged; they were resolved quickly, but this became the project's biggest lesson.
Create a single Slack channel to centralize reports from the production environment.
WhyIncident reports were landing directly with the development team, scattered across channels, competing with deliveries and bug fixes already on the team's plate.
ImpactA centralized, triaged report flow, without overloading the team or delaying work already in progress.
Full validation before scaling costs less than it seems, far less than a production incident during a live event. This project left me with a pattern I still use in every discovery: question the ask, because the problem isn't always the obvious one, and prioritize ruthlessly, because an MVP isn't everything that would be nice to have. With more control over the calendar, I would have chosen a gradual rollout instead, with a feature flag to validate with a small group of users before opening it up to everyone.
A tight deadline doesn't rule out validating in layers, it just demands choosing more carefully where to cut.