I’m going to pull a number completely out of you-know-where and estimate that a full 20% of time in software companies is wasted on completing tasks to avoid the appearance of flakiness.

Product managers are pretty guilty of this, but they’re by no means the only offenders (and when product managers do this, it’s often because of a corporate culture that encourages it, such as bonuses being dependent on the % of your features that are completed and released.)

Here’s what happens:

• a need is identified – a new feature, a bug report, an inefficiency
• requirements are written and agreed upon
• work begins

– but then something happens.

Maybe further customer interviews reveal that the new feature isn’t really that valuable after all.  Maybe watching your usage metrics shows that the bug – as much as it may irk you – is not affecting your customers’ use of the product.  Maybe that improved database query really isn’t needed at current usage levels.

Whatever the reason, the conclusion should be clear: we should stop working on this.

But we don’t.

“We should just finish it – It’s bad for engineers’ morale to have a half-finished feature sitting around.”  No — it’s worse for morale to have a fully-finished feature released but still just sitting around (and probably cluttering up the UI and generating more customer support costs.)

“We may as well do it now even though we don’t need it yet.” No — when you DO need it, it’s almost certain that your needs will have changed and this thing you built months ago will need more hacking to shape it into a still barely workable solution.

“We shouldn’t interrupt development ‘flow’ to start on something totally different.”  No — ‘flow’ is not valuable by itself!  There’s no sense in building the wrong thing fast.

These all boil down to: I thought this was important -> If I admit that it isn’t, I will lose credibility and look like a flake.

And don’t do the weaselly version, either, where you silently lower the priority on tasks and hope people will forget about them.

Make an announcement: “We are no longer working on X.  Here’s why: we thought it was going to solve Problem Y, but [it actually won't/problem Y isn't actually much of a problem/it will, but problem Z came out of nowhere and we've got to tackle that.]  I’m sorry that we already invested time in this, but I’d rather change course than have us waste more time on something that is not needed.”

I say, flake proudly.  Don’t keep working on dumb stuff.

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.

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?

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.

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:

1. The environment has fundamentally changed. The Hummer had unique appeal, but not enough to compete with the one-two punch of $4-a-gallon gas and environmentalism becoming increasingly mainstream.  Even once gas prices fell again, the damage was done.
2. You’ve captured the market – and it’s not big enough to sustain your business. Lots of successful companies cater to a niche audience.  But to be profitable, that audience has to be willing to pay more than it costs for you to sustain the product/service.  (Rocket science, I know!)  If you started out free, you may not be able to move them to “pay”.  Or a specialist audience may demand feature development and support that drive your costs too high.
3. Your product doesn’t have sufficient adoption to create value. Any product that relies on people – social networks, collaboration tools, knowledge bases, review sites, communities – are virtually value-free until they hit critical mass.   If your product doesn’t encourage viral distribution and low-cost marketing isn’t bringing people in, you’re stuck.  Buying a product audience is not a fast-fail means to reducing risk.
4. The alternatives to your product are substantially cheaper/easier/more well-known. Every product has an alternative, even if the alternative is “do nothing”.  Even if customers agree that your product is objectively better than the alternative(s), there is friction involved in them spending more money, spending more time, or even just choosing a different brand than what their friends are using.
5. You’re competing against entrenched competitors who are better-funded/more well-known/have substantial market share. This means you can’t compete with them on their terms – you’ll need to try something different to create a Blue Ocean for your product.

If any of these are true, it’s time to stop, re-evaluate your market and your customer’s needs, and look for the next experiment – as quickly as possible.  Continuing to improve upon your product may get you incremental gains but at a time, opportunity, and funding cost you can’t afford.

Have you experienced any other sure signs that it’s time to change your product strategy? Please share with us in the comments.

This post is Part 1 in a series.  Read Part 2.

The blunter way of putting it is, no one cares about your great ideas. Because as long as they just sit there, good ideas aren’t any better than bad ideas or silly ideas or ridiculous ideas or insulting ideas.

Free Ideas. Just Add Execution. (Laserlike)

Share your ideas. Doing so will make you feel like you need to go do them, because of the small risk that someone will take your idea now that it’s “out there” and beat you to it. Sharing your idea will expose you to diverse feedback on it. Your idea will get pressure tested.

I’d add to this: if you don’t have any already, find some friends who will hold you responsible for following up on your idea. If you really believe an idea is great, you owe it to yourself to make an investment in it. That may be money, but more often than not it’s just time, research, and a commitment to keep questioning. Figure out what kind of experiment you’d need to run to get a better sense of the idea’s future success or failure. Then do it.

Be that friend: hold other people responsible for their ideas. At dinner a couple weeks ago, a friend of mine mentioned a potential new concept for his business. We discussed it for a while and asked some questions and encouraged him to think more about it – “at least grab the domain name,” I said. He promised he would.

A week later, I went to Discount Domain Registry to check up on him and make sure he’d followed through. (He did.) And guess what? Now I will totally feel like a hypocrite if I don’t follow up on my own projects. It’s a win-win situation.

Your Idea Alone Has No Value (Will Shroter)

It’s not uncommon for a startup company to go toe-to-toe with a much larger company offering a very similar product. On its face, it looks like the startup is at a severe disadvantage…If you were to try to compete against the behemoth on their own terms you’d get crushed. That’s why startups tend to look for the weak spots in larger companies and exploit them.

Look for the unfair advantage. It’s not just for making a business case, but for any situation. What do you uniquely know or what are you uniquely skilled at?

When I started working for a financial software company, I was at a distinct disadvantage in domain expertise. Aside from reading Motley Fool and watching CNBC, I didn’t have a lot of knowledge about the various banking industry players or their customers. But I am good at at-libbing. So I’d open up a product demo with “I’m going to walk through our product from the perspective of a customer – help me out as I go by telling me about your customer.” I’d adapt the story as I got feedback instead of pretending to be an expert.

(I remember vividly presenting to a group of wealth management executives, who pointed out that my sample data had far too few zeroes to represent their audience. “Your customers?” I asked, “Uh-oh, this must be the version of the demo based on my net worth. But the beauty of the product is, it works for me, and it’ll still work for me in a couple decades when I’ve made it to being one of your customers.” They laughed – I breathed a sigh of relief.)

Entrepreneurial Proverbs (O’Reilly Radar)

Sometimes an idea catches hold of you and you find you can’t put it down. Pay attention to that! Just start working on it. Can’t get yourself to do anything on it? Move on.

…Entrepreneurs too often worry about keeping their brilliant secrets locked away; we should all worry much more about springing a surprise on a disinterested market (anyone remember the Segway?)