Technology Notables – Part 4: What features require notables?

Earlier articles in this series are available here: Part 1, Part 2, Part 3.

Figure 1 shows a 2×2 matrix of use benefit superiority vs. use-model maturity. The X-axis benefit superiority is a combination of features that have high value in use for customers or channel members, and ideally, some kind of competitive advantage.  With the Mopier 320 usage measurement, measuring toner was a big value add for the end customer, the competitive advantage was that we gave copier resellers a simple program that let them configure and monitor the device for their individual programs.  Our competitor at the time was Xerox and the mentality they had was apparently that only the mother ship could know about toner coverage.

The Y-axis in Figure 1 is use model maturity.  Toner coverage measurement was not a use model that copier dealers knew anything about.  They had strong economic interests to learn about it (benefit superiority) but no existing paradigm for managing variable toner costs as part of pay for page contracts. Writing notables is most effective when you write about strong economic needs that people know well, and non-existent use models.  So the sweet spot for notables is high benefit superiority and low use model maturity.

Figure 1

In Figure 1 the sweet spot is high and to the right.  Writing a notable in this quadrant, allows you to hypothesize how the benefit will fit into the customer’s life, and then test that hypothesis with real customers.  Because you are focusing on just one feature, your questions to the customer are clear.  Because you are focusing on a high benefit superiority target, your questions are interesting to the customer.

Notables in high benefit superiority/low use model maturity operate like sonar.  Each notable is a focused *ping* sent which then bounces off customers, channel members, users, etc. and brings back an echolocation signal.  This isn’t the best market research methodology in the world, but it is better than nothing.  The nothing alternative is to throw the product out into the market and watch what happens.

In theory you could write notables about every new feature in a software release.  In practice, there is not enough time to write about everything.  So, to optimize your effort, start with potential big features, and then work your way down in estimated impact.  Everyone likes having notables on big features or small, because notables are so much clearer than advertisements.  But be careful.  If you write notables on small features and say they are big, you are lying and will kill the signal to noise ratio that few notables on big features establish.

Generating hypotheses about customer need, and then testing, is how a software marketing function can iteratively articulate customer needs from an incipient state, into a want for a specific feature.   Figure 2 displays a wonderful idea from a Gordon Davis IBM Systems Journal article.  The basic idea is that the uncertainty of requirements should determine the research strategy used to gather requirements.

Note that Pleo, the animatronic dinosaur from Ugobe is placed at a pretty high degree of uncertainty.  With 14 motors, two Arm 7s and a bunch of little Hitachi controllers, Pleo was very complex.  It was more computer and artificial intelligence system, than toy.  And in the toy market, Pleo was by far the most complex toy in the competitive arena.  Pleo broke a lot of toy industry rules.  Pleo didn’t really have a precedent in the market.  So Pleo was inherently high uncertainty.

High uncertainty means that marketing for Pleo need to prototype.  Marketing needs to generate hypotheses about Pleo’s functionality and then test them on real customers, real context, real use situations.  Notables are probably not going to help a situation like Pleo’s where there are no use models, and the core need being filled is emotive.  One approach that might help in this situation would be to build a usability lab into the software organization writing code for Pleo.  Scheduling usability test every week and exposing software engineers to the cheers and jeers of customers using their code could give enough information to the programmers about the customer, to allow the software people to emulate the customer in their minds.

I don’t know how Pleo’s market research was conducted (if any).  But most organizations with market researchers suffer from over-professionalization and obsessive focus on low-uncertainty market research tools (i.e., “Asking” to the exclusion of all other research strategies).  High veracity prototype feedback is thrown out by this kind of pathological professionalism.  There appears to be no established body of high-uncertainty prototyping research in academic marketing.  Research that would correspond with say, agile software development.

While sending notables to customers for feedback, is an asking strategy.  Writing the notables is inherently a deriving strategy.  To derive how the customer will really engage with a feature, you learn as much as you can about the feature and customer, then you simulate both in your head.  So dealing with uncertainty can be accomplished by forcing yourself to inductively infer what will be going on when this feature engages the customer.  Market research before product release, always works from left (asking) towards the right of Figure 2.

With the Mopier 320 usage page, HP was able build prototypes usage pages with Microsoft Word months before the firmware was written.  These MS Word prototypes were shown to copier resellers in face to face meetings.  These meetings led to refinements in the design and then PDF documents were sent to other copier resellers for more feedback.  Once you get feedback across a customer community like copier resellers, that is focused on a single feature, you begin to develop an intuitive understanding of the range of variation in customer requirements.  HP didn’t have real context, or real purchase data.  But with real customers and a close enough to real prototype page, we were able to rapidly build an understanding of our customers and their economic challenges.

Lessons learned:

1. The more professional your market research, the less it can help you with high uncertainty features and products.  You can test this generalization by showing this statement to the most professional market researcher you know.  When they hiss and sputter in response, you will see that what they lack in content assessing high uncertainty requirements, they make up for with pomposity.
2. Incipient use models are a gold mine.  If you take initiative and simulate how the world should operate in your mind, and then test your assumptions on customers, you will rapidly take control of how the value of that software feature is captured.    With the usage page feature and notable, HP was able to reposition the Mopier 320 from being a weaker feature set, to the strongest economic value.
3. Don’t plan on writing notables for ever feature.  It is good to write them for high value/incipient features, and for features you are likely to advertise (in order to get the back story solid before writing the ad copy).  In every product, there is an under-promoted feature.  These sleeper features benefit greatly from writing notables.  Customers buy stuff to solve problems.  But they appreciate additional value that is pulled from products they already have.

Technology Notables – Part 2: Exhaustion v Numbness

This is part 2 in a series of blog post on technology notables.  Part 1 is available here.

The big truth about new product features is that they are exhausting to end users.  End users are worn out by the day-to-day battle of keeping their jobs, keeping their companies alive, and mentally managing the stress of getting things done. The average small business owner has a very limited capacity to incorporate new technology.

But cognitive overload isn’t the whole problem.  Even more important is the product-cycle.  Every business has some kind of product cycle.  In the beginning of a product cycle, a new initiative or product is specified.  Next it is designed and taken through the process of readying it for market.  Product cycles hamper technology adoption, because once you choose a technology and start a product cycle, you can’t change the technology without restarting.  New features can only be helpful to customers, if customers learn them before their next product cycle push.

Software organizations don’t realize how limited customers are in what they can use.  Software organizations assume the more features the better.  Only a few breakthrough features are needed to justify shotgun software development.  So, software organizations develop long lists of new stuff that the end user has no clue why s/he should care about.  In particular, software organizations working from open source, are prone to this habitual product development.   Release after release lists of software feature get longer and longer.  Release after release, these lists drive a wedge between software companies and customers.

It is not that software companies over-promise and under-deliver.  It is that software companies who are not daily in contact with customers become feature numb.  And feature numb software organizations do not know the difference between a big and a small features.

To a customer, a big feature is worth taking the time to understand and then, taking much more time to implement and harvest the feature’s value in use.   To a customer, a small feature is just noise.  That is: “If new features are small, please don’t tell me about them.”  But more importantly: “If this is a small feature, please do not tell me it is a big feature.”  Because, the big small feature lie can and will be held against you.  To a big well-run software organization, a big feature is: (a) a significant challenge to develop, (b) hard for competitors to copy, (c) likely to used by the entire customer base, (d) extends the architecture that is already in place, and (e) a low uncertainty requirement that is well understood.

Feature numb software organizations have leprosy.  They no longer can sense customer-induced pain from the dumb and vestigial features they dump into products.  Without the pain of the cheers and jeers of end users, software development managers begins to manage  with customer myths and self hypnosis.  Recent block buster products and markets become the the only valid target for future development.  Product development and sales both become exercises in extrapolation from the past, and the company marches into the future … facing backwards.

For example, I’m a huge fan of network attached storage, but the latest NAS feature “iSCSI” has exhausted me even before I understand it.  All the NAS companies are pushing iSCSI like Jesus freaks throwing tracts at my face.  As a customer, I have an automatic response to new features dumped over the transom into my life: benign cynicism.   Benign cynicism is where I’m going to make NAS companies pay for telling me small features are big features.   The more they lie, the less I listen.

I admit, this could be unfair to the NAS company.  I may very well need iSCSI.  But, life is not fair, and right now I’m in the middle of a product cycle and I don’t want to hear about iSCSI!   I haven’t got iTunes video streaming working from my NAS yet!  And I’m more NAS literate than average.  Way more literate.  And, by the way, if I have to erase my NAS storage volume to use iSCSI, I declare iSCSI to not exist.

Denial is much easier than backing up and reformatting 3.5 terabytes of data.

Cynics are frustrated idealists.  And even though I’m a benign cynic NAS customer, I’m still a cynic.  So frustrated idealism makes me give up on latent killer features because I’m not listening.  Notables are projectiles for piercing this kind of product cycle and cognitive overload-induced benign cynicism.

Notables follow the theory that the way to every over-taxed stressed out customer’s heart, is through superiority that matters.  It is through understanding the customer, and picking the one feature that the customer can implement in the next year, and explaining your product’s benefit superiority.  And explaining the benefit superiority … enthusiastically.   Notables enthusiastically explain benefit superiority for a few big features.

Notables renegotiate the information deal with customers.  The company says “I realize you have been lied to about small features being big.  In this short page document, I’m going to tell you about a new big feature, that will be genuinely big for you. After you read this document (5 minutes) you will know how this feature will benefit you, or you will know the feature is noise.”

Technology notables over come customer feature exhaustion by the promise of a much higher signal to noise ratio than advertising.  And notables overcome feature numbness, by making software organizations aware that each feature needs a value proposition.  When you think about it, software organizations could do their own market research by writing notables for proposed features, and then listening for the cheers and jeers of users.

Notable Lessons:

1. Notables are a great customer development tool because you write them and send them out of the company, and they give you a feature-specific signal to listen for customer bounce back.  Notables are sonar for marketers trapped inside a company.  Customers will respond to big benefit feature notables.  So will field sales.  So will product managers.
2. Most software organizations are sleep walking on autopilot.  They dump features into products and hope for the best.
3. Feature lists drive a wedge between software companies and their customers.

Technology Notables – Part 3: Verifying Benefit Superiority

Earlier articles in this series are available here: Part 1, Part 2.

Most long lists of software features come from large software organizations that have their act together on the engineering side.  The software features go in, mostly from ideas cooked up by the software engineers, and that are gated by software engineering manager preferences.  In theory, customers have input to software development, but in practice, this does not seem to happen.  My experience with software engineering management and customers, is that the software engineers see the customer’s requests and pedestrian or irrelevant.  Customers see software organizations on the other hand, as  bureaucracies that don’t care.

The best way to isolate the value of features, is to expose them to real customers.  Not just in focus groups or surveys.  Valid marketing information comes from working with real customers, in real contexts of purchase and use, with a real product.  Marketing research in strong software companies, however, is usually a mess.  The focus isn’t on validating customer requirements or the business model for a product.  The business focus is on creating a long term software feature manufacturing engine.  So, the problem for effective marketers in strong software companies, is to take the features in the product, and define value in use, and then find a way to test the hypothesized value in use on the real marketing channel and real customers.

As Steve Blank says, inside the building are opinions, outside the building are facts.  So either we have to get outside the building or we have to trick the facts into finding their way back to us.  Notables are a good way to trick facts into backtracking their way to the company when you are in a large ossified bureaucracy.

So your new product is progressing through software development.  You are in marketing, how can you tell what what the big features in the product are?  Answer: By writing a notables on for the features that are most likely to be big. Each notable you write, has to guess at what the benefit superiority for a feature is.  When you write a notable, you make up benefit superiority from hope, thin air, and economics.  Big features need to be believed in before they are seen, and a notable is how you guide your research into use models, and then articulate belief in a feature’s value.

If your feature makes customers big money or, prevents them from losing big money, doing the math of the feature’s economic value in use will magically paint benefits into your notable.  Economics gets you into the ballpark of a good solid starting value proposition for a feature.  In the notable I wrote for the Mopier 320′s usage page, reflecting back over a decade, I can see today, how I could have articulated the feature’s value proposition more sharply.  But perfection is not the point of a notable.

Good enough is enough.   The usage page notable was good enough for everyone down the marketing channel from HP Boise, to see that the Mopier 320 was on to something.  The Mopier 320 was behind on paper counting technology, but it was ahead because it measured toner use and we were able to work out a way that toner use could be fairly charged for.

The big economic moose on the Mopier 320′s table, was toner.  Toner was a 20:1 cost risk over paper.  Copier dealers knew that they were running open loop to toner costs on printers and copiers.  And they knew that this open loop enabled customers to exploit the copier dealer if the customers used more than 5% page coverage.  The usage notable was not perfect, but everyone could see that pixel counting was a lot better than nothing.

Gilb’s Law is that there is always a way to measure, that is superior to not measuring at all.  Ironically, HP’s engineers resisted calls to measure toner toner use because the pixel counting methodology was “only plus or minus twenty percent accurate.”  Wait, what?  That is, because there was a 40% potential swing in accuracy between pixels and toner, customers were left exposed to a 20:1 toner risk.

Pixel counting as a proxy variable measurement of toner use, shows how Gilb’s law works.  Remember a 100% black page has about 20 cents worth of toner on it.  The average page at this time was assumed to have 5% coverage.  Actual coverage was 6.5% which represented a 30% increase in revenue for copier resellers when they began measuring actual toner coverage.  Without working through the simple math of toner economics, a 40% error swing seemed more important to avoid to the engineers, than an unknown cost swing for customers.  Ratios hide things, writing the notable forced the economic magnitudes and risks into daylight, so that business managers could rebalance the value proposition for toner measurement, correctly for the market.  Copier dealers vastly preferred plus or minus twenty percent accuracy to having their largest variable cost running open loop.

So, given that you are a product manager who is consulted about features only as an after thought.  How can you use a notable?

1. To give a feature, its best shot at finding its benefit superiority.  Given that the feature is already in the product, it becomes marketing job to figure out how to pull value out of the feature by comparing the feature to customer needs and competitive offerings.
   1. When you are drafting your feature’s notable, ask yourself “Who in the world is this feature worth the most to?”  Make a guess, and then …
   2. Construct a day in the life of how the feature affects a user, and do the simple math computing economic value.
   3. Answer the five questions.
   4. Then show the notable to your most unfriendly critics.
2. To put down on paper, the back story of a product so that everyone in the company can work together to do inside-out market research:
   1. Step 1: Arguing
      A product management team needs to argue about what the real value for a feature is.  A two page notable, draws the team’s thinking together.  It provokes the marketing team into telling one another stories about their secret prototype customer.  *Note* individuals in strong software companies unguided by marketing research, will do their own market research by picking a customer that they design features to.  These prototype customers, however, are not shared across functions.  Secret prototype customers are undiscussable, and their undiscussability is undiscussable because for some reason, using them seems “unprofessional.”
   2. Step 2: Converge
      Over successive revisions of the notable, arguments will converge.  And once you have a converged story for the feature, your marketing will be come aligned, and will be more powerful as your organization speaks with one enthusiastic voice about the feature.
   3. Step 3: External test
      Once you get a converged notable that works within your marketing team, then you start showing it to customers, your sales people, your advertising and PR firms, and channel members.  Use the notable to draw the thinking together down your channel, just as it drew minds together inside the company.
   4. Step 4: Hypothesis test
      A notable that has been through arguments and enthusiasm inside your company, when it gets into the hands of customers, will tell you if your benefit superiority hypothesis is true or false.  If the customer isn’t provoked, or empowered, or excited by the notable, you’ve got a vestigial feature, or a small feature.  And this is OK.  Not all features are big features.  Each product is lucky to have two big features.

The purpose of writing notables is to separate wheat features from chaff, and to sharpen marketing of the big wheat features to the point of armor piercing effectiveness.

While working on the Mopier 320 I also wrote notables on JetSend which at the time, was a dying technology.  The usage page notable filled up my voice mail with enthusiastic praise and killed competitor sales.  JetSend excited nobody.  Provoked no field sales or customer responses.   The key product of the JetSend division was the HP Digital Sender 9100c.  And I wrote a notable for the 9100c and it, like the usage page notable took off.  Within months, we had Digital Sending built into the Mopier 320 and all medium and high end MFPs.  The notable did not make Digital Sending happen, but it did articulate clearly why the 9100c was a winner and why the rest of the company needed to adopt the 9100c technology ASAP.

Lessons Learned:

1. Notables are hypotheses for feature value.  If you can’t write a convincing notable, the feature has no value or you don’t know your customer.
2. Value has to be believed to be seen.  Encourage your notable writers to ignore doubt and focus on finding one or two killer attributes that deliver value for someone down the marketing channel.
3. If your notable finds a big feature, you will hear about it from the people you share the notable with.  Even cynical field sales people who you think hate you, will light up when you articulate real benefit superiority.  When they read a notable, they will also say “Wow, I feel like a part of the company again!”
4. Even junior marketeers in a company can trick the current bureaucracy into doing marketing research on big features with notables and a willingness to suck down.