What Happens Next?

Today I’d like to talk about why that feature you’re building has taken twice as long to build as you thought it would and why it will be hard to use once you’ve shipped it. The problem is that you didn’t really think it through before you started coding.

Before I jump in, I want to point out that this is not, in fact, an argument in favor of big, up front design, or an argument against Agile or Lean. Please believe that the technique I’m sharing here can very easily be used in any sort of environment.

When you create an interaction for a product, you have to design more than what it looks like. You even have to design more than what happens during the interaction. You have to design what happens after the initial user interaction. And then you have to keep going.
Design what happens after the initial interaction. Then keep going. — Tweet This
Let’s take a look at an example. Let’s imagine that you have an e-commerce product that sells children’s books. You encourage readers to post comments and ratings. It’s a new product, so everything is very bare bones. You didn’t spend a lot of time building a huge commenting system before you knew if anybody would leave comments. Instead, you just made something very simple where people can leave a comment or read a comment. Well done! That’s very Lean of you.

Then one day, you have to have this conversation with your designer:

You: Oh my God. People are awful!

Designer: Right?

You: Someone posted an ad for penis enhancement on the Where the Wild Things Are page, and I didn’t see it until someone sent a customer support email. It could have been there for days.

Designer: We should probably have an easier way for users to flag inappropriate content than sending us an email.

You: I guess we should. Can you add flagging to the comments?

Designer: Sure!

A little while later, the designer claims he’s added flagging to the design and is ready for engineering to implement it. The design looks like this.

“Well, that’s easy,” you think. “I’m just a few minutes away from users being able to tell me when a comment is inappropriate.”

Then, of course, the design goes to the engineer. And the conversation goes like this.

Engineer: What happens when a user clicks the flag link?

You: Well, the comment gets flagged.

Engineer: Ok, I’ll set a flag in the database whenever a user flags a comment.

Hopefully you can see where this is going. The upshot is that, when a user clicks the flag link, the database will record that fact and…well…nothing else. The user who clicked the flag link won’t get any feedback. Nobody will be notified that something was flagged. You can’t do anything with the user report about the comment.

In other words, nothing has been planned beyond the visual implementation and the initial user interaction. And this is all happening because you only designed the initial user interaction.

So, what really needs to happen for this feature to be considered usable and useful? What is the minimum set of subsequent interactions that need to be designed after the user clicks on the flag link?

Probably something like this:
  • The user who flags a comment should get a confirmation that the comment was successfully flagged and be given some sort of information about what will happen next. 
  • Someone at the company should be notified in some way that a comment has been flagged. 
  • Someone at the company should be able to view the flagged comment and probably the identity of the person who flagged the comment. 
  • Someone at the company should be able to remove the flagged comment. 
  • The person who left the flagged comment should be notified that their comment was removed.
“My God!” you say. “My little, tiny feature has ballooned into an enormous undertaking! This is feature creep!”
What really needs to happen for a feature to be both usable and useful? — Tweet This
Well, no. It isn’t. You see, these are all things that would have to happen just to make the feature work at all. If you allow people to flag comments but don’t have any way for someone at your company to deal with the flagged comments, you’ve designed half a feature. Or, more to the point, you’ve designed a broken, unusable feature with a dead end.

Of course, that’s just the minimum set of things that need to be designed. There are all sorts of optional pieces like letting the flagger know when the issue is resolved or letting the flagger indicate why she’s flagging the comment or letting a customer service rep know how often people have been flagged so they can decide whether to ban the person. That last one would mean that you’d need some affordance for banning users and preventing them from returning.

Now, if you’re being very Lean Startup, you can always build the customer facing side first and decide not to build the admin side until people start flagging comments. In that case, when someone flagged a comment, you could simply have an engineer go into the database and remove the comment if you deemed it offensive.

That absolutely counts as designing a solution to the problem, by the way. It’s just a very manual design, and it’s probably one that won’t scale very well.

Why Should You Bother? 

Now you’re probably thinking that this all sounds exhausting and wondering why you would bother thinking through all of this stuff. That’s understandable. It can be exhausting. Do it anyway.

You see, thinking through the entire flow of interactions after the first one has a huge benefit to both your product and your product development process.

It helps your product by making sure you don’t have a lot of dead ends and awkward experiences. You don’t, for example, have a flagging feature that doesn’t result in flagged comments being pulled from your pages. This goes a long way toward making your overall user experience about a thousand percent better than the majority of products I use on a daily basis.

This process also improves your product development by helping you to understand the true complexity of a feature before you build it. You will never know exactly how long something will take to build, but you can certainly tell that building a flagging feature that works will take a lot longer than just putting a flag icon on each comment.

By fully exploring the complexity of features, you are better prepared to prioritize your backlog.

So, How Do You Do It? 

It’s pretty simple. Instead of thinking of your feature, think of the end user’s intent. Then, every time there’s some sort of interaction, you need to ask yourself, “has the user’s intent been satisfied?” If not, you’re not done, so you need to ask yourself, “What next?”

For example, your user isn’t going to flag something because she just loves flags. She’s going to flag something because she wants an offensive comment removed from a product page. Let’s go through the interaction sequence until that intent has been satisfied.

  1. A user can click the flag icon. Does this result in the comment being removed? No? Ok, what next?
  2. An email gets sent to someone at the company. Does this result in the comment being removed? No? Ok, what next?
  3. The person at the company asks an engineer to remove the comment from the database (which the engineer has agreed to do). Does this result in the comment being removed? Yes? Great! You’re done (for now).
Just keep asking yourself what’s next until the user’s intent has been met. It’s the best way to guarantee that your features do what you think they do and what your users expect them to do.

Like the post? Follow me on Twitter. 

Also, check out the book for more product and UX tips — UX for Lean Startups.

The Most Important User You're Not Talking To

Do you have a product? With users? 

If you answered “yes” to both of those questions, you have an amazing untapped source for product research. And I’m not talking about your users. 

I mean, sure, you should be listening to users and observing them. A lot. But there’s another group of people who can provide you with incredible insights into your product. 

You should be talking to people who used your product once and then abandoned it. Tweet This!

Specifically, you need to ask these people the following questions:
  • What were you expecting when you tried this product?
  • How did it not meet your expectations? 
This research will help you understand three things very clearly:
  • What your messaging and acquisition strategy is telling people to expect.
  • What problem the people you are acquiring are trying to solve.
  • Why your product doesn’t solve this problem for the people you are acquiring. 
You’ll notice that I mentioned “acquisition” in each of the above points. This is intentional. You see, one of the things you are very likely to find out from this sort of research is that you are getting entirely the wrong group of people to try out your product. 

If you’ve been spending a lot of time optimizing your ads and your messaging for sign up conversion rather than for actual product usage and retention, it may turn out that you are acquiring a whole lot of the wrong sort of user for your product, which can be a costly mistake. This kind of research is fabulous for understanding if that’s true. 

The other thing that this research helps with is understanding whether or not you’re adequately solving the problem you think you’re solving in a way that users can understand. If new users can’t figure it out what your product does and how to do it in a few seconds, they’ll leave without ever knowing that your product was the solution to their problem. 

Of course, this isn’t the easiest group of people to interview. These folks can be tricky to track down and tough to schedule. But finding a way to interview people who thought they wanted to use your product and then changed their minds is something that will pay off hugely in the long run.

Building the Right Thing vs Building the Thing Right

This originally appeared as a guest post on the O'Reilly Programming Blog.

I love it when companies test prototypes. Love love love it. But it makes me incredibly sad when they use prototype testing for the wrong thing.

First, let me give you my definition of “prototype testing” here. I often build interactive, or semi-interactive, prototypes when designing a product. These prototypes are not actual products. They’re simulations of products. People who see the prototype can often click around them and perform some simple tasks, but they’re generally not hooked up to a real back end system.

“Well, what good is that?” you might reasonably ask. Excellent question. Interactive prototypes are incredibly useful for finding problems in usability testing settings. In a checkout flow, you might create a simple interactive prototype and watch four or five people go through the process (with test accounts) in order to find out if there were any parts of the flow they found confusing or hard to use.

It’s a great technique for any reasonably complicated interaction that you want to test before you spend a lot of time writing code. Interactive prototype testing can save you a ton of time because it helps you make sure that you’re building the product right before you spend a lot of time and money actually writing code.

Read the rest of this post on the O'Reilly blog >

How Bad Can I Make My Product?

Imagine that I have a product that cures cancer. Sadly, the side effect is that you may lose a few toes. I’ll bet that I would still have a huge line of customers who want to use my product.

Now, instead of curing cancer, imagine that the product tells you where you should eat lunch. Unfortunately, the toe-loss thing still applies. I’m going to go out on a limb and say that I’ll probably have far fewer customers.

This seems obvious. Sacrificing a toe or three doesn’t seem like a big deal when weighed against your life, but it’s a different story when it’s just lunch. Even a really good lunch.

If you are asking your users to put up with a lot of pain, you need to do so in the context of giving them something extraordinary. I get asked all the time how to tell when something is good enough. Does it have enough features? Is the visual design pretty? What if it has a couple of bugs?  The answer to all of these questions is that it depends on whether the users are getting enough in return.

Every startup has a slightly different calculus for deciding what product to put out into the world, but I’m going to give you a piece of advice that will make this all a little easier: if you’re solving a really big problem that nobody else is solving, your early adopters will be quite tolerant.

This is one of the reasons why B2B applications often get away with being so awful and hard to use. If a product helps me do my job better and makes me more money, it’s solving a big problem for me. I’ll put up with a few missing features or a less than stellar experience. (There are lots of other reasons B2B applications are terrible, of course, but that’s not what this blog post is about.)

Of course, there is a minimum standard for anything you put out in the world. People have to understand what it does, for example, and be able to use it to solve their really serious problem. In other words, it needs to be both usable and useful. But the more useful it is, the more of a pass you get on a lot of the nice-to-haves.

To be clear, this is not a pass to make your product awful. Think of this as an encouragement to build something important that solves serious problems for people and to get it into their hands as quickly as possible.

Like the post? Follow me on Twitter!

Like the post but wish there were more of it? Buy the book!

Stop Making Users Explore

Often, entrepreneurs ask me something to the effect of, “What’s the best way to let new users explore my product?”

My answer is almost always a variation of, “Stop it.” In order to be slightly more helpful, let’s look at why this is a terrible question.

Users Don’t Care About Exploring Your Product

Nobody cares about your product. Fundamentally, what users care about is themselves. They are using your product as a means to an end. We knew this back in 1960 when Theodore Levitt explained that when customers buy quarter inch drills, they really are buying quarter inch holes.

Think about the last time you bought a drill. Did you sit down with the drill in order to spend time exploring it? Not unless you’re some sort of drill fetishist. What you almost certainly did was try to figure out the fastest way that you could set about completing the project for which you had bought the drill.

The same is true of whatever product you’re building. I know that you care deeply about the user interface of your product and all of the delightful features you have so lovingly handcrafted. Sadly, nobody else does. At least, not in the same way that you do.

People want whatever your product promises to do for them, and they want it to happen as quickly and easily as possible. They don’t want to explore your tax preparation software. They want their taxes done. They don’t want to delve deeply into the mysteries of your To Do List software. They want to not miss deadlines.

But What About B2B Products?

I know, I know. B2B products are different! They’re more complex! They have so many features! They require training and exploration!


All of those incredibly complicated, feature-dense pieces of B2B software that require weeks of training are getting disrupted by things that humans actually understand. I worked with a company that required all documents be shared by filing a ticket with IT to create a personal folder on a shared server which then required mounting a new drive onto the desktop and...blah blah blah. Everybody just used Dropbox, even though it was officially forbidden by the company.

The fact is, people in big companies are forced to work with dozens of complicated products every single day. The introduction of a new, complicated product does not instill in them the desire to spend a lot of their day exploring it. It tends to make them sigh resignedly and figure out if there is some way to avoid learning the new system until it goes away and is replaced by something else.

The only way to make a product that people at work want to use is to make a product that is so obvious and easy to operate that they don’t feel like they have to explore it. They can just jump in, share a document, send an email, or do whatever task it is that they wanted to do originally. They shouldn’t have to explore anything to do their jobs.


Nope. Sorry. Still very little open exploration for new users.

I mean, sure, you can wander all over GTAV and steal as many cars as you want. But have you ever noticed how many quests and tasks and hints you’re given along the way as a new player? Actually, you probably haven’t. Really successful games are fabulous at getting you onboarded without making you feel like you’re going through a tedious training session but also without just dumping you directly into the deep end.

In fact, in good games, the real exploration doesn’t come until users are pretty comfortable with all the basic actions they need to be successful. Often, advanced features are hidden from users until they are unlocked. This not only provides the user with an incentive to keep playing, but it effectively hides complexity until the user is ready for it.

Think about hiding a rocket launcher from a new FPS player. Now think about hiding quarterly estimates from a tax preparer until you know that she needs to file quarterly estimates. There’s a surprising similarity. Note: hiding rocket launchers from people doing their taxes is also not a terrible idea.


Again, not really. While online stores do encourage you to explore and browse, you’ll notice that they don’t have you exploring and browsing the store itself. They have you exploring and browsing the products they want you to buy.

When you’re selling widgets, it’s all about showing off the widgets as quickly as possible. Even while you’re looking at a widget, the site or app is immediately offering you more widgets that you might be interested in.

It’s not about exploration of the product itself. It’s about getting you involved with the things the product is selling.

What Should You Do Instead?

Stop thinking about letting users explore your product. In fact, stop thinking about letting them do anything at all.

When a new user comes to your product, give them a task. Have them do the most obvious, low-friction thing that they will need to do in order to become a slightly more experienced user of the product.

Twitter is an excellent example. When you first join, they don’t just tell you to explore Twitter. They have you immediately start following people. This not only introduces you to the concept of following people, but it gives you a nice, low-friction way to start using the product in the manner it’s meant to be used.

Of course, figuring out what that most obvious first task is can be tricky. In order to do it well, you need to truly understand why your user might want to use your product. What problem are they trying to solve? What task do they want to accomplish? How do they want to change their lives? What sort of hole are they trying to drill?

Once you understand that, you’ll know how to create an onboarding experience that won’t force people to explore your product before using it. In fact, they’ll never have to explore it. They’ll just be able to accomplish their task and get on with their now-improved lives. And that, after all, is exactly why they wanted to use your product in the first place.

Like the post? Follow me on Twitter!

Want more advice like this? 

How about buying the book? It will help you learn how to build great products. I promise. 

Don't Allow Behaviors. Encourage Them!

I wrote this post for the O'Reilly Programming Blog. Here's an excerpt:

As a consultant, I’ve talked to a lot of startups who have “social” products. You could tell that the products were “social” because they had comment sections and sharing icons that let people post to Pinterest or Facebook.

Of course, one of the things that the founders complain about is that too few users are actually making comments or sharing or doing anything remotely social with the product.

There’s a very simple reason for this: the founders have added features to their product that allow users to be social rather than encouraging them to be social.

Read More at O'Reilly > 

Make Meetings Less Awful

Meetings are the worst. I mean, my God, they suck. The vast majority of meetings are simply awful. 

But they don’t have to be!

If you’ve ever been in a meeting where you felt like your soul was being sucked out of your body through your eyes, I have a few tips that will make future meetings more tolerable. If you implement them correctly, they might even make some of your meetings useful! Imagine that. 

Write It Down Ahead of Time

Agendas. You should have one. Well, this seems painfully obvious, doesn’t it? But seriously. How many meetings do you attend where there isn’t a single person who knows exactly what you’ll be talking about in the meeting beforehand? 

Here’s a simple solution for making meetings wildly more productive. The person who is in charge of the meeting needs to make an agenda and send it out to all the attendees before the meeting. A full day is great, especially if there are things that people might want to research in preparation for the meeting. Even a few hours is helpful. It’s best if the person in charge reaches out to attendees early to see if they have anything they’d like to see on the agenda. 

The corollary to this is that the meeting attendees must actually read the agenda, understand what will be discussed, and come to the meeting prepared to discuss and make a decision on any of the agenda items they care about. 

And, of course, if they don’t care about any of the agenda items, they probably shouldn’t attend the meeting. 

Another, slightly more spontaneous, method is the box on the whiteboard. We used to do this in engineering meetings at IMVU. Before the weekly eng meeting started, people could add topics they wanted to discuss to a list on the whiteboard. Once the meeting started, someone drew a box around the list. Nothing could be added to the list once we started, and nothing was discussed that wasn’t in the box. As a bonus, it encouraged people to get to the meeting early if they had a topic to discuss. 

Everything Has a Next Step 

Meetings are not open ended discussion forums. They’re not group therapy sessions. Meetings are for making decisions. Every single thing you discuss in a meeting should have an decision and a deliverable. 

Here’s an example. Once, I was in a meeting to talk about a change somebody wanted to make to a product’s design. We sat together for half an hour discussing the types of research she could do to figure out whether the design would work or whether it was small enough just to ship. At the end of about 30 minutes, she announced, “Well, I don’t think we’re going to decide this now.” To which I responded, “Why the hell not?”

Stop having discussions just to have discussions. Refusing to make a decision in this meeting just ensures that you need to have another meeting later, and nobody wants that. Make sure that all agenda items at meetings have outcomes. Sometimes the outcome will be, “Susan is going to go off and investigate these three questions and report back so that we can make a more informed decision.” Sometimes the outcome will be, “Laura is in charge of building a prototype and will pull in whomever she needs to help.” Sometimes the outcome will be, “We’re shipping this damned thing as soon as we leave the room.” I kind of wish that were always the outcome.

The outcome will never be, “Well, we need to think more about this.” The problem with this statement is that it’s too vague. There is nothing actionable about this. Nobody is assigned to do anything, so nothing will really get done, and the next time the point comes up, you’ll have to have the whole conversation over again. Everything from a meeting needs a specific next step and somebody who is assigned to take it. 

Fewer Attendees

Meetings become far less productive after about four people, so whenever possible, keep meetings as small as you can. Obviously you sometimes need to have more folks, but really ask yourself whether everybody needs to be in the meeting, or if somebody would do just as well with a quick report after the fact.

If there are people who routinely aren’t contributing to the meeting in any way - no agenda items, no adding to the discussion, no making decisions, no deliverables after the fact - then they are great candidates for not getting an invitation next time. Presumably you’re paying these people, and I have to imagine there is something more productive they could be doing than sitting in a meeting checking their email.

Every Meeting Has a Leader

Someone has to be in charge of the meeting. Always. 

The person in charge of the meeting has a lot of responsibilities. The leader must make the agenda, keep everybody on track, mediate disputes, ensure that everybody who has a contribution gets to make that contribution, make sure that all the deliverables and next steps are being captured, and follow up on the things that come out of the meetings. 

I was in a meeting once that was led by a particularly ineffective PM. We were discussing what the priorities would be for her product (don’t even get me started on why engineers and designers were discussing this when it was so clearly her job). We were each giving our opinions about what should be done first, and the discussion began to get heated. 

Instead of stepping in and guiding the discussion or just deciding what order we’d build things in, the PM sat back and let everybody scream at each other. The meeting ended with someone in tears (unsurprisingly, this person wasn’t me) and no decision made about prioritization. 

Unless somebody is in charge, meetings just meander and go on for three times as long as they need to with nobody who is willing or able to say, “Right. We’re done here. Let’s go do something productive.” Having someone whose job it is to end discussion and assign tasks makes things go much more smoothly and quickly. 

Besides, if we actually expected some work from the people who call all those meetings, maybe they’d call fewer damned meetings. 

No Broadcast Meetings

I’m going to assume that everybody working for your company is literate. If this is true, please stop having meetings where you read things to them. You’re not in kindergarten. This is not story time. 

I have been to too many meetings where a PM or CEO or somebody else who should know better shows a slide deck and then proceeds to read all the slides to the audience for an hour. 

Here’s an idea: send the deck out the day before. Tell people to read it for themselves and come up with questions. At the meeting, spend no more than five minutes summarizing the most important things about the slide deck (“We made more money this month than last month! Yay!”), then take questions from the audience about the rest of the deck. 

If you are concerned that people will miss critical information because they are failing to read important emails, that’s really something that you need to address separately. I’ve found that reducing meeting times by a few hours a week gives people far more time to read their email or to do something actually productive. 

More Discussions, More Working Sessions, Fewer Meetings

You know what I like more than meetings (besides everything)? I like discussions. Discussions are things that happen between two or three people who are all interested in and informed about a particular topic. They tend to happen in hallways and they often help disseminate important information to the people who need it. 

I also like working sessions, in which a few people all work together on something like a design or code. Working sessions generally involve a lot of writing on whiteboards or pair programming or gathering around somebody’s screen to try different variations of a particular wireframe. Working sessions are better than even good meetings because by the end of the working session, you’re often done with whatever it was you were going to just talk about in the meeting. 

And maybe that’s the most important point here. Meetings are not conducive to DOING. They are conducive to TALKING. Talking is the enemy of doing. By making a few small changes in the way you conduct your meetings, you can turn them into places where things get done rather than just talked about. And that will make meetings suck a whole lot less. I promise. 

To Kill or Not to Kill

After my rant last week about product managers, the excellent Joshua Porter (@bokardo) made a great point about it. He said, “In my own experience the hard part is knowing when to kill something vs. when to give it more breathing room, as sometimes a really new idea can’t really be tested in low fidelity.”

As much as I’d love to send my pageviews soaring by starting a flame war with somebody popular on the internet, I have to admit that he’s 100% right. Killing a feature or product is exceptionally difficult. It’s tough to know when to do it. It’s tough to figure out if you made the right decision. And it’s tough emotionally to let go of something you really thought was going to be great.

First, let’s talk a bit about why you kill products or features. You kill them because they’re not succeeding or because you don't expect them to succeed. That could mean that they’re not getting enough traction or because you’ve determined that they’re never going to turn into an important part of your business. You kill them because the ROI isn’t high enough to justify investing more resources in them. You kill them because they are using resources that would be better spent in other places.

They’re hard to kill precisely because you never know whether they’re just a few days away from taking off and turning into everything you thought they’d be. After all, every successful product went through some period of time before everybody found about it.

So, let’s look at a few questions to ask yourself before killing a product or feature. For the purposes of this post, I'm just going to talk about killing existing features or products. I'll probably address how to decide to kill things before you build them in a future post.

These questions won’t make killing easy, but hopefully, they’ll make it possible.

Why Isn’t Everyone Using It?

There are four reasons people don’t use your product or feature. Yep. That’s right. There may be thousands of reasons that people do use a product, but there are really only four basic reasons that they don’t.

People don’t use your product because:
  • They don’t know about it 
  • It doesn’t solve a problem for them 
  • They don’t understand that it will solve a problem for them 
  • The problem it solves isn’t worth the investment of time, money, or effort
Before you kill your existing product or feature, figure out why it’s not popular. For example, if you’re simply not getting any traffic to your page, it means not very many people know it exists. On the other hand, if you’re getting tons of traffic, but none of it is converting or engaging, then your problem is one of the last three. People are finding your product, but they don't want it or understand it enough to convert.

You can find out if the product solves a serious problem for people by talking to the types of people you expect to have that problem. Develop a persona that represents the sort of person who might suffer from this problem, and interview them about that portion of their lives.

Don’t just ask, “do you suffer from x problem?” Have them tell you stories about their real life experiences in situations where they might have experienced the problem. For example, if you’re testing to see if people need turn by turn navigation on their phones, you might ask them to tell you about the last time they were trying to get somewhere and they got lost. Then you might ask how often that happens. If it’s extremely rare, they probably don’t have the problem you’re trying to solve.

If you’re trying to figure out if they understand the problem your product or feature solves, you can do that by showing them your product or feature (or a mockup or prototype) and asking them to tell you about it. Don’t prompt or prep them. Just show them the product and say, “Tell me what this does. Who do you think it’s for?” You will be shocked by how often your perfectly crafted prose and imagery cause nothing but blank stares.

When determining whether or not your product is worth getting, don’t forget that money isn’t everything to your potential users. Sometimes there are switching costs that they’ll have to deal with or just the cognitive load of learning how to use a new product. I can’t tell you how often I’ve seen people stick with a completely suboptimal solution to a problem, just because that’s what they’re used to.

Regardless of which it is, determining the reason people aren't responding positively to your product will go a long way toward telling you whether to kill it or keep it. 

Who Is Using It?

So, once you’ve determined that there are people who are using your product or who you expect will use it because it solves a serious problem for them at a price they’re willing to pay, it’s time to look at who those people there are and how many of them exist.

A great company with a very engaged group of users recently killed a feature. Unsurprisingly, there was a huge outcry. They got many, many complaints telling them how sad users were that the feature was going away. If they had gone entirely by the comments on the blog post about removing the feature, they would have been justified in thinking that they were making a huge mistake.

Luckily, they didn’t do that.

It turned out that the number of people using the feature was an incredibly small percentage of their user base. More importantly, the people using the feature were not, by and large, paying customers. In other words, a couple percent of very vocal users who didn’t earn a cent for the company were upset by the removal.

While it’s always best to avoid making your users angry, there are certainly users that it’s safer to anger than others. Keeping a feature or product that is disproportionately useful to people who aren’t benefitting your business in some real way means that you have fewer resources to devote to things that might make you some money. 

The other thing to consider here is how many people you might reasonably expect to have use this product if everybody knew about it. Unless there is a huge potential market for your feature or the small market that exists is willing to pay quite a lot to use it, you may want to consider killing it.

Note: for those few people who inevitably write to me and complain that “it’s not all about money,” I would like to point out that it very frequently does have to be about money or you will go out of business. If you want to keep your 10 free users super happy, you go right ahead. I’m going to cater to the large number of folks who pay me. 

And yes, I do understand the difference between long term and short term gains, and I expect my readers do, as well. Assume I'm optimizing for lifetime value here and not simply what makes the most money right this second.

What Is the Actual Cost of Keeping It?

Now that we’ve determined that people are using your product or feature, we should figure out how much it costs to keep your product or feature alive.

Of course, if you’re talking about your whole product, this math is relatively easy. The only hidden cost to keeping your product alive is the opportunity cost of building something else. If you’re working on your current product, you can’t be working on something more promising.

However, if you’re talking about a piece of your overall product, sometimes it can be harder to figure out how much it costs to keep a feature alive. Obviously there is the cost of the engineers or customer support people or sales people, but often they’re working on other things as well, so it’s not clear that cutting any particular feature will really save you any money. If even a few people are using a feature and it’s already built, why not just let it hang around indefinitely?

Well, consider some of these hidden costs to keeping a feature:
  • Bug fixes 
  • Customer support 
  • A more complicated code base 
  • A more complicated user interface (more features means more cognitive load on your new users) 
  • Server and infrastructure costs 
  • Additional work if you decide to do a site redesign or visual refresh
These may seem like small things, and in some cases they are, but don’t ever think that a feature is free just because you no longer are actively building it.

Of course, there's another alternative, which is to continue to iterate on the feature or product. This obviously adds hugely to the expected costs. Let's say that you create a new search feature for your product, and very few people end up using it. The actual cost of that feature needs to include all the iterations and changes that you're willing to try before people start using it or you give up on it. 

What Is the Actual Cost of Killing It?

In a similar vein, sometimes things can cost more to kill than you think. Unhappy users can cause trouble in forums or for support staff.

Of course, I did mention above that it’s sometimes acceptable (and inevitable) to annoy some of your users, but don’t underestimate the work that it will take to keep that unhappiness from spreading throughout your entire community.

There are engineering costs to turning off a feature, as well. Either you need to pull it out of your code base or leave it there to rot. Neither of those options is free, although both can be ultimately cheaper than maintaining the feature.

If you’re killing your whole product, you are often throwing away a huge percentage of your customer base. Just because you’re pivoting doesn’t mean that all of your users will pivot with you.

And the same goes for your employees, if you’re lucky enough to have any. Killing a product or significant feature can be absolutely terrible for morale. Obviously you’re not going to keep a failing product just to make your employees happy, but make sure that you are prepared for the fallout – and possibly resignations - when you do decide to make a major change.

So, Should You Kill It?

In the end, it really comes down to the expected ROI, and the future is notoriously difficult to predict. Good customer development techniques can help you get a clearer idea of the eventual potential of a product or feature that seems to be failing. An honest assessment of real costs can help you determine the investment that you're really making into the product.

But it's an art, not a science. In the end, you're still going to have to make the decision. And it may be the toughest decision you ever make as an entrepreneur. Good luck!

Like the post? Here's what you should do next:

Expect More From Product Managers

I talk to a lot of startups, and I've noticed a really troubling trend at some of them. A huge percentage of Product Managers at startups suck.

Not you, obviously. I mean, you're a product manager at a startup, and you're the exception. Good for you. I mean all the other ones.

I mean the Product Managers who are failing to do the following obvious things:

Understand their Users

I was visiting a company, and I asked about what sort of ongoing user research they were doing. It turned out that they had an intern for a few weeks who was doing a giant research study to try to understand how people viewed the product. The Product Managers would occasionally attend a session, but basically they seemed uninvolved in the research. They knew nothing about the planning. They didn't monitor to see how things were going.

The research involved talking to a lot of people who had heard about the product but who had never used it before to see why they weren't using it. The Product Managers' main job with regard to research seemed to be to read a report produced by the intern at the end of the few weeks.

Meanwhile, nobody was doing targeted usability research on whether people were confused by the product. Nobody was doing any sort of inquiry into how big customers were using the product. Nobody was calling people who had stopped using the product to find out why. Nobody was following up with new users to understand their initial experiences.

Unsurprisingly, none of the PMs in charge of deciding what to build next had any real idea about usability problems, what separated their biggest customers from everybody else, or why people tried the service once and never returned. And that meant that they weren't very good at figuring out how to build their product, so when they did add a feature, it very rarely improved any of their key metrics.

The single most important thing you can do as a Product Manager is understand your users. This is the foundation for making every single decision about your product that you will ever have to make. If you don't know who your customers are and what motivates them, you can't consistently deliver features that will make them happy. It really is that simple.

Know Exactly How their Product Works

I was talking to a different startup about their onboarding flow, and I asked the product manager to explain how it currently worked for certain types of users under specific circumstances. The product manager said he'd have to check with the designer to get all the details.

The designer, of course, knew exactly how the product worked, since she was the one who had designed it. She also knew all about the user needs and the issues with the current flow and what she wanted to try next. All of this led me to wonder why on earth she wasn't the one in charge of the product.

When I attended meetings with both of them, the product manager constantly had to refer to the designer when talking aout what things they had tried, what had worked, and what users were currently seeing. Whenever an engineer asked a question about how something was supposed to be built, the PM would simply pass the question along to the designer and then relay the answer back to the engineers.

As far as I could tell, the PM was nothing more than a buffer between the engineers and the designer. Once the designer started working directly with the engineers, the PM had almost nothing to do except track the project schedule.

If you don't know everything about how your product works and why it works that way, how are you supposed to make good decisions about it? The role of a product manager isn't to be a passive conduit for information. A great PM needs to understand the product well enough to make important decisions about how to change it.

Validate Assumptions Before Building

I'm not going to tell a specific story about this one, because I've seen it happen absolutely everywhere.

Essentially, Product Managers seem to fall in love with ideas. Maybe they get the ideas from meetings or from their bosses or the ideas appear to them in a flash of light one morning in the shower. But regardless of how it happens, today's idea is always the Big Idea that is going to change everything.

Once they've got the idea, of course, they jump straight to the question of how to get it built. Typically, they get the feature on the schedule, break it down, get a designer in to mock it up, and get the engineers working on it. At no time before all this happens do they stop and ask the question, "How can I tell if this idea is any good before I spend a lot of time and money on it?"

No matter how good your instincts are, you don't really know that adding this new feature is going to be an enormous hit with your users. Sometimes you're right, and the feature is a game changer, but just as often, an unvalidated feature has a negative ROI.

Good product managers do as much work as possible ahead of time to figure out if they're spending their resources on the right stuff. Maybe they devise a small experiment to test whether people will use the feature. Maybe they do a very small version of the feature first. Maybe they do a concierge version of the feature. Hell, maybe they even sell the feature before they build it.

Whatever their strategy, good product managers validate their features before they build them, and that's why their ideas are so much more likely to improve the bottom line of the company. They don't necessarily have better ideas. They just kill the bad ones before spending too much time on them.

Prioritize Changes Based on Business and Customer Needs

Everything can't be a top priority. That's not how priority works. But you'd never know that to talk to some product managers. I can't tell you how often I've seen product managers try to build everything at once, because they simply couldn't make the decision about what was most important to either the business or to users.

Unfortunately, this tends to cause problems as engineering gets spread too thin and the team gets confused about what they should be working on.

Without clear prioritization, nothing really gets done well or quickly. Everybody ends up working on different projects, and all the projects move much more slowly than they would if everybody worked together.

A good product manager can make priorities clear without micromanaging. She makes the decision about what to work on based on things like expected ROI and the outcome of early validation tests. She balances features that are great for the business with features that are great for the users, and she always tries to find features that are good for everybody. She looks at things like long term vs short term pay off and makes sure that features are delivering value to all the different types of customers - new users, power users, business users, etc.

She clearly says that the entire team's goal is to improve a particular key metric and then makes sure that the team understands what that means. She then prioritizes which features should be delivered first while monitoring the metrics, and she keeps the team motivated to follow up by making progress toward the goal very clear.

Keep Engineers from Getting Jerked Around

How many of you have been working on something when a product manager has suddenly told you to stop working on that and work on something entirely different? How often does that have to happen before you become completely unmotivated? Not very often, right?

Of course, sometimes things change. Bugs are found that need to be dealt with. Business people make new deals. Company priorities get shifted around. Organizations get shuffled.

A good product manager protects her team from as much of this as she possibly can. She does this by pushing back on pressure from above to change priorities midstream. She does this by making sure that what her team is working on is important enough that she has a good reason to keep them on it, even if her boss suddenly wants something new and shiny. Sometimes she does it by making sure that there is somebody who can triage high priority bugs in order to keep the whole team from getting pulled off their work in the event of an emergency.

A good product manager manages up as much as she manages down.

Do Jobs that Aren't Technically Product Management

Just because the word manager is in the title doesn't mean you're off the hook for actually building things yourself. This is especially true at startups, where there are very few people trying to do a whole lot of work.

When I was working as a product manager, I frequently wrote copy, answered customer support questions, touched up images, built prototypes, consulted with the CEO on strategy, ran scrums, responded to people on Twitter, and made user research calls. Oh, and about hundred other jobs that had nothing to do with management.

I did those things because they had to be done, and there was nobody else to do them, but I also did them because the act of doing them made me a better product manager. By answering customer support questions, I learned how users felt about the product and where they got confused. By touching up images, I learned how much time it took to do the job so that I could gauge how efficient other people were when they were doing it. By monitoring Twitter, I learned who was talking about my product and what they were saying. These things were all critical to doing my job well, plus it meant that we didn't have to hire a bunch of specialists to do these things.

If you're not doing things outside of your normal job description, take a good hard look at whether you're really doing the most important parts of the job. I'll give you a hint, if what you're doing involves hours of meetings every week, there are more important things you could be doing.

This Sounds Hard

This sounds hard because it IS hard. Product Management should be hard. You're in charge of creating something. You have to make important decision affecting a huge number of people all the time. If you think it's all just going to meetings and making schedules for other people to stick to, you're doing it wrong.

Like the post? Follow me on Twitter!
Want more info on Lean Startup? Check out the Official Lean Startup Workshops Series I'm working on.

Startups Shouldn't Hire User Researchers

Everybody seems to think I'm a user researcher, which is not strictly true.

It's true, I write a lot about user research, and I've certainly done my share of it over the course of my career. But I don't really consider myself a user researcher. I do enough user research to be extremely effective at being an interaction designer and product manager.

There are lots of actual user researchers with degrees in psychology and specialized training who are doing much more interesting and complicated research than I do. I respect those people. They are scientists in many cases. But I don't think that most of them should work for startups. In fact, I don't think that small startups should ever hire a user researcher just to do research.

Don't get me wrong. User research is critical to startups. How else are they supposed to understand their potential customers and find product market fit?

No, the reason people shouldn't hire people to do their user research is that learning about your customer is the single most important part of your startup. If you're outsourcing that to a person who isn't directly responsible for making critical product decisions, then you are making a horrible mistake.

I see startups do this over and over. They hire a consultant, or even a regular employee, to come in and get to know their users for them. That person goes out and runs a lot of tests and then prepares a report and hands it over to the people in charge of making product decisions. Half the time the product owners ignore the research or fail to understand the real implications of it.

And why wouldn't they? The product managers weren't there for the process of talking to users, so they almost certainly haven't bought into the results. It's really easy to ignore a bunch of bad things somebody else wrote about your idea in a Powerpoint presentation. It's a lot harder to ignore half a dozen real users saying those things to your face and showing you problems that they're having in real life.

The right way to do research in a startup is to have the people who are responsible for making decisions about your product intimately involved in the research itself. That means that product owners and UX people are designing and running the tests. Even the engineers should watch some of the sessions and hear first hand what their users are going through.

The reason I talk so much about user research is that I want you, the entrepreneurs, to learn enough about it so that you can DO IT YOURSELVES. You're welcome to hire people like me, or even real user researchers, to teach you what you need to do. But having somebody else do the research for you is not an option. At least, it's not one that you should use if you're still trying to find product market fit or learn anything actionable about your customers.

Stop thinking of user researchers as people you hire to get to know your users, and start thinking of yourself as a user researcher. At startups, you should all be user researchers, especially if what you really are is a designer or product manager.

When Talking to Users Saves You Time

I mentor a few young designers, which is great, because not only do I know exactly who I want to hire when I’m building a team, but they also share interesting stories about their current companies.

I was speaking with one of them a couple of weeks ago, and she shared a story that sounded incredibly familiar. I think this happens to all designers who work with a sales force at some point.

 The designer, whom we will call Jane, is working on the user experience for an enterprise product for hiring managers. The product has some competitors that have been around for awhile.

One day, a few weeks back, the sales team came to the product team and said, “We need Feature X. All of our competitors have Feature X, and we’ve heard from some of our potential customers that they won’t buy us if we don’t have Feature X.”

 Jane and her team looked at the competition’s implementation of the feature, which had a lot of bells and whistles. The product team asked sales which parts of Feature X was most important to the potential customers. “All of it,” sales replied.

Jane’s team starting pushing back. This was not a simple feature. They estimated that it would take months to get the feature to be comparable with the competition. There was one part of Feature X in particular, the live video part, that Jane knew would be incredibly tough to design and build, simply because of all the implicit requirements that would make it useful. They explained this to the sales department, but the sales department continued to complain that they couldn’t do their jobs without Feature X.

Finally, Jane insisted on speaking directly with a customer. A meeting was lined up with a few representatives of the company. Jane started off by asking how the potential customer would use Feature X. They gave detailed explanations of exactly the places that they needed Feature X, none of which had been conveyed by the sales team.

Interestingly, none of the uses they had for Feature X involved the live video part of the feature that was worrying the product team. Finally, Jane came right out and said, “Tell us about live video. How do you feel about it.” The potential customers shrugged. “I guess it might be useful,” they said. Jane asked, “Would not having live video prevent you from buying our product if we had Feature X?” “Not at all,” the potential customers said.

Jane’s team then had a similar conversation with other customers and potential customers. The product team gladly put the much smaller Feature X, minus the expensive live video feature, onto their product roadmap. They also left out a few other parts of Feature X that didn't solve actual user problems, and created a design for Feature X that was significantly different from the competitors' versions but that addressed all the customers' issues.

Sales was happy because now they could tell potential customers that they were competitive on features. Jane was happy because she was able to quickly identify a real customer problem and solve it, rather than fighting with sales about something that would take too long to build and would include features the customers didn’t actually want.

 My prediction is that Jane’s version of Feature X is going to be significantly better than the competitors’ version, simply because it will only have the pieces that customers actually need and use.

The new feature won’t be made needlessly more complicated by bells and whistles that are only put there so that a sales person can check something off on a list. They’ll be put there because they solve a problem.

Sometimes It’s Not the Change They Hate

There has been a lot of discussion in the design world recently about "change aversion." Most of the articles about it seem to be targeting the new Google redesign, but I've certainly seen this same discussion happen at many companies when big changes aren't universally embraced by users.

Change aversion is a real thing. Often people don't like something different just because they're used to the old way. Once they get used to the new way, they discover all the wonderful new features and are happy with the new change.

But sometimes your users' rage isn't change aversion. Sometimes your new design actually sucks.

So, before you blame your users, you should figure out if it's change aversion, or if you really screwed something up. Ask yourself the following questions.

Did You Do Any Sort of User Testing Before Launch?

This is an important one. Sometimes people complain about a product because it has changed. Other times they complain because the product makes them feel stupid or it prevents them from doing what they want to do.

Most often, products make people feel stupid because the products are hard to use.

It's very possible that the changes you made to your product have made common tasks that the user is used to performing harder to do. Yes, the user may eventually learn to perform the tasks the new way, but that new way may be legitimately more difficult! You may even be reducing the amount of time the user spends performing that task, if you make it hard enough.

To pile onto the Gmail redesign for a moment, I can tell you right now that I am constantly hitting the folder button instead of the label button now that they are icons rather than text. I am still occasionally doing this probably a month after I switched to the new look. It's not a deal breaker for me, but it annoys me every time it happens. The new icons, for me, are honestly harder to use than the old buttons, and they build up a certain amount of unhappiness every time I use them incorrectly.

The interesting thing is that this is exactly the kind of problem that you can surface very easily by simply doing some observational testing of people using prototypes or early versions of the product.

Hell, you could probably even figure that one out with metrics. How often are people hitting the Undo button now compared to previously? If people are undoing their actions more frequently, you can bet that your new design is causing them to make mistakes.

Did You Test with Current Users or Just New Ones?

When you have millions of users, it's not cool just to test on people who have never seen your product before.

New user testing gives you really valuable feedback, but it's just one kind of feedback. It doesn't give you any insight into how your current users (often users who are paying you money) are using your product right now.

It may be that your users are doing something surprising with your product. They may be using it in ways you never anticipated. Making major changes without understanding their work styles can destroy something they were relying on.

It's not a matter of their relearning how to do a task in the new interface. You may literally have removed functionality for people who were using your product in innovative ways.

Similarly, if you're only testing with internal users (that is, users internal to your organization), you're not really getting the full idea of how all sorts of different people are interacting with your product. The more types of people you can observe, the clearer your understanding of real use cases and behaviors will be.

Did You Add Something Useful to Users? Really?

Sorry, improving your brand is not particularly useful to users. Even a nice new visual design tends not to be a big enough improvement if you're also changing functionality that users rely on.

Here are some significant improvements that might be enough to counteract a tendency to change aversion:
  • making your product noticeably faster or more responsive
  • adding a great new feature that users can understand and start enjoying immediately
  • fixing several major bugs that people have been complaining about
That's pretty much it.

The problem here is that often companies mistake doing something that is good for the company with something that is good for the user. That can be a tricky thing to spot, but a good way to handle it is to always ask yourself, "What real user problem is this change solving?" If the answer is, "How to give us more money" or "Well, there's more visual breathing space," you might want to brace yourself for the inevitable shitstorm when you launch that change.

Do You Mind Losing a Portion of Your Users?

This is a 100% legitimate question to ask. Sometimes you make changes to your product that you know will piss off a certain subset of your users, and that can be ok.

I've often advocated for prioritizing changes that help your paying customers over changes that help your non-paying users. But there can be other reasons to make changes that annoy certain groups of your users.

The thing is, you have to know that you're making this tradeoff and be ok with it. If you've gone into the change knowing that you might lose a certain percentage of your users, but hoping that you will make up the loss by making other users very happy or attracting new users, that's a fine choice to make. Just be sure that your metrics show this actually happening.

Have You Honestly Listened to Your Users' Complaints?

Let me give you two common examples of user feedback:
  • I hate it! It's terrible! I want the old way back!
  • I'm constantly hitting the folder button when I want to hit the label button, and I find it really hard to tell which emails are more important any longer. Also, every time I try to Reply to All in the middle of an email thread, it's just ridiculously difficult to do.
Can you spot why they are so different? That's right, one of them is completely non-actionable. There is nothing you can really react to with the first one. You can't fix this user's problem. Yet.

The second one is significantly better because you're starting to get at WHY the user hates the change. You know that the user is having trouble performing specific tasks. You can follow up with the user and have her show you the things that you have made harder to do. You can then figure out if those are things that are done frequently enough and by enough users to justify making them easier to do.

Here's the trick. You can turn the first type of feedback into the second type of feedback by following up with users and asking them for specific things that they hate about your change. If they just keep saying, "It's different!" then they may get over it when they get used to it. But a significant portion of them probably have specific complaints, and writing those complaints off as change aversion is really kind of a dick move.

Have You "Fixed" the Problem by Letting Users Change Settings?

Stop it. Seriously. Just stop it.

The vast majority of your users don't know how to change the default settings.

It's not a failing. They're not stupid. They just don't know nearly as much about your product as you do, so they don't have great understanding of the million different ways you've allowed them to customize their experience. They probably don't even know that those settings are there, and even if they do, why are you making them work that hard?

If you are going to include a few settings that they can change, make them obvious, easy to understand, and don't bury them in a thousand other settings that are incredibly confusing to everyone who isn't in tech and half of us who are.

Like the post? Follow me on Twitter!

I Don't Know What's Wrong with Your Product

When I’m talking with startups, they frequently ask me all sorts of questions. I imagine that they’re probably really disappointed when I respond with a shrug.

You see, frequently they’re asking entirely the wrong question. And, more importantly, they’re asking the wrong person.

It is an unfortunate fact that many startups talk to people like me (or their investors or their advisors or “industry experts”) instead of talking to their users.

Now, obviously, if they just asked the users the sorts of questions they ask me, the users couldn’t answer them directly either. This is the wrong question part. But the fact is, if they were to ask the right questions, they’d have a much better chance of getting the answers from their users.

Let’s take a look at a few of the most common sorts of questions I get about UX and how we might get the answers directly from users.

What’s Wrong With My Product?

I often get people who just want “UX advice.” I suppose they’re looking for somebody to come in and say something like, “oh, you need to change your navigation options,” or “if only you made all of your buttons green.”

Regardless of what they’d like to hear, what they typically hear is, “I have no idea.” That’s quickly followed by the question, “Which of your metrics is not where you want it to be?” If they can answer that question, they are light years beyond most startups.

You see, the first step to figuring out what’s wrong with your product is to figure out, from a business perspective, some realistic goals for where you’d like your product to be right now. Obviously, “We’d like every person on the planet to pay us $100/month” is probably not a realistic goal for a three month old venture, but hey, aim high.

Once you know what you want your key metrics to be, you need to look at which of them aren’t meeting your expectations. Are you not acquiring new customers fast enough? Are not enough of them sticking around? Are too few of them paying you money? While “all of the above” is probably true, it’s also not actionable. Pick a favorite.

Now that you know which of your key metrics is failing you, you need to conduct the appropriate sort of research to figure out why it’s so low. Note: the appropriate sort of research does not involve sitting around a conference room brainstorming why abstract people you’ve never met might be behaving in a surprising way. The appropriate sort of research is also not asking an expert for generic ways to improve things like acquisition or retention, since these things vary wildly depending your actual product and user base.

The appropriate sort of research depends largely on the sort of metric you want to move and the type of product/user you have. You will, without question, have to interact with current, potential, or former customers of your product. You may need to observe what people are doing. You may need to ask them why they tried your product and never came back. You may need to run usability tests on parts of your interface to see what is confusing people the most.

Feel free to ask people like me for help figuring out what sort of research you need to be doing. That’s the sort of things experts can do pretty effectively.

But if any expert tells you exactly what’s wrong with your product without considering your user base, your market, or your key metrics, either they’re lying to you or your problems are so incredibly obvious that you should have been able to figure them out for yourself.

What Feature Should I Build Next?

Let’s imagine for a moment that you have built a Honda Civic. Good for you! That’s a nice, practical car. Now, let’s imagine that you come to me and ask how you should change your Honda Civic to make more people want to buy it.

Well, I drive a Mini Cooper, so it’s very possible that I’ll tell you that you should make your Civic more adorable and have it handle better on curves. If, on the other hand, you ask somebody who drives a Ford F-150, they’ll probably tell you that you should make it tougher and increase the hauling capacity.

Do you see my point? I can’t tell you what feature you need to build next, because I almost certainly don’t use your product! To be fair, even the people who do use your product or might use your product in the future can’t just tell you what to build next.

What they can tell you is more about their lives. Do they frequently find themselves hauling lots of things around? Do they drive a lot of curvy mountain roads? Do they care about gas mileage? What about their other purchasing choices? Do they tend to buy very expensive luxury items? Do they care more about status or value?

You see, there is no single “right way” to design something. There are thousands of different features you could add to your product, and only the preferences and pains of your current and potential users can help you figure out what is right for you.

Should I Build an App or a Website or Something Else?

Another thing that people ask me a lot is whether they should be building an iPhone app, an iPad app, an Android app, a website, an installed desktop app, or some other thing.

That’s an excellent question...to do a little research on. After all, what platform you choose should have nothing to do with what’s popular or stylish or the most fun to design for. It should be entirely based on what works best for your product and market.

And don’t just go with the stereotypes. Just because it’s for teens doesn’t necessarily mean it’s got to be mobile, although that’s certainly something you should be considering. It matters where the product is most likely to be used and what sort of devices your market is most likely to have now and in the near future. It also depends on the complexity of your product. For example, I personally don’t want Photoshop on my phone, and I don’t want a check-in app on my computer.

Talk to your users and find out what sort of products they use and where they use them.

Are You Noticing a Pattern?

Experts are not oracles. You can’t use outside people as a shortcut to learning about your own product or your users. You need to go to the source for those things.

If you find yourself asking somebody for advice, first ask yourself if you’re asking the right question, and then ask yourself if you’re asking the right person.

And if anybody ever tells you definitively what you need to change about your product without first asking what your business goals are, who your users are, and what their needs are, you can bet that they’re probably wrong.

Hey, you got to the end! Now you should follow me on Twitter.

Fucking Ship It Already: Limited Products vs Shitty Products

In our second installment of Fucking Ship It Already, we deal with a common problem for startups: shitty products.

Look, I know that building a product with one or two engineers and no money is tough. As an entrepreneur, you almost certainly have far more ideas than you have resources to create those ideas. And it doesn’t help that you have people like me screaming, “Ship it! Ship it!” before you’re really ready.

Who could possibly blame you for shipping a product that is, frankly, kind of shitty?

I could. Knock it off.

Let’s take a step back and try to understand the difference between a shitty product and a limited product.

One big difference is that I wholly endorse shipping a limited version of your product. I think it’s stupid to ship a shitty product. But what does that mean?

A limited product is something that may not do much, but what it does, it does well. It makes it clear to the user what it does and what they should do. It solves a serious problem, or perhaps a small part of a serious problem. It doesn’t crash relentlessly. It doesn’t have enormous usability problems.

It is not half a big product. It is a small but whole product.

Most importantly, a limited product is just big enough and good enough that you can learn something important from it.

But a limited product probably doesn’t do anything else. It doesn’t have bells and whistles. It doesn’t have “nice to have” features. It may only support the problems of a small subset of the market. It may only be released to beta users.

A shitty product, on the other hand, often tries to do too many things at once, and it doesn’t do any of those things particularly well.

You really don’t want a shitty product because, when people don’t use it, you have no idea if they aren’t using it because you have a bad idea or the wrong market, or if it’s just because your users are confused and turned off by your shitty product.

Shipping a shitty product is one of the best ways to get a false negative on your idea. People will use products that aren’t “polished.” They will abandon products that are just bad.

Here’s an example - remember when Amazon only sold books? If you were around in the ‘90s, the company that now sells fifteen different versions of everything on the planet only sold actual printed books.

And they did it really well. They made it pretty easy to find books. They had a large selection of books. They shipped the books to you reliably. They had nice descriptions of the books. They improved on the bookstore experience by offering me a giant bookstore in my own home.

In other words, they did one thing - sell books online - and they did it well. It wasn’t until years later that they even branched out into selling things similar to books. And it wasn’t until they were wildly profitable (and no longer a startup) that they started adding advanced features like eReaders, cloud storage, and a marketplace where other people could sell things.

What they didn’t do was do a half assed job of trying to sell you everything immediately. They didn’t promise to sell you toasters and jewelry and smoked salmon but then fail to actually ship any of that to your house or charge you three times for the same item. They figured out how to sell things to people online with one understandable market that they could learn from.

Other examples of products that started out doing one thing really well are Instagram, Google Search, and even Facebook. Remember, Facebook started out solving a single problem on a single college campus.

Now, I’m not saying it’s easy to build a product to sell books or share photos or search the web. It’s not. It’s incredibly hard, and it’s even harder to get right.

But that’s exactly the reason why you need to dramatically limit the scope of your initial product. Even building something that seems easy is hard to do well. Imagine how hard it is to build something really big!

So, when I’m yelling at you to Fucking Ship It Already, I don’t mean that you should ship something bad. I mean that you should ship something limited - something that is small enough to be shippable and usable in a very short amount of time.

And then I mean that you should immediately improve it and ship it again. Do this over and over again as many times as you can for as long as you can.

Eventually, you’ll build the product of your dreams. It will probably be quite different from what you originally imagined, but that’s a different blog post.

Stop Validating Your Product

I talk to a lot of very small companies that are trying to do Customer Development, and the conversations are often the same. The entrepreneur explains that the company is working on a fabulous product, and they want to figure out a) if anybody wants to buy the product and b) if they need to change anything about the product so that more people will buy it.

The entrepreneurs always ask questions like, “How will I know if I have talked to enough people?” and “How do I know if the people who like it are just early adopters?” and “How do I know if I should change the product in response to feedback or if I should just keep trying to find the right market?” The ones who have already been out in the field trying to conduct these interviews all have a sort of glazed, terrified look.

These are all really important questions. I’m going to give you a way to avoid having to ask most of them.

Stop trying to validate your product.

Now, I fully expect a bunch of people to stop reading here and totally miss the point of this post, but for those of you who stick it out, I promise this will make sense in a minute.

The trick is, it is far, far easier to conduct customer development before you have settled on a product or even an idea for a problem.

Why is that? Well, think about products as solutions to problems. Sometimes that “problem” is “I’m sort of bored while I’m waiting for the train” and the unexpected solution is flinging virtual birds at virtual pigs. But often, the problem is something more concrete, and it’s frequently shared by a large group of similar people.

So, instead of focusing on validating a solution, try one of the following techniques.

Validate a Problem

Let go of your preconceptions about how you are going to solve a problem for people and concentrate on first figuring out whether lots of people have a particular problem and what they’re currently doing to solve it.

For example, let’s say that you’ve posited that people have a really hard time finding and making appointments with trustworthy auto mechanics. The mistake you will probably make is to jump right into solving that problem and then going out into the world with some half-baked idea for Yelp meets OpenTable meets AAA and trying to find out whether it solves this problem that you’re not technically sure exists yet.

Instead of doing that, first validate the problem. Get on the phone with lots of different types of people and ask them how they found their mechanics. Talk to them about all of their mechanic-based issues. Find out what causes them the most pain.

Also, this is a good time to narrow down your market. Start with the market “people who have cars and will talk to you,” but quickly start noticing patterns. Do all the busy people have similar problems? What about people who live in cities vs. suburbs? How about people who are new to an area? Try people with special kinds of cars. I’ll bet that they all have very different problems, any of which you might want to solve.

Once you’ve spent time talking to people in various markets with various problems, you’ll come up with all sorts of ideas of how to solve those problems. The great thing is that then you can validate your product idea with people who you already know have a solvable problem.

This is a great way to do things if you have a particular problem yourself, and you want to find out if there are other people like you who have that same problem. By talking to lots of people with the same problem, you’re going to come up with a much better solution than you would if you just solved things for yourself.

Solve a Problem for a Particular Market

A slightly different approach is to pick your market first. Let’s say you have a special affinity for auto mechanics or busy moms or accountants at mid-sized companies.

The trick here is that you’re not going to change your market. You’re going to figure out some massive problem that is being experienced by a large portion of the market, and you’re going to solve it for them.

Your first step is going to be some ethnographic research. You need to really get into the heads of your target market and see what makes them similar and what’s driving them nuts. You’re not going into the research with an idea of the problem you want to solve for them. You’re going to let their needs drive your product decisions.

This is a great method if you happen to have some specific connection with a group or industry. Let’s say you collect porcelain owl figurines. You might desperately want to solve a problem for other porcelain owl aficionados, but you should be open to what problem you want to solve for them. For example, it might be how to get large numbers of high quality porcelain owls. Or it might be ways to contact therapists that deal with severe hoarding issues. Let the user research guide you!

The Easiest Kind of Customer Development

Hopefully you’re noticing a pattern here. The easiest kind of customer development is the kind that you do before you have a very solid product idea.

If you figure out your problems and your market before you come up with an Idea or a Solution or a Product, then when you do build something, you’ve already done a huge amount of the work in figuring out if anybody’s going to use it.

This is really about controlling which variables you’re testing. It’s hard to simultaneously find a problem, a market, and the problems with a real product all at once.

However, once you’ve validated your market and your problem, you can create something that solves that specific problem for that particular market. The beauty of this is that if you build a product for a problem you know exists in a market you know needs it and still nobody uses it, you can be pretty certain that the problem is your product.

Like the post? Follow me on Twitter.

Give the Users What They Really Want

Recently, I’ve been trying to teach startups how to do their own user research. I’ve noticed that I teach a lot of the same things over and over again, since there are a few things about research that seem to be especially difficult for new folks.

One of the most common problems, and possibly the toughest one to overcome, is the tendency to accept solutions from users without understanding the underlying problem. In other words, a user says, “I want x feature,” and instead of learning why they want that feature, new researchers tend to write down, “users want x feature," and then move on.

This is a huge issue with novices performing research, When you do this, you are letting your users design your product for you, and this is bad because, in general, users are terrible at design.

Ooh! An Example!

I participated in some user research for a company with an expensive set of products and services. Users coming to the company’s website were looking for information so they could properly evaluate which set of products and services was right for them. Typically, users ended up buying a custom package of products and services.

One thing we heard from several users was that they really wanted more case studies. Case studies, they said, were extremely helpful.

Now, if you’re conducting user research, and a customer tells you that he wants case studies, this might sound like a great idea.

Unfortunately, the user has just presented you with a solution, not a problem. The reason that this is important is that, based on what the actual underlying problem is, there might be several better solutions available to you.

When we followed up on users’ requests for case studies with the question, “Why do you want to see case studies?” we got a variety of answers. Interestingly, the users asking for case studies were all trying to solve entirely different problems. But were case studies really the best solution for all three problems?

These were the responses along with some analysis.

“I want to know what other companies similar to mine are doing so that I have a good idea of what I should buy.”

The first user’s “problem” was that he didn’t know how to pick the optimal collection of products for his company. This is a choice problem. It’s like when you’re trying to buy a new home theater system, and you have to make a bunch of interrelated decisions about very expensive items that you probably don’t know much about.

While case studies can certainly be helpful in these instances, it’s often more effective to solve choice problems with some sort of recommendation engine or a selection of pre-set packages.

Both of these more quickly help the user understand what the right selection is for him rather than just give him a long explanation of how somebody else found a good solution that might or might not be applicable to the user.

“I want to know what sorts of benefits other companies got from the purchase so I can tell whether it’s worth buying.”

The second user’s “problem” was that he wanted to make sure that he was getting a good value for his money. This is a metrics problem. It’s like when you’re trying to figure out if it’s worth it to buy the more expensive stereo system. You need to understand exactly what you’re getting for your money with each system and then balance the benefits vs the cost.

This problem might have been solved by a price matrix showing exactly what benefits were offered for different products. Alternatively, it would be faster and more effective to display only the pertinent part of the case studies on the product description page - for example, “Customers saw an average of 35% increase in revenue 6 months after installing this product.”

By boiling this down to only the parts of the case study that were actually important to the user, it gives you more flexibility to show this information - statistics, metrics, etc. - in more prominent and pertinent places on the site. This actually increases the impact of these numbers and improves the chance that people will see them.

“I want to see what other sorts of companies you work with so that I can decide whether you have a reputable company.”

The third user’s “problem” was that he hadn’t ever heard of the company selling the products. Since they were expensive products, he wanted the reassurance that companies he had heard of were already clients. This is a social proof problem. It’s like when you’re trying to pick somebody to put a new roof on your house, so you ask your friends for recommendations.

His actual problem could have been solved a lot quicker with a carousel of short client testimonials. Why go to all the trouble of writing up several big case studies when all the user cares about is seeing a Google logo in your client list?

Why This Matters

This shouldn’t come as a surprise to any of you, but users ask for things they’re familiar with, not necessarily what would be best for them. If a user has seen something like case studies before, when he thinks about the value he got from case studies, he’s going to ask for more of the same. He’s not necessarily going to just ask for the part of the case study that was most pertinent to him.

The problem with this is that many people who might also find certain parts of case studies compelling won’t bother to read them because case studies can be quite long or because the user doesn’t think that the particular case study applies to him.

Obviously, this is applicable to a lot more than case studies. For example, I recently saw a very similar situation from buyers and sellers in a social marketplace asking for a “reputation system” when what they really wanted was some sort of reassurance that they wouldn’t get ripped off. I could name a dozen other examples.

The takeaway is that, when somebody asks you for a feature, you need to follow up with questions about why they want the feature, even when you think you already know the answer!

Once you know what their problems really are, you can go about solving them in the most efficient, effective way, rather than the way the user just happened to think of in the study.

Instead of just building what the user asks for, build something that solves the user’s real problem. As an added bonus, you might end up building a smaller, easier feature than the one the user asked for.

The Art of the UX Steal

I’ve been building interfaces for a very long time, and I can tell you that the number of times I’ve had to solve a completely new and unusual user problem is remarkably small. This isn’t surprising. The vast majority of products we build incorporate a lot of familiar elements.

For example, think about the number of products you use that include one or more of the following: login, purchasing, comments, rating systems, order history, inventory management, or user generated content.

Do you expect that every single login experience gets redesigned completely from scratch in a vacuum? Of course not! It would be annoying if they were, since each new version would almost certainly differ just enough to make things confusing. Having design standards for things like logging in makes a lot of sense for both users and designers.

However, this tendency to fall back on patterns, or just to copy whatever Apple/Amazon/Facebook is doing, can cause some problems, especially for startups. There are a few big reasons why you shouldn’t just adopt another company’s solution without serious consideration.

They May Not Want Exactly What You Want

Companies have hidden agendas. But their agenda is not always your agenda, which means that their optimal design is not your optimal design. And if you think that they’re always optimizing for the best user experience, you’ve lost your damn mind.

Want an example? Ok! Have you ever purchased an item and been opted in to receiving email deals from the company’s partner sites? As a user, who likes that? Who thinks that’s a great user experience? Exactly.

Then why do companies do it? They do it because they have made the business (not UX) decision that they make more money by opting people into partner deals than they lose by slightly annoying their customers. That’s a totally reasonable calculation for them to do.

Now, let’s say your biz dev person comes to you and says he wants to add that feature to your checkout process because he has a partner lined up who is willing to pay for the privilege of getting your users’ email addresses. He says it will be ok to add the feature because other big companies are doing it, so it must make money.

But you have no idea how much money they’re getting for making their UX worse. You have no idea of the number of users they may be losing with this practice. And even if you did know their numbers, you can’t decide whether this feature is the right business decision for you until you know what those numbers are going to be for your product.

In an ideal world we could always just choose whatever made the best possible user experience, but realistically, we make these kinds of business/UX tradeoffs all the time. They’re inevitable. Just make sure that you’re making them based on realistic estimates for your product and not on the theory that it’s right because a bigger company is doing it.

They Don’t Do Exactly What You Do

By my count, Amazon has sold at least one of pretty much everything in the world. Ok, I’m just extrapolating from my purchase habits, but you know what I mean.

Not only do they sell products directly, they also allow other companies and individuals to sell through their marketplace. They also sell a lot of different versions of the same product. This makes their product pages pretty complicated.

Does your product do all of those things? If you work for a startup, I certainly hope not, since many of Amazon’s features were added over the course of more than a decade.

If your product doesn’t have all those features, then you might want to do all sorts of things differently than Amazon does. For example, your product pages could be significantly simpler, right? They could emphasize entirely different things or have clearer Calls to Action or more social proof because they don’t need to account for all of Amazon’s different features.

Whether or not you even have product pages, the point is that no other company is doing exactly what you’re doing (or if they are, you have an entirely different problem), so their optimal UX is, by necessity, going to be different from yours.

They Can Get Away with It

If Dante were writing today, the 9th circle of Hell would have involved trying to sign into multiple Google accounts at once. True story.

A friend of mine decided to make me angry the other day, so he showed me a Google docs screen where the Save button was so cleverly hidden it took him several minutes to locate it. This was on a screen that had maybe four elements, and he’s a very senior software engineer, so this probably wasn’t user error. I find the usability on certain Google products almost sadistically poor.

But I put up with it because Google provides me with incredible value for free that I can’t get anywhere else even by paying for it.

I don’t use things like Google docs for their UX. In fact, I use them in spite of large portions of their UX. And if your UX borrows from Google through some misguided notion that just because Google does it, it must be right, I will quit your product in a freaking heartbeat and bad mouth it to all my friends.

The moral of this story isn’t just “don’t steal UX from Google,” although that’s not bad advice. The moral is that very few companies succeed in spite of their UX, and if you happen to steal UX from them, you’re doing it wrong.

On a side note, you know what had a fabulous UX? The original Google product - the one where there was just a single search box, two buttons, and a hugely successful algorithm for finding great results. Unsurprisingly, that’s the UX that got us all hooked in the first place.

The Right Way to Steal

Now that the horror stories are out of the way, you still shouldn’t be coming up with every design element from scratch.

Not only is it ok to steal a basic login process from another product (although not Google), it’s almost certainly the best possible thing you could do. Having a non-standard way for users to log in to your product is just needlessly confusing.

One product I use on a regular basis used to put their Log In button on the top left of their home page instead of the top right. Just this little change meant that several times I had a hard time remembering how to get into the product, and wasted several seconds searching for the button. I probably wasn’t the only one to complain, since they fixed it relatively quickly.

Logging in isn’t the only thing to standardize. Any time you have a simple activity that users do regularly in lots of other products, you should at least check to see whether there is a standard and consider adopting it.

Of course, you can always choose not to do things the way everybody else is doing them, but you should have a very strong reason for changing things, and you should definitely a/b test your change against the standard design pattern.

Trust But Verify

Most importantly, when you are planning on stealing - or “adopting a standard” as we’re now going to euphemistically call it - it’s still important to test it.

I like to do quick qualitative tests to observe some people actually using the standard. In fact, often I’ll test the standard on competitors’ products before implementing it, rather than implementing it and then finding out that it’s crap. Then, I’ll test again once it’s implemented in my product.

In general, the more companies who are doing things identically the less likely it is to be confusing. But it’s still necessary to make sure that the design works in the context of the rest of your product.

Like the post? Follow me on Twitter!

Breaking the Rules: A UX Case Study

Recently, I was lucky enough to be featured in Smashing Magazine's brand new UX section! Smashing is already a fabulous resource for web design and coding, and I think it's going to be a great place to learn about user experience.

You should read my first article, Breaking the Rules: A UX Case Study.

Here's a little something to get you started:

I read a lot of design articles about best practices for improving the flow of sign-up forms. Most of these articles offer great advice, such as minimizing the number of steps, asking for as little information up front as possible, and providing clear feedback on the status of the user’s data.

If you’re creating a sign-up form, you could do worse than to follow all of these guidelines. On the other hand, you could do a lot better.

Design guidelines aren’t one size fits all. Sometimes you can improve a process by breaking a few rules. The trick is knowing which rules to break for a particular project.

Read the rest of the article!

Stop Worrying About the Cupholders

Every startup I’ve ever talked to has too few resources. Programmers, money, marketing...you name it, startups don’t have enough of it.

When you don’t have enough resources, prioritization becomes even more important. You don’t have the luxury to execute every single great idea that you have. You need to pick and choose, and the life of your company depends on choosing wisely.

Why is it that so many startups work so hard on the wrong stuff?

By “the wrong stuff” I mean, of course, stuff that doesn’t move a key metric - projects that don’t convert people into new users or increase revenue or drive retention. And it’s especially problematic for new startups, since they are often missing really important features that would drive all those key metrics.

It’s as if they had a car without any brakes, and they’re worried about building the perfect cupholder.

For some reason, when you’re in the middle of choosing features for your product, it can be really hard to distinguish between brakes and cupholders. How do you do it?

You need to start by asking (and answering) two simple questions:
  • What problem is this solving?
  • How important is this problem in relation to the other problems I have to solve?
To accurately answer these questions, it helps to be able to identify some things that frequently get worked on that just don’t have that big of a return. So, what does a cupholder project look like? It often looks like:

Visual Design

Visual design can be incredibly important, but nine times out of ten, it’s a cupholder. Obviously colors, fonts, and layout can affect things like conversion, but it’s typically an optimization of conversion rather than a conversion driver.

For example, the fact that you allow users to buy things on your website at all has a much bigger impact on revenue than the color of the buy button. Maybe that’s an extreme example, but I’ve seen too many companies spending time quibbling over the visual design of incredibly important features, which just ends up delaying the release of these features.

Go ahead. Make your site pretty. Some of that visual improvement may even contribute to key metrics. But every time you put off releasing a feature in order to make sure that you’ve got exactly the right gradient, ask yourself, “Am I redesigning a cupholder here, or am I turbocharging the engine?”

Retention Features

Retention is a super important metric. You should absolutely think about retaining your users - once you have users.

Far too many people start worrying about having great retention features long before they have any users to retain. Having 100% retention is a wonderful thing, but if your acquisition and activation metrics are too low, you could find yourself retaining one really happy user until you go out of business.

Before you spend a lot of time working on rewards for super users, ask yourself if you’re ready for that yet. Remember, great cupholder design can make people who already own the car incredibly happy, but you’ve got to get them to buy it first, and nobody ever bought a junker for the cupholders.


I am not anti-animation. In fact, sometimes a great animation or other similar detail in a design can make a feature great. Sometimes a well designed animation can reduce confusion and make a feature easy to use.

The problem is, you have to figure out if the animation you’re adding is going to make your feature significantly more usable or just a little cooler.

As a general rule, if you have to choose between usable and cool, choose usable first. I’m not saying you shouldn’t try to make your product cool. You absolutely should. But animations can take a disproportionate amount of time and resources to get right, and unless they’re adding something really significant to your interface, you may be better served leaving them until later.

“But wait,” a legion of designers is screaming, “we shouldn’t have to choose between usable and cool! Apple doesn’t choose between usable and cool! They just release perfect products!”

That’s nice. When you’ve got more money than most first world governments, you’ve got fewer resource constraints than startups typically do. Startups make the usable/cool trade off every day, and I’ve looked at enough metrics to know that a lot of cool but unusable products get used exactly once and then immediately abandoned because they’re too confusing.

Note: this may seem to contradict my point about attracting users first and then worrying about retention, but I’d like to point out that there’s a significant difference between solving long term retention problems and confusing new users so badly that they never come back.

Before you spend a lot of time making your animation work seamlessly in every browser, ask yourself if the return you’re getting is really worth the effort, or if you’re just building an animated cupholder.

Your Feature Here

I can’t name every single different project that might be a cupholder. These are just a couple of examples that I’ve seen repeatedly.

And, frankly, one product’s cupholder might be another product’s transmission. The only thing that matters is how much of an effect your proposed change might have on key metrics.

As a business, you should be solving the problems that have the biggest chance of ensuring your survival. Cupholder projects are distractions that take up too much of your time, and it’s up to you to make sure that every project you commit to is going to give you a decent return.

If you want to identify the cupholders, make sure you’re always asking yourself what problem a feature is solving and how important that problem is compared to all the other problems you could be solving. Cupholders solve the problem of where to put your drink. Brakes solve the problem of how to keep you from smashing into a wall.

Of course, if I got to choose, I’d rather you built me a car that drives itself. Then I can use both hands to hold my drink.

Like the post? Follow me on Twitter!

5 Fun Ways to Ruin Your Startup

So, you’re interested in ruining your startup. At least, that’s what it seems like based on a lot of decisions I see some companies making.

Let’s talk about some of those terrible decisions that really hurt startups.

Hire Big Thinkers

Here’s the thing about Big Thinkers or people who describe themselves as Big Picture People. They don’t execute. At least, they don’t execute in any way that is helpful to a startup.

Sure, there are a few people who can both lead and get their hands dirty with details. If you find one of those people, hire them immediately.

But more often, I see startups stall out because they’ve got somebody making decisions who doesn’t have to actually implement any of those decisions. They’re delegators. And the problem is, at very early stage startups, there just aren’t enough people to delegate TO.

If you’ve got a team of four or five people (or even ten or fifteen), every person should be spending the majority of his or her time actually building, making, designing, writing, testing, selling, or some other verb that isn’t “setting direction” or “planning” or “establishing policies.”

Want a successful startup? Hire Big Doers, not Big Thinkers.

Talk About Awesome Features All The Time

Yes, yes. You have this fantastic idea for the next big pivot that’s going to make you all rich. But you know what? That idea that you had 2 months ago that you still haven’t finished building was also fantastic. So is the one you’ll have 2 months from now. Also the one you’ll have 2 minutes from now.

Startup people are incredibly rich in ideas. Unfortunately, they tend to be broke in every other conceivable resource.

A great way to ruin your startup is to spend all of your time in meetings discussing in detail all the wonderful features you’re going to add in the future. Instead, capture the broad outlines of the idea quickly, put them in your backlog, and, when you’ve actually built something and need to move on to something new, see what ideas you’ve collected that would solve a real customer need. THEN design and build them.

Want a successful startup? Sure, you need to dedicate a little bit of time to thinking about the future, but spend a hell of a lot more time working on the present.

Wait To Ship Until It’s Perfect

It can be tough to release something into the wild before you think it’s perfect. But the thing is, it’s never going to be perfect, and the faster you get it out there, the faster you’re going to start learning which parts are the least perfect.

The longer you put off getting something in front of users, the more money you’re going to spend on something that might very well fail. Wouldn’t it be better to find that out early enough to turn it around and make it awesome?

Want a successful startup? Release small pieces of your product often, and get over worrying that it’s ugly or doesn’t work exactly the way you want it to. You’re just going to end up changing it all anyway.

Work 40 Hours a Week

This one may not be what you expect. It’s not some diatribe about how startup employees need to work 24/7 and not have outside lives and eat all their meals at their desks. If that works for you, great. Personally, I enjoy going outside.

But you do need to acknowledge that work at a startup doesn’t follow a strict 9-5 routine. Sometimes you need to check on things over the weekend or answer customer complaints late at night. Sometimes you need to make a final push to get something out the door quickly. Sometimes decisions need to be made outside of regular business hours, and there isn’t anybody else to make them.

Want a successful startup? You don’t need to live at the office, but you do need to be aware of what’s happening and be able to react when necessary. If you want to turn your phone off at 5pm on Fridays, you might consider working someplace where you’ve got more people to back you up. 

Make A Lot of PowerPoint Decks

Sure, investors love them, and you’ve always got to show something to your board, but I’ve seen this get really out of hand. If you’re spending an hour or two a week building slides to share information with five other people, you are wasting everyone’s time.

I get that there’s important information that you need to share with the team, but the problem with PowerPoint is that people start doing things like tweaking display and finding funny pictures to make their points. A whiteboard works just as well for writing a few bullets, and it’ll get you out of meetings faster, not to mention taking far less prep time. 

Want a successful startup? Consider creating a simple dashboard of all the metrics that everybody in the company should be monitoring so that they can see the pertinent information at any time. That way, nobody’s waiting on you to build graphs and paste them into a deck once a week.

Like the post? Follow me on Twitter!