LLM Book Knowledgebase

Inspired: How To Create Products Customers Love

37 min read

Inspired: How To Create Products Customers Love

Metadata

Highlights & Notes

I’m sure many teams have discovered the hard way: It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.

I therefore put many of the examples on the Silicon Valley Product Group web site (www.svpg.com/examples).

The product manager has two key responsibilities: assessing product opportunities, and defining the product to be built.

but I have long argued that the root cause of wasted releases can most often be traced to poor definition of the role of the product manager in a company, and inadequate training of the people chosen for this role.

the job of the product manager is to define—in detail—the product that the engineering team will build. In contrast, the role of product marketing is to tell the world about this product.

Further, for all but the simplest of products, the role of the product manager as defined here is an all-consuming, full-time job, requiring a dedicated person.

The product manager is responsible for defining—in detail—the product to be built, and validating that product with real customers and users. The product marketing person is responsible for telling the world about that product, including positioning, messaging and pricing, managing the product launch, providing tools for the sales channel to market and sell the product, and for leading key programs such as online marketing and influencer marketing programs.

Remember: It doesn’t matter how great your engineering organization is if the product manager doesn’t give the engineers something valuable, usable and feasible to build.

A good product requires a good user experience. And a good user experience requires the close collaboration of product management and user experience design.

If you’re an enterprise company and you’d like to differentiate your product from your competition, one of the easiest ways to do this is to create a good user experience.

As a product manager, you’ll quickly learn that if you have a good relationship with engineering, then the job can be a great one. If you don’t, let’s just say that you’re in for some very long and frustrating days.

One key to this relationship is for each of you to understand that you are peers—neither position is subordinate to the other. As product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right. You need both. You need to let your engineering counterpart do what he believes necessary to build a quality product, and he needs to give you the room to come up with a valuable and usable product.

  • @sergeiw @pattydegonzalez

Keep the focus on minimal product. More on this later, but your job as product manager is not to define the ultimate product, it’s to define the smallest possible product that will meet your goals.

When the developers are not sitting right next to you, then all of the normal challenges of communication and execution are magnified, often to the point where many teams get extremely frustrated with remote development, and some members

If you’re trying to create inspiring products, for most professional positions, outsourcing should not be about cost savings—it should be about assembling the right people for the product. Very often, you’ll have to look beyond your immediate geographic vicinity for the best people. This might mean hiring someone that’s based in another state, or in another country.

Few words are more dreaded by product managers than being told by engineering: “No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!”

  • @sergeiw

The deal with engineering goes like this: Product management takes 20% of the team’s capacity right off the top and gives this to engineering to spend as they see fit. They might use it to rewrite, re-architect, or re-factor problematic parts of the code base, or to swap out database management systems, improve system performance—whatever they believe is necessary to avoid ever having to come to the team and say, “we need to stop and rewrite.”

  • @sergeiw

You need to pay your taxes and remember to dedicate at least 20% to headroom. If you haven’t had this discussion with your engineering counterpart, do so today.

It is fairly easy to determine whether or not you are talking to such a person by simply asking them what some of their favorite products are and why. It is hard to feign passion—the insincerity comes through loud and clear. Ask for examples from different domains. Ask what they would improve on their favorite product if they were the product manager. Ask about bad products too.

We tend to want to think of our users as we think of ourselves and our friends. However, the target market very likely has quite different values, priorities, perceptions, tolerances, experiences, and technical understandings.

“The main thing is to keep the main thing the main thing.”

  • @sergeiw

My favorite source for product managers is to look for people with the characteristics described above and then use training, an informal mentoring program, and/or a formal employee development program to develop these people into strong product managers.

I’ll go even further. It can be dangerous for a product manager to have too much domain expertise. I say that because people that have spent a long time building their mastery of one domain often fall into another common product management trap: they believe they can speak for the target customer, and that they are more like their target customer than they really are. The product manager needs to constantly revisit assumptions about the domain and the customers. It’s not impossible for people with deep domain expertise to do this, but they have to work harder at it to remain open-minded to new developments and options.

I also believe that there are some different skills required for leading enterprise products, versus infrastructure, versus consumer services versus consumer electronics. For example, if your product is sold to a relatively small number of large enterprises (as opposed to hundreds of thousands or millions of consumers), then some different techniques are used to understand requirements and try out product ideas. It is also important to understand the different types of sales and distribution channels because these impact the product as well. If hardware is involved, you need to understand the process and time-line differences. For large-scale consumer services, the issues of scale and community management can destroy you if you don’t know how to manage them.

These people have two essential responsibilities. First, they must build a strong team of product managers. Second, they are responsible for the company’s overall product strategy and the various products in the company’s portfolio.

I believe that every new product manager needs roughly three months of hard learning before you can entrust them with the responsibility of guiding a product. During this time, the new product manager needs to immerse herself with target users and customers, get educated on the relevant technologies, and study the market and competitive landscape.

If you empower people who aren’t capable, you are abdicating your responsibility as manager. And if you micromanage people who are not capable, you are essentially doing their job for them.

  • @sergeiw

Recently, a new business metric has been gaining traction across a number of different industries: Net Promoter Score (NPS). It’s a very simple metric, and you can read all about it at www.netpromoter.com. Here’s how it works: You ask your customers how likely they would be to recommend your product to others, on a scale of 0-10. Those who rate 9 or 10 are considered “promoters” (they’re out there telling their friends how much they love your product, and are actively evangelizing for you); those who rate 7-8 are lukewarm or neutral; and those who rate 0-6, the “detractors,” that is, they not only won’t recommend your product, they may even actively warn their friends or the public against your product. If you take the percentage of promoters and subtract the percentage of detractors, you get the NPS, which essentially tells you if you have more people cheering for you or against you.

  • @bawaro

I am a big believer in raising the level of the product organization to be organizationally on par with engineering and marketing. Ideally, the product organization includes the design team, because the interaction between product management and user experience design absolutely needs to be as close as possible. Increasingly, you’ll see an organization with the name of Product or Product Management or Product Management and Design—often with a VP of Product or even a Chief Product Officer running it.

You can see example product strategies, product roadmaps, and portfolio roadmaps at www.svpg.com/examples.

Managing By Objective “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” —General George S. Patton, Jr.

We all have experienced this, as it’s simple human nature for us to try to envision solutions to problems. But when a product manager focuses on what problem to solve, it’s pretty amazing how many possibilities open up as to how to best solve the problem.

  • @sergeiw

Customers and users really aren’t in a position to come up with a good solution themselves. They just don’t know what’s possible, and it’s also extremely hard to envision the solution in advance.

Designers are most valuable very early in the process, when the product manager is working to understand the target market and come up with a solution.

So the more latitude you can give your engineers and user experience designers in coming up with the solutions to the problems you are trying to solve, the more likely they will come up with something that customers will love.

I consider the Product Opportunity Assessment an extremely important responsibility of the product manager. The purpose of a good product opportunity assessment is to either (a) prevent the company from wasting time and money on poor opportunities by ultimately proving the idea should be shelved for now, or (b) for those opportunities that are good ones, focus the team and understand what will be required to succeed and how to define that success.

Fortunately, it’s really not that hard to do a useful opportunity assessment. I ask product managers to answer ten fundamental questions: Exactly what problem will this solve? (value proposition) For whom do we solve that problem? (target market) How big is the opportunity? (market size) How will we measure success? (metrics/revenue strategy) What alternatives are out there now? (competitive landscape) Why are we best suited to pursue this? (our differentiator) Why now? (market window) How will we get this product to market? (go-to-market strategy) What factors are critical to success? (solution requirements) Given the above, what’s the recommendation? (go or no-go)

Many times, the best product opportunities are sitting right under the company’s nose. In particular, often the biggest bang for the buck comes from improving existing products that are not performing at the level they should and could be.

But I think what’s really going on is that there is a tendency in software companies to assume that the product is already about as good as it can be, and continued investment won’t make much of a difference. Companies tend to believe that their products are inherently complex, or that a 9% conversion rate isn’t bad, or that they just need to spend more on customer acquisition marketing or advertising, or that investing in customer service is just a necessary cost of doing business.

But more generally, the truth is that many products are poorly done and, rather than improve a product to the point where it can generate real revenue and success, many organizations view it as easier to create a new product instead.

  • @sergeiw

Do you understand the economics of your product? Do you know your exact revenue model? Do you know the total costs of your product? Do you know how much you pay for each new customer? Do you know their lifetime value to the company? Do you know the return your product has generated for the company?

You can see example opportunity assessments at www.svpg.com/examples.

When in product discovery, you welcome and explore new ideas, talk with scores of users and customers, learn how you can apply new technologies, flesh out your product concepts and test them out, and spend a lot of time thinking about the overall product direction, both immediate and longer term. It is all about discovering that mix of form and function that results in a winning product. However, once you’ve spec’d out this product, and your engineering team begins the process of building it, a very profound and important shift needs to take place for the product team. Now the game is all about execution—getting the product built, tested, and delivered to market. In this stage, you spend your time keeping everyone focused, chasing down the countless issues that inevitably arise, and getting these issues resolved immediately. Acquisitions, competitors, organizational and management changes—these are all distractions, and your job is to keep the team on track so this product can get out there when it needs to be.

One technique I have found very useful is to always keep two versions of a product going in parallel. In other words, as soon as you start the engineering for release 1.0 and switch into execution mode for that project, then you start up the discovery for release 2.0 in parallel. Always keep that innovation engine working—once a given release goes to engineering, redirect your creative urges to the next release.

It doesn’t help to talk to users, create prototypes, and test with users, if you don’t adjust your course based on what you learn.

If you consistently emphasize your obligation to ensure that what engineering builds must be valuable and usable, as well as enlist their efforts to discover a successful solution, you’ll start to move their focus to this—the most critical stage of the product development process.

Coming up with product principles means deciding what is important to you—and what is incidental—and deciding what is strategic and fundamental, and what is simply tactical and temporary.

the principles serve as a clear statement of what you believe, intended for your users, customers, partners, suppliers, investors, and employees.

For virtually all product decisions, the key is to properly frame the decision to be made, and to first get everyone on the same page in terms of: What problem exactly are you trying to solve? Who exactly are you trying to solve this problem for—which persona? What are the goals you are trying to satisfy with this product? What is the relative priority of each goal?

For example, you should be arguing about what’s most important to your target user: ease of use, speed, functionality, cost, security, privacy—this is the right argument.

You can see example product principles at: www.svpg.com/examples.

This is because key product decision makers are all available with the express purpose of making those decisions the product organization needs to get products to market.

The purpose of the product council is to set the strategic product direction, allocate product resources and investments, and provide a level of oversight of the company’s product efforts. This group is not trying to set the company’s business strategy, but rather—given the business strategy—come up with a product strategy that will meet the needs of the business. The decisions this group makes will directly impact the success of the business.

For each product effort, there are four major milestones for product council review and decision making: Milestone 1: Review proposed product strategies and product roadmaps, and initiate opportunity assessments for specific product releases. That is, select the product opportunities to be investigated. Milestone 2: Review opportunity assessments and recommendations, and issue go/no-go decisions to begin discovering a solution. Milestone 3: Review product prototypes, user testing results and detailed cost estimates, and issue go/no-go decision to begin engineering. Milestone 4: Review final product, QA status, launch plans, and community impact assessments, and issue go/no-go decision to launch.

If you find that you are having real trouble recruiting charter users and customers, then it’s very likely you are chasing a problem that isn’t that important, and you will probably have a very hard time selling this product. This is one of the very first reality checks to make sure you are spending your time on something worthwhile. If customers aren’t interested in this problem, you may want to rethink your plans.

I really don’t know how you can build products users will love without a deep understanding of those users, and you won’t get that without lots of direct communication—including face-to-face interactions.

The product discovery process is about answering these questions: What technologies can I apply to solve this problem in a better way? What should the user experience be?

Winning products come from the deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.

The Inmates Are Running the Asylum, by Alan Cooper.

Some teams create personas but they don’t take the next step—to make the hard choices about which persona should be the priority. It’s not ok to say your product is for everyone—you’re only deluding yourself. While this is extremely difficult for most product managers, I try hard to get the product manager to focus each release on a single primary persona. It’s not that the release won’t be valuable and usable by others, but your focus on each release should be to do a great job for just one type of target user.

You can see example personas at www.svpg.com/examples.

Fourth, while it often makes excellent sense to break up a release into several iterations to implement (this reduces risk, improves quality, and eases integration) a user experience is often not something that can be designed in pieces. You have to look at the user experience holistically—it has to make sense to the user at each release. While it’s easy to “stub out” software that’s not yet available, it’s not so easy to do the same for the user experience.

One of the biggest and most common mistakes product teams make is to have far more confidence in their product specifications than they should. They move forward, thinking they’ll adjust the product—if necessary—once they get beta feedback. But of course beta is far past the time for major changes, and it is little wonder so many initial product releases are so far off the mark.

The purpose of the prototype is to have something to test on real people, and usability testing is the art and science of getting useful feedback on your product from your target customers. Certainly, the product manager and designers will use the prototype and learn a great deal from it, but there is no substitute for putting the prototype in front of real people from the target customer base.

This testing can typically be combined with the usability testing process, and the prototypes used are the same. But in usability testing, you’re seeing if users can figure out how to do the necessary tasks, while in value testing you’re seeing if they actually care about those tasks and how well you’ve solved them.

testing your ideas with real users is probably the single most important activity in your job as product manager.

One thing to note is that, while usability testing (seeing if people can figure out how to actually use your product) is critical, you also need to test the value or usefulness of your product (do people actually want to use it?),

  • @sergeiw @pattydegonzalez @bawaro

One technique I especially like for medium to larger companies is to set up regular prototype test sessions—say every other Friday—where you arrange for 10-20 or so users to come into your offices for a couple hours each. Your product managers sign up for the time slots, so a given user might test a couple prototypes each. I like this because one person can do the logistics of invites and screening, and product teams can count on a ready set of test users on a steady basis.

If you’re asking users to come to your location—especially for business use—you will likely need to compensate the people for their time. If you’re doing a consumer service product, a big sincere thank-you along with a hat with your company logo on it will often suffice, as people genuinely want to help in the creation of products—especially for companies they like. However, if you do compensate test subjects, consider providing something along the lines of US$50 of credit on your site.

I can’t count how many prototypes I’ve tested at a tiny table at Starbucks—just big enough for a laptop—with three chairs around the table. In fact, in some ways this is preferable to the testing lab because the user feels a lot less like a lab rat and may be more candid and open in his or her responses.

After your greeting, be sure to tell him or her that (1) this is just a prototype—it’s a very early product idea—and it’s not real, (2) they won’t be hurting your feelings by giving you their honest opinion—good or bad, and (3) you’re testing the prototype—you’re not testing him or her. Your test subject can’t pass or fail—only the prototype can pass or fail.

There are three important cases you’re looking for: (1) the user got through the task with no problem at all and no help, (2) the user struggled and moaned a bit but eventually got through it, or (3) the user got so frustrated he gave up.

Generally, if you can get through six consecutive users who understand and appreciate the value of the product—and can get through the key tasks—you’re in good shape and you’ve done your job.

The first is the book, Don’t Make Me Think by Steve Krug. It’s mostly a book on interaction design, but in the back third he makes a compelling case for this sort of informal testing, and he provides many useful tips. I have long recommended this book to both product managers and designers, and I hope you’ll buy a copy and read it carefully. Second, my favorite product testing firm is Creative Good (www.creativegood.com). These guys specialize in a form of testing they call Listening Labs, which is a powerful form of undirected testing that can find huge issues with your product—functionality and design—resulting in dramatic improvements to the business results. While most testing firms test the products on a task basis, these guys are good at looking at the big picture, which is where many of the biggest improvements are to be found. Several of the techniques described above are adapted from their testing methodology.

Your primary tools for gaining insight into what’s going on are to study the site analytics, and to test your product on real users. You’ll also gather data from NPS tracking, customer service, the sales force, and from win/loss analysis.

So when you’re trying to improve an existing product, don’t fall into the trap of gathering subjective feedback, eliciting customer requirements and chasing features. Instead, focus on relentlessly pursuing your metrics by studying live use and working the numbers in the right direction.

As a general rule, users don’t like change. Sure they want the software to be great, and they clamor for new functionality, but most people aren’t excited about taking the time to learn a new way to do something they can already do.

In the spirit of minimizing the disruption caused by change, there are several techniques that can be useful in deploying changes gently. First, do everything you can to communicate the changes in advance, through vehicles such as newsletters, onsite education, and tutorials. But remember that many people will have neither the time nor the inclination to read what you write, so this technique can only take you so far. Second, if there is any question about the new version of your product working properly—either due to reliability issues, or scale, or performance—then you need to redouble your QA efforts to ensure that you won’t have to rollback your updates, which compounds community angst significantly. Third, if the change is significant, it may be important to contain the risk by pursuing some form of gentle deployment such as parallel, or incremental deployment.

  • @sergeiw

You can do this by deploying a parallel version of your product and inviting people to opt-in and try out the new version when they have the time. Allow those who try to use the new version to make it their default if they like it. Once you are confident that the new version is working well—and the majority of your community has converted to using it—you can make it the default and allow customers to “opt-out” and continue to use the old version for a period of time if they don’t have the time to learn the changes immediately. Give these people sufficient notice of when support for the old version will be discontinued. For a significant client or service with a large community, expect this process to take months. Also expect some heat from your engineering and site operations organizations because it is not easy to support parallel versions.

I advocate that all project teams schedule a phase that begins at launch and lasts typically a few days to a week. I call this phase rapid response, to emphasize that it is all about responding quickly to what you learn once the product has been launched.

The question is not whether there will be issues but, rather, how quickly will you address them?

Do prototypes for three reasons: (1) so you can test with real users, (2) to force yourself to think through the issues; and (3) so you have a good way to describe to engineering what you need built during the sprint. Be sure to test prototypes with real users.

Get Agile training for your entire team. Hire a consultant to help your product team move to Agile, but make sure the consultant has proven experience with product software teams and understands the difference between product software and IT or custom software. If everyone understands the mechanisms around Agile, then you can focus on the execution. If people don’t understand, you’ll get bogged down in the semantics and dogmatic issues.

  • @sergeiw

But as we explained earlier, as organizations get larger, they invariably become more conservative, and less willing to take risks. Again, this is because large companies have much more to lose than smaller companies, so they get really good at protecting what they have. But there are also substantial advantages to shipping product from a large company and, despite their risk-averse nature, your company does need you to innovate.

innovation is rarely about solving an entirely new problem. More often it is solving an existing problem in a new way. So watching people struggle with their existing solutions is a great way to highlight innovation opportunities.

What is really essential, and what is there just because it’s a side effect of the way the product is designed and built?

Every system has an implementation model that is the basis for how the product was built. But the user doesn’t think this way—he has a conceptual model in mind for how he wants to think about this problem, and what he expects the system to present. Frustration happens when the user is presented not with something that reflects his conceptual model, but instead reflects the implementation model. When you spot these incongruences, you have identified an opportunity for innovation (or at the very least, an opportunity for significant product improvements).

Most importantly, make sure you have the time during the week to work on the items crucial to the success of your product: your product strategy, your roadmap, the current prototype of the next release, your understanding of the competition and—especially—talking to actual users and customers.

  • @pattydegonzalez

If Apple has a secret sauce as a technology company, I believe it’s this: They understand better than anyone else the role that emotion plays in getting consumers to crave, buy, and love a product. They know how to create products that speak to these emotions in consumers.

It is entirely understandable why large customers and partners may seek this arrangement. And if you’re a small company that’s strapped for cash, it’s also very understandable that your CEO might be more than a little inclined to agree. After all, you want to be “marketdriven” and you’re probably going to be adding these features at some point anyway, so why not let the customer underwrite them?” So what’s wrong with doing a special? One of the surest ways to derail a product company is to confuse customer requirements with product requirements.

Assuming these are not issues, specials are still dangerous. How come? Because your job is to meet the needs of a broad range of customers—that’s what distinguishes product companies from customer software shops. If a year from now the market changes, you need to be able to quickly change and adapt. If you are contractually obligated to keep supporting a specific way of doing things, then your business will not be as nimble as it needs to be. Remember that every version of your product will have to be built, maintained, tested, released, documented, and supported. It doesn’t take too many specials to weigh down a company to the point where it takes them months to do even the smallest release.

Second, consider looking at how you could keep your product general purpose but allow the product to be tailored/customized/ extended by the customer or by a solutions provider. And then have ready the names of a couple of system integrator/solution provider companies that can tailor your product to meet this specific need. You may need to partner with the solution provider so that your customer doesn’t have to manage two relationships and have to worry about finger pointing if there are issues.

First, they understand their target market and where the current products fall short. Product usability testing is my favorite technique for doing this, and you can do this with your competitor’s products in addition to your own. Second, great product leaders know that what is now possible is always changing. New technologies enable new solutions that may not have been possible or feasible until now. It is not easy to constantly stay on top of relevant technologies and consider how they might be applied to help solve the problems you face, but it can make all the difference for your product. Remember: great product managers combine what is desirable with what is just now possible. Apple and Google understand this. Product opportunities exist everywhere, in virtually every market. But you must identify the need, and then search for new ways of applying technology to solve the problem.

First, as long as there are products that drive you nuts, there are opportunities for someone to do it better. How about a cell phone that doesn’t drop calls? How about a home computer that your parents can actually administer without your help? Second, what is possible is always changing. Just because something isn’t feasible today doesn’t mean it won’t be tomorrow. Third, today’s applications are tomorrow’s foundation. That’s how things work in our business. Initially, the browser was an application to look at some content on a Web site. Today the Internet is a foundation enabling applications like eBay, Skype, and PayPal.

People buy and use products largely for emotional reasons. The best marketing people understand this, and the best product people ensure that their products speak to these emotions. In the enterprise space, the dominant emotion is generally fear or greed. If I don’t buy this product, my competitors will beat me to market, hackers will penetrate my firewalls, or my customers will desert me. Or, if I do buy this product, I will make more money, save more money, or stop spending so much money. In the consumer space, the dominant emotions get more personal. If I buy this product or use this Web site, I will make friends (loneliness), find a date (love or lust), win money (greed), or show off my pictures or my taste in music (pride).

  • @gabrielhdm

Once you have clearly identified and prioritized the dominant buying emotions your customers bring to your product, focus on that emotion and ask yourself where else they might be able to get that need met? That’s your real competition. In many cases you’ll find that the competition you should be worrying about is not the startup or big portal that’s after the same thing you are, but rather the offline alternative.

Crossing the Chasm, Geoffrey Moore introduces the powerful notion of a technology adoption curve, comprised of innovators and early adopters, followed by the early majority, the late majority and, finally, the laggards. He goes on to explain how few products get beyond the early adopters (they fall into the chasm).

Marty: Why do you like to focus on anger? Jeff: Because angry people dictate the future of technology. I like my product managers to focus on the most miserable thing people have to deal with everyday. If you can solve that problem, that actually changes behavior, and that can lead to the truly big product wins.

In my view, far too many product managers talk in terms of features and technology, and we don’t really talk in terms of the user’s core needs or emotions.

Jeff: The Lovers (Innovators) are the techies who buy the product because they find the technology cool. These people are very dangerous to product managers because they are driven by very different needs than the larger population. They look at solving tough technical problems as fun. On the other hand, the Irrationals (Early Adopters) feel the same emotions as the general population, but with more intensity. These are often negative emotions such as anger, fear, or loneliness, but in any case, the strength of these feelings can lead to buying behavior that is not economically rational, for example, they’ll spend more time learning something than the value they get just so they can get the satisfaction of addressing these emotional needs. The good news is that as the product improves, ordinary people who feel the more subdued versions of the same emotions will also be motivated to buy. The Efficients (Early Majority) will adopt when the technology becomes practical. Again, they feel the same emotion, but they’re more pragmatic about the benefits versus the costs. The Laughers (Late Majority, and Yahoo’s core constituency) feel the same emotion, but it’s more muted and they don’t want to deal with any grief in order to get the benefits. The Comfortable (Laggards) are the 15% that want the benefits but it just has to be drop dead simple and convenient for them to make the move.

Marty: So what do teach your product managers to look for? Jeff: Look for anger, exasperation, and frustration. If you just take a look at all those we love to hate—the telcos, banks, consumer credit firms, the tax man, government bureaucracy, airlines, health-care—these are all great opportunities for innovation because the consumer latent frustration is so high.

Politicians like to tap into the fear emotion and explain that bad people are gonna destroy your cities, or come and bomb you, or you’re not going to have food tomorrow. Well it’s not that hard to motivate you to change your behavior when you energize these core emotions. It’s much harder to get people to do something by appealing to their aspirations.

So the question we ask is, “What are the emotions that are driving the behavior?” And then we look for ways to tap into those emotion with features and all the other things. We assess for each of our projects which core emotions they appeal to, and how acute is the user’s pain.

If you can tap into any one of those emotions that every human everyday feels—loneliness, insecurity, fear, frustration, anger—some bit of that freshman thing, then you’re on the right track.

I think what these two cases illustrate is that the disciplines of interaction design and visual design are very different. To have a site that is both usable and appealing you need both skills on your design team.

and the more products I see, the stronger I believe in (a) the role that emotion plays in inspiring products, and (b) the direct role visual design plays in creating that emotion.

Scalability. Weird things happen to products once millions of users start using them. Databases break, performance bottlenecks pop up all over, user interfaces become unusable. You can do some amount of load testing during QA, but I’ve found this only finds the easy problems. I guarantee you that you’ll have surprises—and not pleasant ones. Managing scalability needs takes a collaboration of product management, design, engineering, and operations. It also takes a proactive management team that allocates a significant amount of engineering and operations resources on an ongoing basis (I generally advise 20%) to scaling the product and infrastructure. If you get to the point where everything breaks and the engineering team is telling you that the “house of cards has collapsed,” you’re in big trouble. The only way I know to avoid that is to pay your taxes by working on scale continuously from day one, and don’t let yourself get to the brink.

  • @sergeiw

Availability. Very quickly you’ll find that there really is no time of the day or week or month or year that your service doesn’t need to be running. I don’t know of anyone that has achieved 100% availability, but I know outages are painful to everyone. The life of a consumer Internet service provider is not for everyone. Things happen at all hours, weekday and weekends, and everyone I know in the business has their stories. You need to design-in high-availability to all of your thinking just as you need to do with scalability.

  • @sergeiw

One of my favorite books is The Inmates are Running the Asylum by Alan Cooper.

Specials. One of the biggest mistakes companies make is that they think they can get their product requirements from their customers. I’ve talked about this earlier (see Beware of Specials), but the most dangerous example of this is when the sales organization brings in a potential customer that has a big check all ready to sign if you’ll just agree to put these seven features in your product. Soon you’re becoming a custom software shop, and you don’t have anything resembling a generally useful product. If that’s not bad enough, there’s a good chance the initial customer won’t be happy with those seven features anyway (once they got it and tried it they realized they needed something different). Avoiding specials takes a lot of discipline—especially for a small company struggling to bring in some cash—but it is critical you create products that meet the needs of a wide range of customers.

Designing for the sales channel. It’s critical to design your product around the needs of your sales and distribution channel. Different channels require different capabilities. The key is to provide value all along the distribution chain. If you’re selling through systems integrators, you’ll need to ensure that your product doesn’t try to cut them out of the equation. If you’re selling through VARs that supply a wide range of products, you’ll need to ensure that your product doesn’t overwhelm them with time-consuming technical requirements. Many otherwise good products struggle because they’re not appropriate for their sales channel.

Here is how I characterize a product: People will pay for it; it delivers real and distinct value (and typically has its own SKU). Note that sometimes people pay by tolerating advertising, or by paying for support and not license fees, but one way or another they’re compensating the provider. It works well in multiple customer installations. The point here is that it’s not a special—this is not custom software. Your field and/or channel can effectively sell it. You provide the necessary sales tools and sales training. Your company will stand behind it, providing support and adding improvements as necessary. Your customers and/or channel and/or services partners know how to install, configure and customize the product.

A solutions product has all of the characteristics of a product above, plus: The software solves a business-level problem, often for specific industry verticals. The product may be based on an integration of one or more component-level products, which may come from your company or from partners, and they are pre-integrated. If appropriate, the product is certified with partners’ products as necessary (the customer needs to know the supported configurations).

Related—but the not the same as solutions products—is solutions marketing. I also like solutions marketing over other forms of product marketing because solutions marketing: Speaks to the business-level problem, aligning products with business value Speaks to vertical industry segments, aligning value with a particular industry’s more specific—and sometimes regulated—needs. Showcases live customer success stories in action, in order to prove the business value Shows how to leverage products, professional services and business process knowledge or best practices to achieve business results

By platforms, I am referring to foundation software that is used by application developers to create end-user solutions. Examples include operating systems (e.g., Windows, MacOS, Palm OS), operating environments (e.g., Java, Flash), Web services (e.g., Amazon’s or eBay’s integration APIs), game developer platforms (e.g., XNA), and application-level platform runtimes (e.g., Facebook and Salesforce.com).

If you can’t program the platform through some form of API, and if you don’t have multiple commercial software products or services built upon your software, then you’re not a platform in the sense I’m describing.

  • @sergeiw

To begin with, there are three very different constituencies: The application providers—the businesses that choose to use your platform to build their solution. The developers—those who work for the application providers and who write their software using your platform services. The end-users—the ones who run the application provider’s products, and ultimately use your services. Each of these three constituencies brings to the table very different needs and requirements. You simply can’t be a successful platform without meeting the key needs across all three.

The application provider is going to be concerned with business viability—their viability if they use your services, and your viability in case you go out of business or discontinue support for the platform. The application provider cares about your pricing, licensing, quality, support, and global availability, among other factors. The developers are looking for services that make it easy for them to quickly create maintainable, reliable code in the languages they want to use, working with their favorite tools and infrastructure, on the devices they need to deliver on. The end-users care mainly about the end result. If the features and services they want aren’t there or don’t work in the way they need, they don’t buy the application, and the application provider fails. You lose a customer, and eventually you fail too.

I know this may sound heretical, but it is okay for the developers to work a little harder if the application is something end-users like and use, versus making the developers happy but nobody wants the end result. Countless platform-wannabes made this mistake. The reasoning is very simple: I’m a developer—I know what other developers want, so I’ll create something to help both my colleagues and myself. I would have to include client-side Java in this camp—great development environment, terrible user experience, terrific opportunity for Macromedia (now Adobe).

Backlinks