How a hypothesis about scattered leads became an MVP in 2 months, adopted by 80% of customers in the first month.
I worked as Product Owner of a web (SaaS) lead-management platform for dealerships, accessed through login by dealership managers and salespeople.
Dealership managers had leads scattered across spreadsheets, Facebook and Instagram.
My hypothesis: centralizing them would increase loyalty to the events. 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 gamification and a capture page 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; gamification and a capture page could wait, they weren't 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 Service Desk in Slack to centralize reports from the production environment.
WhyDevelopers were pinged informally, over WhatsApp, and reports arrived scattered, competing with deliveries and bug fixes already on the team's plate.
ImpactCategories and severities defined by me, a Kanban board in ClickUp, ~3 tickets/day with a response within 2 business days; the history fed the backlog and supported the case for a QA hire and for adopting test scenarios before releases.
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.