Hey - it’s Fiona

My parents came to visit this weekend, which was a lovely change of pace from the usual workweek. We had a delicious lunch at Jeremy Clarkson’s pub, The Farmer’s Dog (I highly recommend the steak pie), enjoyed a gin distillery tour (and tasting, of course), and made the most of the unseasonably good weather. Now I’m back at my desk, busily finishing some big design tasks before I head off on holiday next week.

This week’s newsletter is all about falling in love with the problem, not your solution. Founders often come to me with a marketplace idea already fully formed – features mapped out, a lofty vision of where they want to go, even names and taglines decided. But most of the time, the initial idea won’t work the way they hope. And that’s okay. Your job isn't to be right – it's to be successful.

How do I know if I’ve got the right marketplace idea?

I hear this question a lot, from early-stage founders still in their 9 to 5, to those preparing to launch their MVP. My answer is always the same: you don’t know. And you don’t need to.

Your marketplace idea is a hypothesis. Your assumptions about the market, your users, their problems, and how you solve them – all of these need to be tested.

The key is not to seek validation of your idea, but to seek truth about the problem. This mindset shift changes everything.

Be married to the problem, not the solution

When you're building a marketplace, your focus should be on deeply understanding the pain points of your users on both sides of the marketplace.

• What are they currently doing to solve the problem?

• How painful is it?

• Are they actively looking for a better way?

• What would “delight” look like for them?

If you skip these questions and go straight to building, you risk wasting months on something nobody wants. And even if you launch it, you’ll be forced to backtrack later.

It’s normal to be wrong in the beginning. In fact, it's expected. The difference between successful founders and everyone else is that they treat their ideas as experiments, not statements of fact.

You are not the visionary oracle of your marketplace. You're the chief investigator.

Prototype, test, and listen carefully

One of the best ways to test your assumptions is with prototypes. And I don’t just mean polished Figma designs. Prototypes can be ugly. Scrappy. Even paper sketches.

The goal is not to impress. It’s to get feedback – ideally from the kinds of users you want to serve.

Here’s a simple process I use with clients:

1. Map your assumptions.
   Write down everything you're assuming about your users, their problems, their workflows, what they value, and how they might interact with your marketplace. Be honest.

2. Build a simple prototype.
   This could be a lo-fi clickable mockup, a Typeform pretending to be a product, or a concierge-style service you run manually. Choose the method that helps you test your riskiest assumption.

3. Talk to users.
   Not your friends. Not your colleagues. Real people who experience the problem you’re trying to solve. Observe their reactions. Ask open-ended questions. Watch where they get confused or lose interest.

4. Refine or pivot.
   Based on what you learn, you’ll need to make changes. Most early prototypes don’t pass the test. That’s not failure. That’s progress.

Good design follows good discovery

As a designer, I always advocate for thoughtful UX. But design in a vacuum doesn’t work. The most beautiful interface won’t matter if it’s solving the wrong problem, or solving the right problem in the wrong way.

That’s why discovery work (i.e. problem interviews, user research, feedback loops) should be the foundation of your marketplace design. Your prototype is not a final product. It's a question in visual form.

Remember: you are not building the solution. You are building towards a solution.

Avoid falling in love with features

This is a trap I see often. Founders get fixated on specific features:

• “It needs a matching algorithm.”

• “I want to build a points-based reputation system.”

• “We need three user types and a dashboard for each.”

It’s natural to imagine what your product could become. But early on, these ideas are likely premature. If you find yourself justifying a feature before confirming the problem, pause.

Ask yourself: What’s the smallest thing we can build to learn the most?

That’s the spirit of prototyping. Not launching something perfect – but learning something valuable.

—> ✉️ Reply with your questions and I’ll answer them in a future issue.

Great marketplaces that stayed focused on the problem.

Airbnb (early days)

Before they became a global platform, the founders of Airbnb tested their idea by renting out air mattresses in their own flat during a conference. The problem? Hotels were sold out. Their “Air Bed & Breakfast” idea was a direct response to this need. No complex product, no scale – just testing the demand.

Turo (originally RelayRides)

Turo began with a simple idea: let people rent out their personal cars when they weren’t using them. But before building anything at scale, the founders validated the concept manually. They spoke with car owners in urban areas who rarely drove during the week, and with travellers frustrated by expensive, inflexible car rental companies. Early prototypes involved spreadsheets, phone calls, and in-person key handovers. Trust and insurance were the core problems — not flashy features. Instead of building a sophisticated booking engine right away, they focused on solving those foundational issues. The platform grew by staying relentlessly focused on real user pain and validating demand city by city.

BlaBlaCar

BlaBlaCar, the long-distance ride-sharing marketplace, didn’t start with complex tech. Initially, it was just a simple website where drivers could post trips and passengers could reach out manually. The core insight came from understanding that people were already informally sharing rides to save money, especially in countries with expensive train travel. Instead of assuming they needed to build a full Uber-style experience, BlaBlaCar focused on trust-building features like user profiles, ratings, and the quirky “Bla”–“BlaBla”–“BlaBlaBla” talkativeness scale. All of it came from listening to their early community and doubling down on solving what really mattered: making strangers feel comfortable sharing a car.

Further reading and resources on prototyping, problem discovery, and early-stage testing.

If this issue gave you food for thought, I’d love it if you forwarded it to a founder friend. And if you’re ready to validate your idea before you build, take a look at my marketplace validation report.

Fiona Burns

Find me on LinkedIn or Book a 1:1 call

If you enjoyed this newsletter, why not forward it to a friend.

Did someone forward you this email? You can subscribe to Marketplace Minute here!