Tag Archives: early adopters

Yes, Startup Products Can Take A Village

Thomas Pichon is the Founder of The Collaborative Startup. He advocates building a community to gain traction for a startup, and I thought the advice could equally apply to an “internal” startup. The article below is re-posted with his permission from his free e-course.

By Thomas Pichon

I am helping an entrepreneur build a yoga retreat, and I asked her how she was going to build her project. She said:

“I guess I’m going to concretely build the service, which means finding where we’re going to host the retreat, build the program, etc… Then, I’ll try to advertise it.”

I used to build products with this kind of strategy for years. Results have never been extraordinary. However, I have discovered one which brought me much more success:

  1. Build your community. Share helpful content related to the service you want to provide in order to attract people.
  2. Ask them what is their biggest frustration. Build a service around this problem.
  3. Get pre-orders. Start collecting credit card numbers before you have built the service. If you have created trust with your community by providing helpful content from day 1, you will see that this step is much easier than it looks now.

Hope these lines help you understand how to start your business. Do not build your product, then try to sell it. Sell it, then build it. And the better way to sell it before having the product ready is by building trust within a community.

So start now! Write helpful content about your topic in order to start building trust! Share it where your target audience hangs out online.

If you need any advice on this topic, or more generally about startups, you can schedule a call with me anytime, or ask your questions on my forum.

Thomas Pichon is the Founder of The Collaborative Startup, an innovative initiative designed to help entrepreneurs by leveraging the power of community development, Lean Startup and crowdsourcing.

An MVP Is Not The Smallest Collection Of Features You Can Deliver

Source: Spotify

Source: Spotify

There’s a lot of discussion and confusion about what is and isn’t a minimum viable product (MVP).

Worse, many execs have latched on to the term without really understanding what truly constitutes an MVP — many use it as a buzzword, and as a synonym to mean a completed version 1.0 ready to be sold to all customers.

Buzzwords are meaningless. They represent lazy thinking. And using “MVP” to mean “first market launch” or “first customer ship” means you’re back to the old waterfall, traditional project-driven software development, sales-focused approach. If that’s your approach, fine. Just don’t call what you’re delivering an MVP.

On the flip side, lots of folks in the enterprise world, including in product management, over-think the term. It gets lost in the clever nuances of market maturity, and a long entrenchment in the world of release dates and feature-based requirements thinking.

Many folks think of MVP as simply the smallest collection of features to deliver to customers. Wrong. It’s not.

The problem with that approach is it assumes we know ahead of time exactly what will satisfy customers. Even if we’ve served them for years, odds are when it comes to a new product or feature, we don’t.

Now, the challenge with the concept of a minimum viable product is it constitutes an entirely different way of thinking about our approach to product development.

It’s not about product delivery actually — in other words, it’s not about delivering product for the sake of delivering it or to hit a deadline.

An MVP is about validated learning.

As such, it puts customers’ problems squarely at the center, not our solution.

Reality check: Customers don’t care about your solution. They care about their problems. Your solution, while interesting, is irrelevant.

So if we’re going to use the term “MVP”, it’s important to understand what it really means.

Fortunately, all it takes to do that is to go back to the definition.

Download The Handy Primer “What Is An MVP?” >>

Minimum Viable Product (MVP) is a term coined by Eric Ries as part of his Lean Startup methodology, which lays out a framework for pursuing a startup in particular, and product innovation more generally. This means we need to understand the methodology of Lean Startup to have the right context for using terms like “MVP”. (Just like we shouldn’t use “product backlog” from Agile as a synonym for “dumping ground for all possible feature ideas”.)

Eric lays out a definition for what is an MVP:

“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

Eric goes on to explain exactly what he means (emphasis mine):

MVP, despite the name, is not about creating minimal products… In fact, MVP is quite annoying, because it imposes extra overhead. We have to manage to learn something from our first product iteration. In a lot of cases, this requires a lot of energy invested in talking to customers or metrics and analytics.

Second, the definition’s use of the words maximum and minimum means an MVP is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.

Let’s break this down.

1. An MVP is a product. This means it must be something delivered to customers that they can use.

There’s a lot that’s been written about creating landing pages, mockups, prototypes, doing smoke tests, etc., and considering them as forms of MVPs. While these are undoubtedly worthwhile, and certainly “lean”, efforts to gain valuable learnings, they are not products. Read Ramli John‘s excellent post on “A Landing Page Is NOT A Minimum Viable Product“.

A product must attempt to deliver real value to customers. So a minimum viable product is an attempt — an experiment — to deliver real value to customer.

Which leads us to…

2. An MVP is viable. This means it must try to tangibly solve real world and urgent problems faced by your target customers. An MVP must attempt to deliver value.

So it’s not about figuring out the smallest collection of features. It’s about making sure we’ve understood our customers’ top problems, and figuring out how to deliver a solution to those problems in a way that early customers are willing to “pay” for. (“Pay” in quotes as it depends on your business model.)

If we can’t viably solve early customers’ primary problems, everything else is moot. That is why an MVP is about validated learning.

3. An MVP is the minimum version of your product vision. A few years ago, I had to build an online form builder app that would allow customers to create online payment forms without the need to write any HTML or worry about connecting to a payment gateway. Before having our developers write a single line of code to build the product, we first offered customers the capability as a service: we would get their specs, and then manually build and deliver each online payment form one-by-one, customer-by-customer. Customers would pay us for this service.

This “concierge” type service was our MVP version of our product vision. Of course, it wasn’t scalable. But we learned a heck of a lot: most common types of payment forms they wanted, what was most important to them in a form, frequency of wanting to make changes, reporting needs, and how they perceived the value of the service.

We parlayed these learnings into developing the software app itself — which, by the way, we delivered as an MVP to early customers to whom we had pre-sold the software product. (Yes, we delivered two different types of MVPs!)

Whether you take a “concierge” approach or your MVP is actual code, it most definitely does NOT mean it’s a half-baked or buggy product. (Remember viable from above?)

It DOES mean critically thinking through the absolute necessary features your product will need day 1 to solve your early customers’ top problems, focusing on delivering those first, and putting everything else on the backlog for the time being. It also means being very deliberate about finding those “earlyvangelists” that Steve Blank always talks about.

Ultimately, the key here is “maximum amount of validated learning”. This means being systematic about identifying your riskiest assumptions, formulating testable falsifiable hypotheses around these, and using an MVP — a minimum viable product version of your product vision — to prove or disprove your hypotheses.

Now, validated learning can certainly be accomplished via a landing page, mockup, wireframes, etc. And it may make sense to do these things. Super. But don’t call them MVPs, because while they may deliver value to you and your product idea, they’re not delivering actual value to the customer.

At the same time, the traditional product management exercise of identifying all the features of a product, force ranking them, and then drawing a line through the list to identify the smallest collection to be delivered by a given timeframe is not an MVP. Why? Because this approach is not predicated on maximizing validated learning. If you’re going to pursue this approach, go ahead and call it Release 1.0, Version 1.0, “Beta”, whatever. But don’t call it an MVP.

An MVP is about not just the solution we’re delivering, but also the approach. The key is maximizing validated learning.

I’ve created a handy primer on what is a minimum viable product. Download it below. I hope it helps you to become a pro at defining an MVP for your next great product idea!

Download The Handy Primer “What Is An MVP?” >>

Selling An MVP

By John Peltier

The Lean Startup movement led by Eric Ries has put the concept of minimum viable product (MVP) into the current vernacular, and certainly into Shardul’s vocabulary. 🙂 An MVP is generally understood to be a product that has just enough functionality to validate that you’ve found market problems buyers are willing to pay to solve, and that your offering solves the problems effectively enough to capture some of the market. This is an attempt to avoid over-building a solution, and solving problems that buyers don’t actually have.

Conducting a full-scale launch of an MVP can be both rewarding and dangerous.

Fraught with Peril

One area of danger is building an MVP that best fits a segment of the market, but selling the solution to the entire market. Buyers from multiple segments force language into their contracts demanding their most critical features, partially solving problems for multiple segments but delaying fully solving the problem for any segment. This makes it more difficult to get glowing references, since buyers from all market segments perceive gaps for a longer period of time.

Another danger is defining your MVP by the functionality needed to demo, versus the functionality needed to use. Teams may be tempted to defer under-the-hood capabilities until after release, especially when feeling the pressure of time-to-market. This gets you to market faster, but with a product that has known gaps.

As things progress, Sales meets resistance due to needs not met in your MVP, and starts bargaining for delivery promises to win deals. Meanwhile, this can crowd out bandwidth to close the gaps–which represent under-the-hood capabilities all buyers will need. Once you say yes to a few deal-makers, you can’t say yes to any more. This will also strain the relationship with Sales.

One way to adjust is to proactively include fewer big-ticket items on the roadmap, while allocating some percentage of capacity to under-the-hood needs. At some point your estimations won’t line up with reality, though, and you’ll have to escalate something that everyone assumed was already there. The silver lining is that these episodes–often a response to onboarding needs, and sometimes useful in winning an early reference–can be used later as an example of why you need to invest in the engine!

A Focused Solution

On the other hand, selling an MVP delivers revenue at perhaps the earliest possible date.  Prospects who don’t need all the bells and whistles encounter a solution that meets their needs, without having to wait for you to build feature after feature that they don’t need. Early adopters likely wouldn’t wait for you to deliver your solution; it’s much more likely that they purchase another vendor’s solution. The other vendor’s efforts to increase the buyer’s switching costs will then make it difficult for you to get that prospect at a later date.

As early adopters, your first clients get to help you decide which 15% of the hundreds of possible features you actually need to build. While a market is much bigger than a handful of early adopters, some effort towards satisfying their needs is warranted if it can deliver you early references, and especially if the things they need are known needs you’ll have to address at some point in the product’s development.

These benefits carry an important condition: the MVP that you provide must solve the core needs well. Adequate won’t win over prospects with lesser needs, and it won’t convince early adopters to provide glowing references. Prospects will need to be convinced that your solution is already so good, that it’s in their best interest to come along with you for the ride.

Your Turn

Depending on the quality of your execution, the early days of being in the market with an MVP can be both hairy and immensely rewarding. What other benefits or drawbacks do you encounter when going to market with an MVP?


John Peltier is an accomplished product manager and marketer working in the growing technology community in Atlanta, Georgia. John shares his passion for product management by organizing ProductCamp Atlanta, and by writing at The PM Vision.  John is most easily contacted on Twitter at @johnpeltier.