TirX — Leading a 60-Person Product Organisation
- Defined full product strategy and MVP scope from scratch, validating the crowd-sourcing model
- Scaled and managed a 60+ person cross-functional organisation through a delegated leadership structure.
- Achieved the first users with over 100 price submissions in the first month.
- Validated that drivers will contribute fuel prices through a low-friction crowdsourcing model.
The Problem
Fuel prices displayed on maps and petrol station aggregators are often inaccurate. Petrol stations update their prices daily — sometimes multiple times per day — while most third-party services struggle to keep pace. As a result, drivers frequently arrive at a station expecting one price and encounter another, undermining trust in the information they rely on when planning their journeys.
Maintaining accurate fuel-price data at scale is challenging. Existing providers typically depend on expensive commercial data feeds or periodic updates that quickly become outdated, creating a persistent gap between the prices shown to users and the prices available at the pump.
The Opportunity
The inaccuracy of existing solutions revealed an opportunity to rethink how fuel-price data could be collected and maintained. Instead of relying exclusively on costly, centralised data sources, there was potential to leverage the people already visiting petrol stations every day.
If drivers could report prices quickly and effortlessly, a community-driven model could generate fresher data at a fraction of the traditional cost. The key question became whether users would actively contribute updates often enough to sustain a reliable dataset.
The Hypothesis
If drivers can report fuel prices in under 30 seconds,
then they will actively contribute updates,
resulting in a self-sustaining and cost-efficient pricing database.
Success Criteria for MVP
I considered the initiative successful if we achieved:
- Over 20 daily active users within the first month
- Over 10 fuel price submissions per day
- Over 50% station coverage
Product Strategy
I defined the core product vision and bounded the MVP strictly to what was necessary to test the crowd-sourcing assumption. Core features included:
- Browsing map of petrol stations with live prices
- Viewing and updating station prices
- Leaving comments on station
Everything else was pushed to the backlog to protect our time-to-market.
Organisational Design
As the initiative scaled to 60+ people, I introduced operating mechanisms to maintain alignment and delivery predictability. Examples included:
- Split the developers into sub-teams: frontend, backend, UI/UX, QA and DevOps, coordinated by a dedicated Tech Lead
- Separate the delivery into 3-week long sprints with weekly alignment meetings
- Defined communication and coordination mechanisms - Jira boards and Discord channels per team
This structure allowed the project to scale execution without compromising decision speed or requiring central coordination for every technical decision.
Key Decisions
Delegated decision-making
I retained ownership of the product roadmap and prioritisation, but delegated execution decisions. Technical questions went to the Tech Lead first. UX questions went to the UI/UX Lead. This kept decisions fast and well-informed without creating a bottleneck at every level.
Trade-off: Reducing friction vs MVP timeline
To reduce friction in price reporting, we decided to implement an OCR model that would automatically extract fuel prices from photos taken at petrol stations. This decision caused the delay of the MVP launch by 2 weeks. In return, we managed to decrease the time required to submit a price significantly. We prioritised improving contribution speed over shipping on time, as submission friction was a key risk to validating the core hypothesis.
Outcome
The MVP has been launched and is currently in active use. The initiative resulted in:
- Over 50 users within the first month
- Over 100 fuel price submissions within the first month
- Reducing the manual price submission time by 80%
The MVP validated the hypothesis — users were willing to contribute fuel prices with sufficiently low friction, confirming that a crowdsourced model can generate usable real-time data.
Lessons Learned
I'd apply more structured oversight to individual teams — particularly frontend. With a team this size, I underestimated how quickly communication overhead increases in distributed volunteer teams, and how quickly frontend inconsistencies accumulate without strict quality gatess. The product moved forward, but tighter feedback loops — like mandatory team self-assessments and stricter definition of done criteria — would have caught misalignments earlier and improved delivery velocity.