Better Product Managers, and Product Management

I really enjoyed this cautionary blog post yesterday:

We were going to build the coolest tree house around. It was going to be 10 feet off the ground at floor level and have 120 square feet of space under roof… You’ve probably already guessed that we did not, in fact, build the Minimum Viable Tree House.  – Christian Wyglendowski, The Minimum Viable Treehouse

One of the comments caught my attention because it highlights a debate that I’ve seen going on in the startup community:

“under the current popular interpretation of MVP as promoted by Eric Ries, the sketches were the minimum viable treehouse”

Well… yes and no.  Calling anything a “minimum viable product”, in some ways, allows us to fall back into the familiar trap of writing a bunch of requirements and then building a bunch of stuff.

Maybe we should reassociate MVP with Minimum Viable Process, to emphasize that this is an ongoing, iterating cycle that never really allows us to rest in our comfort zone.

Minimum Viable Process Step 1: Validating Demand

The blog post author started with sketches for the product (treehouse).   That WAS the first minimum viable product, in that it successfully validated that there was a market interested in the product.   Sketches were drawn and the kids agreed that they wanted a treehouse.  (They could, after all, have said they’d rather just have a Nintendo DS.)

The problem is what comes next.  Having validated the initial demand, the next iteration should have been another small step.

Minimum Viable Process Step 2: Identifying the Minimum Viable Feature Set

The next step should be another Minimum Viable Product, this time with a minimum viable feature set.   In other words, with just enough “stuff” that the target market could actually do something.

This is hard.  It’s so exciting just to HAVE a prospective customer and to see THEIR excitement, that it’s tempting to just ask them for all the features they might ever want.   You may not even have to ask – they may come to you with lists of options and features and configurations.

The author let the target market do their own sketches, which were probably very cool-sounding but had little to do with the target market’s existing behaviors and needs.  And it wasn’t because they were kids – most people are not very good at identifying, let alone articulating, the features that they will use and be delighted by.

This is where observation (or “ethnographic research”, to use the fancy term) comes into play.  As the initial treehouse sketches were created, the author could’ve spent some time silently observing the target market for their existing behaviors.

This might’ve yielded observations like “target market likes being in small spaces”, ”target market does not mind dirt, darkness, broken objects”, and “target market frequently changes style and format of play”.

A good product manager would follow up those observations with a couple of hypotheses, like:

• “target market’s primary desire is for a place where adults will not go (either due to size constraints or squeamishness about cleanliness)”.
• “desirable space for target market must be simply designed so that it can accommodate multiple styles of play”

Sometimes it’s possible to validate those hypothesis through asking the target market, but often they need to get their hands on the real thing to provide the feedback you need.

Minimum Viable Process Step 3: Releasing the (Totally Embarrassing) Minimum Viable Feature Set

Ironically, in this case the creator and the original stakeholders DID actually identify the minimum viable feature set.

“Papa built our last tree house in a day!”, my oldest said.
“Yeah, but that tree house was a couple pallets and a ladder”, I replied.

Exactly.  A couple pallets and a ladder, available within a day, was the minimum viable feature set.  3 features: something to sit on, up high, ready ASAP.

You should build that — something so crude that it embarrasses you as a product manager or engineer — and put it in front of your market.

Since you’ve validated the desire for a treehouse, you know they’ll use it.

Minimum Viable Process Step 4: Repeat

And maybe two days later, they’ll come tramping into the house and say “the treehouse sucks” and you’ll ask why, and they’ll say “because it doesn’t have X”.

And then you ask how it would be better by having X.  And then they say “because then we could do Y”.  And then you build something that helps the target audience to accomplish task Y.  Which may or may not be the exact feature they requested, but it solves the correct problem.

Seriously, Why Can’t We Just Listen to the Customer?

I’ve heard a lot of people who try and jump from Step 1 to a full product: “Now I’ve validated my original idea and found customers, and guess what?  My customers know exactly what they want!  I’m going to spend 10 weeks building it and they’ll be so happy that I listened to them!”

There are definitely times when the customer is the expert and you aren’t.  They know what they need, and if you want to be successful, that is what you will build.   There are also (many more) instances where the customer doesn’t know what they need.

How do you tell the difference?  By understanding why.  If you don’t fully understand your customer’s existing behaviors and what factors are important to them, you will not be able to tell when a desired feature is incompatible with them.  And if you don’t know when features are incompatible with your users’ behavior, you won’t know when to say “no” and you won’t be able to say “no” effectively.

Let’s look at a couple of the features built into the treehouse:

Skylights: They provide light and make a room feel open, airy, spacious.  These qualities are highly desirable for adults, but not a priority for kids.  In fact, they’re actually a detriment — how can you pretend you’re in an underground cave or vampire’s lair with all that light streaming in?

High ceilings: Desirable for adults, who are taller and don’t like hunching down to fit into small spaces.  Not required for 4-foot-tall stakeholders.  In fact, if the objective of the treehouse is a “kids only” space, why would you want adults to fit inside?

Understanding the psychology of your customers would allow you to push back on these requirements in a way that gets your stakeholders to agree.  “High ceilings, huh?  Do you really want Mom to come up here and hang out with you?” “NO!”

So, there’s no ONE minimum viable product.  You can’t identify one thing and then stop talking to your customers and go build.  Because you’re not really building a product – you’re building an environment that supports increasingly educated guesses.

It’s uncomfortable to not have a “stopping point” – but it’s a lot better than watching that treehouse sit empty week after week.

Did you like this post? Tweet it! Stumble This Post

Category: Execution   Comment: Add A Comment
Trackback URL: http://www.cindyalvarez.com/execution/maybe-we-should-call-it-minimum-viable-process/trackback/