How to Prioritize, Experiment, and Build Products That Matter (Growth Talks Edition)

‍

Building a product is easy. Building a product people actually want? That’s the hard part. In today’s world of endless possibilities, especially with AI making it easier than ever to ship features, startups and product teams face a fundamental challenge: How do you decide what’s worth building?

David Pereira, CEO of Omoqo, and Büşra Coşkuner, a seasoned product coach, tackled this challenge head-on in a recent discussion. Their insights cut through the noise of traditional product management and focused on a simple truth: Product success isn’t about building faster—it’s about learning faster.

‍

Stop Prioritizing the Wrong Things

Most product teams struggle not because they aren’t working hard enough but because they’re working on the wrong things. As David put it, “It’s all about how fast we can learn.” Companies waste time debating ideas in endless meetings instead of putting those ideas to the test.

So, how do you know if an idea is worth pursuing? Here’s the mindset shift you need:

• Treat every feature as a bet. Instead of assuming something will work, ask: What’s the smallest thing we can do to test this assumption?
• Stop debating. Start testing. More discussions don’t lead to better decisions. Action does. Like Kjael Skaalerud explained on our podcast, action kills doubt.
• Recognize strong signals. As Büşra explained, “The strongest signal in product development is someone paying for what you’re building.”

When deciding what to build, teams should ask:

1. How do we know customers want this?
2. How do we know we can deliver it effectively?
3. How do we know it will generate value?

If you don’t have strong answers, then your first step isn’t to build—it’s to test.
‍

Designing Smart Experiments: Move Fast, Learn Fast

Many teams equate “experimentation” with “building an MVP.” But building something isn’t the same as testing an idea. I wrote and talked about this and the importance of using Minimum Viable Tests to gather evidence, reduce risks, and increase your confidence level as fast as possible.

David shared his approach to launching his book:

• First, he posted the idea online and asked people to sign up for early access.
• Within 24 hours, 500 people had signed up. That was his first strong signal.
• Next, he released a paid guide as a micro-test.
• Once he saw demand, he wrote the full book.

This approach applies to product development, too. Instead of investing months in a big launch, try this:

1. Start with a question. What do you need to learn? (e.g., Do users care about X?)
2. Run a quick test. What’s the fastest way to get a strong signal? (e.g., A landing page, a fake button, a manual concierge service?)
3. Measure commitment. Are people willing to pay, sign up, or take meaningful action?

Büşra calls this the gating principle of experimentation: Start with light signals, then move toward stronger ones. The goal isn’t to build—it’s to learn.
‍

Watch the full Growth Talks Replay

‍

Stop Trying to Build the Perfect Thing

Another common trap? Overcomplicating everything. Many teams assume they need a perfect, scalable solution before they launch anything. David gave an example from his time in Brazil, where his team spent three months building a complex training platform—only to find out that the trainers they were building for preferred using spreadsheets.

“Sometimes,” he said, “we just need to make peace with boring solutions.”

In other words, ask yourself: Is there a simple, pragmatic way to test this first? A CSV upload might not be sexy, but it could save you months of wasted effort. By the way, I strongly encourage you to read David's book, Untrapping Product Teams. It's full of actionable insights.

Büşra echoed this sentiment: “Sometimes, the release itself is the experiment.” If it takes more effort to validate an idea than to just build it, then ship it—but be ready to kill it fast if it doesn’t work.
‍

Managing Product Development: The Balance Between Discovery & Delivery

One of the biggest tensions in product teams is balancing discovery (figuring out what to build) with delivery (actually building it). As Büşra pointed out, many companies try to assign rigid percentages—e.g., “30% of our time goes to discovery, 50% to delivery.” But the reality is more fluid.

Instead, she recommends:

• Work in cycles. Every sprint or quarter, teams should assess how much uncertainty they have. If you’re in unknown territory, dedicate more time to discovery. If you’re confident, focus on execution.
• Use outcomes, not tasks. Instead of saying, “We need to launch feature X by next month,” say, “We need to increase engagement by 10%.” This keeps teams flexible.
• Anticipate roadblocks. If you know a decision is coming in two months, don’t wait—start testing now.

David’s approach? Ruthless prioritization. “If you don’t own your calendar,” he said, “your calendar owns you.” Each week, he advises teams to ask:

1. What’s the one outcome we need to achieve?
2. What’s distracting us from that?
3. What meetings can we cancel?

Too many teams waste time on work that doesn’t move the needle. By setting clear goals and eliminating distractions, they can make real progress.
‍

The Art of Saying No

Product success isn’t just about knowing what to build—it’s about knowing what not to build. Büşra recommends teams regularly audit their product backlog, looking for features and metrics that no longer serve a purpose. If a feature isn’t delivering value, why are you maintaining it?

David agrees: “Less is more. The best products aren’t the ones that have the most features—they’re the ones that have the right ones.”

A few ways to cut the noise:

• Question every feature request. Instead of asking, “How do we build this?” ask, “What’s the real problem?”
• Set expiration dates. If an experiment doesn’t prove itself within a quarter, kill it.
• Delete metrics that don’t drive action. Tracking everything means understanding nothing.
  ‍

Final Takeaways: Build Smarter, Not Harder

David and Büşra’s insights boil down to a few core principles:

• Prioritize learning over building. If you’re not validating assumptions, you’re wasting resources.
• Start with quick, scrappy tests. You don’t need a full product to test an idea.
• Keep your backlog lean. More features don’t mean more value.
• Ruthlessly focus. If it doesn’t help you achieve your main goal, cut it.

At the end of the day, product development isn’t about shipping more features—it’s about delivering real impact. The teams that succeed aren’t the ones who build the most; they’re the ones who learn the fastest.

If you want to go deeper, follow David and Büşra on LinkedIn. They regularly share no-BS insights on product strategy, team leadership, and how to avoid building things no one actually wants.

‍