Do Less Better

There’s a temptation to always want to do more. More features, more products, more whatever.

But sometimes the best thing to do is less. Get focused on the core of what you offer your customers or users and really dig down to figure out how to be the best at that small thing.

It’s all so simple

We have a fairly simple business if you look in from the outside. We help our users search for domain names, register one or more and add an email address or two if they want.

That’s it.

All of the underlying complexity of searching for, finding, registering, configuring, adding email, setting up DNS, etc. is nicely hidden from our users (for the most part).

But trust me…domain registration is far from simple. The fact that we make it look fairly easy is a testament to the smart people we have on our team.

We could add a bunch more services like hosting, a site builder, WordPress, SEO services, trademarks, Office 365, Google Apps, and so on. But in doing that, we’d lose our ability to do domains, email and DNS well. We’d be spread too thin and customer experience would suffer.

That’s not to say we’ll never do that stuff. Maybe we will. But when that day comes, it’ll require a bunch more people who look at their slice of the business the same way the current team looks at domains.

Not Having Data Leads to Bad Solutions

There’s a McDonald’s around the corner from our offices on the edge of Liberty Village. It’s not the nicest McDonald’s, mostly because it’s in Parkdale, but it’s fine if you want to get a quick bite and get out.

They have the new touch screen ordering system in place where you order on a screen, get a numbered receipt and you wait ten minutes with a dozen other people for some employee to get your food together. Eventually your order is prepared, someone yells out your number and you are on your way. It’s terrible customer service, but it works.

No ice cream for you!

For about two months now, at this McDonald’s, when you try to order a cone or sundaes on the touch screen kiosk, it says “Sorry, this item not available”. We all assumed that meant that ice cream wasn’t available because the machine was broken. Once or twice over the last couple of months, we noted that the ice cream machine was torn apart during the day and not working.

Today I walked over to see if I could get a hot fudge sundae. The kiosk said it wasn’t available so I figured I would ask the manager if they were ever going to have ice cream again.

She told me that there was nothing wrong with the ice cream machine.

Huh?

When I noted that the kiosk wouldn’t let me buy any ice cream products, she informed me that “too many people were buying ice cream from the kiosk and the machine would get overwhelmed so they had to stop selling from the kiosk.”

Wut.

In other words, demand for ice cream was greater than their ability to supply it so they stopped selling it entirely.

Valid problem solved badly

That’s admittedly a problem. It’s no good if you sell ice cream and the machine is overwhelmed and breaks down. The principle of supply and demand is fairly simple and my local McDonald’s has a few options. They can increase supply to accommodate demand, or they can limit demand to keep it below what they can safely supply.

Now, I’m no expert on economics or supply chain management, but I have to imagine that there is someone at McDonald’s who could do the math and determine whether it’s worth it to invest in an increase in their ice cream supply. And maybe they did that (but I doubt it).

I’m willing to bet you a McDonald’s ice cream sundae that the solution that they ended up going with – limiting demand by simply removing the items from the ordering system that the vast majority of customers use – was done without any analysis of whether adding capacity would have made more sense.

No data leads to shortcuts and bad bets

The temptation to take the quick and easy solution is always there for product managers just as it was for this restaurant manager. Maybe the quick solution is the best way to go, but without proper data and analysis, there’s no chance to fully understand the issue and come up with the right solution.

Since it’s now literally impossible to order ice cream from the kiosk, and since few (if any) customers know you can still order from the counter, how does McDonald’s know whether the demand at any given time still exceeds the supply?

Perhaps the demand for ice cream today would be lower than the threshold at which the machine would breakdown. It’s not very hot outside, and I bet that ice cream demand really matches up with the weather. But how would anyone at that store know? They can’t and they don’t.

Even worse, maybe eventually someone will maybe try to make the case to add a second machine, or switch to a higher capacity machine, and they won’t have any justification to do it. They’ll look at sales of ice cream and wonder why they would have to add more capacity when customer demand seems so low.

Apply it to your business or product

The same might apply in any business. An independent coffee shop with a single till might be losing customers who walk in during the morning rush, see a long line and continue to the Starbucks down the street instead (hello Louie…are you listening???). But if they asked staff how the mornings were, they’d say, “Fairly busy, but the lines never got too long.”

For the coffee shop, maybe a camera on the front door that revealed when people looked in and then walked by would provide the data required to make the decision to add staff, or capacity. But without the data being collected and analyzed, there’s no way to make that call.

The takeaway is this: collect the data, analyze it, and don’t opt for the easy solutions. Otherwise you risk turning good paying customers away and leaving money on the table.

Protecting Users From Themselves

If there’s one thing I’ve learned in my four plus years as a product manager, it’s that you can’t count on the user to do anything right.

You might design the most intuitive interface around. You might have perfect prompts and highly visible buttons and calls-to-action. But users will still get it wrong and it’s your fault because you didn’t stop them.

Those pesky users…

The solution for users like that is what makes the job of a product manager both infuriating and fun. How can you design a system or workflow that accounts for users who don’t know what they are doing? Can you save them from themselves if they do something dumb?

We spend a lot of time thinking about when to show warnings or information to users. Sometimes we deliberately leave information out because we’re fearful that the user will act on the information in the wrong way.

For example, at Hover, if you have your nameservers set to a third-party DNS system, you can still create and edit DNS records on our DNS system even though that literally does nothing. We do warn users that the DNS records won’t have any effect, but we don’t suggest to them what to do.

Some users in that situation should change their nameservers to Hover. Others should go to their DNS provider and add or edit the records there. But we don’t know which are which and if we make a suggestion (even if we suggest both options), there’s a good chance the user will do the wrong thing and break everything. Guess who gets the blame?

Just call us…

Instead, we suggest they call us or start a chat so that a smart human can talk it through with them and find out what really needs to be done. Yes, it costs us a support interaction, and it takes some time and maybe adds some frustration for the user. But when you can’t count on your users to know what to do and to do it, sometimes protecting them from themselves is the best option.

The end result is that the user gets their problem fixed and we don’t hold there hand and walk them off a cliff.

How Being a Marathon Runner Makes Me a Better Product Manager

Aside from getting hours a week to think while out running, there are some shared lessons to learn between being a marathon runner and product manager.

Here’s a few that I came up with (while out on a run, naturally):

  • It’s about having a long-term goal and a plan to achieve it — training for a marathon takes months. You map out a schedule with various runs, and your gradually build until race day. As a PM, the product roadmap is your guide and you plan out a strategy to get you there over the course of many sprints.
  • It’s about collecting and analyzing the right data — cadence, pace, heart rate, effort, what I ate, how I felt…it all goes into painting a picture of where I’m at, where I need to work and whether I’m improving. On the PM side the same holds true. Collecting and analyzing the right data gives insights into where to work on the product, and whether what we released had the intended effect or not.
  • It’s about taking thousands of small steps — when it comes to the marathon, you can’t go into it thinking about all 42.2 kilometres. You break down the training into weeks and days, and the race into kilometres and even steps. As a PM, you need to focus on getting from here to there, but not all at once. Iterate, take small steps, learn and repeat. Keep it moving.
  • It’s about learning from those around you and sharing what you’ve learned — I talk to running friends and learn from their experiences to grow as a runner. I share my experiences with others to help them grow too. It’s a community. As a PM, I learn from other product managers and study other products to learn things to apply to my own product. I share what I’ve learned with others to help them do the same. It’s a community.
  • It’s about highs and lows, and celebrating the good while learning from the bad — you have good runs, and you have bad runs. Some races it all comes together. Other races…not so much. As a PM, some releases are a reason to celebrate while others leave you scrambling to understand how you got it so wrong. In both cases, you learn from it and move forward.

Midway through the BMO Vancouver Marathon
Midway through the BMO Vancouver Marathon
I’ve been a runner since 2008, and a marathoner since 2010. I consider myself a veteran marathoner now after eight full marathons and two ultras. I learned a lot in my first few years as a runner, going from running for about 20 minutes at a time to running a 50km ultra marathon in five hours and 18 minutes.

I’m a relative rookie as a PM, only taking the job at Hover in the summer of 2013. Similarly, the first few years as a PM have been spent getting my feet under me and building up the skill set to work with our team to make a great product.

In both roles, I still have a ton of learning to do and goals to achieve.

Know Your Product

If you are asked a question about the product you manage, there are only two answers that will suffice:

  1. The answer to the question.
  2. “I don’t know, but I’ll find out for you.”

If you aren’t the expert on your product, then you’ve got work to do. There should be very few stumpers when it comes to the ins-and-outs of what your product does, what it’s good for and how to use it.

Count the “I don’t knows”

It’s not the end of the world if someone asks you something and you don’t have the answer at hand. You can’t know it all. But if you find yourself saying, “I don’t know…” a little too frequently, then it’s time to dig in and give yourself an in-depth refresher on just what you are building.

Most importantly, when you don’t know something, make it a priority to get the answer. You owe it to the person who asked (especially if it’s a customer) and you owe it to yourself and your team.

But I just got here!

It’s particularly tough for product managers who didn’t work on the product from the start. It’s not an easy job to get up to speed and become an expert user. But that’s your job.

Photo credit: Christopher Sessums
Photo credit: Christopher Sessums
Don’t overlook users when it comes to learning about your product. Watch them use it. Talk to your support team and ask to watch them work.

Once you think you know everything there is to know, go back and learn some more.

Why it matters

It’s hard enough to build a great product with all of the information and experience and knowledge. Having less than the full picture puts you at a huge disadvantage.

Knowing exactly how (and why) things work the way they do gives you the great insight to understand how to make it even better. Seeing where you get frustrated, or watching your users run into roadblocks shows you where you’re coming up short.

When it comes to leading a team, not knowing how things work puts you in a tough spot. It’s a waste of a developer’s time when she or he has to explain that the feature you asked them to build is already there. Support has enough work to do supporting customers…don’t make them spend valuable time on you. Marketing should be able to lean on you to explain how something works and why it matters to your customers.

Be the expert on your product.