Posts Tagged ‘Experimentation’

Mmp

MVP (Minimum Viable Product) – the minimum amount of features needed to validate the business hypothesis with target customers.

MMP (Minimum Marketable Product) – the minimum amount of additional features on top of MVP which will allow marketing to start growing the product.


Validated learning is one of the five principles of the Lean Startup method and the MVP technique aims to test the business hypothesis. MVP was introduced in 2001 by Frank Robinson but popularised by Eric Ries through his book The Lean Startup.

Since startups tend to work under conditions of extreme uncertainty with limited resources, validating the hypothesis with target customers early in an efficient way using a prototype, wireframes, surveys or marketing material becomes even more important if it is to avoid the scenario of spending months or years building a product which customers don’t need or want (does not have product/market fit).

Achieving product/market fit would involve multiple iterations on the MVP based on target customer feedback, but once the product/market fit is validated it’s time to build the product for real and head towards an MMP by adding features to enable marketing to start growing and scaling the product, with the first set of additional features usually focusing on MarTech and improving the core customer experience.

Now, with an Agile mindset of iterating frequently based on value, it makes the MVP technique similar to Agile product development – building a product that customers need, want and loves by frequently talking to customers/target customers and we only need to look at three of the twelve Agile principles (also introduced in 2001) to see this:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Simplicity–the art of maximizing the amount of work not done–is essential.

Welcome changing requirements. Agile processes harness change for the customer’s competitive advantage.

Because of this, I prefer to use a broader definition of MVP: the minimum amount of effort needed to learn. This is because you can apply the MVP technique (Agile mindset) to a multitude of scenarios outside of launching a new product at a startup where you get the same benefits of reducing wasted money/effort/time by learning sooner rather than later, whether it’s a:

  • New Product – validate before building the whole product
  • New Feature – experiment rapidly before building and rolling out the full feature
  • New Process – being inclusive/gaining feedback before a full roll-out
  • Retrospective – ensure teams are empowered to make changes before having retros
  • Complex Solutions – start discussions early with assumptions before waiting for concrete answers
  • New House – view before purchasing
  • New Job – research/interview before accepting a job
  • New relationship – dating before marriage
  • New Car – test drive before purchase

Start small and fail fast!

Adding a new feature to an existing product is the most common scenario where you can use an MVP approach, but also where it’s most common for businesses to spend months building a new feature that turns out to be low value to customers. Similar to a new product, it’s important to validate new features where the projected value is uncertain by building a lightweight prototype/wireframes to validate with target customers when conducting interviews.

Saying this, if you have qualitative/quantitive data which gives high confidence that solving the problem will be valuable and time to market is important, then it’s equally effective to just develop and go live with the basics you need for the new feature to function at the right quality, then iterate in an Agile way.

When there is uncertainty, break it down, start small, test and learn quickly and it’s surprising how much easier and efficient the problem is to solve.

With tools to easily conduct remote customer interviews (UserZoom, Lookback.io), A/B testing (Firebase, Maxymiser) and prototyping (Sketch, Figma), it makes it easier more than ever for empowered product teams to efficiently conduct experiments to validate that the solution will solve the problem.

A thought-provoking read which explains the impossibility of predicting a certain future, but using #experiments, working together and staying open-minded results in a more probable future.

Remarkably this book was written just before the Covid-19 pandemic!

Even though futures are impossible to predict, by having shared, passionate guiding #principles or an inspiring #vision can increase the chances of reaching our goals even with extreme uncertainty, where we only need to look at how art and cathedrals are created as evidence of this.

The book touches on how traditional management is addicted to masterplans and want safety and certainty, not creativity and risk that come with experimentation, which as a result constrains their chance to map a safer future. This section reminded me of Waterfall vs. #Lean/#Agile.

More automation is a common prediction of the future, but Margaret explains that this comes with a risk of falling into a trap: more need for certainty, more dependency on technology; less skill, more need. The more we depend on machines to think for us the less good we become of thinking for ourselves.

“Making the future is a collective activity…the capacity to see multiple futures depends critically on the widest possible range of contributors and collaborators.”