Thursday, November 20, 2014

Your Guide to the Complete Lean Startup Conference Program

Guest post by Lisa Regan, writer for The Lean Startup Conference
Eleven months in the making, the full schedule for The Lean Startup Conference is at last complete, and we can’t wait to show you around! OK, sure, we’re still nailing down a couple more speakers and sessions, which we’ll announce as we finalize them. But other than that, it’s all there. Talk descriptions, speakers, workshops, evening events, Ignite, Office Hours…but we’re getting a little ahead of ourselves. Let’s slow down and go over just what we have and for whom.

We took the feedback we gathered in previous years to expand on and improve the program. We’ve got more in-depth how-to talks than ever and even better opportunities for you to meet other relevant attendees. That means there’s never been a better year to attend than this one. For first-time attendees, this conference offers a complete introduction to Lean Startup. Returning participants will find new speakers, fresh ideas, more options to meet other entrepreneurs, and special sessions for advanced practitioners.

Here’s an overview of it all, and of course, you can find more detail on our site. (If you need additional ammo to convince your boss, we’ve written up detailed benefits for employees of established organizations.)
-- The Conference Core: Two Days and Three Nights of Intense Education and Connection --
We don’t fix what’s already awesome. So as per usual, we kick off the main conference on December 9 with Ignite--a high-energy, entertaining series of lightning talks.

On December 10 and 11, the two main conference days are packed with mainstage talks to inspire and breakout sessions to teach you the how-to of implementing Lean Startup methods. At your request, we’ve brought in speakers from all kinds of organizations--including young companies, Fortune 500s, mission-driven orgs, and government, and they create websites, apps, games, hardware, consumer goods, social services, media products and more. We’ve tagged the talks by topic, so you can zero in on what interests you most.

If you’ve scanned the list of speakers before, take a second look. We’ve recently added talks from: Former US CTO and current tech advisor to the White House, Todd Park; former Facebook engineering director Joceyln Goldfein; Dropbox engineering VP Aditya Agarwal; and KISSMetrics founder Hiten Shah.
Take a third look, too, because there are a lot of people there you haven’t heard of but who have in-the-trenches information to share. That’s no accident. We actively sought out great stories, not just big names, and we found people who had compelling experiences to present. These are people you won’t hear at any other conference. It’s what keeps the Lean Startup Conference on point: No stale talks.

We’re also going beyond traditional sessions. To help experienced Lean Startup practitioners share knowledge with each other, we’re dedicating several breakout sessions each day for advanced attendees to hold focused conversations with each other. And after dinner on December 10 and 11, we’ve added hands-on sessions for you to learn video-editing techniques from one of our favorite speakers last year or to catch a jazz set with a discussion of improv as an analog for business collaboration.

We know that meeting other people at conferences can be rewarding--but surprisingly hard to pull off. So On December 10 and 11, we’ve booked tables for Lean Startup group dinners at popular San Francisco restaurants. These were such a hit last year that we’ve expanded on them, and we’ll designate groups for each venue--startup founders and early employees, entrepreneurs within the enterprise, or mission-driven and non-profit innovators--so that you can connect with the attendees most relevant to you.

You probably don’t come to this conference for the food--but that wouldn’t be a crazy idea. For lunches, we’ve contracted with local food trucks to park outside the conference and offer a taste of San Francisco entrepreneurship (literally) just for conference participants.
-- Go Deeper: Up to Five Days of Incredible Events --
We designed our Platinum and Gold Passes specifically for people looking to do a deep dive into Lean Startup. They include training and are an amazing deal; they also offer exclusive networking opportunities. You can buy these passes now or upgrade an existing Silver Pass. Platinum Passes include everything above, plus:

  • Startup site visits. Who doesn’t love a field trip? Platinum Passholders will spend December 8 visiting four successful San Francisco startups. See for yourself what innovation environments look like and connect with the people making them work.

  • Workshops. December 9 is devoted to full-day, hands-on sessions led by our community’s most accomplished Lean Startup trainers. This year’s workshops cover Lean Startup 101; Introducing Lean Startup in Your Corporation; Lean Impact; Innovation Accounting; and Metrics: The Data That Will Make or Break Your Business.
  • Office Hours. On the evenings of December 10 and 11, you can sign up for 15-minute, one-on-one conversations with select conference presenters and expert mentors. This was an experiment we tried last year, and we were frankly overwhelmed by the positive response. So this year we’re expanding Office Hours not only with more speakers, but also with more mentors from a range of fields--giving you an unusual chance to talk with people like O’Reilly Media CEO Tim O’Reilly, Reverb Technologies founder Erin McKean, and entrepreneurship expert Nathalie Molina NiƱo.

  • Live Q&A with Eric Ries. On December 12, Eric will answer attendees’ questions live. He’s going to take all kinds of startup questions--on designing experiments, understanding metrics, deciding when to pivot--whatever comes. You not only get to ask, but you also get to hear details of the challenges other entrepreneurs are facing.
  • Perks include:
    • Reserved front-row seating in every conference room
    • Platinum line at Registration to save you time
    • Platinum line for our food trucks on Tuesday and Friday
    • First dibs to sign-up for our Office Hours
    • First dibs to sign-up for our group dinners

Our Gold Pass covers three days--including December 10 and 11, plus your choice of Workshop on December 9 or Live Q&A with Eric Ries on December 12. Gold Passholders also get access to Ignite, Office Hours, and designated ballroom seating for December 10 and 11 mainstage talks.

-- A Pass for Every Income --
We’ve talked a lot here about the Gold and Platinum Passes, because they offer incredible value. But we also want The Lean Startup Conference to be accessible to everyone. So we’re pleased to offer passes at a complete range of levels:
  • Our Silver Passes are a great deal: Two full days of the conference, a seat at Ignite, sign-ups for dinners, food truck tickets for purchase.
  • Our Scholarship Pass offers the same benefits as the Silver Pass, but brings the cost of the conference down to $200 for people who otherwise wouldn’t be able to attend (think: fledgling solopreneurs, employees at very young startups and small non-profits). Apply for a Scholarship Pass here.

  • Livestream the conference. For the first time, we’re making the conference available via livestream to individuals. You get all the mainstage talks and the most popular breakouts, along with access to live Q&A, moderated chat, and a conference social network. You pay per screen, so sit down with a couple of friends and split the cost.

  • If you’re a student, you can apply to volunteer. Pitch in for a shift, and we’ll give you a Silver Pass. Apply to volunteer here.
All passes are on sale now, and you can compare them here. And, again, you can now see the whole program on our site. Register today to join us for our best Lean Startup Conference yet!

PS. While you wait for December, check out our webcast on November 25 with Brant Cooper--one of our most popular workshop leaders--and Coca Cola’s Carie Davis. It explores a topic we haven’t seen discussed elsewhere yet.

PPS. When you register for the conference, you can also choose to add on-site childcare options. Here’s the deal.

Friday, November 7, 2014

How to Get Your Coworkers to Care About User Research

Guest post by Lisa Regan, writer for The Lean Startup Conference.

If you build products or services, then having empathy for your users is part of your job. Good news: If you build products or services, then we have empathy for you. We talked with Laura Klein, a preeminent expert on user experience, about the questions she gets asked most often by other product pros. Laura is not only the author of UX for Lean Startup and the creator of the design blog Users Know, she’s also Head of Product at Hint Health, a software company working on healthcare affordability, and one of our most popular speakers. At this year’s Lean Startup Conference, she’s running a hands-on session teaching you how to validate your assumptions, explained below (the conference runs December 8 - 12 in San Francisco, and you can register here to attend in person or via livestream).

Lisa Regan: So what are some of the questions people most often ask you, and what advice do you give?

Laura Klein: Here’s one question that I’m going to share with you not because it's the most important one, but because it is the one that I get asked, I think, in every single talk I ever give that has anything to do with research. The question is, "How do I get people at my company to understand that what I do is important? How do I get them to see the value of User Experience research or design?"

The answer that I used to give, which I think was not very helpful but was how I felt, was, "Quit and join someplace that actually understands what you do, because they're going to win in the end anyway.” But I think the right answer--assuming that first answer is not an option or that you just enjoy tilting at windmills--is to find a way to treat the other people at your company as themselves being users of your research. Just as you would with a customer, you need to understand their needs better.

First, you need to find a way to have them experience what their customers are actually going through. Often, a good way to do this is with video. So you would just go ahead and do that user research yourself, figuring out a fast way that you, on your own, can capture that information and then share those little snippets with the people that you need to convince. Nothing is more impactful than actually seeing what you are putting your customers through. Because it's very easy to ignore that or not fully accept that there are problems with your product, but seeing person after person after person struggle with the same thing is incredibly impactful. So that’s an excellent way of doing it.

But I think that another thing to do is to understand why they don't care about this. Is it because they don't understand the value of it? In which case something like showing a video of people struggling with the product, and then showing video of people not struggling with it after it's been fixed, can be incredibly helpful. Is it because they've had a bad experience in the past with research? I think then the answer is to help them understand ways to do research or design that aren't what they've experienced in the past. Maybe they worked with a really big agency that charged them a huge amount of money and gave them really crappy results. I've run into this. Maybe they're just like, "We don't have time for this." I hear this all the time, "We don't have time for research." At that point, you really have to explain to them that they don't have time to not do research--because it takes a lot longer to fix it later than it does to fix it before it's built.

LR: Do you think people just don't want to hear what they already know to be true?

LK: There's also that, and I think this happens a lot, honestly. This happens whenever people are rushing to get new features out, and they're ignoring the old product. There's, "We already know about the product problem. We already know about that. We've heard about that." At that point, you really actually need to show them the impact that the bug is having on their bottom line. In that case, metrics and analytics are really important. "Hey, look, look at the funnel. You're spending all this money to get people into the product, and they're all dropping out here, and we've identified why they're all dropping out here. This problem that you've been ignoring for a year, that I know you are totally used to, is costing you X amount of money or X number of users. This is a quantifiable problem.” If they're real numbers-driven people, then that's a good way of getting to them.

But again, I think the way to figure out how to change people's minds within your organization is to understand them better. User experience people, we are trained to have empathy, or at least try to fake it, but we can understand. That is always our goal. We need to understand our users, and we need to understand our own problems. Apply that within your company, apply that to your engineers. I'm a big advocate for having empathy for your engineers. Understand what their needs are in terms of what you're delivering to them, and they will be much better about implementing the things that you're asking for. Understand and have empathy for your managers. Understand what they're getting judged on and what their role in the organization is, and understand how to make them better at their jobs, and they will be much better about helping you do what you need to do.

This seems a little bit off the topic, but it's around this concept of, how do I convince people that what I'm doing is important? I think the answer is that you give them not more deliverables or not more exact deliverables, but you understand what they need to see from you, and you deliver that. That's a very user experience way of looking at things.

LR: What's something that the product team would need to see? What's an example of what that would look like?

LK: I just joined the team I’m working with as Head of Product a couple of months ago, and I've been working very closely with the engineering team. In fact, I have to tell them what to build, because part of the Head of Product's job is to be sure that they're building the right things. So the first thing that I did when I came in and sat down with them was I looked at how they're currently working and I basically asked them, "What do you need from me to be successful?"

To get an answer to that, I would show them different levels of deliverables. For example, I would show them various works in progress. The last thing that I'm ever going to deliver to an engineering department is a pixel-perfect set of Photoshop mock-ups and just be like, "Here, implement this exactly." That's pretty much never the right thing. So I was like, "What level do you guys want to work at?" I would show them, "Here's a task flow of when something happens. Then here's some human-readable user stories that document everything that could possibly happen in this situation, and here's a sketch with some notes on the side. Which of these--or is it some combination of these--will help you when you're sitting down and writing the code? Also, by the way, I'm standing right here. I'm not away at a desk. I'm right here, a foot away. Literally turn around, tap me on the shoulder, and ask me a question.”

What we ended up with is that we use some combination of all of these kinds of things, including interactive prototypes sometimes, sometimes sketches with annotations, and sometimes test flows, and sometimes user stories, and sometimes sitting down and working through an error case together. We use a combination of all of these things to produce the different features. Depending on the feature, they get something different. Because it depends on if it's a little thing, or a big thing, or a very complicated human interaction. They don’t just get the deliverable that I want to give them. It's never that. They get the thing that they need in order to move forward and be successful on the first try.

The funny thing is that, with my team, I haven't had you resort to showing them videos of the users. I probably won't have to do that, because they are incredibly empathetic, and they see all the customer service emails that come in. They care deeply about the users already. So, I don't have to convince them that users are important. But I think in a lot of engineering teams--not mine luckily--but in a lot of engineering teams, especially at big companies, they can feel very removed from what the customer actually wants. So the design deliverables that you give them have to be quite explicit, because they are not necessarily going to have the framework for making good decisions about the user on their own. The right approach to that is to help them get closer to the user, because if they understand the user's needs they will make better decisions on their own, because they will make them by thinking about the user. So I figure out what deliverables I can give them that will be the most useful will help them to make the right decisions.

LR: So that was one question that actually breaks out into two approaches. What else do people ask you?

LK: I get asked the difference between UX and UI a lot, and I see a lot of explanations of this online. Again, UI--user interface--is a subset of user experience design. I really like to think of UX as the umbrella for all of this stuff. But the UI is very much more about the layout and the heuristics and the visual design. It's about the flow. Are you going to give people one big screen, or are you going to give them three screens where they do something different on each one, or are you going to give them a walkthrough, or are you going to point out important things, or are you going to hide things from them until they become more involved?

If you're a Twitter user, is your first experience with Twitter just seeing a random list of tweets, or is it picking from a bunch of different topics that you're interested in, or is it finding your friends? What is Twitter about in that onboarding experience? How does that work? That's a crossover of UX and UI, and they definitely impact one another. I think that too many people focus too much on the UI part. They focus too much on the visual and the pretty, and just the layout of the screen, and they don't focus enough on what's the context in which the user is using this product? What's the flow? Where did the users come from? Who are these people? What are their needs? What is the reason that they are using your product, and what is the fastest way that you can fulfill that need for them?

Nobody ever says, "I want to use this product." Nobody's ever like, "I want to use a power drill," unless they just bought a power drill, and they might be like, "Let's see what I could use a drill for." But in general an owner of a power drill very rarely goes, "What can I drill a hole in today?" They have to put up a bookshelf, or put together a piece of IKEA furniture. They think, "You know what, I should totally get my power drill, because that's going to help me put together this furniture." So, what's the fastest way that you can get that bookshelf built? What's the fastest way that you could fill the need that prompted someone to use your product?

That's the context of the user, and that is very much about the user experience. Yeah, having a bad UI on a power drill is really dangerous, and it can totally prevent the user from fulfilling their need. But you can have a great UI that actually has a bad user experience. Because it can be a beautiful, really well laid-out, really nice-looking page that just doesn't fulfill a need for anybody or that dead-ends people. Or, where people are like, "This is beautiful. I don't know what to do." It's not that one is more important than the other; it's that one actually is just a part of the other. The UI is part of the general UX, and so I'm just getting very tired of people coming and saying, "We need a user experience designer, because our pages aren't pretty enough" or, "because things are laid very badly" or whatever. It's like, "That's a small portion of your problem."

I might look at something and go, "It's not the problem that your product page is laid out wrong; it's that when somebody puts something in their cart, they actually can't make it through to checkout because the checkout flow is really confusing, and it has all of these dead ends," or, "because if you go through the checkout flow, and then you jump out to get a new product, something bad happens." There's what I always call the "happy day flow" or the "sunny day flow." A sunny day flow is: I come to the product, I find something I love. I put it into my cart, I go through the checkout process, I put in my credit card number, and I buy it.

In the real-life flow for a lot of people, it's more like: I put something into the cart, I realize, "No I'd actually don't need that; I need something else." So I go back and get something and try to take the other thing out of my cart. I try to get two of this new thing. Then I go through, and I realize I don't have my credit card, I want to pay with Paypal, but then I realize it's a gift. Then I go back and I try to change the gift options and ship it to someplace else and suddenly, I'm lost. That's not just the user interface, that’s the user experience.

LR: Is the problem that the people designing the flow don't know that's how people behave? Or is the problem that they find it technically difficult to find solutions to all of these contingencies?

LK: Certainly it is much harder to design for the second thing. But realistically, I think one of the reasons that this happens is because lot of designers think from the screen. "Does this screen allow people to put their credit card information in?" "Yes." "Great, it's done." But they're not thinking about the actual user experience; they're not thinking through the whole list of human stories that could happen. They're not actually being user-centered. They're thinking, "What can I allow my user to do?" Don't allow your user to do anything. Show them what they're supposed to do. Help them do the thing that they want to do and that you want them to do. Understand that there will be problems as they do it, and that your design has to comfortably accommodate all of those edge cases to a certain extent.

LR: Talk about the relationship between edge cases and MVPs.

LK: A lot of times people ask me about MVP: “How do I know if my MVP is big enough?” The answer to that is, "Can you learn something from it?" Not just anything--we can all learn something from everything. But, can you learn the thing that you wanted to learn from it, specifically? The truth is that MVPs should solve very hard problems, but they should really only solve one problem. Like if you are a startup and you've got your first product, it should solve a serious problem. But it should solve one serious problem for one specific person.

If you're trying to solve a bunch of problems for a bunch of different people, you have increased the complexity of your product to the extent that you're going to run into that thing that I talked about before. You're going to run into all these edge cases and corner cases and, "What if they do this? What if they do that?" The more contained the problem that you're solving, the easier it is to account for all of those cases. So that you don’t get somebody who comes in with the right problem and they want to use your solution, but they have a really shitty experience doing it.

If you're building a product that allows people to buy something, maybe the first iteration of that, so that you can avoid all of that cart stuff, maybe the first iteration of that is that they come in, and they click a button, and they can buy one of those things. What you're trying to learn from that is: Are people interested in buying this particular thing? That's what you're trying to learn. They can come in and they can buy that thing, and maybe you store their payment information, so if they want to buy another one they can click the buy button again, and it will just buy it for them.

Maybe you avoid all of that business of put it in your cart, take it out of your cart, put it on your wishlist, buy something on your wishlist. Avoid that for now. You don't have to do that first. If what you are trying to learn is, do people want to buy this thing that I am selling, then make it as easy as possible for them to come in and buy that thing that you are selling. Don't necessarily make it possible for them to come in and do all of this other things with it. When Amazon started out, you could go in and you could buy a book. I shopped on the original Amazon. You could search for a book, you could pick a book and you could buy a book. That was it. It's gotten a little bigger since then.

Just because I'm talking about building a very small thing that only does one thing, it does not mean you're going to launch that to the entire world. The entire world is not going to look at it and go, "It only does one thing; I’m not interested." You're going to show it to a small number of people. You're going to get feedback. You're going to iterate. You're probably going to hear the same thing, "Why doesn't it have a wishlist?” That’s fine. You're not worried about that yet. You're worried about getting the interaction of this one thing correct. Then you could add in the other things. Adding in the other things later really helps you to manage the complexity of the design.

LR: It sounds simple, but let's say you're not doing a shopping cart-driven business. How do you know which complexities of your model you can just set aside for now?
LK: At that point, it's all about early user research and customer development. You have to know really, really clearly what problem you're solving, and for whom you are solving it. The kinds of problems that you are looking to solve in an early early, early product are not things like, "I would like to reduce energy usage among US households." Too big. "I would like to save time for moms." Too big. That is not a specific, addressable problem for an individual human being that you can identify. Moms are not an early adopter group. Some moms are, but there are too many of them. Mine is not like yours. That's not a persona; that's not a group I can define for. They have too many very different types of problems, depending on who they are, where they are, and what they like, dislike, and what technology they're using, what their jobs are.

By narrowing it down to a very specific small user group with a very specific problem, you will be able to narrow down that initial product or that MVP to something very specific. Facebook always is the good example of this. It started for Harvard students to look at pictures of other students. That's what it did; that was the whole thing. They didn't start out being whatever the hell they are now--an advertising platform and a gaming platform and a way to keep in touch with everybody you've ever met and a way to follow celebrities. No. None of that. Harvard students looking at pictures of other Harvard students. You don't have to start big to get big.

LR: So interestingly, the best thing to do for improving your user interface is to strip a bunch of stuff off your website?

LK: I honestly think that's why the whole mobile-first thing is so popular, because all mobile-first really means, if you really look at the design ethos behind mobile-first, the reason people go mobile-first is because mobile forces you to make every screen about something very specific. You can't add shit into a mobile interface. You have five inches; make the most of it. That means every single interface, every single thing is about one cold action. It's about one message, at least the successful ones. You could take a picture and you could post a picture, and it's got to go in that order. Those are the successful ones-–that every single screen is about solving a very specific problem within the user experience. It's not about allowing people to do whatever they want; it's about showing people what to do to be successful.

I think there's a really nice method for doing this, which is imagine your successful customer. Don't just imagine them, use metrics to figure out who they are. What have you helped them become? If you're doing tax preparation software, your successful user has successfully filed their taxes without tearing their hair out. Maybe you've been able to show them that they've saved a certain amount of money by doing it. How do you get them from the person who thinks, "Shit, I need to file my taxes," to the person who has filed their taxes? You have to start from imagining who your successful, happy user is. Then you can tell them how to get there. You don't let them get there; you help them get there. You show them the path.

You start even before you have a product. You talk to the people who had the problem that you think you're solving. You understand what they've tried to do to solve it in the past. This is actually a question that I get a lot, which is, "How do you figure out what the user’s needs actually are?" You reach out to people who you think will have this problem, and you have conversations with them. You don't pitch them your solution; you just have conversations with them about their problem. You see what other things they have tried, because here's the thing. If they've got a problem and they have tried in the past to solve it and they have failed, they are a great market. Much easier to sell into that market, where people already know that they want your product.

Then you go back to them afterwards and you see how they're doing with your stuff. You also go back to the people who have tried your stuff and given it up to understand what promise you didn't fulfill to them. "Why did you try this product? What were you hoping to get? What did it did not do for you? Why did you stop using it?"

If you talk to five people who are really similar to one another, you should start to see patterns. If you do not start to see patterns, then you may need to narrow down the type of people you're talking to. There is another question I hear a lot, "How many people do I need to talk to learn something?" Well, you need to talk to enough people to where you're seeing patterns. If you are not seeing patterns within about five people, you are talking to too broad a group. Again, you may be going out talking to moms. Don't talk to moms.

One way to narrow the people you’re talking to is to use screeners. These are surveys that actually help you recruit for user research people that you think would like your product. You can write your own screener, or you can hire a recruiting agency that will go out and find people in very specific groups. But you're trying to identify the people that you think are going to use your product. You write the screeners in such a way that you're asking about behavioral things. You're not asking them necessarily about things that are directly related to product design. And you're not looking for just like 35- to 45-year-old men who smoke and read GQ.

Again, if you're making tax preparation software for accountants you might ask what their job was. You're only going to pick the ones who are accountants. But it may be that you think that your market is accountants who do taxes for a lot of small businesses, maybe even in a particular industry. That might be accountants who handle the taxes for restaurants. That's a market that you can imagine. You would go out and write a screener that would help you recruit people like that. You would try to weed out all the people who didn't do taxes for restaurants or who only did taxes for big companies or who worked in-house at big companies or whatever.

So then you get five of those people, and you do interviews with them about their needs, their problems, or maybe you show them your product and you see if it solves a problem for them. If you can record ten of those talks and do the same interview with them and hear the same significant problem from nine of them and it's a problem you could solve, that's excellent confirmation that you're onto something. That's a pattern. Like, if they all have a problem with getting the restaurants to file quarterlies on time or whatever. If you start to see that pattern, that is a problem that is worth solving. Especially if it is a pattern where they are like, "Urgh, I have this terrible problem. I've tried to solve in at least three ways, I've paid for solutions, they never worked. I'm just doing it all on Excel, because it's super hard. It's really manual." That is worth solving.

LR: Is there something nobody ever asks you, that you think, "People ought to ask me this," or, "People should want to know this, and yet they don’t ask”?
LK: People often ask UX questions in the wrong way. In general, the questions that people ask about UX are too broad. They're like, "How do I user research?" Not, "How do I learn this specific thing about this particular user?" If you asked me how to do user research, I would launch into, as you saw, a lot of talk about needing to figure out who your user is and what you’re going to learn, and so on. But once you've gotten there, if can come to me with, "I have this particular question that I want to learn about this person, and it's very specific. How do I do that?" that’s framing things in a much more specific way. And that’s also telling you that, if can frame things in a more specific way, you've arrived somewhere more detailed.

LR: One last question: What are you going to speak on at this year’s Lean Startup Conference?
LK: I'm doing my talk on validating assumptions in order to build better products. This idea is really core to Lean Startup. My approach is very hands-on, teaching people a particular skill and a method for figuring out what assumptions they are making when they are deciding to build a product.

What I’ve found is that if you make the wrong assumption too early, you then build a lot of things on that assumption, and it's like building your house on quicksand. I see an awful lot that people go into building a product and they specifically make assumptions like, "Well, I just assume that people have this problem that I'm solving." It turns out that if they don't, or not enough people have it, or if it's the wrong people who have it and it's not the people that you're going after, then this thing that might have been really easy to correct before you build a product becomes really hard to fix. So, that's what I'm talking about: how to identify those things and how to think about them, and I actually have a test people can take.

LR: I love a test! Ok, so you’re going to be speaking on validating assumptions, but much of your work is in UX. It sounds like your talk is going to be more broadly Lean Startup?

LK: So, here’s how I think about it. I've done a lot of dance in my life, and I know a whole bunch of different types of dance. I was talking to a dance teacher about different styles, and she was like, "At some point, after you know a bunch of different styles and you're just used to it, it's all just dancing.” There is no Lindy, or salsa, or even ballet. It's all just dancing.

This is how I'm starting to think about product: it's all just product. To me, it's all just the user experience, because the user experience to me covers literally everything. The user experience is the user's entire interaction with your product and company. If you think about something like Uber--however you feel about Uber--the experience of being in an Uber is not just the Uber app, and it's not just the rider. It's also the driver, and it's also the service of the cab company you’re not using. There's a whole experience with the company. There's the time in the car. There's the time waiting for their car. There's the time when you get the email afterwards telling you how much the car cost. There's figuring out who's paying for it. Really, there's this entire experience that exists around what a lot of people consider to be the product. But, what's the product there? I stopped thinking about it as, "There's product and there's user experience and there is customer experience.” It's all just user experience.


Laura has a very useful PDF available for $10, "How To Recruit Participants For User Research/UX Tests." To learn from Laura and many other great speakers at The Lean Startup Conference, register today to attend in person or via livestream.