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.

Popularity: 3% [?]

The recent press about Mint’s acquisition and the “Good-Enough Revolution” has gotten me thinking that there’s an emerging pattern here that more startups (and established companies!) should be capitalizing on.

The Formula

1. Look for markets where the existing solution is incredibly powerful but people dread using it, or feel stupid using it because they haven’t invested enough time in learning how. 

   You’ll recognize these when you repeatedly see people look sheepish and mutter, “I know I should do X…” or “It’s probably really simple to do X, but I just can’t figure it out…”

2. Define the Minimum Viable Product.  What’s the smallest set of features in this problem that people absolutely need to complete?  

   Look for the offline alternatives to the market-leading software solution – for example, what are the bill payment behaviors for people who don’t use online bill pay?  Circling dates on calendars, adding up numbers on scratch paper, sticking envelopes in the mail…  (In some cases, the MVP may not be much smaller than the existing solution, but just contain totally different features.)

3. Build an intuitive user experience that aligns with the tasks users most need to do.  Remember that this is an activity that people sort of dread, so make it beautiful!  Make it dead-simple.

    People should feel reassured using this new solution.  They should feel like it’s preventing them from making mistakes.

Some Examples

• Mint (Quicken does everything you need in personal finance. It’s also bloated and overwhelming.)
• TurboTax (For most people, doing your taxes by hand isn’t rocket science. But it leaves you with a looming sense of dread and fear that an honest mistake will send the IRS pounding on your door, audit forms in hand.)
• Flip (Hand-held video recorders have been around for years, but most people still don’t know how to share that video with Grandma in another state.)
• BaseCamp (Microsoft Project has every feature imaginable. It’s also so complex that, reportedly, even the internal Microsoft team working on Project doesn’t use Project for their project management – they use Excel.)
• PayCycle (ADP and Paychex are probably the right choice for larger companies with more complicated payroll options – but total overkill for micro-businesses.)
• Twitter* (Blogging is a big time investment. A forced 140-character limit frees you to share thoughts and links without feeling the pressure to be super-eloquent.)

* I include Twitter because I know a lot of really smart people that I’ve learned from because they use Twitter when they could never invest the time in blogging.  They haven’t invested in the “intuitive user experience” part at all, though – for new users, it’s totally unclear where they should start.

Why More Companies Aren’t Doing This

I call into evidence a quote from a couple years ago, when a friend was talking about FreshBooks:

“What a stupid idea!  QuickBooks has the highest Net Promoter Score of practically any software out there! People LOVE QuickBooks!”

People who have already invested in using the existing solution are often happy with it.  They’ve forgotten the steep learning curve. If you interview them, they’re much more likely to ask for additional features than to think about how the system they’re used to could be changed.

Your advisors and friends are likely to warn you off this path.  Why would you deliberately choose a smaller set of functionality?  At best, they warn, you’ll steal 1-5% of the market leader’s users – that’s not enough for an interesting business.

The trick is that, while you are entering an existing market, you will probably need to define a mostly new customer base.

(I don’t know, but based on Yodlee experience I’d be willing to bet that a very high percentage of Mint users are NOT ex-Quicken users but people who had NEVER used personal financial management software before.)

This means you need to find non-users, thoroughly understand their needs, and validate that there are enough of them, feeling enough pain, and enough willingness to spend money on their problem.  This takes a lot of legwork, and there are no “let’s check the Forrester research” shortcuts here.

Now, Go Execute

and when you’re successful, throw me a few shares, eh?

Popularity: 12% [?]

What’s your technology zeitgeist?

Sure, you’ve put together short-term and long-term product roadmaps, you’ve done SWOT analyses against your competitors, and win/loss analyses on sales efforts.  But there’s another major factor affecting your product’s chances at adoption and eventual success: the current technology zeitgeist.

By this I mean: the collective effect of people’s attitudes towards technology, usage patterns, access, expectations, past problems, what they’re reading in the mainstream news and hearing from their techier friends, what is socially acceptable.  All of these are constantly evolving, and it doesn’t take long for a tipping point to occur where a strongly-held belief from six months ago is now no longer relevant.

How is this critical to product management?  A good percentage of our requirements are actually assumptions.  We assume that, without feature X or rule Y, our product cannot be viable.  We assume that adoption policy Z will repel customers and prevent adoption.

A small example: Nine years ago, my products had a requirement to be fully compatible with Netscape 4. At the time, it was a correct assumption that eliminating support for that browser would make our products unusable by a significant percentage of Fortune 500 corporations whose IT departments had standardized on that browser. 

A bigger example: Eighteen months ago, one of my current company’s social applications was designed to mask individual usernames.  At the time, it was a correct assumption that the average consumer would consider it a massive privacy violation to have their name appear next to articles they’ve read.

Today, both examples border on the ridiculous.  But when you’re in the middle of managing a product, it’s easy to forget to re-assess these assumptions.  Even if you’re in an agile environment where there are releases monthly or semi-monthly, it’s easy to continue working under the rules of an outdated technology zeitgeist.

Make it a rule – mark it on your calendar – to re-assess the landscape quarterly.

That’s right – even three short months is enough time for certain elements to reach a tipping point.  (Personal example: within the 3 months after the iPhone release, I’d estimate that the percentage of my friends with mobile web access went from 20% to 90%+.)

How to Do a Technology Zeitgeist Assessment

Each product manager will have their own sense for how important individual elements are to their product’s adoption.  But these are general guidelines that (to some degree or other) affect pretty much all products.

Ask two questions: Has this changed? and Is this gradually changing? in the following areas:

• Concerns about personal privacy / What’s acceptable to share publicly?
• Expectations around how companies protect data privacy
• Technology access: broadband, CPU power, hours/day with Internet connection
• Comfort levels with using your type of product (novice to expert ratio)
• Where people are finding out about your product
• What factors influence the decision to use/not use your product
• What are consumers willing to sacrifice for convenience
• How fast/dynamic/personalized do consumers expect products to be?
• What technologies are supported by the lowest common denominator of computer/browser/Internet connection?
• Expectations around visual design (what’s “professional”/”fun”, etc.)
• Age of your average consumer
• Location and frequency that your average consumer uses your product

I’m sure there are more out there!  Please add your “technology zeitgeist” elements in the comments.

Popularity: 1% [?]

This post is Part 1 in a series.

If you work for a tech startup, you know that the smartest thing to do is “fail fast” - devise a hypothesis, figure out the quickest way to validate it, and, when it doesn’t work out, scrap it and learn from it to move on to the next, improved hypothesis.

“If you review your first site version and don’t feel embarrassment, you spent too much time on it.” – Reid Hoffman

“If everything seems under control, you’re just not going fast enough.” – Mario Andretti

Everyone loves to talk about “fail fast”, but how do you do it?   Ideally, you started out with a specific metric or criteria to meet – but not everyone planned that well from the beginning (and some of us inherit others’ poorly-laid ‘plans’).  How do you recover and move on from there?

How do you know that what you’ve got now isn’t working and isn’t salvageable?  Here are 5 signs that it’s time to move on:

(more…)

Popularity: 5% [?]