Product Team Mistakes, Part 1: Communicating Company & User Needs

A little while ago, I asked a lot of designers what product managers did that annoyed them the most. For the sake of fairness, I also asked PMs about the most irritating habits of designers. I thought maybe I’d get a few responses and write up a quick blog post about some of the worst offenders. I’m going to be honest here. I dramatically underestimated the number of responses I’d get. 

This is the first in a series of blog posts covering some of the biggest mistakes product teams are making when it comes to collaborating and a few suggestions of how all of us might work together a little better. 


Understanding the Business

One of the biggest complaints was fascinating, because I heard it from both PMs and designers. Designers complained that PMs were bad at understanding and describing the business case for features they were requesting, while several PMs complained that designers didn’t understand the company’s business. 

Whatever you think about splitting up roles within a product team, most people agree that understanding and explaining the business side of a product is more the PM’s job than the designer’s. If they don’t understand the business or if they’re not sharing it in a way that helps everyone know what is being built, that’s a pretty serious problem. Still, let’s not let designers off the hook here. Everybody making changes to the product should understand the business needs, but it sounds like there are quite a few folks out there who don’t. 

Designers cited “vanity metrics” and “death through optimization” as examples of PMs who misused metrics or didn’t understand the business well. Instead of focusing on important KPIs that would reflect a better user experience or an improvement in things like revenue or retention, some PMs looked at numbers that didn’t mean much, like “time on site” or “total registered users.” Others spend a huge amount of time focusing on eking out tiny improvements with tweaks to things like button color or text, instead of making larger changes that might have a significant impact on usability or usefulness. 

Several designers also said that their PMs only seemed to have a very high level understanding of the product and didn’t have any real ideas about how to improve anything important. Designers felt that PMs should have a deep understanding of the business model and how changes to the product contributed to improving the bottom line and customer experience. Unfortunately, in many cases, PMs either didn’t have a firm grasp on the economics of the product or they couldn’t explain it in a way that designers understood. 

I’m not putting all the blame on the PM here. There were also PMs who complained that designers or researchers with whom they worked were actively hostile to learning about money. When the PMs tried to get designers to understand that their work had to improve metrics, some designers insisted that design was somehow different, and they were exempt from understanding the business model. 

Solutions vs Problems

Another frequent complaint was that PMs weren’t sharing user needs or problems with the team. In fact, in some cases, they were actively interfering with designers contacting users to learn this themselves, but I’ll explain more about that in a future blog post. 

So if PMs weren’t clearly articulating business needs or user problems, what were they doing? Demanding specific solutions, in most cases. Designers claimed that PMs would frequently come to them with a “solution” and simply ask the designer to “make it pretty” or in some cases “make it work.” 

In general, designers wanted PMs to share the goals of the user and the specific problem that needed to be solved. Instead the PMs would come up with a solution and deliver it as a specific feature request without explaining how the feature would help the users succeed. 

Even when the PMs did write problems statements, they would sometimes write them in the form of a solution. For example, “The user can’t place their order using SMS,” or “The user can’t use the advanced search tools to filter results by relevancy,” rather than explaining the context of the user and the user goals that weren’t being achieved. 

The problem with this approach is that it devalues the potential contribution of designers in a very specific way. It limits designers to mostly visual decisions, which is fine if you’re dealing with a designer who is only concerned with things like typography, color, and whitespace. But it’s a terrible waste of designers who have experience and training in things like information architecture, systems thinking, or research synthesis. 

Many user experience and product designers are used to coming up with creative solutions to user needs. They would much prefer being given a problem and asked to solve it rather than being given a feature and asked to draw it. 

Why does this happen? 

None of this is particularly unusual. In my experience working with teams, I’ve seen quite a few PMs who think their job is either to:

  • Come up with all the features and solve all the problems themselves, OR

  • Come up with a high level idea and then leave all the pesky details (like how it works and what metrics it will improve and how it might help users) to somebody else

The biggest culprits for all of these behaviors are the following (all of which probably deserve blog posts of their own, but who’s got that kind of time??): 

  • The CEO/Stakeholders really want a specific feature

  • The designers on the team are largely visual designers and aren’t used to being asked to come up with feature ideas 

  • PMs don’t have access to customer research and/or metrics (I know! It’s terrible.)

  • Sales says they need a key feature to be competitive with a big customer (VERY common in B2B)

  • Somebody falls in love with an idea or solution instead of starting from the business and user needs

  • PMs believe their job is to simply gather requirements from various stakeholders and then prioritize the list (to be fair, in some orgs, this is literally the PM’s job - although it rarely results in a good product)

How do you fix it? 

If you’re a PM reading this, you might think, “Oh, this doesn’t apply to me!” And you may very well be right! This was not a huge statistically significant survey of all types of teams. This was random whining on the Internet. But let’s just say there was no shortage of that whining, and there were some extremely strong patterns to be found, many of which I’ve seen in my own experience working with teams. 

The best way to find out if your team (not just the designers!) really understands the business is to ask them to explain it to you, preferably in a friendly, non-confrontational way. If they don’t get it, try not to automatically blame them or assume designers don’t care. Take a look at what you’re doing to make sure that everybody on the team understands the “why” behind everything you build. 

Also, make sure that you take a look at when you’re bringing designers into the planning process. Do you wait until you have a really good idea of the feature and how the feature will work before “handing things over to” design? Stop it! Bring design in at the point where you’ve figured out the business need and the general user problems and have your UX designers help figure out the right features. 

Of course, handing over nothing more than a single sentence or short paragraph can be just as bad. Saying “we need better search!” isn’t strategy! It isn’t high level thinking! It isn’t even particularly helpful! 

Instead, try framing what you need as a user and business problem. “Our data are showing that a lot of users are searching for x or y and then abandoning the product. Some initial research suggests that they may get really frustrated because they’re having a hard time understanding the results. What are some things we could do to fix this for them and help them get what they’re looking for.” 

And designers don’t get a pass on any of this either. If you refuse to understand the business needs or feel like getting insights from customers is somebody else’s problem, you’re not going to make very good decisions. 

If PMs come to you with a fully formed feature, try asking about the needs behind it. Maybe something like, “This looks really interesting. Can you tell me what sort of impact you expect this to have on the business? How about the user need? What is this solving for them?” If you don’t understand the answer (or if the PM doesn’t have one), hopefully you can work together to understand why the PM wanted the feature in the first place. 

Whether you’re a PM or a designer or anybody else working within a company to build something for humans, it’s critical that you understand why everybody is making the decisions they’re making. When we all understand what the company needs and what the users need, we can all make better decisions. If you’re interested in some exercises for working better as a team, you should check out Build Better Products. 

Portfolios for Product Managers

Interviewing people is hard. If you’ve been a hiring manager for more than a few years, you’ve almost certainly run into somebody who seems great in the interview but can’t do the work. And you’ve probably missed out on some amazing talent who, for whatever reason, weren’t impressive in their interviews.

It’s tough on the other side, too. When you’re looking for a job as a product manager, you need to find a way to show people not just that you’re great in conversation but that you’re great at making things. Designers and engineers have a bit of an advantage here over PMs. They have portfolios and GitHub where they can showcase actual things that they’ve made.

But as a PM, what you make most often is decisions. How do you show that you made the right ones?

I know it’s not common, but I think that interviewing would be an awful lot easier on both sides if everybody created portfolios of their work, even PMs. Now, before you run out and grab a Dribbble account, let me give you a few guidelines for what a good portfolio could look like.

Don’t worry! You don’t have to be an artist (or even a designer) to make one. I’m not suggesting you create a beautiful showpiece, just something that will help people understand what sort of projects you’ve worked on and what your contribution was to the team.

A good portfolio should consist of one or more case studies of projects that you’ve personally worked on. The point of each case study is to show your particular contribution to achieving a necessary business goal.

State the Goal

When I’m working with designers on portfolios, I always ask them to make sure to state the goal of the project up front. While it can be tempting to jump right into a long description of the thing you made, that can pretty quickly turn into a boring list of features.

There’s a good chance that those features won’t be at all interesting or relevant to potential hiring managers. What IS interesting is how you made decisions about those features, because it shows the way you approach problems. To do that, make sure you share the problem you were trying to solve or the goal your team was trying to reach.

The type of goal you want to share might be a specific metric, like “increase revenue among a specific subset of users” or “decrease the amount of time users spend on tasks that could be automated.” It could also be something more exploratory like “find an adjacent market that could be an opportunity for an existing product expansion.” Or it could be an experiment to validate an existing idea.

Whatever the goal, make sure it’s not something proscriptive like “build a comments system.” Describing your goal that way makes it clear that you’re not thinking strategically about customer needs; you’re just taking orders from somebody else and executing on an existing plan. If you did build a comments section, tell your reader why on earth you’d want to do such a thing!

Show Your Work (and give credit to others)

I did say that you don’t need to be an artist, and that’s true. You do need to show your work deliverables though.

Products don’t jump fully formed from the heads of their creators. If you’re going directly from vague feature to fully implemented product, then you’re either skipping a bunch of steps or you’re completely removed from how your product is actually getting built.

Show the process that your team used to research, synthesize, ideate, communicate, and develop. If you did in depth user research, describe how you did it and what you learned. If you made sketches or mockups, show them. If you ran a design sprint, explain how and why and show the results. If you built a Powerpoint deck to sell the idea to execs, include a few slides. And if you actually built a functional prototype, by all means link to it (if you can).

This is your chance to show what you’re capable of. It’s also the chance to give credit to the rest of your team. If the designer made the mockups, credit them. If an engineer helped on the prototype, give them a shout out. Explain which parts you built yourself and where you collaborated with others, since very few of us are expected to build software on our own.

Explain Your Thinking

Here’s the most important part. You need to explain why you made the decisions you did. Try, if at all possible, to pick a project where the explanation isn’t just “because the senior execs told me to,” although I know that most PMs I know have lived some version of that project.

You already said what the goal was, and you showed what sorts of ideas you came up with and how you explored them. Now explain why you picked the direction you did.

What does the product do now do that it didn’t do before, and how did you expect it to help your company reach its goal? What made you sure that it would work? How did you prioritize the changes you made over others?

Share the Result (if possible!)

I know, it’s not always possible, but if you can share the results of the change, even at a high level, it can be incredibly helpful. Even if the feature didn’t perform in the way you’d hoped, sharing that and explaining what you did to fix it later can be a great example of how you’d recover from a similar setback at your new job.

If you don’t have (or aren’t allowed to disclose) numbers, consider describing user reaction to the feature or the general reception by the intended audience. Sharing results helps show that you care about the outcome of what you’re building and that you are focused on creating value for both your users and your company.

Get Started Now

So, how can you do this? There are a few options. One is to go with something fairly simple like this write up done by an ex-student of mine in UX. Alternatively, here are a couple examples made by students of Alex Cowan, with whom I’m teaching class in May 2019:

“But wait,” you say. Those are all student projects, not real life examples. That’s right. For those of you who don’t have projects that you can share publicly, presenting a student project or some sort of side hustle can still help show what you can do.

Learn to Be Technically Literate

Before the printing press was invented in the 15th century, the vast majority of people around the world were illiterate. Which makes sense. Before the printing press, there wasn’t much to read.

Miniature from Liège-Maastricht area, ca. 1300-1325 [Public domain], via Wikimedia Commons

Miniature from Liège-Maastricht area, ca. 1300-1325 [Public domain], via Wikimedia Commons

Even after the press, it took hundreds of years before a majority of people in Europe were literate, and more than half the world’s population still couldn’t read until more than halfway through the 20th century. There are some fascinating charts and graphs here, if you’re interested.

But this post isn’t about learning to read. It’s about technical literacy.

The first real computer programmers (apologies to Ada Lovelace) appeared in the late 1940s and early 1950s. Considering the fact that they had to write assembly code by punching holes in cards, it’s not surprising that there weren’t a whole lot of them. Now, 70 or so years later, there still aren’t a whole lot of them.

Evans Data Corporation, a company that studies these sorts of things, estimates that there are about 23 million software programming jobs in the world. Of course, this doesn’t include folks who can code but aren’t employed as computer programmers, and it’s impossible to know how many of those there are, but even if there were 10 times as many people who could code as there are people employed as computer programmers, that would still only be about 3% of the world’s population.

That’s...not great.

As software takes over the world, that’s a huge number of people who will have very little understanding of how anything they use works, and who will find it harder and harder to participate in building new products. It’s like we invented the printing press but only a tiny minority of people bothered to learn to read all the books that are being printed.

I truly don’t believe that everybody needs to learn to program or that we need to teach everybody to be a software developer. There are still plenty of jobs where you’ll never have to write or even read a line of code. But there are going to be fewer and fewer products that don’t have any sort of code associated with them. Smart home devices mean that refrigerators have their own mobile apps now and have to connect to smart hubs. Hotel keys have embedded chips. Sales teams use complicated CRM systems to manage relationships. Everything is sold online. The number of jobs that don’t require any technical ability is becoming vanishingly small.

Understanding how technical things work and interrelate is incredibly important. It can also be incredibly intimidating. There’s just so much to learn, and it can be hard to figure out where to start. Let’s say you want to build a simple mobile app. What language should you use? What development environment? How do you get started? What are packages and libraries? Do you need a server? What platforms should it run on? Why am I getting all of these cryptic errors??? I don’t blame people for taking one look and running for the hills. We don’t make it very easy to get started.

The Easy Way to Get Started

It doesn’t have to be this hard. The great thing about building stuff for the web is that you can get started it with nothing more than a text editor and a browser. With the knowledge of a few pretty simple things, you can start making things that work immediately.

So, what do you really need to know? The easiest place to start is still HTML and CSS. They give you a quick and obvious way to build things that people can use. Add in some basic Javascript, and suddenly you can build fully interactive prototypes and simple web applications and tools.

Even if you never ship a single line of code to a customer, being able to make something yourself can give you the confidence to start learning about other, more technical aspects of building products. If you work with engineers, it can give you a better understanding of some of the challenges they face. And, if you’re anything like me, it can make you feel amazing and powerful and a little bit like a wizard.

Why Is Innovation Hard at Big Companies?

I gave a keynote at Lean Startup Week 2017 in SF, early in November about some of the most common problems that large companies have implementing Lean Startup. Here's a little blog post I wrote up for the Business Talent Group blog summarizing the talk. 

If you’re responsible for launching new products, you’ve probably come across Eric Ries’s best-selling book, The Lean Startup. The Lean Startup methodology—which was created to help founders in Silicon Valley build better products—is incredibly useful for new companies and entrepreneurs who are trying to create innovative products and find product-market fit.

Over the years, however, Lean Startup has gone from something practiced by a few early adopters in very small companies to something that’s made inroads at organizations like GE, Toyota, and the federal government. And when you’re trying to introduce a big change at a large, established organization, you run into some very specific challenges.

I’ve spent years helping organizations of all sizes build new products and, in particular, create product development processes that help them continue to deliver. Here’s what I’ve learned about being an innovator at big companies—and helping them adopt the best of Lean Startup methodology. 

Read the whole post here >

Making Dashboards Useful and Usable

Products that people love and incorporate into their everyday lives tend to have two things in common: they’re both useful and usable. In other words, they’re things that people people want to use because they fill a particular need, and they’re things that people can use, because they’re not prohibitively complicated. 

Unfortunately, a lot of products fail one or both of these tests pretty badly. Either nobody wants to use them because they don’t see the value, or people try using them and give up in frustration. If you’re struggling with an analytics dashboard that isn’t getting the sort of usage you’d like, it’s worth conducting some research in order to find out if you’ve shipped something useless or unusable. Or both! 

Read more on the Logi Analytics blog >

The Right Deliverables

Once upon a time, I worked with a designer who refused to use any tool except Illustrator. Everything got made in Illustrator, whether he was building a visual design mockup, a task flow, or a discussion guide for a user research session (seriously). All of his deliverables were gorgeous.

He was also the slowest designer in history. Every single thing he did took five times as long as it would have taken anybody else, and much of it wasn’t very usable or useful. Pretty, though. 

While the visual interface, if your product has one, is an important part of the user experience, it’s not the entire user experience. And that means that the deliverables designers create to demonstrate a visual interface are not the only deliverables they need to make. 

So, if designers aren’t going to just produce pixel perfect Photoshop or Illustrator files, what sort of deliverables should they be creating? That's easy. They should make whatever they need to communicate the thing that needs to be communicated to the audience to whom they're communicating it.

Let’s get a little more specific. First, you have to understand the role that design deliverables play in the product development process. Designers, the good ones anyway, help to craft the experiences that users will have with a product, but they are rarely the ones to build the end product. Of course, there are designers who also code or build things, but even when this is true, there are typically other people on teams who also need to build things that the designer has specified. This means that the designer needs to create some set of documents or artifacts showing other people what to build.

But those aren’t the only deliverables that designers create.

In fact, designers make artifacts for three general reasons:

  • creation
  • communication
  • validation
Designers make artifacts to aid in creation, communication, and validation.          - Tweet This
Deliverables for Creation

The first type of artifact or deliverable that designers use are those that are helpful during the creation and ideation phase of design. These are tools that designers use by themselves or with small groups of people working together in order to get ideas out of their heads and into the physical world.

These sorts of deliverables might include things like sketches, ideas written on sticky notes, affinity maps, or dozens of other works in progress. In fact, many of the exercises in my upcoming book, Build Better Products (Rosenfeld Media ‘16), produce these sorts of deliverables - often bunches of sticky notes presented in some sort of framework.

These deliverables are great for communicating within a small team and making sure that everybody is talking about the same thing.

Created by the amazing students at my Stanford Continuing Studies class!

Created by the amazing students at my Stanford Continuing Studies class!

Ideally, these are done roughly and quickly, since they’re essentially temporary and meant to facilitate a meeting or work something out in a group. In fact, they're hardly deliverables, at all. You might prefer to call them artifacts of the design process, if that's what you're into. 

When done right, these artifacts are incredibly useful to the people creating them and completely useless for communicating anything to anybody who wasn’t there when they were made.

Even when what you’re creating is a visual design, the early stages of working out that design can be done quickly with the goal of iterating through lots of ideas to find the one you want to move forward with. Many visual designers start with mood boards or collections of colors and examples of typography and imagery in order to narrow down the exact look and feel they want to achieve. Again, these don't tend to be that helpful to anybody who isn’t the designer or at least extremely familiar with the visual design process. 

That’s fine. Artifacts that help the creation process are not meant to be used for communication to other people after the fact. There are entirely different deliverables for those.

Deliverables for Communication

Designers have to communicate their ideas to other people. Frequently, they have multiple audiences for that communication. For example, they may have to communicate designs or concepts to engineers who are going to build the product. They may have to communicate new feature ideas or directions to customers in order to get feedback. They may have to present things to managers or execs within the company.

Each of these different audiences can require different types of deliverables. In fact, any given audience might require different types of deliverables depending on the purpose of the communication.

Some executives simply can’t stand seeing any designs that aren’t complete, pixel perfect, and fully interactive. Others might be fine with an early sketch or even a task flow. Depending on what the engineers are building, they might prefer a well constructed task flow and a set of detailed user stories rather than a static Photoshop mockup. At other times, they might need a detailed visual design specification.

Task flows help you understand which screens need to exist and how a user might experience them.

Task flows help you understand which screens need to exist and how a user might experience them.

Deliverables for communication are a type of product in themselves. You need to understand who the intended audience is and what you want to communicate to them.

However, these deliverables do tend to be higher fidelity than deliverables that are only intended to help the designer create things. Because they are meant to communicate complicated ideas to people who may not have had anything to do with their creation, they have to be easier to understand than the type that are used merely to help a team think about the product together.

Deliverables for Validation

Another type of deliverable is used for validation. For example, a designer might produce a mockup or interactive prototype for the purpose of usability testing or to get feedback from a customer on a particular direction the team is thinking of going.

As with the deliverables for communication, what you produce here is going to depend on your audience. Some customers may be comfortable with low fidelity sketches or static pictures of features, but in general, these are going to be the most detailed deliverables a designer creates.

There are good reasons for this. When you’re usability testing a prototype, you can get much more realistic feedback from a prototype that behaves like the final product. If you’re trying to get feedback from a customer about a possible feature, there’s an excellent chance that the customer doesn’t have nearly as much information about the product as you do, so showing a more realistic example will help them to assess whether it’s an interesting feature.

Of course, the type of deliverable that you share here will also depends on what your goal is. Are you interested in getting usability feedback? You probably want an interactive prototype. Do you want to get customers excited about an upcoming feature? A high fidelity mockup might be better.

In general though, when sharing with outside people, avoid very high level sketches and concepts or boxes and arrows, since outsiders will have a difficult time understanding what they’re looking at.

Why On Earth Does This Matter?

Ok, that was a lot of time spent talking about things that designers make, and you may be wondering why it’s useful. It’s not just designers that create artifacts and deliverables. Everybody on your team creates them, all the time. You probably create documents, decks, spreadsheets, emails, and a dozen other types of documents every day.

Many teams have trouble communicating because they create the wrong types of artifacts for the job they’re trying to do. Thinking about what you’re trying to communicate and to whom will help you determine the correct level of specificity required from a deliverable.

Being thoughtful about this can save you a huge amount of time - both because it keeps you from creating overly detailed deliverables and because it prevents a lot of confusion that can happen when you share the wrong level of deliverable with a team member or customer.

Let me give you an example. Let’s say you’ve just had a meeting with your team where you’ve been sketching possible feature ideas on a board. Maybe you’ve gotten to the point where you all agree on a direction and even sketched some wireflows. In order to make sure that everybody remembers what you decided, you take a picture of the whiteboard and attach it to the story in your issue tracker.

Wireflow. Illustration by the awesome Kate Rutter from Build Better Products. 

Wireflow. Illustration by the awesome Kate Rutter from Build Better Products. 

Now imagine that a new engineer has just joined the team, and they weren’t in the meeting where you had that discussion. How useful will that picture be? Or, imagine that you share it with a customer who requested a similar feature in order to get feedback. Do you expect that the customer will be able to give you any sort of useful information about what you’re sharing? Very unlikely.

On the extreme other end, let’s say that you decide that you need to make a change to your app to allow users to opt out of certain notifications, and you need to share the specifics with the engineers who will be building it. Do you really need a fully prototyped, pixel perfect version of the feature? Or would a quick task flow and a sketch showing the changes be more useful to the engineer who is implementing the change?

Instead of always creating the exact same deliverables or whatever’s easiest - photos of whiteboards, powerpoint decks, Photoshop mockups - think about the audience for the deliverable and what you’re trying to communicate. And make sure that everybody on your team does, as well.

A Deliverables Framework

When you’re deciding on what sort of deliverable to create, you need to consider the following:

  • who is your audience?
  • what are you trying to communicate?
  • what sort of action do you want them to be able to take?

Honestly, the best way to find the right deliverables with your team is to sit down with them and understand how they work, and then experiment with different levels of fidelity. If they want something with significantly more detail than you think is justified, talk to them to understand why.

Are they trying to avoid a problem they’ve had in the past? Are they uncomfortable making decisions? Are they new and lacking any of the background? Are you just really bad at judging how much direction someone might need? All of these are possible. In other words, treat your deliverables like a design problem and your coworkers or customers as the users of those deliverables.

Once you understand your user and what you want to communicate to them, you need to have a firm idea of what sort of action you’re expecting from them. Are they supposed to implement a feature? Give usability feedback? Help you flesh out a concept? Estimate the amount of work something would take? Greenlight a new project? You should always give people what they need in order to give you the sort of feedback that you want.

In other words, don’t expect people to give you usability feedback on a high level sketch. There simply isn’t enough information there to respond. On the other hand, a developer shouldn’t need a fully functional prototype with complete visual design to start working on building a feature.

Once you know who you’re communicating with and what you’d like to get back, you need to pick the right deliverable. Deliverables can come in a dizzying array of styles. Let’s look at a framework for deciding which is right for what you need to do.  

The first question you need to ask about your deliverable is whether it needs some visual component. In other words, can it be described easily in words or a story? Or does it need a conceptual model? A sketch? A full visual mockup? This depends on what it’s conveying, of course.

Some deliverables are more visual than others.  

Some deliverables are more visual than others.  

Many things benefit from being shown visually. For example, explaining the layout of a page or the context of use for a product can be done much better with images than with words.

However, other things, like how often an email gets sent or which pricing plans to offer to different types of customers might be better shown in something like a spreadsheet or user story. When you’re communicating something, don’t just fall back on whatever you’re used to. Ask yourself, “could this be communicated better with an image or with a story?”  

If you do need something visual in your deliverables, the next question you need to ask is how high fidelity does it need to be.

Some visual deliverables are higher fidelity than others.

Some visual deliverables are higher fidelity than others.

You should be careful here. While high fidelity visual designs can make users or team members feel more like a product is “real,” having a very finished looking prototype can get you worse feedback on your idea. When confronted with pretty, finished looking mockups, people tend to focus on the look of them rather than whether they’re useful or usable. A gorgeous demo looks like a fait accompli, and you’ll rarely get good input other than surface level visual comments.

You also need to decide how interactive your deliverable should be.

Some deliverables are more interactive than others.

Some deliverables are more interactive than others.

Again, how interactive something needs to be depends on the sort of feedback you want. You’ll get significantly better usability feedback on an interactive prototype than you will on a sketch or a static mockup. People who can play with something that feels like a real product won’t have to imagine nearly as much as they would if they were looking at a set of user stories. That said, interactive prototypes take time to build, and sometimes you don’t need that level of feedback.

The last thing to consider when creating a deliverable of any sort is how maintainable it needs to be. Everybody forgets to take this into account, and it’s exactly the sort of thing that will cause you problems six months from now.

There are a lot of options between a Google Doc and a Poster.

There are a lot of options between a Google Doc and a Poster.

Imagine that you’re creating a set of personas. A huge number of teams seem to think that personas should be turned into posters that can be printed out and displayed around the office. That’s fine. It can make them very high visibility.

However, imagine that three months from now you realize something that needs to change about the persona. How do you do that? You’d have to remake all the posters. That’s not terrible for things that are fairly simple and aren’t likely to change constantly. But if you’re building a product prototype for usability testing, being able to quickly and constantly make changes as the product changes and features get added will save you an enormous amount of time in the long run. If you’re building an interactive demo to show to high level execs in order to get funding for a project, on the other hand, being able to update that demo later is significantly less important.

The most important thing to remember in all of this is that deliverables, like everything else in the product development process, are not one size fits all. All the deliverables you create have a purpose and a user. Understand those before you make anything at all. 



Good Enough

I've been thinking a lot about building better products lately. After all, I'm writing a book called Build Better Products, and it'll be out this autumn, so I haven't been thinking about anything else, really. 

The hard part about building better products is often knowing what better means. This is especially true when building MVPs or first versions or experiments or whatever you want to call that thing that you put out in the world in order to see if anybody might care about it.

It's even harder, I think, for designers, since many of them seem to have some sort of belief in the idea of Good Design as its own thing. Like there's a cosmic governing panel that decides whether something is Well Designed that is independent of whether the product makes users happy or makes money for the company.

And it's a tricky balance. I'm the first one to point out that if you release an incredibly crappy product, you're not going to learn anything other than that people don't like to use crappy products. We're already pretty clear on that. They don't. On the other hand, if you spend months tweaking the fonts and obsessing over every single word or loading the product up with unnecessary features, you're very likely to waste a huge amount of time and money building things nobody wants. 

How do you choose? I really wish I had a simple system that would allow you to decide when you've hit Good Enough every single time. "Should I release now? Y/N" Maybe someday we'll get that working. Until then, how about a weird analogy? 

Let's say you're cooking dinner, and the first step is to cut up some potatoes. Now, if you do a terrible job of it and hack them up into uneven pieces, it's probably going to ruin the dish and make it inedible because half of the potatoes will be raw and half will be overcooked and mushy, and the whole thing will be awful. So, instead, you take a little time and use good knife skills and cut the potatoes better. 

Now you have to decide how much time you're going to spend on the potatoes. 

Obviously, you could make them perfect - where perfect means all exactly the same size and shape and weight or cut into animal shapes or trapezoids or whatever. Molecular gastronomists have almost certainly discovered the golden ratio of surface area to interior, and I'm sure they'd love to tell you about it.  

But the more time you spend carving your potatoes into identically sized spheres, the less time you have for cooking the rest of the meal. And, frankly, having the potatoes perfect doesn't contribute that much to the overall meal. The end result of perfect potatoes may not be noticeable to the person eating the meal, and even if they did notice, it wouldn't increase their enjoyment of the meal enough to justify the time it took you to do it. They don't want perfect potatoes at midnight. They want good potatoes at 7pm. 

Remember, your goal isn't to make a perfect potato - whatever that means. Your goal is to make dinner. Preferably a dinner that the people eating it will enjoy. 

And when you think about it, you don't even know what "perfect" means. Is it that the potatoes are all the same size? Is it that they're all the same weight? Is it that they're all exactly 20% smaller in order to improve the texture? Does it depend on the person who is going to be eating the potatoes? (note: it does! If you're cooking them for me, they should be sweet potatoes, and just go ahead and fry them, thanks.)

You don't know what "perfect" means. - Tweet This

The great thing about cutting decent potatoes that are close to the same size but not worrying about more than that is that you can get the meal on the table, have your family eat it, and then make decisions about what you want to try next time. Maybe the potatoes would be better if you cut them a little smaller. Maybe the dish needs twice as many potatoes. Maybe you decide to substitute cauliflower for potatoes like a terrible person who doesn't deserve food. Maybe the problem isn't the potatoes at all. It's the spices. They're all wrong. You didn't see that coming, did you? 

You'll have a much better idea of what "better" means once you've shipped the meal and gotten feedback about what people liked and hated and what they left on the plate and why. 

Remember, the more time you spend obsessing about the damn potatoes, the less time you spend fixing important things like the fact that you forgot to make dessert. 

This is why I say that there's nothing wrong with aiming for "good enough," especially on the first few versions of something.  Good enough doesn't mean "too crappy to learn from" and it doesn't mean we're never improving it. It means we're getting something out that is good enough to get feedback on and that we can improve over time.


Whose Job is User Research? An Interview with Adam Nemeth

For this installment of my series on good user research practices within companies, I spoke with Adam Nemeth, UX strategist at, a UX research firm based in Hungary. He shared his perspectives on how teams should think about user research and when they should get help.

Why You Should Be Doing Research Yourself

There are a lot of reasons that your team should own and run user research. Most importantly, research is deeply connected to the product. “Design is essentially a plan for a product,” Adam says. “Whoever is responsible for bringing the product on the market should be held responsible for the research about the ‘true’ underlying problem, and also the for the research which validates whether the product is truly a solution for the problem.”

Because understanding your user’s problem and finding the right solution for it are so integral to the product design process, whoever is making product decisions needs to be held responsible for the research that produces this understanding.

Of course, understanding the problem and solution are important, but they don't make up the entirety of user research. Another critical part of your product is its ease of use. “Learn usability testing,” Adam says. “For God’s sake, just do it!” He even wrote a Medium post on how to do it well, in case you don’t have any experience with it.

Why You May Need Help Doing Research

But doing your own user research may be easier said than done. There are, unfortunately, some common roadblocks that teams run into, especially when starting to conduct research without a specialist. 

“Research is easy to mess up,” Adam warns. “It’s a world full of biases.” That’s very true. It can be extremely difficult for PMs, designers, or founders to get unbiased feedback on their own work without appropriate training.

Adam explains, “A startup CEO once had a hard time believing nobody needed their wonderful product, even when it came out as an unsolicited statement from the 4th participant in a row.” Research needs to be done by somebody who can deal with the bad news. Because, as Adam says, “Research bringing only good news is usually self-deception.”

Even if you’re not actively denying bad news, some research techniques can be hard to learn and perform well. “Usability testing is easy,” Adam explains. “but learning how to do interviews and field studies properly is much more difficult. You have to watch your own posture, your tone of voice, choose your words carefully, and be open to a world you know is filtered by your own assumptions, yet you must strive to get a glimpse behind them.”

To improve, Adam recommends recording yourself, not just to listen for the answers to your questions but to hear the questions themselves. You want to hear what you’re asking, how you’re asking it, and the sorts of responses it’s eliciting so that you can improve.

Also, some research is simply harder to do. It’s not all just usability studies and guerrilla coffee shop tests. Diary studies take a long time and a lot of attention. Hard to locate participants from very specific groups can make recruiting a huge task. Sometimes you’ll need to find an external person to manage bigger research projects, just to make sure that they get the attention they need.

Finally, even if you do have a research specialist on the team, they can run into an entirely different set of problems. Sadly, user researchers within organizations aren't always believed. In-house researchers can suffer from credibility issues, through no fault of their own. Companies sometimes need to hear the same results from an outside consultant in order to really listen.

So, Who Is Responsible for Research?

“It all boils down to these three factors,” Adam explains. “Who is able to argue the best for the user against a product choice? Who is able to notice a product error? Who is responsible for the product?” Whoever that person is, they’re the one who should be responsible for research.

Whoever is responsible for it, “Understanding users should be deeply embedded in the culture,” Adam says. “When I'm working with clients, I always facilitate studies. I don't believe in handed-in reports, no one will care about them and everyone will forget them soon. But making sure every single stakeholder participated in field studies, and that we watch usability test videos together - that is an experience which brings users closer to everyone within a product team.”

In other words, it doesn’t matter if research is being done by internal resources or external consultants. We’re all responsible for being involved in the research so that we can truly understand our users.

Whose Job is User Research? An Interview with Amy Santee

Almost every time I give a talk, I get asked how people can convince their companies to adopt more user research or pay attention to the research that’s being done. I’ve always given various answers, ranging from “quit and go to a better company” to “try to make research more inclusive,” but I realized that I was giving advice based on too small of a sample set.

So, earlier this year, I became obsessed with finding out who owns user research in functional teams. I’ve asked dozens of people on all sorts of different teams what makes research work for them, and I’m sharing their responses here. If you’re someone who is very familiar with how user research works on your team and would like to participate, please contact me.

Recently, I asked Amy Santee, an independent UX research consultant, some questions about who should own research. She trained as an anthropologist, and she’s been doing user research for several years for companies ranging from healthcare to insurance to hardware and mobile tech companies, so she’s seen what works and doesn’t work in a lot of different models.

Who Owns It

“For internal teams,” Amy explains, “researchers and designers who do research should ‘own’ the research process in the sense of being the go-to people responsible for driving its fundamental activities: planning and budgets, coordination, research design, recruiting participants, conducting sessions, and disseminating the results. It’s not so much ‘owning’ it but being the point person for getting things done.”

One of the themes I’ve seen so far in these interviews is the strong difference between the responsibility for conducting research and the ownership of the results. Regardless of who is responsible for getting research done, research results and participation should be owned by the whole team. The researcher or designer might be driving the process, but everybody else on the team should be along for the ride.

It’s not just direct members of the team who need to participate, either. “Stakeholders in design, product, engineering, business, marketing and other areas should share in this ownership to the greatest degree possible,” Amy says. “That’s why they’re called stakeholders – they have (or should have) a stake in the game when it comes to incorporating research into their processes and decision-making.”

To be clear, in Amy’s model, the stakeholders aren’t just interested in the outcomes. They should be active participants in the research. They can offer important perspectives from their respective business areas, and they should contribute to the research process itself by observing sessions, brainstorming ideas and solutions, and helping to synthesize the results.

The benefits of this sort of participatory research, Amy says, are clear. “The more this is done, the more value people will see in being involved, and the less the researcher needs to ‘own’ research by him or herself. Stakeholders might even learn how to do research so they don’t always have to rely on a single person or team to do it.”

Researching without Researchers

Of course, not all teams are lucky enough to have dedicated researchers or designers who are trained in user research methods. Amy has some suggestions for those who decide to do research without any experience on the team.

“My preference is for internal researchers because they have an understanding of the company and product from the inside,” she explains. “They are able to really get a sense for how research fits into the design process and business strategy. They can build relationships with other business areas and roles in order to figure out how research can bring the most value, when to do it, who to get involved, how to communicate most effectively, and possibly make more effective recommendations.”

That said, there are reasons to bring in experts from outside. “Training from an expert who has the right background and experience can help a team get started with the fundamentals and avoid the inappropriate execution of a research project (e.g., wrong methodology, misinformed research questions, etc.),” she says.

Sometimes, combining an external expert with internal trainees can even yield certain unexpected benefits. For example, outside consultants might have a fresher look at the questions the team should be asking. They might be able to bring up things that team members wouldn’t feel comfortable saying because they don’t have a bias or agenda. And, of course, they’ll typically have experience working with many different teams, so they’ll be able to spot patterns that less experienced researchers might not see.

Whether you’re working with internal experts or external coaches, the important thing is that the people on your team are engaged in the process. Making research a collaborative effort means more people in your company will learn from users, and that’s good for your product.

Learn More

For more information about Amy, check out her website, find her on Twitter, or connect with her on LinkedIn.


Whose Job is User Research? An Interview with Steve Portigal

This post appears in full on the Rosenfeld Media blog. 

Those of us who conduct user research as part of our jobs have made pretty big gains in recent years. I watched my first usability test in 1995 then spent a good portion of the 2000s trying to convince people that talking to users was an important part of designing and building great products. These days, when I talk to companies, the questions are less aboutwhy they should do user research and more about how they can do it better. Believe me, this feels like enormous progress.

Unfortunately, you still don’t see much agreement about who owns user research within companies. Whose job is it to make sure it happens? Who incorporates the findings into designs? Who makes sure that research isn’t just ignored? And what happens when you don’t have a qualified researcher available? These are tough questions, and many companies are still grappling with them.

So, I decided to talk to some people who have been dealing with these questions for a living. For this installment of the Whose Job is User Research blog series, I spoke with Steve Portigal, Principal at Portigal Consulting. He’s the author of Interviewing Users, which is a book you should read if you ever do any research on your own.

Steve has spent many years working with clients at large and small companies to conduct user research of all types. He also spends a lot of his time helping product teams get better at conducting their own research. Because he’s a consultant, he sees how a large number of companies structure their research processes, so I asked him to give me some advice.

Read the rest at Rosenfeld Media>

Whose Job is User Research? An Interview with Dorian Freeman

As part of my ongoing series about how user research is being done in organizations, I asked Dorian Freeman, the User Experience Lead at Harvard Web Publishing to answer a few questions. She shared her experiences working in UX design since the late ‘90s. See the rest of the series here

Owning Process vs. Owning Results

When I asked Dorian who on a product team should own user research, she explained that there is a difference between owning the process and owning the results. “The people who are accountable or responsible for research are the ones who oversee the researching, the synthesizing of the data, and the reporting on the findings,” she explained. “However, the data from the research is ‘owned’ really by everyone in the company. It should be accessible to everyone.”


This is an important distinction. Regardless of who is collecting the data, the output is important to the whole company  and should be accessible and used by everybody. Research, in itself, is not particularly valuable. It’s only the application of the research to product decisions that makes it valuable. Making the results of the research available to everybody means that, hopefully, more decisions will be made based on real user needs. 

External vs. Internal

A few folks in this series have talked about the benefits of having UX research done by members of the team, but Dorian called out one very important point about external researchers. “An external expert can often provide insights that are more credible to the leadership than an internal expert, which is a perception issue, but helpful in some cases.”

And she’s absolutely right. We may not always love that it’s true, but highly paid external consultants will sometimes be listened to where an employee won’t, even when they’re saying the same things.

On the other hand, for day to day research that is informing product team decisions, an in-house expert is often preferable. Dorian says, “Typically, the in-house expert researcher has more institutional knowledge which can speed up the process and provide more insight. In the ideal scenario, the product team should always have an internal expert researcher working closely with them.”

For teams that aren’t lucky enough to have an expert, Dorian recommends getting someone on the team to learn how to do it. “Understanding the people who use your product is essential,” she says. “If you’re not interviewing users, you’re not doing UX.”

Who Does What on Product Teams?

This is a post I wrote for the Rosenfeld Media blog in preparation for the PM+UX conference. Some of the research I did will also be covered in more detail in my upcoming book, Build Better Products

When we started talking about putting on the PM + UX Conference, the first thing we asked was, “What sorts of things should we talk about?” Since the folks at Rosenfeld Media are, not surprisingly, extremely user-centered, the obvious answer was, “We’re not sure. How about we do some research and find out what questions our attendees might have?” So we did.

The most interesting thing to me was that a lot of the questions people asked boiled down to “Who does what on a product team?” This was curious. I mean, we’re all working on product teams or we’ve worked on them in the past, right? Shouldn’t we know what our jobs are? Shouldn’t we know what everybody else is doing? Well, yes! We should! And yet… when I started to dig around and have conversations with people, I got very, very different answers about how things really worked.

That was odd. It turned out that, although we all have job titles like Product Manager or UX Designer, many of us have very different ideas about what it is that we’re supposed to actually do all day. Do designers talk to customers? What about PMs? Who decides what features go into a product? Who makes wireframes? Does anybody do usability testing? If not, could they please start?

Like any good team faced with more questions than they started with, we did some more research. Ok, first we had a couple of stiff drinks. Then we did some more research. I was volunteered to lead the way.

Read the rest at Rosenfeld Media>

Whose Job is User Research? An Interview with Susan Wilhite

As part of my ongoing series where I try to find out who is doing user research in organizations and who should be, I spoke with Susan Wilhite. Susan is a lead UX researcher. She was incredibly helpful in explaining how teams work best under different conditions. This is the third post in the series. 

Strategic vs Tactical

When we talk about ownership of the research function, we have to start with the type of research we’re doing and our goals for that research. “When research is mostly tactical,” Susan explains, “it should be owned by either product management or the design team, with the other being a key stakeholder.” 

Research that is intended to answer very specific, well understood questions, should be driven by people on the team who are asking those questions. For example, usability testing and other forms of tactical, evaluative research are going to be owned and driven by the people responsible for making decisions based on the results of the studies. 

Strategic research, on the other hand, like that done when a company is still developing its primary product or service or is branching into other lines of business, should be led with broad direction and budget from the VP of product or other high level stakeholder. This puts that leader in the best position to interpret UX research findings for their peers and champion those ideas into wider strategic decisions.

Most importantly though, generative and formative research is best done in-house rather than by people outside the company. “This research, unlike evaluative, has a very long shelf life. A tiny amount of information from strategic studies are communicated in a final report,” Susan explains. "Findings developed outside the company can be a lost opportunity to grow institutional knowledge within the org over time. Down the road this is important because findings from generative and formative research inform the most tactical research.” 

In other words, don’t pay vendors to acquire deep knowledge about your users unless you intend a long-term relationship those outside researchers. Understanding the product/service and users is a critical advantage, and the understanding that comes from conducting generative and formative research should be kept close to the vest.

Cross Functional Teams vs Silos

Recently, with the growth in Agile and Lean methodologies, we’ve seen a lot of companies break down functional silos in favor of cross functional teams. This can improve communication within the product team and help diminish the waste that happens when silos only communicate through deliverables. Susan points out some of advantages and disadvantages of doing away with the research team. 

“I have become a fan of the embedded research function,” Susan says. “Researchers are themselves tools, and as such are vastly more effective when given the chance to compound learnings and develop stakeholder trust in a circumscribed domain.” When a user researcher works within a product team, they become much more effective, since they’ll have a better understanding of the team’s real research needs. They can also build trust with the team, which will hopefully lead to less resistance to suggestions made by the researcher. 

On the other hand, embedded UX research has its own problems. “The hazard here is that product groups have varying budgets and sexiness – a researcher caught in a group not advancing fast from attention given by executives or the market can hobble a career.” Having a separate research team can prevent that by allowing researchers to circulate among teams and find areas of interest and groups where they work best. But still, it takes a very well managed corporate culture for a silo to work. As Susan warns about research teams in silos, “Success is uncommon.” 

Regardless of the company org chart, Susan encourages summing up and offering evolved thinking on strategic frameworks and tactical principles throughout the company. “I’d like to see twice-yearly off-sites where the org reviews what has been learned and workshops ideas from the product team at large,” she says. “Partly to remind the team of what has been learned and how we think we know it, but also to ponder aspirational research - what’s next.”

Whose Job is User Research? An Interview with Tomer Sharon

I'm interviewing researchers, designers, product managers, and other people in tech about their opinions on how user research should be done within companies. This is the second post in the series, and it appeared in full on the Rosenfeld Media blog. 

If you'd like to be featured as part of the series, contact me

As part of my ongoing series of posts where I try to get to the bottom of who owns user research, I reached out to Tomer Sharon, former Sr. User Experience Researcher for Google Search and now Head of UX at WeWork. He also wrote a book called It’s Our Research which addresses this exact topic, and his new book Validating Product Ideas is now available. He’ll be speaking at the upcoming Product Management + User Experience from Rosenfeld Media about ways teams can work together to learn more about their users.

I asked Tomer a few questions about his recent statement that UX at WeWork won’t have a research department and what suggestions he has for creating a team that conducts research well and uses it wisely.


Read the rest at Rosenfeld Media >


Whose Job is User Research? An Interview with Jeff Gothelf

I'm interviewing researchers, designers, product managers, and other people in tech about their opinions on how user research should be done within companies. This is the first post in the series, and it appeared in full on the Rosenfeld Media blog. 

If you'd like to be featured as part of the series, contact me

While doing research for the upcoming PM+UX Conference, several respondents requested guidance around how user research should managed. In fact, it was the most common write-in answer on our survey, and a question that comes up repeatedly whenever I give talks. Apparently, there seems to be very little consensus about who on a product team should own research. This makes it a lot harder to get user insights and make good product decisions.  

In a way, this is good news. Five or ten years ago, there would have been more questions like, “How do I get my boss to consider doing user research?” and “What is user research good for?” Those still come up, but far more frequently, I’m hearing things like, “How do we make sure that everybody on the team understands the research?” and “Who is in charge of making sure research happens and deciding what to do about it?” Research, these days, is assumed. It’s just not very well managed.

To answer these questions, I interviewed several very smart people who know a thing or two about research and building products. I’ll share some of their suggestions in a series of blog posts.

First, I spoke with Jeff Gothelf, the author of Lean UX (O’Reilly, 2013) and Sense and Respond (Harvard, 2016).

Read the rest at Rosenfeld Media > 

Predictive Personas

This blog post originally appeared on the Invision blog

In theory, personas should let us better understand our real users, spread that knowledge throughout the entire company, and help everybody on the team make smarter, more human-centered product decisions.

Unfortunately, personas don’t always live up to the hype. I’ve been on plenty of teams where creating personas turned into a time-consuming exercise in design theater and produced nothing but fictional stories of imaginary people based in little-to-no research.

And posters. For some reason, everybody turns their personas into posters.

Even the best personas tend to be descriptive, but not predictive. - Tweet This

We can do better. Frankly, most teams can improve their process for creating personas in a lot of ways, but there’s one problem that’s inherent in even decently researched and constructed personas: even the best personas tend to be descriptive, but not predictive.

Why use personas?

Before I jump into how to do this, I’ll explain why it’s important that personas are predictive. The goal of good, well-researched personas should be the ability to treat the constructed personas as a proxy for the user.

This doesn’t mean that we don’t talk to users, obviously. It means we take what we’ve learned from and about users and produce something that lets us constantly check our design work to make sure it matches what we’ve learned.

Hopefully, we’re all in environments where we get to conduct sufficient user research in order to make great decisions. But even great user research needs to be analyzed and interpreted in order to draw conclusions about the majority of our users.

We don’t just interview 100 people and then start designing. We take that knowledge and condense it down into a picture of our ideal customer. Sometimes we turn it into several different people with different needs if we have different groups of customers, but producing a coherent design for many different types of users requires that we consolidate people into groups that reflect who they are and how they use our product.

Designers and researchers are great at this. They can convincingly draw a portrait of “the people who use our product,” or, in the case of new products, “the people who will use our product.” They draw a picture of a “mom in her early 30s who has 2 kids and a golden retriever and went to Santa Clara University and holds a part-time job.”

And they believe that this accurately describes their user because when they reach out to their users, they find that she often matches that sort of description.

But the question they should be asking themselves isn’t, “If I interviewed a user, would this describe her?” The question should be, “If I found a person like this, would she become a user?”

What is a predictive persona?

A predictive persona is a tool that allows you to validate whether you can accurately identify somebody who will become a customer, which is an incredibly useful thing to be able to do when you’re looking for new users or designing for current ones.

If you can create a predictive persona, it means you truly know not just what your users are like, but the exact factors that make it likely that a person will become and remain a happy customer.

Let’s look at our “mom in her early 30s who has 2 kids and a golden retriever and went to Santa Clara University and holds a part-time job.” This very clearly describes a person. You can picture this person. In fact, it’s so specific, you could almost certainly go out right now and find her.

In fact, you could probably find 10 of her.

So do it.

Based entirely on the persona your team created, go out and recruit 10 research participants who match. Most personas include, in addition to basic demographic information, some behavioral information or a description of the needs and goals of the user. Make sure those match, too.

If you think you care about what kind of car she drives or whether she only buys organic produce, control for those factors.

Whatever the profile, recruit 10 people who match it.

Remember, if you’re completely incapable of recruiting those 10 people, you’ll have a hard time finding thousands or even millions of them to be your actual users. Your persona should reflect people you can find in the wild, since you’ll need to do that in order to acquire them as users of your product. If they’re impossible to find for research, either that person doesn’t exist or they exist but you’re not the right person to try to build something for them.

Let’s say you do find them, though. The next step is to try to sell them your product. You don’t ask them if they’d use your product, since most of the time people will just smile and say yes in order to make you happy. You actually try to sell it to them—see if they’ll give you their credit card number or sign a letter of intent or start the procurement process right then and there.

Can’t recruit 10 research participants? You’ll have a hard time finding millions of users. - Tweet This

If your product is free, have them sign up for it and then monitor their account over the next few weeks to see if they continue to use the product. Do whatever you can to turn them into a customer.

If your persona really reflects the needs and goals that cause a person to want to use your product, you should be able to get your research subjects to sign up for and use your products. They should be thrilled to have found you.

I know this sounds incredibly hard, but it’s also important. If you have the perfect candidate for your product and you can’t sell something to her in person, how will you ever do it when you’re not there to give her the pitch? If hearing about all the benefits of the product from somebody who knows exactly how great it is doesn’t convince her, why do you think that a landing page or app download page or Facebook ad will?

Of course, the chances are that you don’t have the perfect candidate for your product. You have a description of some people who currently use your product, or, even worse, a description of a completely imaginary person who you think should want to use your product.

Until you can identify the specific things that make a person want to be a customer, you don’t have an accurate predictive persona. And that means your product and design decisions will be based on a lie.

That’s the beauty of personas. They allow you to answer questions like, “Would our ideal customer want this feature?” or “Is that going to solve a problem for the main persona?” If you’re basing the answers on factors that don’t really matter, your product won’t get better for real users.

Accurate predictive personas identify the things that make people want to be customers. - Tweet This

As a side note, this also works beautifully with current users and new features. Contact 10 current users and try to sell them a proposed upgrade. Show them a prototype of the upgrade and ask them to pre-order it for a small discount.

Again, you want the majority of them to take you up on the offer or you want to understand which ones do and which ones don’t, because they probably should be represented by different personas.

What to do when you’re wrong

So what do you do when you find out that none of the people you recruited want your product?

You iterate on your persona or your product. Because you’re either wrong about what makes a person use your product, or you’re wrong about what your potential users will buy. You have to change one or the other, and you have to keep doing it until you can conclusively prove that your persona isn’t just descriptive of your users, but also predictive of the type of person who will become a user.

Let me give you another example. Let’s say you decide your persona is just “moms.” And believe me, this isn’t far off from the level of some of the personas I’ve seen. So, you go out and you just recruit moms. That’s the only thing you can use.

You might get a new mom, a grandma, a mom from China, an adoptive mom, a mother of 20, a full-time working mom, and a stay-at-home mom. Additionally, all of those moms would have all sorts of other aspects that would probably affect whether they might use your product.

Is it very expensive? You may want to target more affluent moms. Is it only in English? You probably only want English speakers for now. Does it help with scheduling multiple children? You probably want moms with multiple children. And so on.

All of these factors will affect whether the “mom” will become a user. So even if every single one of your current users is a mom, they probably have several other, more important, characteristics in common.

Your job is to identify the ones that really matter so that you can say conclusively who your ideal customer really is. The best way to do that is to be able to predict ahead of time whether somebody is going to be a user.

Try predictive personas. You’ll find them difficult, frustrating, time-consuming, and possibly the best tool you can use for finding out if you really do understand exactly who your user is and why on earth she’s using your product.

For more information about ways to improve personas, listen to the podcast What is Wrong with Personas.

Three Reasons Your Visitors Don't Convert

I wrote a post about Conversion for Startup Grind. 

Let me tell you the story of far too many startups. A few people have a brilliant idea. They go off and spend six months to a year building it. Then they launch it into the world and wait for the users and money to come pouring in.

When that fails to happen roughly 100% of the time, they break down and start spending on PR. Maybe they get a mention on Techcrunch. They get featured in a few blogs. The traffic starts trickling in. The problem now, is that while they’ve got some visitors, none of those visitors are sticking around or turning into customers. Nobody is converting.
What Is Conversion?

The first problem with conversion is that the term is a little bit vague. Theoretically, it means turning a visitor into a customer. E-commerce companies use it to mean when somebody buys something. Growth Hackers use it to mean getting an email address on a landing page. Mobile developers can use it to mean getting somebody to download an app or create an account.
All of these definitions have a couple of things in common:

  • They all represent an exchange of value of some sort.

  • They’re all much harder to do than you’d think.

Read the entire post at Startup Grind! >


What You Don't Know About Growth

You shouldn’t have to be a growth hacker to care about growing your product’s user base. Understanding growth is important for Product Managers, UX Designers, and Entrepreneurs, too.

If you read about growth hacking (and I’ll admit that I do this obsessively), you’ll come across a couple of points that seem like they contradict one another:

  • There are hundreds of tricks and hacks to improve reach and growth for your product.
  • An incredibly important part of growth is building a great product that solves a serious problem for someone.

These are both true statements.

It is far, far easier to achieve sustainable, long term growth for a great product that solves problems for people than for a gimmicky product that doesn’t really work. However, even the best products can fail if you don’t pay attention to growth and use some smart tactics to get it in front of the right people. History is littered with “better” products that lost to “worse” ones.

“It’s easier to grow a great product.” — Tweet This

So, how do we combine these things and build great products that grow? The key is to pay attention to growth strategy and tactics as we build, rather than wait until we’ve launched and then spin up the marketing and PR machine or try to hire a growth hacker.

I’ve spent the last several months collecting advice from real growth experts in order to put together the top strategies and tactics that Product Managers, Entrepreneurs, and UX Designers should know about building high growth products, and I’ve put all this information into a class that I’ll be teaching on July 21st.

You should take this class if you’d like to learn more about:

  • Identifying your Ideal Customer for product/market fit
  • Acquiring the right customers from the right places
  • Measuring the customer lifecycle funnel and improving your customer’s journey through your product
  • Helping your customer get successful sooner
  • Finding the right engine of growth for your product (tip: viral sharing is not for everybody!)

This is an online, hands-on workshop. That means that you can tune in from your desk, but you’ll be expected to do some work on your own product to follow along.

If you want to learn what growth, product, and UX experts like Sean Ellis, Lincoln Murphy, Nichole Elizabeth DeMere, Dan Martell, Christina Wodtke, and Amy Jo Kim have to say about building a product that acquires, converts, and retains people quickly, you should take this class.

Sign Up Now!

Intent to Solve

I wrote an article about finding out whether prospective customers will buy your product over at Boxes and Arrows. You should read it!

"When we’re building products for people, designers often do something called “needs finding” which translates roughly into “looking for problems in users’ lives that we can solve.” But there’s a problem with this. It’s a widely held belief that, if a company can find a problem that is bad enough, people will buy a product that solves it.

That’s often true. But sometimes it isn’t. And when it isn’t true, that’s when really well designed, well intentioned products can fail to find a market."


7 User Research Myths and Mistakes

I wrote a post over at O'Reilly's Radar blog about a few of the myths and mistakes surrounding quantitative and qualitative research.

I can’t tell you how often I hear things from engineers like, “Oh, we don’t have to do user testing. We’ve got metrics.” Of course, you can almost forgive them when the designers are busy saying things like, “Why would we A/B test this new design? We know it’s better!”

In the debate over whether to use qualitative or quantitative research methods, there is plenty of wrong to go around. So, let’s look at some of the myths surrounding qualitative and quantitative research, and the most common mistakes people make when trying to use them.

Read More at O'Reilly >

Or sign up for the Webcast on March 11th, 2015 to learn about combining qualitative and quantitative research more effectively.