How train platform noodle shops can teach us about product & service differentiation

In response to my recent article about how product managers can learn from the way Starbucks opens its stores while still under construction, several colleagues rightly pointed out that not all companies have the brand recognition and loyal customer base that Starbucks has when launching a new product or service. While I still think it’s true that the “coffee and cash register” approach that Dave Pickett summarized so well represents the “core revenue-generating loop” for a minimally viable product (MVP), basic functionality is not always enough to ensure success.

In addition to defining a well-constrained MVP that will enable you to get into the market and begin earning revenue, learning, and iterating to further improve the product, startups facing entrenched competition must fundamentally differentiate themselves rather than merely shipping a product with a subset of the competitors’ or alternatives’ features.

Now, bear with me as I stick to food & beverage analogies for a quick bowl of noodles…

I was born and raised in Japan, and I recently returned to visit friends and family there. Traveling from Tokyo to Matsumoto via Nagano, I had about 30 minutes between the bullet train from Tokyo and the express to Matsumoto, right around lunch time. As I stepped off the bullet train, the first thing that caught my eye was a small shop built on the train platform announcing “soba” (buckwheat noodles) on its blue curtains. Mountainous Nagano, where the Winter Olympics were held in 1998, is famous all over Japan for its soba, so I wasn’t about to pass up the opportunity.

An automated kiosk took my order for a 500-yen (less than USD 5.00) bowl of sansai or mountain vegetable soba, served cold in the mid-June heat. The kiosk issued a voucher, which I simply handed to the lone attendant inside the shop. She cooked up the fresh soba, chilled the noodles briefly in ice water, and then grabbed plastic containers full of mountain vegetables — such as fiddlehead fern shoots and other edible plants foraged from the nearby woodlands. Garnished with green onions, I had my meal within about three minutes and, standing at the counter, I’d slurped it down in another five, leaving plenty of time to do some gift shopping before my next train.

There are undoubtedly much nicer traditional Japanese restaurants right outside the train station in Nagano, with wonderful hospitality, a larger menu (including drinks), and a comfortable ambiance — perfect for spending a liesurely lunch or an evening with friends or colleagues. But these train platform noodle shops all over Japan differentiate themselves from their competition through important attributes like location, convenience, and speciality. And by automating order-taking while creating a compact, highly optimized work station for the attendant, the business is also able to keep costs incredibly low without sacrificing quality — aside from 7-Eleven onigiri (rice balls), this was by far the least expensive meal I had in Japan, and yet it was also one of the tastiest bowls of noodles I had during my two-week trip.

I could also argue that this noodle shop meets the definition of a good MVP — core features that generate revenue without unnecessary frills — while also successfully differentiating from restaurants that serve similar noodles. With a location primed to serve rushed travelers, this train station platform noodle shop provides a unique local delicacy at very low cost. And with the revenue and loyalty of frequent diners at a small shop like this, a wise business owner could potentially expand to other locations and even take over that upscale soba restaurant across the street from the train station.

It’s far too easy for product managers to fall into a comfortable trap of focusing merely on a feature set (or worse, interesting or “fun” technology), losing sight of the bigger picture that includes the fundamental problem you’re trying to solve, the competitive landscape, industry focus, user segmentation, and so on. For those of us who’ve survived failed startups, I know we’ve learned these lessons and that all of this feels very basic. But, so often rushed to deliver something functional for investors or stakeholders, I believe failure to differentiate is one reason why so many V1 products defined as overly narrow MVPs fail — they lack the differentiation necessary to make the product attractive or desirable. In an age when many users can quietly use SaaS alternatives to corporate-mandated systems (how many enterprise-wide instances of Slack start from the quiet frustrations of a handful of employees?), I believe this is true for internal corporate IT projects as much as it is for the hottest new app. I’m certainly not advocating the polar opposite of a narrowly focused MVP or V1 product — merely suggesting that MVPs can be too small as well as much too large.

So, the next time I’m defining a minimally viable product, I won’t just be thinking about my latest morning coffee here in Seattle, I’ll be thinking back to that wonderful bowl of buckwheat noodles in Nagano, considering how to differentiate my product rather than meet minimum functionality.

How Starbucks helps Product Managers define what a true Minimally Viable Product (MVP) is

As a Seattleite, I’ve supported my “local coffee company” when visiting New York, Tokyo, London, and Madrid (and yes, I support independent coffee shops as well). Starbucks receives universal acclaim for its excellent customer experience, whether you take advantage of the mobile ordering system, gamified loyalty program, convenient drive-throughs, or just walk up to the counter at any store around the world. For example, I recently noticed that the partners (as the company calls its staff) had stopped asking for my name when I paid using the mobile app. Observing them in action, I saw that each station, from the espresso machine to baked goods, now printed the order stickers that had previously only appeared on mobile orders. With no more handwritten misspellings of customer names on coffee cups, late night comedians will have to find new material!

But it’s not just a well-integrated customer experience that can provide lessons for Product Management and User Experience professionals in the technology industry. One of the two Starbucks stores on my commute to work (yes, they’re across the street from each other) has been under renovation for a few weeks, and yesterday the store opened for business, even though construction was not yet complete.

Every product development team defines differently what a “minimally viable product” (MVP) looks like for them, ranging from what other companies might consider a mere Beta release to a full v1.0 product that supports a broad range of customer and user needs. Debates about MVP scope can often get rancorous between business and engineering stakeholders as scope and schedule come into conflict, even in an iterative model like Scrum.

There’s a very simple lesson in how Starbucks chose to open this particular store. Even though all of the CX details — the comfortable seating area, trendy music, or reliable WiFi — are part of the full customer experience, and even as Starbucks continues to extend that experience with its high-end Roastery stores, the fundamental “MVP” for a Starbucks store isn’t all that, it’s the coffee. So when the espresso machine and register were ready, Starbucks promptly opened the store. The next day, parts of the store still remained cordoned off, and by the look of things construction may continue for some time. (I’ve even seen Starbucks counters in shipping crates while the store next door got rebuilt from the ground up.)

Some project manager at Starbucks headquarters in the industrial district of south Seattle (SoDo) is probably getting impatiant, and for all I know this phased reopening of the store was not according to plan, but from a product development standpoint, this was exactly how a new product or service launch should take place. A smart leader understood that the core experience — the true minimally viable product — is about meeting the caffeine and muffin or bagel needs of the store’s customer base, and that the core business goal is to begin generating revenue again from this location.

So, the next time you’re debating how to define your product’s MVP, consider this Starbucks store rather than the well-worn skateboard analogy (can you really even build a car on top of a skateboard anyway?) — consider what the core customer experience needs to be, and how you can begin generating business value sooner.


As a final note on customer experience, I can’t help but share the adorable cartoon that a barista in Tokyo drew on my Starbucks cup, putting a huge grin on my jetlagged face. Starbucks in Japan takes an amazing customer experience to new heights. I’m not sure what this character is, but it’s wearing a bowtie and that makes it awesome. “Have a nice day!” indeed.

Paleolithic archaeology, software design, and the social brain

Over the past 18 months, I’ve immersed myself deeper and deeper in the Paleolithic, reading scores of books and journal articles. Why?

Backed knife on a Levallois blade - Right-handed (5)

Ever since my first visit at about age four to the Historical Museum of Hokkaido, with its mammoth skeletons and Paleolithic dioramas, I’ve been fascinating by the archaeology of deep human history (as Clive Gamble puts it in the subtitle of his exceptional book Settling the Earth). I wandered by chance onto the Tategahana Paleolithic Site at Lake Nojiri in Nagano during an excavation, walked carrot fields in Yokohama looking for Jomon potsherds, and when I traveled to Jordan during college for an Iron Age dig, I spent my evenings surface-collecting Middle Paleolithic tools from a nearby barley field. The vast, mostly unknown and seemingly unrelatable world of the Stone Age seems so much more interesting than the thoroughly modern world of Archimedes, Hadrian, and Augustine of Hippo.

The people driving their cars around the Coliseum in the photo below are separated from the Romans who built it by a mere 1% of the time our species has walked this earth. The archaeology of the complex, stratified societies that emerged during and after the Neolithic frankly bores me.


Photo by Kaosrimo on Wikimedia Commons

I’ve always been that strange arty type just as entranced by science and technology — there is no dichotomy or conflict for me. I’ve spent the last 20 years of my life melding my background in language and communication with a passion for data-driven research and the creation of new technologies. Despite being an English major during college back in the mid 90’s, my first “real” technology job was running the websites for several university departments, using vi on Sun Solaris to hand code the sites’ HTML — a skill carried over from repeatedly hitting F11 to Reveal Codes in WordPerfect on DOS.

When I finally took calculus alongside aspiring engineers and physicists, I had an epiphany: Mathematics and programming languages follow the same rules as music and human languages — a vocabulary with syntax and return values. Poetry is code. Music is math. And they’re not mere logic — they’re beautiful, emotionally rich expressions of this amazing, symbolic, social brain we’ve inherited from our ancestors.

When friends and colleagues wonder at my diverse interests — writing poetry, playing with LEGO, reading as much as I can about the Paleolithic, and running the planning and design teams for software development companies — I explain that there is a common thread throughout. I observe patterns and I make connections. I imagine and I explore. In doing so I create. I make stuff. I build things.

But I’m not special — to do all that merely defines me as a member of the human species. Understanding how we became us — and what “us” even means — is precisely what we can learn by studying human origins and the vast reaches of the Paleolithic. That is why I read.

Lean Content Is Smart Content

Closing out my conference junket for 2014, I’m at Information Development World in sunny San Jose, California. Content reuse is not the only tactic you can apply as part of your content strategy to reduce cost and improve discoverability.

How often have you proudly described the great big manual or Help system you just finished writing to your fellow tech writers, your manager, or even potential employers? But how much of that bulk was really necessary? How do you decide when you have too much content? How do you decide which content stays and which lands in the archive? Applying metrics-driven lean content principles & practices as part of your content strategy can not only save you money on maintenance and localization, but more importantly it can make your content more discoverable and usable.

In this session, I’ll provide both strategic advice on how to decide whether you need to streamline your content, as well as practical suggestions about the tools and techniques you can use to make the streamlining process successful.

ABecraft_Streamlining_IDW_2014

EDIT: You can now see my full presentation on SlideShare.

Techniques for Maximizing Content Reuse

Kicking off the conference season for 2014 in Palm Springs, California, I’m back at another WritersUA. Taking advantage of my experience across all the major content development platforms over the past 20 years, I’m presenting about the various ways writers can improve the level of reuse in their content.

Text insets, conref elements, embedded topics, variables, tokens – no matter what technology you’re using to create your content, there’s a dizzying array of options available to you to enable reuse. With all that power and so many choices at your fingertips, you can quickly paint yourself into a corner. To truly take advantage of the potential cost savings and improved consistency that reuse offers, how do you decide which techniques to use for which types of content, and at what level in your information architecture?

Though I promise this will be technology agnostic, it’s inevitable that I’ll occasionally reference the software I’m responsible for designing, developing, and delivering.

ABecraft_Content-Strategy_Master