Ambani’s strategy was simple. Find a big underserved market and build a system to serve it at scale. He didn’t target a niche. He went for volume. For a services company, this means building features almost every user needs. It’s not about one loud customer. It’s about finding what serves the many.
Here’s how a small team can apply this using XP principles like collective ownership and simple design. (2/5)
Before sprint planning, look at your backlog. Ignore edge cases. Ask the team, “What single thing would help the most users right now?” That becomes your candidate sprint goal. It’s your MVP for the masses.
Write the goal in clear, simple language. Describe the common benefit. A bad goal is “Implement API for client X.” A good goal is “Allow users to export their data in one click.” The first serves one. The second serves all. (3/5)
During the sprint, use pair programming. As you build, keep asking, “Is this simple enough for a first-time user?” Your continuous integration tests should check high-volume use cases first. This is your feedback loop for mass adoption.
In your sprint review, don’t just demo to the product owner. Show it to a few different users. Watch how they use it. Did you build the common thread, or add complexity for a few? This tells you if you met the true mass-market goal. (4/5)