ProductMarketing.com

designing products for customers

Scott Sehlhorst at Tyner Blain writes:

We talk about designing products for customers, getting feedback from customers, focusing on problems, and the differences between requirements and design. I'll wager that every product manager has thought about these things.

Understanding these requirements is a necessary (but not sufficient) component of developing products inspired by your customers.

Are your customers designing your products? Or are they inspiring your designs? Read more in Inspired By Your Customers.

My Will

The more you tighten your grip, the more star systems will slip through your fingers.—"Princess Leia" in Star Wars (A New Hope).

My wife and I realized that our wills were twenty years old and out of date. We now have a bigger house, more assets, more guitars, more jewelry. Our kids are now in their twenties and no longer need a guardian.

So we went to a lawyer who asked us our requirements. Basically, my will is “the kids split it all” but it took the lawyer 85 pages of legal jargon to say it. As I was proofreading the final document, I found a whole paragraph defining the number 30 and I burst out laughing. Clearly this paragraph was the result of a lawsuit. When I complained, the lawyer replied, “But remember, when the will is being disputed in court, the judge needs to understand your intentions—because you’re dead and can’t explain.”

‘Because you’re dead.’ The reason it takes 85 pages to explain “the kids split it all” is because you’re not able to explain yourself when things go wrong. The lawyer is actually counseling you as to the options of what to do with your assets when you’re gone.

Our lawyer asked about other assets such as expensive jewelry and musical instruments. We have both. For the jewelry, the lawyer recommended a “sweet young thing” clause—which sounded pretty compelling to me. Actually, alas, this clause is for Susan’s will: if Susan dies and remarries, Susan’s daughter—not Steve’s new wife—will get Susan’s jewelry. I remarked that I didn’t see how I could attract a new wife without Susan’s jewelry but that just got a frown from both Susan and the lawyer.

But really! Do we have to write this down? Apparently. Look at the families who have been ripped asunder, fighting over family heirlooms. It happens more often than you might think.

Over dinner, I explained the basics of the new wills, that they would split it all, that my daughter would get Susan’s jewelry and my son would get my guitars. After all, my son Chip is a professional musician. He plays bass for a great rock band called The Alternate Routes (Their songs are available from Amazon and iTunes. Download them. Please). It seemed logical that he should get my guitars until my daughter said, “But Daddy, I want one of your guitars.” She doesn’t play but she’s been hearing me play since she was a baby. That makes sense too. Good thing we talked about it.

Then the kids started arguing over which of the five guitars my daughter could have. They both wanted the one I play the most—which is also my best one. It’s a 1979 Martin HD-28 in pristine condition. The disagreement started friendly enough—you know, kind of kidding around but not really—and then it got kind of mean. For a few days it created a wall between them until I solved the problem differently. I found and bought another Martin, a D-35 in pristine condition.

You can specify exactly what you want—but only when you know exactly what you want. Unnecessary detail wastes time and energy. Guessing often makes things worse. A more agile approach usually makes more sense. Don’t try to anticipate every potential interpretation or misunderstanding. After all, if questions arise about your business case, your marketing plan, your market requirements document, or any other artifact, you’re alive! People can ask for clarification.

don't forget the accessories

The PLATFORM strategy is one of the five strategies recommended in The Marketing Playbook by Zagula and Tong. Rather than assuming customers want one-stop shopping, the platform strategy encourages third-parties to extend your product with accessories.

The famous case of dBase III shows how an extensible solution led to an industry full of thousands of VARs actually adding value to the basic dBase III platform. Then, as explained by Rick Chapman in his book In Search of Stupidity, the execs at Ashton-Tate decided to kill the third-party market but instead destroyed the dBase product. The dBase platform created the third-party community but the third-party community ultimately created the success of the platform.

People spend much more on the accessories than for their iPods and Blackberries. Didn't you buy the better headset, the bluetooth, the car mount?

I have a Toyota Camry. It has a nice little cubby with a line-in jack for my iPod. Uh, how do I select songs? Oh yes, open the cubby, remove the iPod, choose your playlist, put it all back in the cubby, and enjoy! Hmmm, sounds like the dashboard designers didn't want anything to interfere with the elegance of their design. It seems that Toyota (and all car manufacturers) would rather sell me rims and sports apparel than a phone or iPod mount that integrates with the dashboard.

Thankfully, the team at ProClipUSA has the solution. They have figured out clever ways to shove a mount into the joints and openings of most car models. First, tell them what car you have and they'll tell you what mounts work; then tell them what device you have and voila! you have a holder for your iPod, your Blackberry, your GPS, your whatever.

You'd think that the car designers would offer these dashboard "extensions" for the most popular third-party devices or perhaps they should set up a partnership with ProClipUSA. Instead they assume a "closed" posture and miss an opportunity.

Should you pursue a platform strategy? You could. You can create a better customer fit without using your own resources. To do so, provide APIs and partnering programs to extend your product without doing everything yourself.

where does design belong in your organization

A product designer is--or should be--a valued member of any product team. Cooper's Kim Goodwin writes,

These days, more and more companies are recognizing that design and innovation are essential to their strategy and bottom line: effective design sells products and services, improves your position in the marketplace, and turns customers into loyal advocates for your brand. If you've gotten your organization to this point, take a moment to enjoy your success! Creating demand for design is no small achievement. Unfortunately, to reap the full benefits of design, you probably still have a lot of work to do on your organization's structure, processes, and culture.

Read more in Where does design belong in your organization?

In 10 minutes...

I'm speaking today at Business of Software 2007 in San Jose. I have 10 minutes to make my case and I've spent the weekend editing and pruning and cutting. Assuming I don't get over-excited, I think my speech is only 9 minutes.

Sometimes a deadline or a hard-stop is a good thing. What would you say if you knew you couldn't run long? What features would you omit if you had a hard ship date?

A fundamental idea of Scrum is to see how much development you can do in a two-week period. Get something done, show it to the customer, repeat. Scrum sprints give the team the satisfaction of completion of something--a form of closure--which inspires the team to begin again. Deliver 100% of something rather than 70% of everything. "Do less more often" is so much more satisfying (and successful) than "over commit and under deliver."

Those who have attended Practical Product Management have done positioning in an hour. Granted, it was a case study product so you didn't care too much but... what if you only had an hour to do positioning for your product? Could you do it? And would the result be any worse than the document you and your team agonized over the course of that all-day off-site you ran? Maybe the one-hour version is just as good.

Arbitrary deadlines can be weapons: dates that are imposed from above result in schedules that no one believes. But more often, deadlines are a good thing. They force us to choose; they challenge us to focus. They give us a marker for completion. They introduce an artificial but no-less-real terminus. What can we do in one hour? What can we finish in two weeks? How much can we accomplish in the allocated time?

What would you say if you only had 10 minutes to do it?

On buying and using

I bought a portable player made by JBL for my iPod. I bought it from a store on the web so I couldn’t really see much except for the one picture of the unit itself. And the experience of buying was fine but the experience of using was deplorable. And now I’m not a satisfied JBL customer. I know it may not be fair or even rational but who said I had to be? Customers aren’t.

For a start, it took about 15 minutes to break into JBL’s anti-theft packaging. I broke a pair of scissors, almost gored myself on a letter opener, and finally resorted to my Cutco shears--they can cut anything. Once opened, the innards spilled out of the floor in a huge mass of plastic and parts. Not really a great first experience. Of course, I’m sure the packaging is designed to prevent theft but I wonder how much theft JBL has from Amazon employees and customers; I’d guess none. But in the one-size-fits-all world, JBL decided that all channels were the same and it was easier for them operationally to standardize the packaging for BestBuy rather than Amazon. 

OK, so I’ve broken into the packaging and have a pile of junk on the floor. That’s when I discover that the transformer for my portable iPod player weighs more than the portable iPod player. And the transformer is huge! No really very portable after all. Nicely, the player also has a remote control but no place to house the remote in transfer. And no case of any kind.

I don’t know; can I return this thing with the packaging completely destroyed? I doubt it. So I’ll put it in the garage for those times twice a year when I’m organizing the hoses and garden tools and want to listen to some Jackson Browne. And tell all my friends to buy the iMotion instead of the JBL. And (believe it or not) I have a lot of friends!

How often, when you buy a product of any kind, are you disappointed? For me, it has to be more than half the time. Horrible packaging. No batteries. A huge transformer. An absolute lack of integration.

I’ve started to notice, really notice, those rare occasions when a purchase is satisfactory. Buying my RAZR from the Cingular store started that way; nothing went wrong, the sales person was knowledgeable, and we encountered no problems during the setup. Only later did I discover that the Motorola software is infamously terrible. I still have high regard for my Cingular store but will never buy another Motorola phone.

My friend Kristin met Kevin, the world's worst sales person, this week. In The customer is always wrong, she writes:

There are two kinds of salespeople in the world. One knows that the customer is just trying to get some questions answered, and does what he can to answer those questions. The other sees the customer's questions as "objections" to be overcome - obstacles to his making the sale and getting a commission.

Does this sound like anyone you know?

The salesperson behaves as if the customer is just plain wrong. During the conversation with the customer he is, by turns, evasive, dismissive, and downright rude as he spits out answers. He is combative during the question-asking process. He interrupts the customer, argues with the customer, and treats the customer like an idiot.

Is that the most that we can expect? That a good buying experience is merely the absence of bad?

One of the Secrets of Market-Driven Leaders is to see the product experience from the customer’s point of view. I don’t think many folks were thinking much about the total buying and using experience.

Are we ready to ship?

The problem with “quick and dirty” is that dirty remains long after quick has been forgotten.--Steve McConnell

Reginald Braithwaite posted this to the Toronto PMA:

Try this experiment: go to an engineer, and say "I don't care, your
career is not on the line, it is more important that we have a
quality product and happy customers. Now: are we ready to ship? If
not, when do you think we will actually be ready?"

Now go to another engineer. Tell her that vacations and weekends are
cancelled until we ship. Tell her that hitting our ship date is the
only thing that matters, slipping dates is for losers. Explain that
we have made commitments in the press and that the President will be
embarrassed and angry is we miss our date. Now, ask her if we are
ready to ship.

Is quality a variable? As Reginald points out, quality is the variable when dates and features are fixed... and careers in jeopardy. Timeboxing is the only solution that I know of that consistently gets good results.

Time is so much less important than we generally believe; urgency is typically in the minds of the vendor rather than the market. So remember, you never get a second chance to make a first impression. Ship less or ship late but don't ship poor.

on precision

Those who cannot remember the past are condemned to repeat it.-- George Santayana

My mind seems to work in a funny way. A program’s quirk got me thinking about precision.

I tend to be overly organized. I use lots of folders to categorize: office, photos, movies, product management, presentations, humor, and so on. For a while I tried cross posting if you will, putting aliases or shortcuts in one folder pointing to the actual document in another. I think it is rather natural to try to categorize items. I know I should just throw everything in My Documents without any organization and let Google find them for me but I don’t. And invariably I end up with the same document stored in multiple places. I found a great tool for searching for duplicate files: zsDuplicateHunter, available for Macintosh, Windows, and Linux. I’m sure there are others but this is the one that I use. It’s amazing to me how often it finds duplicate files even when I think my computer is clean.

But here’s my point (finally). The program uses unnecessary precision. It tells me that the search has 47.6 seconds remaining. Why is the .6 relevant? For that matter, is 47 seconds relevant or even true? Isn’t “less than a minute” more accurate?

I learned about precision back in public school. 1 divided by 2 is 0.5. Period. In this instance, more decimals are not more accurate. Telling me 0.5000000000000 is both irrelevant and harmful, as it implies a level of precision that is not supported by the data.

I see this error of precision in estimating dates for roadmaps and requirements. A developer guesses a man-week of work, which someone translates to five days, and someone else translates to 40 hours. It shows up on a Gantt chart as 40.0 hours. But a week could be two days if the developer gets in the zone and doesn’t encounter any surprises, or it could be a month if the developer gets pulled into a dozen other problems.

I fear that we have an unrealistic expectation of precision from our project schedules. Compare the precision of development estimates to sales estimates. How precise are the numbers in your sales forecasts? What accounts will you close on what date for what revenue amount? No sales person could provide that information. Yet we somehow expect exactly that from the development schedule.

An old estimating joke is this: take the estimate, add one, and change the unit of measure. One week becomes two months; one month becomes two quarters.

A guess is a guess. Let's not attribute precision where none exists. If we track our history of guesses, we can assign a factor of accuracy. Take a look at estimates of the past to see how accurate they were and use this against your future planning. Don’t infer precision without the data to support it.

Different types of goodness

In the world of requirements, (virtually) anything is possible. So given more than can be done, how does one choose?

Bob looks at requirements: different types of goodness:"As I consider a raft of requirements from both inside and outside the organization, I'm struck by the motivations behind them. Some features are suggested because 'they'll make money'. Others because 'they complete the product'. Still others 'are really, really important to customer x'. Competitors dictate some, preferences of developers others, and executives still others. The list of sources is as long as my arm, which truth be told, is rather on the longish side."

An old Danish proverb states: He who builds to every man's advice will have a crooked house. As Bob points out, choice involves focus--focus on a segment, focus on a persona, focus on a set of problems for a persona in a segment.

The more we listen to everyone, the less we actually seem to accomplish for anyone. The question for your next MRD is what type of customer do we want to delight?--and who are we not going to focus on, at least not this time?

The real secret to success: a loveocracy

Kathy Sierra explains the conundrum of Buying and Using criteria in The real secret to success: "The secret is simply this: you have a much better chance for success when your business model makes what's good for the users match what's good for the business, and vice-versa."

There are certain features in your product that must be present or no one will buy it; these features are buying criteria. Features like a camera in your phone. Sales-oriented companies tend to be really good at loading up their products with buying features. But what about the user? If the end-user customer doesn't use it--or doesn't like using it--you won't get renewals and referrals. Engineering-led companies tend to focus on using criteria to the detriment of buying criteria. As Kathy points out, we need to find the right intersection between both to get the product both bought and used.

Joel Spolsky pointed this out in a different context. Buyers requested the option of custom fields so they could tailor the product to their existing environment. He writes, Historically, I am opposed to custom fields in principle, because they get abused. People add so many fields to their bug databases to capture everything they think might be important that entering a bug is like applying to Harvard. End result: people don't enter bugs, which is much, much worse than not capturing all that information.

Joel knows that offering a bunch of custom fields will make the product more difficult to use and he’ll lose renewals and referrals. The solution is to recognize the source of the request: is the idea coming from buyers or from users? Will people buy without it? If not, can we implement it 'skinny' so that it won't mess up users?

If we listen only to the buyers, we end up with a Zune instead of an iPod. But if we listen only to the users, we'll never get the thing sold in the first place.

Which features in your product are buying criteria? Which are using criteria? It's the intersection between the two that results in a product that people love.

Setting priorities

When everything is a priority, nothing has priority. But, according to Sage Software product manager Dave Jones, a modified version of a technique developed more than 20 years ago by Japanese engineer Noriaki Kano can quickly and easily help you sort through long lists of customer requirements and prospective enhancements to help you decide which features really need to be first in line. Read more in Setting priorities at the Product Strategy Network.

using ROI for prioritizing requirements

Return on investment calculation is critical to using ROI for prioritizing requirements. Tyner Blain offers five tips to help you when calculating return on investment. Also check out the links to how to forecast return on investment by estimating costs and predicting benefits.

"It just worked."

My daughter bought a new printer, plugged it in, turned it on, and it... worked. She was so surprised that she called to tell me. Now, granted she has a Mac which explains much but why is it such a surprise that a computing device just works? Shouldn't things work by default? Are your customers surprised when their experience isn't painful?

Likewise customer service. I've become an incredible procrastinator; I avoid interacting with any vendor in any form other than on the web. Calling their support or visiting the store is just too painful--it's just too time-consuming. I had a billing problem with my phone service for 18 months. It was only $5 a month and I figured I was ahead. Even now they have no idea why I canceled nor have they attempted to find out. No follow-up call; no email inquiry.

And then there's my son's Volkswagon GTI. The windows fell off when he was driving. The windows... fell... off. The dealer said, "Yeh, that happens sometimes." That happens sometimes?!?!? Good grief. While they fixed the VW they loaned us a Toyota; we liked it so much that we bought a Camry.

The contract isn't the end of the deal. The deal isn't done until the customer is satisfied. A loyal customer is our ultimate objective. Jim Foxworthy will be exploring this idea in more depth in his webinar on January 31.

Dreaming in Code

Ansel Adams wrote, "There is nothing worse than a sharp image of a fuzzy concept." And such is the case with the Chandler project. After four years of development, they have delivered only a 0.6 release with no general availability in sight.

In Dreaming in Code, author Scott Rosenberg follows a group of programmers tasked with creating a new product over a three-year stint. Along the way the book explores disciplines in development (and the lack of), the history of computing (particularly its truths and folklore), and explains why software engineering isn't a science but an art. A common misconception even among developers is that software is similar to construction when, as becomes clear in the book, developing software is more like cooking. Programming methodologies are as plentiful as cookbooks but both are limited by the realities of artistry. A chef can make miracles from a pantry full of ingredients; a cook cannot.

If you're involved with a development team as a product manager or marketer, there is much here that will illuminate your team's dysfunction. Rosenberg reintroduces us to concepts that have been known since The Mythical Man Month and The Soul of a New Machine but apparently not understood, remembered, or believed. Strongly recommended.

Use scenarios from start to finish

The use scenario may be the most important artifact of the requirements document. They go by many names depending on your company's nomenclature: goals, tasks, usage cases, whatever. The use scenario provides the details of the question "what is the customer attempting to accomplish?" Or said another way "Explain the entire experience from beginning to end."

I have a personal blog--updated information about what's happening with me, my family, and especially my son's band The Alternate Routes. I use the blog to update my extended family and friends without having to send emails to all of them. I frequently want to post a picture in the blog, which shouldn't be hard but actually is. Here's what I used to do: resize and copy the desired picture to a shared folder on my Mac that was synchronized with my .Mac account on the web; then I would link to the picture in my public folder which actually involved using an undocumented URL. It was convoluted but easy enough once I figured out how to do it. I later found that I could accomplish the same thing a little more easily via Flickr but it was still rather convoluted. Nowadays I add the picture to my photo program, which can export to Google's PicasaWeb. Then I click on Embed and PicasaWeb generates the HTML necessary to incorporate the photo into a blog post. Photo resizing, transfer to web, and code-links are all easily done in three steps. If I managed the blog with iWeb (which I don't for other reasons), it's even simpler: drag and drop the picture onto a placeholder. That's it.

What I've been describing are all of the individual tasks necessary to achieve my goal: I want to include a photo in a blog post. Use scenarios explain "Steve wants to have a photo in his blog post." Or perhaps "Steve has taken a dozen pictures of the winter storm. He wants to put one of those pictures on his blog with a link to the collection of pictures."

Instead of saying "the user might want to do" this or that, a use scenario is a specific, illustrative situation. And thus, keeps us from the edge cases of the implausible and from the vagueness of non-specific.

The American Cancer Society defined their use scenarios extremely well; they followed the transaction from the beginning to the end. My office made a donation recently in memory of a family member. The American Cancer Society sent me a notification in the mail and included a ready-to-use Thank You card with a return envelope. Beautiful. Think this through. After a funeral, the bereaved family gets dozens, perhaps hundreds, of memorial gifts. As with a wedding, etiquette requires that you acknowledge the gift. But while a wedding is a period of great anticipated joy, a death usually is not anticipated and certainly not joyful. While the wedding bride may not be completely thrilled with writing hundreds of thank-you notes, a bereaved family after a funeral must dread it. The American Cancer Society has made it simpler to pen a short note and get it in the mail without all the drudgery of addressing the envelope. They looked at the gift from the standpoint of the 'customer' and the customer's usage. After the giver or 'buyer' transaction was complete, they also helped the receiver or 'user' with their part of the transaction.

We get so caught up with tasks that we miss the goal; we get some involved with buyers that we often forget the user. What is your customer trying to accomplish? Write some use scenarios from their point of view and from beginning to end, and you'll be delighted with the outcome.

6 Tips To Double Your Requirements Interview Effectiveness

To be successful at interviewing, we have to first understand how to interview our experts. This understanding allows us to define our approach, plan, and follow-up after the interview. Having a good framework for the interview is neccessary, but not sufficient. We also need to be good listeners. Being a good listener encourages our interviewee to answer our questions more comfortably and openly. But to be truly effective, we need to do more than that. Read 6 Tips To Double Your Requirements Interview Effectiveness from Tyner Blain.

Writing Correct Requirements

Scott Sehlhorst of Tyner Blain updates Writing Correct Requirements:

We ran a series called 'Writing Good Requirements: The Big Ten Rules' in May 2006. The original series started with a summary of the ten rules to writing good requirements, and then we followed up with ten articles with details of each rule. And now we add another one--writing correct requirements.

Read Writing Correct Requirements plus the entire series of articles on writing requirements.

on Bad User Interfaces

LeeAnn pointed out these Golden Rules for Bad User Interfaces from SAP Design Guild:

The SAP Design Guild Website is full of guidelines and tips for good user interface design, and it's not the only one on the Web. Nevertheless, we see examples of bad user interface design everywhere--many more than users would like to see. As people like to do just the opposite of what one is proposing, we thought that it might be a good idea to promote bad user interface design. Therefore, we collected "Golden Rules for Bad User Interfaces" on this page--please help yourself (and do the opposite). We started this page with ten rules and are continually expanding our collection.

Software Development's Evolution towards Product Design

Some product managers spend more time designing products than they should. If you're drawing screen samples and logic flow, you're not writing requirements, you're specifying design. Check out On Reqs and Specs to understand the difference. Product design is a skill! Hardware is designed by an industrial designer. Why isn't software?

One such designer comments: Occasionally, some poor fellow at a dinner party makes the unfortunate mistake of asking what I do for a living. My initial (and quite subdued) response is that I help design software for artists. Then comes the inevitable question, "Oh, so you are a programmer?" A gleam appears in my eye and I no longer feel obligated to blather on about the rainy weather. With a great flourish, I whip out my gold nibbed pen and draw a little diagram on a napkin that explains concisely how modern software development works. In the grand finale, I circle one of the little scribbles buried deep in the entire convoluted process and proudly proclaim "And that is what I do!" This admittedly selfish exercise usually keeps everyone involved merrily entertained until dessert arrives. Read more about software design in Software Development's Evolution towards Product Design.

Lights, Camera, Distraction!

Allan discusses the conundrum of buying versus using criteria in Lights, Camera, Distraction!

"That's when it hit me. I had fallen victim to one of the classic product management blunders. I focused so heavily on comparing specs, performance indicators and review data that I forgot to take into account one of the most important factors of all: How will customers use the technology?"