It’s product-building time, baby!

In our Web Dev Path product management series based on the Stanford course Product Management: Transforming Opportunities into Great Products, we've talked about the importance of identifying user problems, designing thoughtful solutions, and crafting a product vision that aligns business goals with user needs. Now, it's time to turn those ideas into something tangible: we build. The build phase is where the vision starts to materialize—where all the research, alignment, and ideation converge into a first version of the product. But this phase is more than just execution. It’s where clarity turns into momentum, and where product managers must balance speed, focus, and adaptability. Vision vs. Product: What are we building? We already know that the product vision translates the company’s mission into an actionable blueprint. But in the build phase, it’s worth zooming in on one key idea: A product is only successful if it stays true to the vision while adapting to real-world constraints. This is where alignment becomes critical. Each line of code, each feature shipped, should move us closer to the future we’ve committed to creating. If your product vision emphasizes transparency and trust, then what you build— and how you build it —must reflect those values. This includes aspects such as how data is handled, the onboarding experience, and how content is personalized. For PMs, this means checking in constantly: Is what we’re building consistent with our vision? Or are we prioritizing what’s easy to ship over what actually matters? The answer to those questions should guide how we define our Minimum Viable Product (MVP). The Minimum Viable Product (MVP) An MVP is not a half-baked product. It’s the smallest version of your solution that delivers real value to your target users and helps you learn something meaningful from a quick testing phase with user validation through surveys and user experience sessions, for example. Your MVP should: Solve a clear and validated problem. Deliver one strong core feature that reflects your vision. Be measurable so that you can quickly assess your success. Tip: Avoid bloating your MVP with assumptions disguised as must-haves. Instead, focus on what gets you the highest learning return for the lowest build cost. If you can’t clearly explain the problem your MVP solves and what you’re testing, it’s probably not minimal or viable. How do we measure what we’re building? Building a product without tracking whether it works is like flying blind. That’s where metrics and, more specifically, OKRs (Objectives and Key Results) come in. Here’s how metrics support the build phase: They align the team around what success looks like. They help you prioritize what to build first. They provide early signals to validate (or invalidate) your assumptions. Let’s break that down. Start by setting a clear objective, which is the desired outcome for your users or business. Then, define 3–5 measurable key results that indicate whether you’re on track. These aren’t just aspirational—they should be quantifiable, realistic, and time-bound. Example: a dating app feature that assists users in filling out their profiles Objective: Help users feel more in control of their online dating experience. Key Result 1: Increase profile completion rate from 50% to 90%. Key Result 2: Increase match numbers by 30% due to more complete profiles. Key Result 3: Reduce profile editing churn (users who abandon mid-way when they find the process boring or too complex) by 40%. Once your OKRs are in place, you’ll want to track them using lightweight dashboards or tools like: JIRA dashboards (paired with sprint goals), Google Sheets or Notion (for early-stage products), Product analytics tools, such as Mixpanel, can be used to monitor user behavior in real-time. Tip: Pair quantitative metrics with qualitative feedback. A rise in profile completion is great, but hearing why users finished their profile (or didn’t) through user interviews or surveys is what brings context to the numbers. Whether you’re using OKRs or another framework, the principle remains the same: build with accountability. Metrics ensure you’re solving the right problem the right way, with evidence to back it up. What is the PM's job in this phase? During this phase, the PM serves as a translator between the strategic and tactical levels. You’re not here to micromanage, you’re here to keep the team aligned, empowered, and unblocked. You’re also responsible for keeping the product cohesive, ensuring that each feature connects to the overall product strategy, rather than becoming a scattered list of to-dos. Here’s how you show up: Clarify the “why”—every sprint, every ticket, every iteration should map back to your product vision. Unblock the team—whether it’s cross-team coordination, late decisions, or shifting priorities. Hold the line on quality—no

Apr 21, 2025 - 19:52
 0
It’s product-building time, baby!

In our Web Dev Path product management series based on the Stanford course Product Management: Transforming Opportunities into Great Products, we've talked about the importance of identifying user problems, designing thoughtful solutions, and crafting a product vision that aligns business goals with user needs. Now, it's time to turn those ideas into something tangible: we build.

The build phase is where the vision starts to materialize—where all the research, alignment, and ideation converge into a first version of the product. But this phase is more than just execution. It’s where clarity turns into momentum, and where product managers must balance speed, focus, and adaptability.

Vision vs. Product: What are we building?

We already know that the product vision translates the company’s mission into an actionable blueprint. But in the build phase, it’s worth zooming in on one key idea:

A product is only successful if it stays true to the vision while adapting to real-world constraints.

This is where alignment becomes critical. Each line of code, each feature shipped, should move us closer to the future we’ve committed to creating. If your product vision emphasizes transparency and trust, then what you build— and how you build it —must reflect those values. This includes aspects such as how data is handled, the onboarding experience, and how content is personalized.

For PMs, this means checking in constantly: Is what we’re building consistent with our vision? Or are we prioritizing what’s easy to ship over what actually matters?

The answer to those questions should guide how we define our Minimum Viable Product (MVP).

The Minimum Viable Product (MVP)

An MVP is not a half-baked product. It’s the smallest version of your solution that delivers real value to your target users and helps you learn something meaningful from a quick testing phase with user validation through surveys and user experience sessions, for example.

Your MVP should:

  • Solve a clear and validated problem.
  • Deliver one strong core feature that reflects your vision.
  • Be measurable so that you can quickly assess your success.

Tip:

Avoid bloating your MVP with assumptions disguised as must-haves. Instead, focus on what gets you the highest learning return for the lowest build cost. If you can’t clearly explain the problem your MVP solves and what you’re testing, it’s probably not minimal or viable.

How do we measure what we’re building?

Building a product without tracking whether it works is like flying blind. That’s where metrics and, more specifically, OKRs (Objectives and Key Results) come in.

Here’s how metrics support the build phase:

  • They align the team around what success looks like.
  • They help you prioritize what to build first.
  • They provide early signals to validate (or invalidate) your assumptions.

Let’s break that down. Start by setting a clear objective, which is the desired outcome for your users or business. Then, define 3–5 measurable key results that indicate whether you’re on track. These aren’t just aspirational—they should be quantifiable, realistic, and time-bound.

Example: a dating app feature that assists users in filling out their profiles

  • Objective: Help users feel more in control of their online dating experience.

  • Key Result 1: Increase profile completion rate from 50% to 90%.

  • Key Result 2: Increase match numbers by 30% due to more complete profiles.

  • Key Result 3: Reduce profile editing churn (users who abandon mid-way when they find the process boring or too complex) by 40%.

Once your OKRs are in place, you’ll want to track them using lightweight dashboards or tools like:

  • JIRA dashboards (paired with sprint goals),

  • Google Sheets or Notion (for early-stage products),

  • Product analytics tools, such as Mixpanel, can be used to monitor user behavior in real-time.

Tip:

Pair quantitative metrics with qualitative feedback. A rise in profile completion is great, but hearing why users finished their profile (or didn’t) through user interviews or surveys is what brings context to the numbers.

Whether you’re using OKRs or another framework, the principle remains the same: build with accountability. Metrics ensure you’re solving the right problem the right way, with evidence to back it up.

What is the PM's job in this phase?

During this phase, the PM serves as a translator between the strategic and tactical levels. You’re not here to micromanage, you’re here to keep the team aligned, empowered, and unblocked. You’re also responsible for keeping the product cohesive, ensuring that each feature connects to the overall product strategy, rather than becoming a scattered list of to-dos.

Here’s how you show up:

  • Clarify the “why”—every sprint, every ticket, every iteration should map back to your product vision.

  • Unblock the team—whether it’s cross-team coordination, late decisions, or shifting priorities.

  • Hold the line on quality—not in a perfectionist way, but to protect user trust.

  • Keep the energy up—acknowledge wins, protect focus, and yes, sometimes bring the donuts.

An experienced Product Manager knows that structure enables creativity. During the build phase, systems such as sprint planning, QA gates, retrospectives, and feedback loops (thanks, well-applied Scrum Agile!) help keep the team moving in sync.

  • These systems create clarity on what’s next.
  • They ensure velocity without chaos.
  • And they give everyone confidence that the product is moving in the right direction.

The build phase is also when we start thinking about what comes next—the launch. But we’re not there yet.

What’s coming next: launch types and go-to-market

Once your MVP is ready, the next natural step is to get it into the hands of users. But not all launches are the same. In our upcoming articles, we’ll cover:

  • Different types of product launches—from soft beta rollouts to full public releases.

  • How to design a thoughtful go-to-market (GTM) strategy that drives adoption and closes the loop on your product lifecycle.

This is the final stretch of the Stanford course—and it’s where all the upstream thinking pays off.

Final thoughts: build with clarity, test with intention

If defining the product vision gave you the blueprint, then building is where you lay the foundation. And just like any structure, what you build now will shape everything that comes next, so it pays to be intentional.

Focus on solving the core problem. Use metrics to keep your eyes on the outcome. And empower your team to build something meaningful, not just shippable.

Talk soon, take care, and get ready to launch