MVP execution

If you and your team experience one or more of the following pains:

  1. Slow MVP development
  2. Features in the backlog are not data driven
  3. Features don't come from an articulated customer problem but from stakeholders
  4. The vision is not clear
  5. The problem is not well articulated
  6. Tech stack is too complex
  7. Customer needs are not identified correctly
  8. You're not sure your building the right thing
  9. Teams have no context or have second hand information

What is an MVP?

MVP stands for "Minimum Viable Product" and was first introduced by Frank Robinson in the early 2000s.

A product of this caliber can be a website or a mobile app with just enough functionality to satisfy early customers and gather feedback for future iterations.

The old approach of building products, assumes that you know everything and can take the risk of investing without iteration in the real world.

Your target audience needs a means of transport right away.

But, the initial version has to get the job done. The high-end vehicle is still a hypothesis. Remember to focus on a single audience and build a product that delivers real value and solved a problem for your customers.

MVP challenges

You failed to identify customer needs correctly

As you probably learned until now, ideas are worthless. Solutions are somewhat more valuable, but the right solution to a clearly articulated problem is priceless. Making sure you articulate the problem of a customer segment is critical to the success or failure of your product. This process is called customer discovery. In this process you need to deeply understand your market and that means getting our of the building. There are no facts inside the building, just opinions.

Customer development is the first step that will help you clarify the vision and make sure you build the right thing, the right way.

Problems we can help with:

  • articulate the customer problem correctly by doing customer discovery

You keep pushing the MVP launch date

This is a common problem with a lot of early stage products: perfectionism. An MVP should only provide an answer to:

  • are we going in the right direction?
  • do initial customers see value in our solution that they invest energy and time to help us get it right?
  • is anybody willing to pay for our solution? How much?
  • should we pivot? (change the product or change the market)

Problems we can help with:

  • backlog prioritization for making sure the team works only on important items
  • making sure the importance of the features is data driven from customer interviews
  • reduce the technical complexity of the features by creative problem solving
  • keep the budget under control
  • ship product fast

Features come from stakeholders (top-down approach)

In a lot of companies we keep seeing that product teams don't actually work customer-data driven, but are executing features coming from stakeholders without any context. This ends up in frustration at the team level most of the time, because everything looks like assumptions or orders coming from above. We cannot tell for sure which stakeholders are wrong or not, but we know that transparency and alignment brings energy and a sense of purpose.

Problems we can help with:

  • providing a medium for clear communication between teams and stakeholders
  • helping teams adapt faster and work agile in the real sense by having context
  • helping teams ask the right questions for better communication with the stakeholders

The list of possible problems does not end here.

If you and your team experience one or more of the following pains:

  1. Slow MVP development
  2. Features in the backlog are not data driven
  3. Features don't come from an articulated customer problem but from stakeholders
  4. The vision is not clear
  5. The problem is not well articulated
  6. Tech stack is too complex
  7. Customer needs are not identified correctly
  8. You're not sure your building the right thing
  9. Teams have no context or have second hand information