Minimum Viable Product (MVP) is a foundational approach to tech products today, but it’s often misunderstood to always mean technical iterations, to always involve coding and development.

That’s far from the truth!

Experimentation starts long before any developer is involved.

In fact you can use the MVP concept in areas of your company that have nothing to do with code, but could have a big positive impact on your business.

To prove this point, let’s explore the MVP process through the example of something not exactly tech-y. ProdPad used the approach on one of our most popular pieces of brand collateral: The Handy Guide for Product People.

You’ll probably walk away with new ideas for your company and a solid way to test them! But first, we need to cover the basics.

Minimum Viable Product definition

A Minimum Viable Product, or MVP, is a product with the least amount of effort put into it – the least you can get away with, so to speak – in order to test, collect feedback, and learn.

“Doing the least” seems counterintuitive in our modern work culture, but it’s the most efficient and effective way to discover the right product to build.

When building a product, every idea you have is a hypothesis. As part of The Lean Startup build-measure-learn feedback loop, you build the bare minimum of your hypothesis in order to validate it.

If you’re right, then you can put more time and effort into building – you iterate on it and measure again. If you’re wrong, then you’ve saved all that time and effort, you’ve learned something new, and can immediately move to the next hypothesis (or pivot altogether).

The Handy Guide MVP

Minimum Viable Product is a process of experimentation that you can apply to almost any part of your work or business – including free marketing materials, whether they’re designed for brand awareness or concrete lead generation. It’s how we developed our free booklet, the Handy Guide for Product People.

Did it launch as a complete, comprehensive, perfectly designed and polished book? No.

It started out as pieces of scrap paper stapled together. 
We started this in the early days of the company, back when it was just me and my co-founder Simon. We needed a brand play to get people’s attention on ProdPad. Over the years, the Handy Guide has iterated and evolved alongside our product and the business as a whole.

Version 1

You should frontload the testing and prototyping before you ship a product, especially if it’s a physical product. So Version 1 is where the bulk of the experimentation is done, after you’ve identified your problem or goal.

Our goal was brand awareness. Once we could go to conferences as ProdPad, we wanted to leave people with something other than a business card–something with higher value, but not as time-consuming as writing an actual book!

We decided to test something that was cheap and cheerful. So the Handy Guide began as an in-hand booklet with 28 pages.

Build
It was just me testing the content, which was repurposed from ideas we’d write about on the blog. I started with the most broad question, “What things would I want to teach somebody in this guide?” Then could focus on defining the principles of product management (what the guide calls “pillars”) and map it all together on sheets of paper.

Test
I would then show the actual papers to people in my product circle and say, “This is the kind of content I want to create. Is this right?” People would respond with new ideas or concepts I’d left out. They’d suggest quotes or other valuable stuff to include.

Iterate
In those early days, when it was just a piece of scrap paper stuck together, I could experiment with order and structure without upsetting the design. I was interslicing quotations and visuals, adding valuable tidbits and removing other stuff that didn’t work as well.

Learn
All the while, I was trying to figure out–and starting to understand–how it fit together as a prototype. All of this experimentation and research revealed how much space the content needs, and how many pages the guide needs to be.

And most importantly, from the feedback in my product circle, I knew it was worth advancing this guide to the next stage of development.

Versions 2-5

During this phase, iterating from Version 2 to 5, the guide really took shape.

Build
With the bulk of the content settled, we could focus on design. We upgraded to a digital version of the design, but the process was still pretty scrappy. I downloaded a template from the web and edited it myself in Adobe InDesign. I’d do a self-print run just in time for a conference.

Learn
When we’d hand out the guides, I’d tell each person that we’d love their feedback on it. And we got lots of feedback, largely via email. We collected feedback in our ProdPad backlog like anything else.

During this phase, the quality and quantity of feedback starts to shift. The earlier in the MVP, the easier it is to iterate – and the more crucial! You’re sensitive to feedback, because you know the product is probably incomplete. There’s lots of low-hanging fruit and easy wins.

As the versions mature, feedback is less about the core usability of the product. For the guides, we’d hear about a missing comma or a subjective opinion about the branding. You learn how to tell if this feedback is actually important. Does it address a core problem about the guide’s readability, or is it a minor typo or personal preference?

Iterate
We did have to do some release planning when it came time to print a new version! We’d need to understand how much feedback we collected, review it all, implement the worthwhile stuff, make any design adjustments, review the new version, then ship to the printer. We’d have to do all of this by a deadline to get to the conference on time!

Versions 6-7

This phase was more of the same building, learning, and iterating. We leveled up the design and had the guides professionally printed, but we still kept the release efforts as simple as possible. We continued using InDesign and saved the guide as a PDF that we could send to a local printer at a few days’ turnaround.

Version 8+

We went digital, baby! The guide proved so popular that we put it online. Now you can sign up for it on the website, and get a PDF of the e-book in your inbox.

The digital-only offer makes more sense for a few reasons. It’s cheaper and eco-friendly. Updates and iterations are easy to republish. Plus, now we’re able to reach product managers from all around the globe.

Measuring and validating the Handy Guide MVP

Measuring and validating your hypothesis – your idea, your direction, your feature – is a big part of developing an MVP. But this can be a gray area if you’re working on projects that don’t have quantifiable data or user insights.

At ProdPad, we felt that people loved the Handy Guide! But this was hard to validate and track with data because the guides were a brand play more than anything else. So we used our own anecdotal forms of validation:

Now, several years later, we have a solid marketing asset that takes very little resources to maintain, and we’ve established ProdPad as a thought leader in the space. By treating it as a minimum viable product, we could minimize our own efforts while ensuring we produced something super high-value.

The Handy Guide has gone through huge iterations but still kept its original purpose – to help people become great product managers.

The post Minimum Viable Product (MVP) Experiment – The Handy Guide Example appeared first on Product Management Software | ProdPad.