We Can Do Better
The five of us entered a restaurant across from the Sai Yee Street Garden on Soy Street in Hong Kong. We’d been walking around Mong Kok for a while, looking for a place to eat. Nothing was looking good, but we figured, enough walking, let’s just go in and eat.
We’d been at Savannah College of Art & Design — Hong Kong earlier in the evening and while there were snacks (and a tour of the cool, previously-a-jail building) it was past time to eat real food. Some of us were getting hangry.
We were shown to a table near the open kitchen. Handed menus. Almost immediately Amber, our guide for the evening, said something to the extent of, “Matthew, you’re not a vegetarian, are you?”
In fact, I am. Been that way since 1994 or so. Usually that’s neither here nor there. But when you are at a conference, in a city you don’t live in, in a country where you really don’t speak the language other than to ask for the bill and say “thank you,” being a vegetarian becomes here and there.
“There’s nothing on this menu you can have.”
Usually when I hear those words, it’s an exaggeration. In this case, there was literally (classic definition) nothing on the menu that didn’t have meat on it or in it. Even the items identified as vegetarian (shaved pork sprinkled as a garnish on steamed lettuce!).
But that’s fine. For me, in that moment, or any like it, I really don’t want to be the one person that others have to work around. Everyone else was fine with staying, including me.
Amber wasn’t. She was in full-on host-mode. She closed the menu, stood up, and declared, “Come on. We can do better.” I was the only one who protested. We got up, went down the street, and we actually did do better. Better food, more choice, better ambience, and everyone was included.
Amber’s “we can do better” has always stuck with me.
For most software, iteration is the name of the game. You build the first version, let’s call it the Minimum Viable Product (MVP) and if that version finds enough success to warrant version 1.5, then version 2, etc.
What interests us is what happens prior to all that. This is the stage for all decisions you are able to make in the future. Exploring opportunities, evaluating hypotheses, and forming an idea. Then on to Alpha, Beta, Beta 2, Beta 3 …
Here, getting things right, doing better, can make all the difference.
We start with an hypothesis. We have to, in most cases, as there’s a budget to consider and even when we’re doing exploratory research, we’ve got to scope our exploration to something. But at the same time, if said hypothesis doesn’t pan out, we toss it out and start with a new hypothesis based on the data collected to that point.
The data we collect is based on interviews, surveys, usability testing (of current and potential interactions and processes), and a number of other methods. For the most part, the plan is to build confidence that we’re on the right track to “better,” whatever that means in the context of the project.
Which Leads to an Idea
“I want to build a new social network.” What you really want to do is make something that connects people online. You want to make it easy for one person to make another person laugh by posting a picture with the caption, “Remember this?” You want to enable people to get things done together. You’d like to make money while doing it.
Whatever the idea you have, it shouldn’t be stated in terms of a solution. It should be stated in terms of goals and outcomes. It should be centered on people.
This isn’t a difficult concept to grasp intellectually. You probably agree with me. And yet, we see terrible apps all over the place. Apps with such ridiculously minimal functionality you wonder if those building it fell asleep part-way through.
There’s that word. Minimal.
You down with MVP?
Build just enough of a product to put it out in the world, let anyone and everyone give you feedback. See if your idea is viable. It sounds very reasonable.
There is evidence to suggest it’s a really good idea. But I don’t think the way “minimum” and “viable” are typically defined lead to good outcomes. Sometimes good outcomes are lucked into, but that’s not a good foundation on which to build a product or a company.
“Minimum” as a modifier gets placed, within conversations, wherever it needs to be to make the person’s point. More often than not, “minimum” is applied as a modifier to “product.” These are the bad conversations—the ones that focus on the minimum amount of functionality that needs to be built for people to use said product. It skips over viability.
When people ignore the viable part of an effort, they are essentially saying, “Let’s build a Minimum Usable Product.” If you are doing this on purpose, fine, but call a MUP a MUP.
When the conversations use “minimum” to modify “viable” I think this is closer to the point. I suspect most people would say, “We totally do this! Not that MUP thing.” Maybe you do. But I don’t think it’s enough.
If you’re saying, what’s the minimum amount of effort I can put in to get the maximum amount of reward, well … you’re speaking my language. But if you’re saying, let’s put in the minimum amount of effort and we’ll see what happens, well, you’re just making shit up.
Viability defines what it takes, as a baseline, to live. In the product world, that would define the core functionality or feature set that is needed to be successful on its own.
Everything done after viability is met enhances what is there (or becomes bloat because you’re supposed to always keep adding on to a product, right?).
A viable product doesn’t deliver 30% of the features with the hope that things just really take off and you can then have the support you need (eyeballs, clicks, users) to finish out that pesky 70%.
What does this mean?
A company’s reputation feeds as much into its ability to turn a profit as does the things it creates in its operations. Your design should take that into account. The people who approve your deliverables should understand that. The people that sign the cheques should demand it.
It’s on all of us to stand up, be good hosts, and say “We can do better.”