Archive for 24 January 2016

Friday Lunch with Takashi

It’s a running joke with one of my colleagues that I often force him to drive with me up Takashi in Salt Lake City before it opens in case there is a line around the block. Usually there are only five or six people waiting in front when we pull in; once in a rare while, there are several dozen, even at 5:00 (the restaurant opens at 5:30 most nights) and we’re lucky to get a table. 

Jason, Tim, and I did the same for lunch this past Friday, arriving a few minutes before they opened at 11:30, but this time was different: We were there to interview Takashi Gibo himiself, at his eponymous restaurant. The premise for the meeting was two-fold:

  1. Eat delicious sushi with friends, obviously. 
  2. My session at Adobe Summit is going to use an analogy comparing analysts and sushi chefs, and getting Takashi’s perspective on his practice will inform the story I tell. 

Our group with Takashi

I had sat in front of Takashi before, at his sushi bar, while he prepared rolls and fish for me, but I had not taken the opportunity at that time to introduce myself. I wish I had. Today we found Mr. Gibo to be soft-spoken, humble, and patient. We stumbled through hastily prepared interview questions that probably seemed rambling and incongruous, but he thoughtfully, slowly answered each one, talking at length about how he got into sushi, where his inspiration for his menu comes from, and why he is in Salt Lake City of all places. 

Jason and I were both a bit intimidated, since Takashi is something of a local legend as well as the owner and proprietor of our favorite restaurant in the world, but I think Takashi was also intimidated in his own way, and behind his teal-framed glasses his eyes were as furtive as mine. 

He speaks with an accent blended from the three countries where he has lived: Japan, Peru, and the United States. I did not expect to hear a Japanese chef speaking English with a hispanic flavor, but this also explains his menu, which features ingredients that, in his words, “could get me arrested if I tried this in Japan.” Spicy peppers are a mainstay. Ceviche, a Peruvian dish, is featured in a few places. He mentioned his Strawberry Fields roll several times, as it happens, was inspired not by the Beatles song which lends the roll its name (although Takashi mentioned loving the Beatles), but by an experience where Takashi gazed on a strawberStrawberry Fields rollry cake and got the idea to combine strawberries, escolar, and almonds with thai chili peppers rounding out the unorthodox combination. 

This is a man whose life, going back to his earliest memories, has been about delighting the taste buds. Takashi’s parents first owned a bakery, and then got into the restaurant business themselves, first in Lima when Takashi was a small boy, and then in Okinawa beginning when he was 12 years old. While there was sushi in Peru, it was not until his brother took him to a proper sushi bar in Okinawa that Takashi fell in love with the craft. He is, I got the sense, the only sushi chef at his restaurant who has been formally trained in the ancient Japanese art of sushi preparation; he mentioned that he has several times hired chefs with zero experience making sushi. In fact, he prefers them; they are often better learners. I am amazed at how well he is able to teach them, as I have never had a bad sushi experience in however many dozen pilgrimages I have made to his sushi mecca. 

In fact, the flavors that he has crafted over the years are so delightful that I was taken aback when he said that the one he believes represents his restaurant best is ponzu sauce, the citrus soy-based sauce that his chefs use on many of their dishes. While it is a common addition, and they use it well, there are so many others that I would have gone with. Their lemon pesto adds a tart zing wherever it goes. He mentioned that they use garlic quite a bit (again, flying in the face of the Japanese tradition in which Takashi trained). Or their spicy mayonnaise, which they always use sparingly, but which is also much more intricate than the lazy Sriracha-and-mayo like most American sushi joints. I happen to know from experience (attempting to recreateScreen Shot 2016-01-24 at 9.30.54 AM it) that it is a blend of mayonnaise, tobiko, togarashi, Sriracha, and sesame oil. The fact that they have their own unique take on spicy mayo is really what Takashi is all about, but it is not the flavor that he thinks best defines his restaurant. On the other hand, ponzu sauce may be the perfect epitome of Takashi’s sushi, because it is an ingredient that anyone can use—they sell it every grocery store—and yet nobody uses it as well as he does. While he certainly has his exotic ingredients too, he is a master of taking fairly common ingredients and using them better than anyone else can. 

Takashi’s wife, Tamara, is the general manager at the restaurant and brokered the interview for me. We sat at a table for four, and talked while I ate a Black Magic Woman roll and a Buddha roll, the latter of which was invented, it turns out, not by Takashi, but by one of his chefs, who needed something to serve to a vegetarian friend. It is a fairly pedestrian roll if you simply list the components: tempura vegetables, rolled in rice and seaweed, and drizzled with a bit of eel sauce (but, unlike most other sushi restaurants, not to the point that the roll itself tastes sweet). To Takashi’s point about ponzu sauce, the quality of these very common ingredients makes the roll quite a different, almost purer experience than a similar roll from another restaurant. 

Perhaps the best thing I can say about Takashi comes from his answers to my final questions. I asked him why he still serves from behind the sushi bar. He certainly does not have to. He has a large staff, and many capable chefs. “I love it,” he said, as softly as ever. These are the people Seth Godin wrote about in Linchpin: people who take genuine pleasure in sharing their art with you. Takashi sincerely wants to dazzle you with sushi, to have you love what you just ate, and the pleasure he gets fromScreen Shot 2016-01-24 at 9.23.55 AM providing you with that experience is enough to keep him on his feet for five hours a night most nights of the week. Lastly, I asked him whether, with waiting times for tables commonly reaching two hours even on weeknights, he has ever considered expanding, perhaps opening another restaurant in the area. He smiled, but firmly answered no. Why not? “My inventory list is very long,” he said. His concern comes down to quality. He would not be able to ensure quality in two places at once, and he does not want to have to hop between both restaurants. He believes, I got the sense, that it would degrade the experience in both locations. He is choosing quality over money. Fortunately, as long as Takashi is in charge at his own restaurant, he probably does not need to fear losing either one.

Tips and Tricks for Tips and Tricks

It has become a tradition of sorts that I get the opportunity to lead an hour-long session at Adobe Summit every year in the U.S. and London on “tips and tricks” to help users get value of the product I work on, Adobe Analytics. When we say “tips and tricks,” what we really mean is practical, hands-on advice specific to a product or toolset, as opposed to theoretical thought leadership content that makes up much of the rest of conferences (including Adobe Summit).

I’m certainly not the world’s most accomplished speaker, but I’ve been doing this for a few years now and—truly for reasons unrelated to my presentation skills—they’ve been really well received.

Every year I seem to get questions from a few colleagues or presenters at other conferences asking me what my “keys to success” are. Seriously, it’s mostly serendipity, but here are a few tips and tricks I’ve learned about doing “tips and tricks” sessions. (Some of this may be applicable to sessions where you’re not doing tips and tricks for a software product, or not. I don’t know.)

1. Make sure your tips and tricks are tips and tricks
The goal with a session of this type is to get practical recommendations into the hands of users of the product. Don’t wax too philosophical or spend a lot of time on industry/market trends. There is a time and place for those, but this isn’t it. If it can’t be demoed live or shown in screen shots of your product, it probably doesn’t fit in this session.

2. Create a cheat sheet that attendees can take away with them
You’re likely going to throw a lot of information at attendees; there aren’t 2-3 big ideas that you are leading the audience toward, there are probably 6-10 minimally related product tips, and it’s a lot for audiences to consume. A handout summarizing the tips/tricks you’re sharing makes it easier for them to remember everything, and giving attendees something to take away (even if 70% throw it in the garbage) shows that you really want them to take value away from the session. It allows them to focus on learning/watching without feeling the need to document everything as you’re talking.

3. Where possible, spend 80% of your time on things users can do today, and 20% teasing things that are coming soon
If you have to, it’s better to spend 100% of your time on things users can do today. Again, you want your session to be practical. But I have found that a couple of “coming soon” tips gets people excited about what’s coming soon and gives you an opportunity to boost usage of a couple of neat features that they might miss if they aren’t looking for them. NOTE: Make sure none of your sneak peaks are part of larger main-stage announcements, and make sure they are coming reasonably soon (i.e., within the next 2-3 months).

4. Make sure you know the intended audience for your tips and tricks
If your session is positioned for advanced users, make sure you are sharing advanced tips; if positioned for novice users, share basic tips. I like to be really clear about the intended audience in my session description so that the audience is not disappointed. For what it’s worth, I have never gotten survey feedback that the tips/tricks I shared were too advanced, but every year I get a few comments that they were too basic.

5. Walk people through the tips in detail
I normally give a short introduction to each tip, explaining why what I am about to share is interesting/valuable. Then I take the audience through the tip, step by step. (I use screen shots because Internet access at conferences is notoriously spotty and it avoids having to wait for pages to load, but if you’re up for it, you may want to do this in the product.) I probably go into more detail than I need to, but I want to emphasize how approachable each of the tips really are.

6. Have really solid use cases
Many attendees won’t automatically make connections between their business problems and the tips you’re sharing, so good use cases or stories are critical to making your tips relatable. They are the difference between “That was interesting!” and “Wow, that will solve the exact problem I’ve been having.” I try to keep them generic so that they are as easy to understand as possible, even though this means talking about (in my case) really basic metrics like Page Views and Revenue.

7. Even if your tips don’t have a common thread, try to come up with a good overarching theme.
You need something to frame the session in the audience members’ minds, even if the limbic device doesn’t have to do with the tips themselves. For example, two years ago my session was focused on tips related to recently released features, so my theme was “we’ve been busy,” and I used the image of bees in a beehive. Last year I talked about these tips being the difference between a “good” user of the product and a “hall-of-fame level” user of the product, and I made an analogy with Tony Parker of the San Antonio Spurs improving his jump shot a few years ago to go from “very good point guard” to “hall-of-fame point guard.” (So, in this analogy, the tips are like his shooting stroke.) If nothing else, a good theme will give you a way to introduce your session and warm up your audience.

I’m sure there is other advice I’m forgetting, but these are the big ones. Most of the other advice I would give applies to any presentation you might give at a conference: prepare early, rehearse often, and use humor. Tips and tricks sessions are great at vendor-specific conferences, and if you’ve been invited to give one, you should feel fortunate. They usually score highly with attendees, and they’re highly rewarding because you know you’re giving people something they can take back to their offices and use first-thing Monday morning. My last piece of advice, therefore, is to have a great time with the experience and enjoy knocking the socks off of your attendees with some amazing content!

I got 99 problems . . . but are they customer problems?

A lot has been written about “user versus customer” as an abstract concept ever since (and probably long before) Jack Dorsey asked Twitter to stop calling its users users and start calling them customers. I’ve also seen product managers and UX designers write about how “product owns the customer; UX owns the user.” I think most of this discussion is useful and relevant in defining roles and responsibilities in a product organization, and I’ve referred to various aspects of it many times in my own work with other product managers, UX designers, and developers.

That said, while I don’t spend a lot of time on product management blogs, I haven’t seen a good, concise explanation of how to think about user problems versus customer problems when defining product requirements for design and engineering. I’m writing this post mostly to remind myself to think a little differently in the new year.

I often find myself sitting down to write up a PRD and starting from what I call the “customer problem.” But is it really the customer problem? For example:

  • The customer needs to better understand retention and churn in their own customer base.
  • The customer needs a better way to visualize the overlap between marketing segments.
  • The customer needs to be able to upload massive amounts of customer data for analysis in our tool.

No. No. NO. These statements do represent problems, and they are probably even worth documenting and elucidating as we present our ideas and try to win advocates and acolytes to our cause, but they are not customer problems. They are user problems. They describe what a user needs to be able to do once they are already in the product.

Okay, then; what is a customer problem?

A customer problem—which should be at the beginning or near the beginning of every PRD and concept deck we create—should describe how the customer (a business) is failing to grow. Both customer problems and user problems describe inefficiencies, but customer problems come with a clear indication of the actual (monetary) value that a solution would provide to the businesses we serve, while user problems may only hint at that value.

As such, customer problems are more likely to describe something that would keep the CEO or CMO or CIO up at night than they are to describe something that keeps the day to day user of the product up at night. That’s a good thing, because it can’t hurt to start speaking the C-suite’s language.

Here are a handful of examples of what I mean:

  • The customer has reached a point of diminishing returns from their acquisition budget but still needs to hit a top-line growth target of 20% YoY. The most efficient way for them to do this is by personalizing the on-site experience.
  • The customer is facing intense downward pricing pressure from a smaller competitor who is trying to steal market share, and they are looking for new ways to engage with their own customers to keep them from attriting.
  • The customer knows that segmentation is everything in marketing, but beyond their legacy market segments they have been going after for years, they do not know how to find the right groupings of individuals so that they can reach them in the right way at the right time.
  • The customer has been unable to consolidate customer data stores across the enterprise and, as such, has not been able to empower various marketing teams with insights at the brand level.
  • The customer has millions of dollars flowing into marketing campaigns across various channels, but has only a very limited view of how those dollars influence not just short-term revenue, but long-term customer value.

As I’m sure you can see, user problems can/should flow from customer problems. But we could solve any of the user problems a few paragraphs up from here without actually ensuring that we’re solving the real underlying customer problem that will help users of your product grow their business.

As I’m sure you can also see, the customer problems I’ve listed here are composites, more indicative of a market problem than anything any one particular customer is facing uniquely. (Unless you’re building a product for an individual customer, you will want to pick a someone from across your customer base to represent the customer problem, but it should reflect broader trends, obviously.)

All of this might seem obvious, in which case maybe you haven’t made it to this point in the post. In a way, it is obvious; we all probably try to focus on customer problems, but we often settle for user problems even though we know better. Why is that? As a colleague pointed out, it’s probably because we spend a lot of timing documenting problems, use cases, and solutions for developers, who do solve user problems with their work; thus, we naturally tend to put things in terms that developers are most likely to understand and relate to; however, those user problems should still be grounded in customer problems. This will enable engineering teams to understand the deeper problems as well, giving them the best chance to innovate in ways you could never have envisioned.

What if I don’t know what the customer problem is?

As a product manager you are probably fairly close to your users. Your users sit within the organizations that pay for your product, and many of them likely understand the factors that are limiting growth of the business. If you ask them what challenges the business as a whole is facing, they may or may not get right to the heart of the matter, but this is why (no pun intended) I love the “Five Whys” method of interviewing.

The theory is that within (roughly) five iterations of asking a person “why?” you can get to the root cause behind the initial problem described. You ask what problems are facing the business, and they give answer. You ask why that’s a problem. They answer. You ask why that’s a problem. They answer. Lather, rinse, repeat. By the fifth “why,” you should be at a root problem that motivates the users you’re interviewing to action in a big way. That should either be the customer problem or very close to it.

You may need to ask to interview the user’s manager, or his/her manager’s manager in order to get the level of detail you want in order to truly understand the customer problem, but the “Five Whys” method will help you get there.

A final huge benefit to thinking about customer problems

One of the most underrated skills in product management, in my limited experience, is the ability to convince people. You have a vision for your area of product ownership, and you’re likely competing for resources (development, UX, etc.) with other products or other features. You will get nowhere with that vision unless you are able to convince key stakeholders that what you want to do is supremely valuable to your customers (and therefore to your own business).

There are many factors that play into the “convincingness” of a product proposal, but in my (again, limited) experience, proposals that are based in a rock-solid knowledge of the problems your customers at large are facing, where the product manager can speak knowledgeably and authoritatively about the business problems preventing customers from growing, tend to convince more people more completely. These projects tend to get funded because stakeholders feel the customer’s frustration much more acutely than if the problem presented is purely a user-level problem.

Think customer

One of my goals for 2016 and beyond is to do a better job in interviews with users getting to the root of the customer problem and being deliberate about making that the central focus of my product requirement/design work. (Incidentally, I think I’ve been reasonably successful at this, but more by chance than by choice.) I have no doubt that it will produce better products and features; I just wish I had come to these realizations much sooner.

Ah, well; I never said I was a fast learner.