Sign in Subscribe
Product Engineer

Learn and Iterate

Dohyeon Kim

• 6 min read

In our previous article, we explored how outcome orientation can transform product development. Now let’s take a closer look at how you actually implement this approach using the Build-Measure-Learn cycle: the engine that powers truly customer-focused teams.

Stop Building Features Nobody Wants

Building software is hard, but building the right software? That’s when things get really tricky. How many times have you spent weeks on a feature that ends up with barely any user engagement? Or watched your carefully crafted UI gather dust while users stumble around with problems you never saw coming?

The uncomfortable truth is that most product efforts fail not because of technical issues, but because we’re solving the wrong problems.

The Build-Measure-Learn Cycle

Your mission as a product team is to discover what your customers actually want and will pay for, as quickly as possible. This means replacing the old feature-factory mindset with a learning mindset.

Here’s how it works:

  1. Build: Create the smallest possible experiment to test a hypothesis.
  2. Measure: Collect data on how real users interact with it.
  3. Learn: Analyze the results and extract insights.
  4. Repeat: Form new hypotheses from what you’ve learned.

When executed properly, this cycle creates a continuous learning cycle that drives your product toward real value at high speed.

Starting With Strong Hypotheses

Every effective experiment begins with a testable hypothesis. This is where the product manager leads the way, and as engineers, we need to be just as invested in forming hypotheses that tie technical decisions to user outcomes.

A strong product hypothesis follows a clear template:

“We believe that [doing this] for [these users] will achieve [this outcome]. We’ll know we’re right when we see [this signal].”

For example:

“We believe that reducing our app’s initial load time to under 2 seconds for new users will increase onboarding completion rates by 15%. We’ll know we’re right when we see the conversion funnel showing higher completion rates for users with faster load times.”

Notice how different this is from a vague request like “make the app load faster.” A hypothesis connects a specific action to an expected outcome and defines how you’ll measure success.

The Build Phase: Less Code, More Learning

Here’s a common pitfall that many teams stumble into (and I’ve been guilty of it myself): defaulting to production-quality code from the start. Instead, ask yourself, “What’s the smallest thing we could build to test this hypothesis?”

Sometimes, you don’t need to write code at all; perhaps you just need a quick design prototype. If you do need code, it doesn’t have to be production-ready. Here’s a hierarchy of experiments, from fastest to slowest:

  1. User interviews: “If we built X, would you use it?”
  2. Design prototypes: “Here’s a clickable mockup of X. Does it solve your problem?”
  3. Fake door tests: Add UI for a feature that doesn’t yet exist and track clicks.
  4. Concierge MVP: Manually deliver the outcome before automating.
  5. Feature-flagged minimal implementation: Build the smallest possible version behind a feature flag.

When writing code, optimize for learning speed over perfection:

  • Use feature flags to control who sees the experiment.
  • Set up A/B testing from the start.
  • Build with proper instrumentation for measurement.

It’s worth noting that a feature built with feature flags requires extra effort to roll out to all users. It’s important to emphasize this to stakeholders so they don’t assume everything is complete. In reality, we’ve introduced some technical debt to accelerate learning, and we need to “clean the kitchen” before moving on to the next experiment to avoid slowing product development.

The Measure Phase: Setting Up Your Learning Radar

Measurement is where everything gets real. You need both the technical infrastructure and the discipline to track the right signals.

For mobile apps, your measurement toolkit should include:

  • Core app metrics: Installs, active users, retention, session duration.
  • Feature-specific engagement: Usage frequency, completion rates, abandonment points.
  • Performance data: Load times, crash rates, application not responding (ANR) stats.
  • User feedback: In-app surveys, support tickets, store reviews.

Every new feature should answer:

  • Who used it?
  • How did they use it?
  • Did it solve their problem?
  • Did it create new problems?

This calls for:

  1. A consistent event-tracking strategy.
  2. Clear naming conventions.
  3. Proper user segmentation.
  4. Enough context with each event to understand why people behave the way they do.

Don’t chase “vanity metrics” (like downloads or DAU) if they don’t connect to genuine user value. Focus on metrics that truly validate or refute your hypothesis.

The Learn Phase: From Data to Insights

Data means nothing without analysis. The learn phase is where you convert raw measurements into actionable knowledge.

Make learning a deliberate practice by:

  1. Holding regular data reviews: Block out time each week to go over metrics.
  2. Documenting insights: Keep your findings in a shared space where the whole team can see them.
  3. Collaborating across functions: Include engineers, designers, and product managers in the conversation.
  4. Separating signal from noise: Don’t overreact to every small change in metrics.

When looking at app data, pay special attention to:

  • Patterns within user segments.
  • The correlation between specific feature usage and user retention.
  • Surprising user behaviors.
  • The performance impact on critical flows.

Often, the best insights emerge when you blend quantitative data (“what happened?”) with qualitative feedback (“why did it happen?”).

Closing the Loop: From Insights to New Hypotheses

The final step, and the beginning of the next cycle, is turning your learnings into refined hypotheses.

  1. Evaluate the original hypothesis: Was it confirmed, refuted, or inconclusive?
  2. Identify fresh questions that came up.
  3. Form new hypotheses based on unexpected findings.
  4. Prioritize which hypothesis to test next.

For instance, if your theory about faster load times boosting onboarding completion is confirmed, you might propose:

“We believe that applying these same optimizations to the checkout process will increase purchase completion rates by 10%. We’ll know we’re right when we see higher conversion in the optimized flow compared to the control group.”

Real-World Example

When I was working on the checkout feature in my previous team, we hypothesized: “providing step-by-step options for the checkout would increase conversions.”

Instead of overhauling the entire feature immediately, we:

  1. Built: Refactored the feature so the view layer was independent from the logic, and added A/B testing with two variants: “one-screen” (existing) vs. “step-by-step” (new).
  2. Measured: Tracked the conversion rate and time to checkout between the two experiences.
  3. Learned: Discovered that the one-screen option actually performed better.
  4. Iterated: Created another variant based on the one-screen approach, making it responsive to reduce dead ends.

We reached the right solution much faster by laying the foundation, experimenting with different user flows, and letting real user data guide us.

When Build-Measure-Learn Goes Wrong

It’s not all sunshine and rainbows. Sometimes teams latch onto the language of hypothesis-driven development but miss the actual point.

Common pitfalls include:

  • “Hypothesis theater”: Writing hypotheses after you’ve already decided what to build.
  • Confirmation bias: Tracking only the metrics that make your idea look good.
  • Analysis paralysis: Drowning in data and avoiding decisions.
  • Set-it-and-forget-it: Not rolling new insights into fresh hypotheses.

The biggest mistake is running experiments without letting the results influence future decisions. If your roadmap never changes based on what you learn, you’re not truly practicing Build-Measure-Learn.

Tools for Mobile Engineers

To bring this cycle to life, you’ll need the right gear:

For Building:

For Measuring:

For Learning:

If you’re a small team looking for cost-effective tools, Firebase Analytics, Remote Config, and A/B Testing are available at no cost. However, using other Firebase products can become expensive as your user base grows.

Getting Started: Your First Build-Measure-Learn Cycle

Ready to jump in? Start simple:

  1. Pick a small feature you’re thinking of building.
  2. Write a clear hypothesis stating the outcome you hope to achieve.
  3. Define the minimal experiment needed to test that hypothesis.
  4. Instrument for measurement before launch.
  5. Schedule a specific time to review the findings.
  6. Document and share what you learn, even if the hypothesis is proven wrong.

The first cycle is usually the hardest, but each iteration builds your team’s learning muscle.

Conclusion

In today’s overcrowded mobile app market, the ability to learn faster than anyone else might be your biggest advantage. Teams that excel at Build-Measure-Learn don’t just churn out features more quickly; they solve actual user problems more quickly.

Anchoring your work in hypotheses, building minimal experiments, measuring carefully, and learning continuously is what separates the exceptional product teams from the rest.

Remember: your goal isn’t to build more features. It’s to create more value. Build-Measure-Learn is the most reliable way to reach that destination.