Skip to content

BLOG

How We Turn Product Ideas into Product Strategies

5 min read

Most new products fail. At Very, we don’t just build whatever collections of features our clients ask us to build and call it a product. We take pride in our work and we want to make sure we build the right product — one that’s likely to succeed out in the wild.

To come up with a product build strategy with a good probability of success, we walk our clients through a series of questions to establish a clear and compelling value proposition (or refine an existing one) and finally create the shortest path to a minimum marketable product (MMP).

Often when we start a project, the client has already done some initial validation of assumptions via Minimum Viable Product (MVP) experiments – like researching product interest by tracking clicks on landing pages – and they are ready for an actual product build. This is where our specialization in MMPs comes in.

As opposed to an MVP, the MMP is a more polished product with the smallest possible feature set that addresses the needs of the initial users: the early adopters and innovators.

Focus on the Problems First

While our clients typically come to us with a high-level product idea and even a set of features already in mind, we do our due diligence by starting the process from the very beginning of a product development lifecycle: understanding the vision and problems to be solved.

One mistake that we help companies avoid is coming up with a product idea that seems “cool” and then trying to make up problems it could solve. This is a common blunder that plagues both billion-dollar enterprises and small start-ups. 

For example, the original release of Google Glass met all of the “cool” product criteria – it was brand-new, flashy, and futuristic. However, it was never quite clear what problems Google Glass solved, or what made it the best solution to a user’s challenge. 

That’s why we always start a project by clearly defining the problem or problems that the product could solve.

Understand Your Users

Once the problem definition is clear, then we define the types of people/personas that struggle with the problem and try to understand how these people are currently dealing with it. This understanding is best achieved via user interviews. 

We use a detailed outline to guide our user interviews and help us understand a person’s background, role, and the challenges they experience. We strive to get the most honest, transparent answers as possible, so we do more listening than talking and work to make interviewees feel comfortable. At the end of the day, validating a product idea is not about us – it’s about the real-life users.

Define the Value Proposition

The next critical question we ask is about the competitive landscape. Does a product exist that already solves the same problem we’ve defined? If we identified a problem that currently has no solutions out there, we lucked out!

If there are some other existing solutions, however, the next step is to figure out what the new product can do better than the current solutions. Differentiators will be a critical piece of defining the MMP feature set.

Questions to ask here include:

  • Do the existing solutions only solve the problem for certain types of users? If yes, we should go more in-depth to define which segment of users applies to our product idea.
  • Are the current solutions to the problem lacking in some way and can the new product provide some additional value?

Here’s a common simple template for clearly stating the value proposition:

For (target user)

who (statement of the need or opportunity)

our (product/service name) is (product category)

that (statement of benefit).

Unlike (existing alternatives),

our product (does something better/new).

Identify Assumptions

Now that the value proposition is clear, it’s time to list all the assumptions made so far. (An assumption is simply something that we’ve assumed to be true.) We need to identify the assumptions that have already been validated either by earlier MVP experiments, user interviews, or publicly available data.

Then, we identify the assumptions that still need to be validated, e.g. “our product is better than X because of Y”.

Find the Shortest Path to Validate Assumptions

With the problem statement, value proposition, and assumptions in hand, we come up with a list of features. We often use a Needs/Wants/Desires exercise to prioritize feature development, sorting them into “must-have” and “nice-to-have” buckets. 

Our goal is to go to market as fast as possible — hence the word “minimum” in MMP — so the feature set should be kept as lean as possible. This is where the list of assumptions comes in handy. Any feature that is necessary to prove any of our critical assumptions is classified as a Need. 

Roadmapping

Now that we’ve aligned on the solution we’re building, who we’re building it for, and what we have to have in our MMP, it’s time to talk about the quickest way to reach our goal. 

Our roadmapping process allows us to identify scope, set budget parameters, track progress and story points, and prioritize. We determine the number of releases needed to arrive at your MMP, with the goal of delivering a usable product in every release. 

We track all of this using a project management tool called Jira, focusing first on the main value-add features so that if things change down the road, the most critical parts of the project are less impacted.  

Wrapping Up

This post provides just a taste of what goes into building, launching, and managing a product successfully, but it all comes down to having a clear product vision, a strong value proposition, and consistently challenging and validating assumptions.

To learn more about how we work — from laying the foundation to launch and beyond — check out our process outline here.