I never would have bought this book for myself. I won it in a drawing at InBubbleWrap.com. I’m not sure what made me enter the drawing. Maybe it was, Eh, it sounds moderately interesting, and it’s free. Or maybe it’s that I have a soft, cuddly spot in my heart for Build-a-Bear Workshop. And as I read through, I recognized lessons I had learned in developing software, especially from Agile development.
The book I’m talking about is The Bear Necessities of Business: Building a Company with Heart by Maxine Clark, the founder and Chief Executive Bear of Build-A-Bear Workshop. If you’ve been following this blog, you know I’ve been reading it and finding inspiration and enlightenment. I wanted something a little different, and I picked it up off my shelf, and I started reading it, and I was like, “Wow! This is really good!”
Maxine Clark has a child’s heart and advocates a child-like approach in order to spawn success. So Build-A-Bear Workshop is not just about selling stuffed toys. It’s about fun. That’s why the company has no CxO’s. Instead, it has a Chief Executive Bear, a Chief Financial Bear, a Chief… and so forth. Seriously. No joke. To me, these and other Bearisms just seem, well, corny. (“Everything is pawsible when you put your mind to it”? Puh-leez!) However, I had a different reaction to sidebar quotes like:
- “Get involved in the successes and accomplishments of those who work for you.”
- “There are some simple things you can do to make sure each workweek begins with anticipation and fun.”
- “Give workers license to take risks without fear of failure or management’s wrath.”
- “Experiment freely, and view every so-called mistake as one step closer to getting things right.”
- “Bosses are in charge and dictatorial. Leaders listen to what their employees have to say and create a climate of reciprocal respect.”
- “Ask new hires what you’re not doing that their previous employer did that could make their jobs easier and the company more successful.”
- “Positive reinforcement works much better than criticism.”
- “Never castigate an employee in public or use his or her mistake or failure as an example.”
Again, if you’ve been following this blog, you’ll know that these strike a chord with me. Actually, I whittled the above list down to just the best of the best of the best. Reading The Bear Necessities of Business, I came to see that Maxine Clark has made success out of all the things I believe in.
Numerous chapters connected with me. But here I want to talk about just two parts of the book, part 3, “Connecting with Your Customers,” and part 4, “Creating an Incredible Experience.” So often, all a software team needs is to learn these simple lessons. Starting with the first, the simplest, the most child-like…
1. See Through One Small Person’s Eyes
Build-A-Bear Workshop came into being because of a 10-year-old girl named Katie, who one day picked up a Ty Beanie Baby and said, “You know, these are so simple. We could make these.”
Katie is now nearly twenty, but that 10-year-old girl is the customer Build-A-Bear Workshop still has. This company does not muddy its message by trying to make it palatable to everyone. Rather, it speaks to 10-year-old Katie and gives her what she wants. Play is important to her, so the Workshop does not rush Guests through the store. Guests may stay awhile and play. She likes playing with her friends, so Build-A-Bear holds parties in all its stores. While young, she wants to be older. So the bears have age appropriate, brand-name fashions. She likes to dress up. So they sell bear-sized princess outfits, wedding dresses, and superhero costumes.
If you’ve ever been to a Build-A-Bear Workshop, you’ve seen many more of its unique elements. Every one of those came from or was approved by a child. The company even has an advisory board made up of—You guessed it—children. Maxine recounts showing the Cub Advisory Board at World Bearquarters the new Floppy Kitty:
Originally, the cat was a vibrant yellowy-orange, a hue that one cub adviser described as “like macaroni and cheese.”
“That’s great,” I remember saying. “Everybody likes macaroni and cheese, right?”
“Yeah,” piped up the little girl. “But you wouldn’t eat your cat.”
They changed the color of the Floppy Kitty before putting it in the stores.
So what does this have to do with software development? Many software teams don’t know their customer. Or else they don’t think about their customer first. They spend time on features the customer doesn’t want. Meanwhile, what the customer needs gets short shrift.
That’s why some of the most important key practices in every Agile methodology have to do with connecting developers to the customer. Alistair Cockburn talks about “frequent delivery,” getting deployed software in the hands of real customers, the most important of his 7 properties of successful software teams. Then at number 6, he brings up the customer again, with “easy access to expert users.” In XP, we have the planning game, where the customer’s representative gets in a room with the developers and hashes out what’s most important for the upcoming iteration. In Scrum, we have the backlog and all that goes along with it. All practices whose most valuable function is to keep developers mindful of who the customer is.
We often argue over quality. What’s quality? It depends on how you measure it. It depends on where you’re standing. But in the final analysis, there’s only one person whose point-of-view matters. There’s only one person’s opinion that counts. Our customer.
2. Eat Your Own Bear Food
We’ve all probably heard the phrase, “Eat your own dog food,” meaning we should use our own software. Unless we produce a development tool, that’s probably a rule more honored in the breach than in the observance. But the value of eating your own dog food is not about software. It’s about seeing yourself through your customer’s eyes. As Maxine Clark puts it, “Among the best ways to get inside the mind of your customers is to act like one.”
She frequently visits her stores, not as Chief Executive Bear, but as a first-time visitor. She talks to the staff as though she doesn’t know what she’s doing. She lets them help her select a toy, customize it, pick out clothing for it. Of course, by the time she reaches the checkout line, the manager has usually discovered her. The idea is not to check up on the staff but to discover first-hand what it’s like to be one of her own customers.
Even if we can’t be a customer, just watching customers is a great way to find out what they’re thinking. This is the idea behind usability tests. Most of us say, “We can’t afford usability tests.” But even if we can’t afford a full-blown usability lab, we can surely afford to ask a user to try some new feature so we can see how well it works. If we have a functioning Crystal team, we should have easy access to expert users. In most teams, we could ask actual customers to try out the new feature, and they’d feel privileged to be in on cutting-edge development.
But to apply Maxine Clark’s advice, “See yourself through the public’s eyes,” we don’t need to see our customers using our software. We need to see our customers using us. We need to see the planning game from the customer’s perspective. We need to visualize what it’s like to make someone else understand your requirements, tell them it’s not quite right, request a change, and see delivered features (or not).
Maybe we’d all get a little closer to this ideal, if occasionally each of us sit back and noticed how his customers are behaving, really notice. Not to solve, not to judge. Just to take it in, to observe, to learn. Indeed, this is another tactic Maxine Clark recommends:
In addition to shopping incognito, I like to ease into the background and simply watch and listen to what goes on in our stores. I’m like a lab student observing an experiment through a two-way mirror. Even at our World Bearquarters in Saint Louis, I frequently walk around the office. By doing so, I get to eavesdrop on the conversations our associates are having about concerns expressed by our Guests. It’s yet another way I put myself in our Guests’ shoes.
Eating your own bear food isn’t just about using your own software, it’s about using your own services. It’s about a experiencing the full customer experience, good, bad, and ugly. And if we do this, we’ll discover…
3. It’s More About the Experience Than the Result
No matter who you are, when you step into a Build-A-Bear Workshop, you’ll get the same treatment and the same opportunities.
We offer the same interactive experience to our Guests, whether they’re 3 or 103, and it’s their choice how far they take it and how involved they become. We have some adults who are very reserved as they make their bears. There are others who just overflow with enthusiasm and go through each station with gusto. They give their hearts a big smooch, jump up and down, and sing silly songs with their friends. They preen over their newly made bears and try several outfits before deciding on just the right one. They cuddle their animals, name them, and enthusiastically accept the free stickers and ribbons we give away. And they walk out with huge grins on their faces.
The point is that at heart, we are all little kids. We love to have fun. We want someone else to provide for us. And we hate to worry. We want to feel someone will take care of it and everything will be alright.
Software customers are that way, too. I remember overhearing a conversation a project lead was having with an off-site customer, via a speaker phone. He apologized profusely that he was not going to be delivering the software he had promised. The team had discovered some critical issues that required significant changes, and they just weren’t confident that the software was free of bugs. So he was keeping the software back for another week in SQA. He actually used the phrase “beg for forgiveness.”
It will forever be etched in my mind how that customer responded. He said, “Yeah, that’s okay. I just want to know what’s going on. So you plan on releasing it next week?”
Our customers don’t know software development. They don’t want to. They want someone else to take care of it. They don’t care about lines of code or bug count or SQA or race conditions or deadlock. That’s our job. Our customers just want to know what’s going on. Keep them up to date on how your progress will affect them. Make their job easier by giving them the best information you have as soon as you have it.
There are other ways we can bring out the child in our customer. How about giving him free stuff? That is, implement that extra feature you didn’t plan to have time for. Listen to him, and make sure he heard you listen to him. Answer him respectfully. Make his concerns your own. Treat him like a friend to the team, rather than a burden. One of the reasons Agile practices work so well is that they involve the customer, from planning to deployment.
In short, let the customer experience be a priority. People care more about how you make them feel than how much you get done. If they see you going out of your way for them, it’ll be easier for them to get on your side.
4. Invest in Future Value
One of the most profound insights of this book was the following statement on page 148: “Spending more creates more value.” That is, getting bargain prices is not necessarily better. Doing without is not necessarily better.
When faced with expenditures in your business, think carefully about the long-term consequences of your spending. Weigh the future impact of that investment against the near-term challenges that will be created if you part with the money. Then, make the all-important choice: spend or scrimp.
Money spent wisely now will pay off for you in the future.
Buying better equipment will mean we’ll spend less time waiting for the computer. Using the right tools will short-cut problems. Hiring better people will mean fewer mistakes and more maintainable code.
But not all of our expenses are monetary. What about taking some extra time up-front on a good design, rather than hacking together something just to get it out the door? That will mean fewer bugs and more maintainable code. How about removing dead code? Or cleaning up that monster function before hacking on it? How about migrating to a more appropriate technology? Or doing code reviews?
Value-creating spending occurs even on the personal level. I try to take a walk every day. It’s important that I take a walk every day, because if I miss a couple of days, I’m likely to start having trouble thinking. Likewise, it’s important to work moderate hours, giving your mind plenty of time to recuperate. And read, read, read. Keep your mind and your creativity awash in new information and new ideas. These things may seem like a waste of time in the short-term, especially if you’re under the gun. But they pay off, and if you’re not doing them, you’re losing out.
None of these expenditures are waste. Even something as superfluous as spit-and-polish is a value-adding investment, because it’s an investment in the user experience. From the Build-A-Bear checkout counter, you’ll carry your bear in a Cub Condo carrying case. It’s a box. It’s a toy. It’s a walking billboard. And Build-A-Bear pays less for it than they would a paper bag. But even if that weren’t true, the Cub Condo, like everything else at Build-A-Bear Workshop, is an investment in the customer experience. And that brings us to…
5. Escape from the Ordinary
You don’t go to Build-A-Bear Workshop to get a stuffed bear. You could do that anywhere. Rather, you go there to bring to life a friend of your own creation. Or to quote trademarked tagline, Build-A-Bear Workshop is “where best friends are made.” Build-A-Bear Workshop was not the first store that let you build your own stuffed bear. But it was the first to turn it into an extraordinary experience. What makes Build-A-Bear Workshop different from the other stores is the multitude of touches that make its customers feel special.
I was on a one-man project. As part of this project, I said I’d deliver a certain feature with certain functionality by a certain day. And I did. When my customer saw it, he replied via email, “I wish you had showed me this earlier.” He said the way it worked was not right, and he needed it to work this other way. My manager was livid, because we had gone over what it would do, all of us, and the customer had signed onto that, and I had implemented what we had gone over.
How did I react? I just fixed it. I had designed the code so I could make changes, and a half-hour later, I had what the customer wanted. Clearly, he did not expect that. He seemed to be gearing up for a game of Blame the Programmer. My manager seemed surprised, too, probably preparing for a game of Blame the Customer. To them, the problem looked insurmountable, like I needed to rearrange everything to get it to work. As the developer, I saw that I only had to rearrange one particular function and use a slightly different algorithm. No huhu. And I delivered the unexpected. I think I made brownie points that day.
Another of the things I love about Agile development: We get to demonstrate concrete progress to the customer. We get to find out earlier, rather than later, what the customer wants. And we get to deliver it to him, probably faster than he’s used to. And we do that all without even breaking a sweat. As you know, it’s not a matter of donning blue tights and a red cape. Rather, it’s about focusing on what works. But to the customer, it can look like we are indeed Super-programmers. And you know what? I’m fine with that.
What the book’s really about
The Bear Necessities of Business is written in an easy-going style. Like other business books by CEO’s, it’s full of practical techniques the author uses in her own business. Unlike other business books by CEO’s, in this one Maxine Clark and her co-author Amy Joyner also include many examples from other businesses. I didn’t talk about that in this blog post, since my focus is on what software teams can learn from Build-A-Bear Workshop, not from other companies. But as you read the book, you’ll see where companies like Apple Computer, Tiffany, Disney, Toys “R” Us, Wal-Mart, Burger King, and many others have done the same as Build-A-Bear and succeeded, or done differently and failed, or even done differently and succeeded. These last are tactics you can expect Build-A-Bear to try soon. Stay tuned.
There you have it, five lessons software teams can and should learn from Build-A-Bear Workshop. Will many teams learn them? Unlikely. Will yours? Only you can tell.