Easy to Use is Not a Feature

Really sorry to say that, but it’s true: Easy to use isn’t a feature. It’s a selling point. It’s marketing copy. Just look around and see all the different products out there. I see this and hear this all the time. Talk to a rep, and they’ll say the same when faced with the choice of option A versus option B. Never will you find a company that sells their product as “Most Difficult to Use ERP System!”

Building a product that has the right features and not all the features is just part of finding the  product market fit. Sure, making it easy to use is just part of the task.  No product manager in their right mind will purposely build a product that’s going to be like setting up the Large Hadron Collider. Building the right features and learning from it is the path to a successful product.

Making Stew Is Easier Than Baking Bread

Flour, water, yeast, salt.  Just a couple of simple ingredients to bake a nice bread in your oven.  But the steps involved prior to your first taste may sound easy, but it really isn’t.  Exact measurements are required for all ingredients on your kitchen scale.  The oven must be right temperature, and the constant kneading of the dough over the course of several hours will presumably make great bread. But things happen, and once it’s ready for the first taste, it might not be what you expect and you may not initially know why this happened.

That’s why you should try to make stew when it comes to modern day product development. The idea is there, the recipe is close, and you start throwing ingredients at your stock pot. We know that simmering it a little longer would make the stew just that much more flavorful.  Just like in the product development cycle, a quick taste during the simmering process will give you a sense of where the stew will be going. A little pinch of salt, and a crackle of pepper is no different than taking a look at the product and making a minor tweak to it.  With the stew, you have the opportunity to stop it early when it’s ready for consumption, or keep simmering it down to tighten up the flavors. In a product, this could be tightening up the design. Keep checking, keep tasting, keep adjusting and you’ll have great stew.

This a comparison between waterfall (bread), and agile (stew) methodologies.

Evolve Your Product

A common theme with web tools I use daily are very jarring and big changes to the core functions of the product. Overnight. There were many times where I find myself using a tool on a Friday, and come Monday, the entire UI changes dramatically. It then can become very difficult to find the actions I use, which may lead to frustrations.

How many times have you heard your peers say “oh, Company A changed their app again!” and “What happened? I can’t find anything anymore?” The solution? Evolve your product. It needs to be a natural progression to be able to get your users ‘trained’ to use the function, and not feel forced.  There are some good and bad examples I’ve seen out there.  When Google Maps changed their UX about a year ago, it felt a bit painful and quite dramatic.  There was always a way to escape out of the new UI and continue to use the classic one.  What I noticed they did from an outsider’s perspective was that they gradually made changes over time during the beta period.  The changes were quite small but significant enough that the user experience continually improved over the course of time.  Today, I don’t consciously realize I am using the new UI.  The transition was smooth.  Striving for this as a product manager is a goal.

Good User Experiences Begin at First Touch

User experience seem to be the hot topic in Silicon Valley these days.  There’s always talk about it being the number one thing a company needs to focus on.  Without it, it doesn’t matter how many boxes your product checks off, it won’t be usable.  I’m going out on a limb and say that the experience should not be just in the product itself.  It’s well before that.  It’s at the first interaction your customer/user has with your company.  The first touch.

With web applications, a user may start their search traditionally on a search engine.  They will probably be taken to some landing page where there is some information about what they are looking for, and hopefully, a call to action.  Now this is where the user has their first experience interacting with your company.  This page is very important.  It must answer three basic questions:

  1. What does your company do?
  2. Why do I need it?
  3. What is the next step?

If these three questions can be easily answered on the page they are viewing, they might be more likely to convert.  Miss just one, and they’re leaving.

Another way to explain it when you’re out looking for an Italian restaurant with friends.  You search on your phone and find Joe’s Italian Restaurant.  It’s probably pretty clear that they serve Italian based on the name.  Check.  Looks like they are a traditional Tuscany style restaurant.  Luckily, you are craving a Florentine steak.  Check.  Bonus points, they take reservations.  There’s your call to action to call them up or book a table online.  The story will be no different even if you stumbled on the restaurant walking around neighborhood.  The experience begins the moment you spot it, and step inside to and ask for a table and doesn’t end until the check arrives.

Why I bring a chair to a casual meeting

Back in high school, I remember having an english teacher who always carried a short stool around.  Not one you would play a guitar on, but one that is quite low.  He would give us an in class assignment to do and sit down at his desk.  If we had a question, he would walk over with his stool, sit on it to be at eye level with us.  His reasoning was great.  He wanted to make sure we were comfortable, and that his 6 foot frame would not be intimidating to us.  It puts him more on a personal level with us.

I still think about this today in the workplace.  I may not practice this to the full extent by bringing a stool around with me, but when I do need to run over to a colleague’s desk for a quick discussion, I do ensure I grab a chair near by and have a seat.  It keeps me in a more comfortable position when speaking with my colleagues.  I don’t want to feel like I intimidate others by standing tall while the other(s) are sitting.  I do hope that I come across softer, and more professional.  I may not be a psychologist, but standing and speaking in a non-formal situation puts you in a more commanding position.  Probably not your intention as there is certainly a time and place for that.

Switching roles.  If you were the one sitting and the other is standing, most individuals feel a bit more intimidated, and possibly put on the spot.  In those cases, I stand up and put myself at their level.  Much like meeting someone for the first time with a handshake, it is considered rude to not stand up and perform the shake.  It can show a lack of respect.

So the next time you need to speak to someone, grab a chair, stand up, squat.  Just put yourself at the same level.

The Fine Balance of a Minimum Viable Product

One of the most difficult task for a product manager, let alone a company to do is finding that Minimum Viable Product (MVP). Whether you are trying to launch your first product, or updating an existing one, you’ll need to make those hard decisions to cut features and functions. If you’re going to try to get Widget A to have all 100 key features from its initial conception, don’t hold your breath. By the time you launch your product, you might already be chasing your competitors. YMMV.

But MVP doesn’t necessarily mean that your product won’t have any features. It may mean that you have just enough to get your customers off and running for the time being. With a SaaS product, you do have the freedom to go back and forth with your customers to fine tune your product. Missed the boat with a feature? Get those major items identified early on in your research.

I do like to make sure you give your customers the functionality they need to be able to get their job done. Just enough. Put the must-haves and nice-to-haves in separate buckets and move them from one side to the other based on your research. An important aspect of this to not forget to return back to your MVP and find out if the nice-to-haves still need to be implemented. You might find out it’s not needed after all.

It is a fine balance between what’s needed and what’s enough.