text:
Author Archives: Lean Startup Co.
End the Year with Our Favorite Talks of 2015
We love hearing about all the different ways that people are internalizing Lean Startup principles. Eric Ries' scientific approach continues to embolden a global community of thought leaders, many of whom we heard from at this year's Lean Startup Conference.
Before we give 2015 a rest, we're looking back at the powerful talks that our conference attendees told us they loved most. So regardless of whether you were able to make our big event, we have eight important and entertaining bits of workplace wisdom to share.
1. The Modest Experiments That Became Huge Companies
Know this: Successful companies start by focusing on small target communities and growing their MVP from there.
Laura Klein's (Users Know) lightning tips talk spotlights the small-scale experiments that today's big tech darlings crafted on their way to global domination. Examples include focusing on problems affecting a core group of users (Facebook), building an internal tool whose effectiveness could be calibrated in real time (Slack), testing assumptions locally before scaling those ideas globally (Airbnb), and creating a product manually before getting into automation (Product Hunt).
2. The 10 Keys to Building a Strong Community
Know this: Sending your users personal emails, memorable swag, and other messages that they're important keeps them involved with your brand.
Speaking of Product Hunt, founder Ryan Hoover knows how to stoke and support a rabid fanbase, and he has great advice for growing a community of your own. Highlights include seeding that initial base and personally welcoming new users, recognizing both good behaviors and the bad actors, and sharing mockups of redesign concepts with your users. "You're changing their home," he says of the importance of design transparency, "so you want to make them feel like they're part of the design process."
3. How to Intentionally Design a Lean Startup Culture
Know this: Map out the right kind of culture for your business with this cool new tool.
Strategyzer's Alexander Osterwalder understands that the belief systems, attitudes, and values held by employees directly affect the products a company creates. He's part of the team behind The Culture Map, which helps organizations intentionally shape the purveying ethos in an office. He shows us how to use this tool to design a Lean Startup culture.
4. Testing the Riskiest Assumptions First
Know this: Build stronger startups by testing the assumptions that could topple your business before you tackle the easy stuff.
Gagan Biyani has been involved with renowned startups Udemy, Lyft, and Sprig, companies that maintain their singular missions while changing what they've created over time. He shares the specific Lean Startup practices that've made these organizations so successful, including strategizing creative ways to solve customer problems and untethering your ego from the products your company creates.
5. Applying Lean Startup to Storytelling
Know this: Savvy movie producers and fiction publishers alike are crafting tighter audience feedback loops that allow them to edit their way to big hits.
There's nothing Lean Startup about the typical Hollywood blockbuster. As Telepathic's Prerna Gupta explains, studios generally sink hundreds of millions of dollars into a production and hope they have a hit on their hands. But there are ways to use data and audience feedback to create more compelling movies — and books — while keeping the artistic process intact. Gupta explains how to fine-tune both our storytelling methods and the business models supporting them, through examples ranging from The Martian to her company's innovative text message YA novels.
6. Spreading Intrapreneurship Across an Organization
Know this: Instigate genuine innovation in your organization by creating a model for intrepreneurship that empowers people in all levels of the company to build and test new ideas.
So you've become your company's innovation evangelist — how do you go from being a singular force to incentivizing widespread change? Intuit's Bennett Blank breaks down the steps through which Lean Startup practices moved through his company, such as allowing coworkers to make these practices their own and giving people a safe space in which to test out new ideas.
7. The Playbook for Creating Product Market Fit
Know this: Make sure the products your business creates are the ones your target customers really want by taking a page or two from the Lean Product Playbook.
Dan Olsen, author of The Lean Product Playbook, takes us through the methodology behind his book, which includes determining the underserved needs of your specific customer base and creating a strong value proposition and MVP.
8. Lean Startup, The Musical
Know this: Definitely the funniest interpretation of Lean Startup ideas that we've ever seen. Really, you're just gonna have to watch this one. Especially if you're a TLC fan.
We'd yet to get serenaded by stories of innovation until we met designer William McDonnell.
What's Next in 2016
On that (ahem) note, there's more cool stuff on the horizon for 2016: we'll host our annual flagship conference in San Francisco, of course. Save the date for the Lean Startup Conference Week on November 1 – 7. It's the one week in the year where you'll strengthen your foundation of the Lean Startup methodology, learn advanced strategies and tactics for implementing Lean within your organization, and meet experts from your industry who are facing similar challenges. Early bird registration opens in January.
And if you can't wait til Fall to see us, there's our inaugural Lean Startup Labs series, which are industry-focused summits around the country. We're starting with an enterprise lab in New York City in February; later in the year we'll have summits in Detroit and New Orleans on startups and social good, respectively.
CREATE A CULTURE OF INNOVATION AT ANY LEVEL
By Lisa Regan @mybldanube
Established companies are established. Which means they're big, operate with layers of complexity, and have a set way of doing business.
And as these established—we call them enterprise—companies look toward new ways of working, and new products to create, it often happens that their company culture isn't quite ready to support the transformation. Sure, leadership might be looking to make a change, but they get pushback from the product or business teams. Or self-starters on individual teams may be eager to experiment, but they get the sense leadership isn't interested. To find out what works to shake up a big, entrenched culture, we spoke to Brant Cooper.
Brant is co-founder of Moves the Needle and author of The Lean Entrepreneur—in addition to his many years at startups—and helps large enterprise companies like Intuit, Capital One, and Hewlett-Packard shift traditional business practices toward innovative ones.
We also recently dove in with Brant to explore the role of leaders in continuous innovation in this webcast conversation with Carie Davis, Coca-Cola's Global Director of Innovation and Entrepreneurship.
Lisa Regan: What are the obstacles to innovation in large corporations?
Brant Cooper: We actually hear the same story pretty often: A company has made a first foray into integrating Lean Startup practices, but they can't move the new methods past a small product team or innovation group. That's pretty much always because other parts of the business—legal, or regulatory compliance, or marketing—are worried about the risk to the brand. We start to hear, "What will our customers think about that? It might adversely affect our brand." Or maybe there are legal and regulatory compliance considerations around accepting payments. And those are all valid concerns. Big companies have to protect their core business—it's where they make all of their money. So while this idea of bringing startup practices to large enterprises is not really new, often it hasn't worked because those companies are right when they say, "Listen, we can't just become a startup."
So then the question is: What can you do about that? And I think the first thing you have to do is: Ask. Talk to people. A lot of these innovation teams will just sit inside their work area, and they'll go, "Oh, Legal will never allow us to do that." And they don't even ask! Pick up the phone, or go out for a cup of coffee, and just see what the response is. Like, maybe they're worried that you'll want to run an MVP that's not fully baked, but they don't know that an MVP is usually not going to be released to millions of people anyway—it's for targeted early adopters. And once Legal finds out that you're only interacting with a small handful of customers, they're like, "Ugh, don't bother me with this trivial stuff."
But it's also possible to actually get those operational teams—branding, sales, IT, legal, compliance, even HR—truly on board with new methods for creating products. In our training, we encourage people from those teams to join the innovation teams and the internal product teams so that they are able to experience first-hand what it's like to run experiments. Then, they can understand why the teams are acting the way they are, and what these experiments mean, and what's really happening when they're interacting with customers. When I say "join," I don't mean that they're sitting on the side and taking notes—they're active participants. We ask them to provide ideas.
Another strategy we use is to train the business and operational teams to themselves act like an internal startup, where the employees are their customers. We ask them to think, "What are some products or services that we can roll out to our internal employees that will enable them to innovate better?" If legal or HR start re-framing their employees' concerns as problems that they might be able to solve, then they can act like an internal Lean Startup and propose solutions. They can go and do customer development on their own employees, and then run experiments with employees to see which one of the ideas might actually work.
"IN STARTUPS, PEOPLE PUSH THROUGH NO MATTER WHAT THE EVIDENCE MIGHT STATE. IN LARGE ENTERPRISES, IT'S EXACTLY THE OPPOSITE."
LR: At enterprise corporations, what's the role of managers in guiding teams through entrepreneurial processes?
BC: This is a big question. How do you mentor internal innovation teams? It's not the same thing as managing. A lot of managers have a lot of experience, and they're very successful within large enterprises. But their skill set really is around managing known processes, versus mentoring teams to try to discover new processes. We're finding that to be a very tough nut to crack. We do some "train the trainers" work, so that they can then do the workshops themselves and teach. But even beyond training the trainers, it's: How do you teach leaders to mentor the teams, not just manage them?
Here's an example: In one of the sessions that we did at Intuit, a senior manager said it was interesting that they actually had to teach the teams how to persevere, that teams were willing topivot too early. It was interesting because, in the startup world, I encounter something different. In startups, people push through no matter what the evidence might state, or they're scared to even seek the real evidence. In large enterprises, it's exactly the opposite. They get a little bit of evidence, and then they're ready to pivot to the next idea.
Intuit's senior managers were like, "Actually, there are all sorts of ways that you guys can test ideas." You need that perseverance. The real innovation is not going to come easy, so you have to teach the internal entrepreneurs that they really need to iterate as much as they can before they "give up" and go off to a different idea.
To get there, you have to come up with new ways to measure these teams so that, on a week-by-week basis, they're making significant progress. It's, "You will go talk to 15 customers in the next week," rather than just making promises like, "Oh, yeah. By the end of the month, we hope to have a dozen downloads." The mentoring is really about teaching entrepreneurial teams to push aggressively.
LR: Why do you think it is that in the established companies, everybody gives up and goes, "Okay, let's just pivot"?
BC: That's a good question. Here's another example of a client that we're working with, a large consumer website. The President and CEO were urging the teams to move faster, so you had these teams running experiments, then they'd go, "Oh, I don't know if we can do this." And it was this senior leader that was going, "No, no. You have to do this. Push faster. Move faster."
So it could just be that, when growing up inside larger, well-established organizations, you've been mentally trained to sort of resist failure. Or if you fail too quickly, you'd better do something else where you might be able to succeed. Maybe there's even a fear of persevering, because, like, how far do I want to push on an idea that might not succeed? Is that going to come back and ding my career? So a lot of people inside these large enterprises are still trying to figure out, "Is senior leadership really on board with this whole idea of failing fast?"
That said, I've always been impressed that, when bringing these ideas to large enterprises, they have entrepreneurial people there. They have people that like chaos, that like wearing many hats and are problem solvers. And actually inside these large enterprises are pockets of agile programmers and design thinkers. So they already have these skill-sets at the grassroots. Those are the people that we can help identify, and teach them a little bit more about Lean Startup and how they can start running experiments. And then how they can teach it and how they can become mentors.
Real cultural transformation is going to take a while, and it's going to be difficult. It's not a linear journey. It's not from here to there. It's not short. Because you're going to have ups and downs, and you're going to come across these obstacles, and you have to go out and find mentors, and you have to go and find allies—all in order to overcome the obstacles.
But I think the rewards at the end are pretty big, especially if you're the one that's driving it, right? You're sort of an internal hero. Hopefully what it does is help your organization create real value for their customers and discover new business opportunities that result in real revenue. I think there's a lot of upside. And the bottom line: My hope is that employees feel empowered to create new value for customers. I think it's necessary for these big companies to survive, but it's probably also necessary for these big companies to keep their best employees, as they feel empowered to not just follow the process inside their known market but to go out and discover new value.
"HOW DO YOU GET BUY-IN? DON'T WAIT FOR PERMISSION. JUST START RUNNING YOUR EXPERIMENTS."
What about the person with an entrepreneurial spirit who's working in a large company? Can they make a difference on their own?
Recently I presented at a startup conference where I met a lot of people at the practitioner level who were asking that question: How do you get buy-in? What I tell them is: Don't wait for permission. Just start running your experiments. I'm sure you can find something that you can work on. Maybe it's after hours, and maybe it's beyond your existing scope. But once you start having evidence, you're in a position to start training leadership because you're not just asking for resources and money, but you're showing them evidence that there's something here that they should be interested in. Pretty likely the leadership is going to look at that and say, "Yeah, okay, I think you should continue that experiment." And so that's starting down the path.
My other bit of advice is to go find like-minded people. Run a meet-up inside the company, do a lunch-and-learn, do a regular happy hour where you get together with entrepreneurially minded people and start asking, "What are some experiments that we can run?" And you can start churning out evidence. Again, the leaders will start to take notice. And as a matter of fact, it's likely that, when you reach out like that, you will find leaders that buy into this approach as well.
Eventually, I do think you have to have that C-Suite executive that says, "Yes, we are going to do things differently," to get it to spread and to really get a cultural transformation. But you can get the whole process started just by going and doing it.
Lisa Regan is a writer for The Lean Startup Conference and creates content for individual companies—tech startups to design firms. She divides her time between the San Francisco Bay Area and Vienna, Austria, where she also writes on art and travel.
THE RIGHT QUESTIONS TO ASK BEFORE YOU BUILD SOFTWARE
By Ellen Sturm Niz @ellenbird
People building new software products tend to have a lot of similar questions. To get useful answers, we talked with Lauren Gilchrist, product manager at Pivotal Labs, a leading software development consultancy.
An edited, condensed version of our interview is below, and you can also catch Lauren in person at this year's Lean Startup Conference, December 8 – 12 in San Francisco, where she's leading a session on getting confident shipping products quickly so you can learn from users faster.
Ellen Sturm Niz: What do clients ask you most often?
Lauren Gilchrist: They often ask about growth problems before they've built anything. They have this huge vision in their head, and they just want to know how to get to that vision faster. So they ask a lot of questions like, "Should I build this feature first and then release that? Or that first and then release this?" Or, "Which of these seven different marketing strategies should I try?"
As humans, we tend to start with solutions. When we go to build a product, we don't generally say, "What are the kind of problems that, for example, new moms in New York have?" Or: "I wonder which of the problems new moms in New York have is the most painful, and what's the smallest thing that I can build to solve that problem?" Instead, people say, "What we need is a service that delivers diapers right to your door." They start with that, which is the solution to a problem. They don't start with the problem.
So a lot of questions that people come to me with look like this: They have a solution in their head, and they're like "I've already got the truck lined up, and I've got the diaper provider, and what I really don't know how to do is how to expand to 35 cities." And we're like, "But you haven't launched anything yet."
ESN: So what do you do?
LG: I tell them, "Before we deal with world domination, let's back up." I help people walk back up the ladder to get to: Who's the user? What problem are you solving for the user? Does your proposed solution actually solve that problem—and how can you answer that? Then, how can you answer that faster?
ESN: So, if somebody came to you and they said, "Oh, I'm going to deliver diapers to moms, and I want to do it in 35 cities," and you're like, "Wow, you haven't done it in one city yet." What would you bring them in to do, and suggest that they do instead?
LG: Where I start first is this: "What's the need? Help me understand why this is the problem that you're devoting all of your time to solving." That usually brings up a couple of different scenarios. One, people see a really big opportunity, whether it's a marketplace or a need that's not met. Or two, they're dealing with a problem that they, themselves, are really familiar with.
There's a woman named Allyson Downey who's the founder of the company called WeeSpring. She has this great story about how when she was pregnant, she started asking her friends what kind of bottles they purchased, what kind of cribs they bought, what they needed, what they didn't need, and it wound up turning into this crazy email chain of spreadsheets. She wound up launching a company a couple years later that was about getting recommendations for baby products from your friends. So, for her, that's something where she really understood the need, and she wanted to build it. And she started very small.
Contrast that with someone who doesn't have kids and says, "I'm going to solve diapering for every major city. I'm going to solve the problem that no one ever has enough diapers in their house." They start with the classic business school case: here's the market size, here's how many people are going to have babies and diapers, and they work their way down to the three-year business plan. And nowhere along that journey have they even validated whether or not someone wants to receive a shipment of diapers within six hours. They haven't talked to any moms, they haven't potentially tried to make a quick MVP of like, "Hey, here's a list of five moms, and we'll just rent a car, go to the grocery store, pick them up, and drive over with the diapers."
There's this great story about Zappos when they first started, their MVP was actually that they took photos of shoes in retail stores and posted them. Then, if someone actually bought something, they would go buy the shoes in the retail store and ship them to the purchaser. That's a great MVP. [This may be obvious, but it bears emphasis: It was a great MVP because it quickly and cheaply answered the question, "Will people buy shoes online?" Once they proved that people would, it became worth it to start building a more thorough system to do that. -Eds]
ESN: I love the story of Zappos. When I heard it, I thought, "That's genius."
LG: It's so smart. It's amazing. I worked for a startup called Yipit, and they did something similar. This was back when daily deals like Groupon and Living Social were really, really hot. They thought, "Oh hey, I bet it would be cool to see all these in one place, rather than subscribing to six different emails." So, in three days, they built a website where you could sign up, and they kind of aggregated every single daily deal into their database. So, they would get up at like 3:00 in the morning, and put all of these things into their database, and then they'd send out the email. That was their MVP. And a year later, they actually still didn't have a way to automate it. It was still all manual—there was a team that manually copied and pasted these daily deals into their database.
Obviously, they automated it finally. But for a year while they were still growing, and still getting their user base, they were building from the ground up and it was a cheap way of making it work without starting with, "Oh, what we really need is a web scraper that goes into a back end and can handle all these different cases." Because they didn't know if they actually needed to invest that money at first.
ESN: What are one or two questions you wish clients would ask you, but they never do?
LG: I wish they would ask, "How do I know I'm right?" As entrepreneurs, we start with solutions, and sometimes you don't learn until much, much later that nobody wants it. It's this double-edged sword, because to be an entrepreneur, you have to face down a lot of adversity, and you have to deal with people saying, "You're wrong, and that's crazy, and you're never going to do it." You have to power through that.
At the same time, left unchecked, the assumptions that you're making that your solution is actually adding value to your users can grow and grow and grow, and it can make a failure much more expensive.
ESN: In other words: The belief you need in your product to overcome the adversities can cloud your judgement. So you don't see when you need to pivot and do something differently?
LG: Right. It's a tough balance. Those are the moments when it's really helpful to come back and say, "How do I actually know that I'm adding value? How do I know that this product that I've built is solving a problem?" Without hard evidence, it's really challenging. That ties back into, "How do I know that I'm right? How do I know that I'm adding value—and how I can actually validate that?" That's something I wish people would ask more of.
What I teach people over the course of working together, usually, is that you can actually know whether something is adding value before it's a fully baked, fully featured product. Which is really exciting. That learning and that validation that you get is so satisfying.
ESN: At The Lean Startup Conference, you're going to talk about how releasing a product that doesn't solve all of your customers needs at once is okay. Is that what you mean here? That you can get the information and the validation that you need with a less-than-perfect MVP?
LG: Absolutely. An easy analogy is when you release a product. The time period right before you release is kind of like going grocery shopping when you're really hungry. You're like, "Oh my god, maybe I really need the rack of lamb with goat cheese and lavender and honey. Or maybe I need some chips. Oh my god, I need a frozen pizza too." And you're sort of just crazily throwing things into your cart, because you are so ravenous that you don't necessarily know what you need. You just need something.
Right before you release a product, you're like, "Oh my god, what if we forgot the share on Tumblr button? We forgot the "Share on Tumblr" button. We totally need that." Or like, "Oh my god, we can't ship to London. What if we get a user in London?" You have this moment of absolute panic, because you're about to push this thing live, and it may not be perfect. You may have overlooked something. It's terrifying. It's absolutely terrifying.
But what I've learned over time is that you can mitigate that panic. Just like you'd say in this same analogy, "Eat an apple before you go to the grocery store." Same analogy you're carrying out to the product side. You can release smaller versions of your product, or pieces of functionality. It doesn't even have to be a functional product. You can put wire frames, or sketches, or something that's totally fake in front of people to get feedback before you have to release this product into the world. And that helps you answer some of these questions about like, "Is this actually adding value, and how, right now?"
ESN: Right, is this "Share on Tumblr" button really going to make or break the product?
LG: Right. Not only is it going to make or break it, but do I even need it? So rather than saying, "Let's put the button in just in case and delay the launch for a week," you say, "We've already figured out that none of our users use Tumblr." Or, "Well, we put a 'Share on Facebook' button in, and no one used that, so we're just going to assume that we don't need that." Or, "We put a 'Share on Tumblr' button in a prototype and no one even asked what it did, or no one tried to click on it, so we can probably do without that."
ESN: How do you know when you should delay a product because you overlooked something really important, versus when you're just having that, "I'm hungry at the supermarket" moment?
LG: Ideally, that overlook moment isn't coming at the point when you're going to ship something. It's coming before that, because you've been putting your product in front of people before your ship date. You've been interviewing users. You've been doing actual user testing sessions. That tends to come up earlier and some of the red flags are that no one's using this feature, or maybe it's a product that's supposed to be inherently viral and no one is inviting their friends.
To go back to the diaper example, maybe everybody signs up but no one actually orders diapers. Or, nobody signs up. Or maybe you show this product to someone, and then you ask them how they would explain it to a friend—then they explain it like, "This is a new baby registry," when you think it is a product where you could get recommendations from your friends about baby products.
When you're like, "Huh. Whoa. People perceive this differently than I do," that's where you might decide, "Huh, maybe this isn't ready to go, because people aren't using it and talking about it in the same way that we think they should be, in the way that communicates that they understand the value in the same way that we do."
ESN: I would think that entrepreneurs would fear that releasing something imperfect would affect the reaction of users. Do they think, I know people won't like this because it's not perfect so why release it yet? I'm just setting myself up to get negative feedback?
LG: Yeah, there's a lot of fear. When you're an entrepreneur, you have an enormous vision. You're trying to disrupt an industry, or disrupt patterns. You're trying to cause people to change their habits and change their behaviors. That's a very big vision. If what gets released doesn't match what's in your head, it can be really hard to accept that users aren't using the product for a fundamental reason, not because it doesn't contain everything in your vision.
Another thing we get a lot of, particularly for projects that are for internal customers, is, "Oh my god, it didn't solve everything." You get this fear that everything is going to be judged on this one big release and reveal. That's not actually true. There's so much work that goes into a release and so much work that happens after it. But you get caught up in the big reveal moment, and that's another thing that trips people up.
ESN: Does releasing an imperfect MVP ever kill a project? Does it ever happen where you say, "I knew I should have put that 'Share on Tumblr' button on there, and that's why they hate it, and now everything is ruined!"
LG: But there's so many ways to fix that. You can say—and this is so much about communication—you can always say, "Thanks so much for your feedback. We incorporated that. We listened, and guess what, now there's a 'Share on Tumblr' button, and we put it out three days later." The other thing that's important to think about is that products are never done, they're always evolving. They're living, breathing, evolving beings, and it's not as if you just push it out there, and then it sits there for two years, and you don't change anything.
ESN: You can't just sit back and say, "Hey, look what we did! I'm done and now we can just make money."
LG: Right, exactly. You don't put your feet on the desk and your hands behind your head and have a beer. You're like, "It turns out we have all these users in the Philippines, how did that happen? I don't know how we wound up there. Huh, that's interesting. They can't check out. We need to fix that." And all of a sudden you're like, "Are we a company that caters to a Filipino audience? Do we need two different sign-up flows?" You notice these trends, and all of a sudden you're like, "Huh, that's not what it was a couple of months ago. That's not what is was three days ago. What is this evolving to?"
Going back to the launch scenarios, you learn from releasing something that's imperfect, because you learn what problems you've already solved for people—and you learn what problems you still have yet to solve. You also learn more about what your users think. No matter what stage you release something, whether it's literally sitting down and putting a napkin sketch in front of someone and saying, "What do you expect to happen when you click here?" Or whether it's functional software that you release to millions of people, you're still going to learn. The earlier that you can get something in front of people, the faster you can launch.
ESN: Can you give an example of a company that did release something that was imperfect in the early stages, that didn't quite solve all the problems, but was good enough, and it worked out?
LG: I want to go back to that Yipit example, where they launched with like four daily deals rolled into one email, and they launched in one city. And then a couple of months later they launched in another city, because they were getting emails saying, "Hey, can you launch in Boston?" And you couple of weeks later, they launched in 10 more cities. And a couple weeks after that, they decided to add in categories, because people were like, "I don't want all the daily deals, I only want spa deals." It evolved slowly but surely. Now it's a way to search for any discount for anything. But that's not where it started.
ESN: What's another question that you wish entrepreneurs or enterprises would ask you, but they never do?
LG: "Should I even build this?" I wish they would ask that, because validating the idea in the first place would save time and money and frustration on their part. They're convinced that they should build it, there's no question in their mind. But when you ask someone, "What's the evidence that you should build this?", they're very taken aback. It's like, "Wait, why are you questioning my vision?"
ESN: Because to them it's so obvious. They know.
LG: Right. It's so obvious to them. But a lot of times, there's not a lot of evidence. I'll give you a concrete example. I was working on a project where we were building a content management system, and we interviewed all the users, and we tried to understand what they needed to accomplish. It was a live video system, and often, the users needed to cut or reorder the segments for breaking news. They also needed to be able to see what everybody else is working on, and they needed to be able to edit things quickly.
You listen to that list of requirements, and you think, "Huh, well, clearly we need drag-and-drop to be able to reorder things quickly." Building drag-and-drop is actually pretty time-intensive: It can be a week or two of development to build that kind of interface.
What we started with was this: Let's put a box next to each segment, and that box will have a number in it, and that number will determine the order on the page. If they want to change the order, they can change the number on the box, and then refresh the page. We built that, we put it in front of them and we said, "Build a show on this tool." Guess what? There wasn't a single person who said anything about it being necessary to reorder segments faster.
So we validated that we'd solved their problem, A, which was needing to reorder segments quickly, and, B, we saved two weeks of not needing to build drag-and-drop, because we solved the problem in an easier way. In other words, we built the smallest feature that we could to solve that problem, and then we put it in front of them. That let us learn whether that solution solved their problem or not.
Had we learned that it wasn't fast enough, we would have progressed to a drag-and-drop, or maybe another solution.
ESN: One of the other things you're going to be talking about at the conference is about how too much empathy for customers slows product managers down. It seems counterintuitive in the startup world to be less empathetic to users. Can you talk a little bit about that?
LG: Absolutely. In my job, the process of finding out who the users are and what their problems are involves interviewing people and asking them a lot of questions and asking why a lot. The project I'm on, we just interviewed eight users at this company. We asked them about everything from their day-to-day habits, to how they use certain tools, what their frustration with those tools were, how they knew when they did a good job. You're doing this psychological digging of, "What is it that's really bothering you about this thing?"
You then have all that information in your brain as you start building solutions, so you've become incredibly empathetic with these people. All of a sudden, you're like, "Oh my god, we can't ship that, because it doesn't have Bob's drag-and-drop, and Bob really wants drag-and-drop!" It becomes second nature to want to solve all of their problems and want to help them and want to be this interesting savior figure, whose software solves everyone's problems.
That's where I really empathize with entrepreneurs who say, "I just want to fix it all." But you can't. You have to realize that people have some large problems and some small problems and some things that aren't really problems at all. If you can fix one and make people really, really happy, then they'll start asking for other things.
ESN: So, users will forgive you if you haven't anticipated everything, but if you solved one of their problems really well, they will be happy with that. And they'll give you feedback about other problems you could solve that you add later.
LG: That's exactly it. There's a Nobel Prize-winning psychologist, Daniel Kahneman, and he has this saying, "Nothing is as important as you think it is while you're thinking it." Which basically translates to "Yes, this is the thing that's keeping you up at night, but your user hasn't logged into your tool in two weeks and doesn't remember it."
ESN: You think Bob is secretly stewing over the fact that there's no drag-and-drop, but really, Bob is on vacation.
LG: Bob is really worried about the fact that he has a flat tire, or his kid is sick, or he is hungry. There are so many factors in our lives, and the way that people use software is just one of them. And interestingly enough, if you don't solicit feedback on your product in a way that is encouraging to get both positive and negative feedback, a lot of times you only hear the negative. Because what do people post online? Angry rants.
A lot of the positive reviews will get lost, and people will only talk about their frustrations. What you miss was that experience of watching them use it for the first time. Seeing them say, "This is great." So, a lot of what we encourage people to do is be there at the point when 10 or 15 people are interacting with your software for the first time, and observe them, and ask them questions. You can watch their faces, you can watch their movements to understand whether or this is actually solving a problem for them.
ESN: So you should get really hands-on user feedback?
LG: Yes, and testing. There are two different phases: user interviews and user testing. User interviews are how you understand who your users are, what's their demographic information, what are their behaviors, what are their needs and goals, and what is their motivation. And you sort of do that in a sprint, five or 10 people, and you're like, "Okay, I've got all the information about these people and now I understand how my product might possibly add value." Then you put your head down and you build for a little bit, and then you pick your head back up, and you go back to those 10 people for user testing.
You say, "Hey, here's this thing. I'd like to watch you use it for the first time. Can you try to do this, and can you try to do that?" And like, "Oh, I saw you got stuck there, why did you get stuck?" In that moment, you get these amazing reactions. You either get, "This is the greatest thing ever." Or you get, "I don't get it." Or, "What goes here? I'm confused." Or like, "This says name, does it mean customer name or my name?" Like, Bob didn't realize that he could drag-and-drop.
That's ideally how you learn whether or not this adds value, and, also, what the other problems are. You're doing it first hand, so when you launch this thing, you're confident that you actually have solved somebody's problem, and you also have a decent understanding of what the complaints are going to be. Maybe you'll get some surprises, but you're much more confident.
ESN: Is there any other advice you would give to product managers who want to get their services and products to users more quickly and effectively?
LG: First, before putting your own product in front of people, practice user testing on someone else's product. Go to a friend and say, "I'm going to show you this product called Wikipedia. I want you to use Wikipedia in front of me to do these specific tasks." User interviewing and user testing are really sort of awkward things, because you have to be able to sit back and watch someone call your baby ugly—and then just ask, "Okay, why is my baby ugly? Why do you think that?"
If you practice doing that on things that you are not emotionally invested in, it makes the habit and the practice a lot easier when you work on something that you do care about. Even if you do it among your friends or some coworkers and pretend to demo something that isn't yours, you get that fear out of the way. It becomes more natural for you to ask those questions and to demonstrate something that is new to someone else.
Second, whatever fidelity you have, put it in front of someone. I have people that come to me and they're like, "Well, I can't show it to anyone because it's a sketch, or it's a wire frame, or it doesn't actually work." What I tell them is that you can learn something from whatever level of fidelity you put in front of someone.
For the content management project, for example, we started with just wire frames, and we put those wire frames in front of people, and we said, "Does this have everything that you need to do your job? Is this laid out in the same manner?" They said, "We need to be able to enter data." So, we built a tool to let them enter data. We actually built the front end of the website and hooked it all up so that it almost was working. We let them type into it, and that's was where we realized people were missing the save button, which is really bad.
ESN: That's super frustrating to the user.
LG: It's super frustrating, and we were able to catch all of that before we actually had the functional software. So, on the one hand, someone could possibly say, "It's not ready yet. It's not actually built." But on the other hand, we were able to learn that faster, which means that by the time that we actually released the software to these users, we were able to validate in a day whether this was a tool sufficient for their needs.
So no matter what you have, and no matter how polished/unpolished, whatever, just put it in front of somebody, because you're going to learn something, and that's going to help give you feedback, and it's going to help you answer some questions, which always helps refine your product.
Third, at the lab, we have a regular user testing schedule, so we actually bring in a couple of people every Thursday from Craigslist. Staff can sign up for slots and say, "Hey, I need to test this new flow that I'm working on," or, "I need to figure out if someone is going to understand what this app even is, and can they explain it to a friend?" They have the opportunity to have someone just in the office. If you make it a habit where you don't even think about, you don't have to have this existential crisis of getting all these users, and, "Who do we interview and when do we bring them in?" It's just routine, and it's there, and you can do it once a week. It becomes less scary. It's all about reducing this fear of getting things in front of people faster.
ESN: Just put it in front of a couple of people and see if they do it.
LG: Right. For a product that I'm working on right now, we have a date range. Except rather than its having two date fields, one is a date and the other shows up with a button that says, "Add end date." I was panicking, like, "I don't know if this is the right way to do it. Are they going to understand that to add a second date in a range, you click the button and then you get the thing?" Everybody did it without a problem.
So my advice is always whatever is keeping you up at night, you can probably figure out by putting something in front of users.
By the way, on this project, the date range worked, but we have a button to add the customer, and the users didn't know what that did. So now I have a new problem to work on.
ESN: Are there any other articles or information on user testing that you think would be helpful for people?
LG: There is a guy named Rob Fitzpatrick, who wrote a book called The Mom Test. He also has a bunch of videos. He's the one that taught me how to phrase your user interviews and your user testing questions in a way that is not leading, that actually gets the information out of the people that you need to get it out of. That one was really useful to me.
Ellen Sturm Niz is a freelance content strategist and writer for The Lean Startup Conference.
HOW TO CHANGE YOUR COWORKERS' MINDS
The Lean Startup Conference, a three day gathering of entrepreneurs, is held at the Nob Hill Masonic Center and the Fairmont Hotel in San Francisco on December 8-11, 2013. (© 2013 Photo by Jakub Mosur)
Every time user experience expert Laura Klein gives a talk, she's asked, "How do I get my coworkers to understand that what I do is important?"
Her insightful answer is below, excerpted from a recent interview with Lisa Regan for Eric Ries's blog; you can read the full interview here. Laura is the author of UX for Lean Startups, creator of the design blog Users Know, and Head of Product at Hint Health, a software company working on healthcare affordability.
Lisa is a writer for both The How and The Lean Startup Conference.
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 to 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.
WE CAN'T FIND CUSTOMERS TO INTERVIEW. NOW WHAT?
By April Joyner @aprjoy
Cindy Alvarez | Photo: Cindy Alvarez
In our "Now What?" series, startups ask real-life questions, and we find experienced entrepreneurs to offer deep, relevant advice. If you have a startup challenge, and you'd like insight from an experienced entrepreneur, let us know in this short form. – Eds
Another thing that's helpful is to do what I call a traits continuum, which is basically to write opposing traits, one on one side, one on the other, and figure out where you think people are. For example, for anything app-related, you might have from tech-savvy to not tech-savvy. Way over on the "not" side might be someone who's never downloaded an app to their phone—probably not a good candidate here. A little further over might be someone whose significant other or kids put apps on their phone, but they don't know how to do it. That's still probably not the best market. Way at the other extreme is the kind of person who will try anything and download anything.
CA: To be honest, what this smacks of to me is not that they've run out of people to talk to, but that there's some other problem. Personally, as a parent, I think it would be pretty easy to get me to agree to an interview about this topic, because it's a pretty painful thing when parents have a hard time getting care. The fact that people aren't champing at the bit suggests to me that either the problem isn't being pitched in a way that's resonating, or that the request for conversation sounds onerous in some way. Maybe it sounds like it's going to take a really long time, or they might be trying to contact people via phone who would rather use email, or vice versa. They might be trying to call people during the dinner hour. If you try to get anything out of me between 6:30 and 8:30 pm, I am not receptive.
What's tricky is that people usually will not tell you what the problem is, so you have to do a certain amount of troubleshooting. If someone was like, "Hey, my friend really wants to talk to you about this," and I kept saying, "Oh, yeah, I keep meaning to talk to her," that's a sign that for some reason, it's not valuable enough to me. So the founders need to take a look and make some guesses about what that problem is. Is it that their pitch is not compelling enough? Are they communicating with people in a way that's somehow off-putting, but they may not realize it? Are they communicating at people at the wrong time? Are they communicating with people in achannel that's not common to them? Are they coming off somehow as advertisers? There are lots of things like this that might actually be an issue.
You're obviously never going to predict all of these things. But what you can do is constantlyiterate on the process. People who aren't willing to talk to you may still be willing to answer a single question via email. If you say, "I'd love to talk to you about this solution," and someone doesn't respond, instead of continuing to try, you might say something like, "I'm just curious. We don't have to have this conversation, but did I ask in a way that was inconvenient to you?" Or "Is there a way I could have phrased this better?" Or "Is there something I could have done to make this seem more appealing?"
"I'LL SEND IT TO MYSELF AND OPEN IT ON MY PHONE. AND I'LL BE LIKE, 'OH, THE ASK IS WAY BELOW THE FOLD. THIS IS TERRIBLE.'"
If you have a startup challenge, and you'd like insight from an experienced entrepreneur, let us know in this short form. – Eds
HOW TO TEST YOUR PRODUCT BEFORE YOU BUILD IT
Daina Burnes Linton | Photo: The Lean Startup Conference/Jakub Mosur and Erin Lubin
The Lean Startup method tells you to test your product idea with customers before you spend time and money building something you aren't sure people want.
But how can you test a product without having the actual product? In her talk at the 2013 Lean Startup Conference, Daina Burnes Linton, CEO of Fashion Metric, explained how her company had done just that. As a result of their approach, Linton said, "Fashion Metric is today is very different from what our original idea was"—and she considered that a very big success. Here's how Fashion Metric started:
We challenged ourselves to really understand the real problem the customer was experiencing…. We thought clothing shoppers—shoppers in stores and malls—might have a very difficult time deciding what to buy. Maybe it's because they're alone, and they're not with their friends, and they can't get their opinions. So, we thought, "Well, wouldn't it be great if there was a mobile app, and you could take a picture of what you're trying to figure out what to buy, and you can gain access to a personal stylist that can give you advice in real time and help make your purchase decisions?" Sounds like it could be a reasonable idea, right? Of course, friends and family always say, "Oh, yeah, that's a great idea. Build that. That sounds awesome." But we weren't sure if we were solving a real problem, and so, we decided to really understand: Is this a real problem that customers are experiencing when they're shopping in stores? So, we talked to who we thought our customer was all over the country. We went to malls in Los Angeles, New York City, and San Francisco. We asked, "What's the biggest problem that you have when you're shopping for clothes?" Very open-ended. What we found when we did this exercise was that not a single person—not one person—gave us the natural response that they had a hard time deciding what to buy. Not one person. So we almost built an app to solve that problem that didn't exist.
By doing targeted customer research before building their product, the Fashion Metric team gave themselves 20/20 hindsight.
Of course, if they had stopped there, the company wouldn't exist today. Instead, they looked carefully at the data they were gathering and realized that 90 percent of the men they spoke with said that finding clothes that fit was a problem. So the team dug deeper and learned that men particularly struggled to find dress shirts that fit well. With a clear trend around a real problem, Fashion Metric now had data to start building. Rather than code up a site, however, the team decided to validate their idea with an MVP that consisted of two parts: 1. a landing page asking for potential customers' email addresses, and 2. follow-up phone interviews to gather customer sizing information. (Note that Daina is an engineer, so holding off on the coding was no small act of will.)
Before writing a single line of code, all we had was that landing page, and we learned a lot. We had an accelerated understanding of the problem; we were no longer building an app to solve a problem that didn't exist; we understood the depth of the problem. We were able to see how far customers were willing to go to solve it. We were starting to see some trends in the data, to understand what questions we could ask, and whether or not it was technically feasible to solve the problem. You would think at that point, "Okay, great. Build something," right? "Build the whole thing." But we didn't.
To find out what Fashion Metric did next, scroll down to watch or listen to Daina's 12-minute talk. We've also included the full, unedited transcript below.
In the comments, we'd love to hear your best advice for finding relevant customers to interview before you have a product to show. Please tell us about the idea you were testing and how you found people. B2B and B2C ideas equally welcome! – Eds
Daina Linton is the co-founder and CEO of Fashion Metric, a company that builds technologies to increase sales and reduce returns in apparel e-commerce by improving fit accuracy. Fashion Metric's comprehensive data-driven technology calculates a customers' full compliment of measurements based on a seed of information provided by the customer. Fashion Metric then uses this algorithm output to fit customers in made-to-measure clothing or integrated on e-commerce platforms that carry "off-the-rack" sizes. A trained engineer, Daina pursued her degree while simultaneously holding several research internships at university affiliated hospital research labs. Eventually, she left a PhD engineering program at UCLA to parlay her experience in data analytics and image-processing methodologies and ultimately launch Fashion Metric. Follow her on Twitter.
Sarah Gaviser Leslie is a corporate storyteller and executive communications consultant in Silicon Valley.
Jargon, demystified
Includes terms from the talk that we didn't quote above. If there was a term you didn't know that we haven't defined, please let us know—we want to help! Also, if you have a better definition or an addition to a definition, shoot us a note.
MVP. An MVP, or minimum viable product, is an experiment that helps you quickly validate—or often invalidate—a theory you have about the potential for a new product or service. (Although often a stripped-down version of your product, an MVP is different from a prototype, which is intended to test a product itself and usually answers design or technical questions.)
The minimum concept is key because, in order to move rapidly and definitively, you want your experiments to include only features that help you test your current theory about what will happen when your customers interact with your product. Everything else is not only a waste of time and money, but can also cloud your results. The viable concept is key, too, in that MVPs have to actually produce test results you can learn from, which means it has to work on some meaningful level for customers.
The classic example is that if you're trying to test the demand for a new service, you might do that by putting up a one-page website where people can pre-order the service before you've spent any time developing the actual thing or hiring people to make it happen. By the same token, if you're testing a hypothesis around customer use of a new jet engine, then you have to make sure it will fly safely—in order for it to be truly viable, or feasible.
Landing page. A web page with a form to collect visitor info. HubSpot has an opinionated take on landing pages.
Ideation. Fancy word for brainstorming or idea formation.
Concierge. A type of MVP in which you manually fulfill a service that you're thinking of automating in your product. A concierge MVP usually doesn't require building much, if anything, and the high-touch interaction with customers lets you learn a lot.
Intelligence engine. Software that analyzes raw data to create useful insights.
Post by Lean Startup Conference co-hosts Sarah Milstein & Eric Ries
We're excited to announce this year's Lean Startup Conference, December 8 – 12 in San Francisco. Tickets are on sale now, at the best price we're offering this year, so we recommend registering today. But that's not really what we're here to talk about. Instead, we want to focus on the themes of the conference.
This year, we're defining the conference program as a series of hard questions entrepreneurs commonly face, and we'll address them in our talks and workshops. Below is our initial list of questions. We'd welcome your input on which of these challenges feel most vital to you, along with additional questions you and your team are facing. You can leave ideas in the comments or email Sarah Milstein, co-host for the conference and CEO of Lean Startups Productions.
Very soon, after we've refined this list, we'll post our call for proposals from potential speakers, seeking talks that can answer the questions we've collected. [UPDATE: The call for proposals is now open.] If you'd like to learn when we open the call, follow us on Twitter, subscribe to this blog, or sign up for the newsletter on our site.
Questions we're aiming to address at this year's conference, by category:
Experiments and Process
How can I ensure that meaningful customer feedback is included in our evaluation of new initiatives?
How can I get new products, services, and internal initiatives to market more quickly?
How can I design a good experiment–a minimum viable product–for services or internal customers?
How can I create a sandbox for innovation with my organization without putting my core business in jeopardy?
What can I do when a team proposes an experiment that might undermine our existing brand?
How can I experiment and iterate quickly on mission-critical products and systems?
How can I keep up team morale when experiments invalidate a lot of our ideas?
What can I do when I have a handful of customers who absolutely love our new product, but not enough to meet our revenue or impact goals?
Metrics and Accountability
How can I measure a new initiative before it has large numbers of customers or revenue?
How can I measure a value hypothesis and a growth hypothesis at the same time?
What metrics I can use to hold people accountable on projects that include extreme uncertainty?
How can I measure impact when financial metrics are not the bottom line (or not the sole bottom), such as in NGOs, non-profits and governments?
Teams and People
How can I convince my leaders and managers to support entrepreneurial methods?
How can I convince my co-workers and direct reports to use entrepreneurial methods?
How can I set up teams to ensure cross-functional collaboration?
How can I get internal services like IT, finance, legal, and HR to act like startups and serve entrepreneurial teams throughout my organization?
What does the culture of a high-performance, high-growth team look like?
How can I build a culture that serves existing customers and unlocks new sources of growth?
How can I best hire and train people who haven't used Lean Startup methods before?
We look forward to your input on these questions in the comments or in email to Sarah—and we look forward to seeing you at the conference (register now for an honestly amazing deal.
A Few Surprising Facts about the 2014 Lean Startup Call for Speakers
Post written by Sarah Milstein & Eric Ries, co-hosts for The Lean Startup Conference
We're seeking speakers we don't already know for this year's Lean Startup Conference, December 10 -11 in San Francisco. Our call for proposals is open now, and if you know already that you want to apply, jump to it (but read the directions first!).
If you've never applied to speak at The Lean Startup Conference before—or never even considered it before—here are a few things to keep in mind, some of them surprising:
You don't have to be on the speaking circuit already. In fact, we're psyched if you're not a seasoned speaker. What we care about is the business experience you have to share, not the speaking experience. In other words, if you've applied Lean Startup techniques at your company, and you have advice or a story about your work that will help other entrepreneurs, we want to hear from you. While we'll have a few speakers who are long-time Lean Startup experts, we're primarily interested in case studies from people we don't already know.
We don't favor speakers we know personally. We aim to use the most meritocratic processes we can to find and evaluate speakers. That is to say: We don't pick our speakers because they're our friends or because they're big names; we pick them because they have absolutely useful advice to share. In addition, we assess 95% of them via our call for proposals, which helps guide and standardize the submissions so that we're comparing apples to apples (and not, for example, evaluating one proposal based on the recommendation of a mutual friend and another based on a video of the speaker from another conference).
Since we started focusing on fairness, a welcome though not surprising result is that we've regularly fielded a roster of excellent speakers that comprises more than 50% women and/or people of color. (In the past, the roster was nearly all white men, as those were the entrepreneurs Eric knew personally; they were very good speakers, too. But we now go much deeper into startup communities, finding speakers you won't necessarily have heard elsewhere.)
Actually, we pre-select a very few. What about that other 5%? Full transparency: We do invite back particularly strong speakers from year to year, and we very occasionally invite entrepreneurs we meet out in the wild who strike us an unusually good fit for The Lean Startup Conference. We readily acknowledge that one of our best speakers in 2012 and 2013 was Sarah's brother. We keep inviting him back because other entrepreneurs tell us they learn so much from him, not because he's related to one of us.
We offer free speaker training. We do a lot of hands-on work with speakers to help ensure that your presentation really resonates with our audience. That includes, but is not limited to, both group and individual speaker training. If you're a new speaker, this is a great opportunity to get some very good guidance (it's also a great opportunity if you're an experienced speaker; last year, some of our most avid trainees were our most accomplished presenters).
We'll cover your travel costs. This year for the first time, we're offering travel assistance for any speaker whose companies can't cover it. We are ourselves a startup, and this represents a significant chunk of our budget, but we want to bring in speakers regardless of their own companies' finances. (We also give all speakers a full Platinum Pass to the conference, but that ought to go without saying. If you register now to get the best price, and we subsequently pick you as a speaker, we'll refund your ticket.)
Our call for proposals has a lot of directions—but the form itself is short. Don't be daunted by the first page of the call, which has a lot of information that we ask you to take in. Those directions will help you submit a successful proposal, and they include links to some of our favorite talks from last year, for inspiration.
This year, we've come up with the questions our attendees most want answered—so you don't have to do that part. All you need to do is figure out where you can offer relevant advice or a case study, and fill out the application form accordingly.
The call for proposals is open until 11:59p PT on June 12, and we encourage you to apply today. If you're not interested in speaking but you know you want to attend the conference, register now for the best prices.


text:
"If you're thin enough then you don't have that as* that everybody wants": Taylor Swift's Brave Confession About Unrealistic Beauty Standards Gets Much Needed Support
Sampurna Banerjee
The grass is always greener on the other side. One might think looking at a relatively lean person how privileged they are for being that way naturally and vice versa. It also has a negative impact. The same "trendy" body type becomes problematic when the internet decides you're "too much" of something. People dream of having the "trendy body type". But what happens when one's body type is out of trend? It is impossible to please the internet? Well… Taylor Swift is living proof of it.
In Taylor Swift's Netflix documentary Miss Americana, the record-breaking singer spoke out about her relationship with her body and how one can never be enough and people voiced their support for her.
Taylor Swift, a record-breaking singer
Also Read: "She's literally begging her to stop": Emily Ratajkowski Loses Her Mind After Ellen DeGeneres Insults Taylor Swift in Viral Video
Taylor Swift on her relationship with food and her body image
The Internet is a weird place, especially for teens and tweens. When exposed to such vast "body-positive" content online it can sometimes mess up one's psyche. People are supportive of one's body until they are too fat or too skinny. Then people are "concerned". This lets the young and impressionable youth believe they have to meet a certain unspoken standard of beauty to fit in. As Taylor Swift rightfully puts it,
"There's always some standard of beauty that you're not meeting–Because, if you're thin enough, then you don't have that ass that everybody wants. But if you have enough weight on you to have an ass, then your stomach isn't flat enough. It's all just f—ing impossible."
The "ideal" body type that keeps getting promoted changes from time to time. Recently, Kim Kardashian was under fire for reportedly removing her iconic "BBL". Does that mean people with natural curves are out of trend? It is very dangerous to believe, as human bodies don't work that way. To sculpt a body according to trends can do significant damage to that individual physically, as well as mentally.
Young Taylor Swift
Taylor Swift recalls an incident where,
"a picture of me where I feel like I looked like my tummy was too big, or… someone said that I looked pregnant … and that'll just trigger me to just starve a little bit — just stop eating."
And then again, after being called "pregnant" at such a young age for putting up a healthy amount of weight, when she lost a few pounds, people said, "She's too skinny. It bothers me."
A group of "concerned" people is always voicing their concerns. One can never truly win.
"But all I know is my own experience. And my relationship with food was exactly the same psychology that I applied to everything else in my life: If I was given a pat on the head, I registered that as good. If I was given a punishment, I registered that as bad."
She later realized how dangerous the reward system she was following was. She is now in a healthy phase and understands herself way better. Thus, Taylor Swift speaking out on such a sensitive yet very common topic started a discussion.
Also Read: 'Always wanted to be that hardcore, bad b**ch': Says Lady Gaga as She Cries To Her Fans for Stopping Concert Because of Rain
Many are thankful to Taylor Swift for speaking up, including Lady Gaga
A clip from Taylor Swift's documentary received a heartfelt reaction from Lady Gaga.
"That's really brave everything you said wow."
Lady Gaga's comment on the TikTok clip
Wrote the pop star to the fellow singer. Taylor Swift is undoubtedly a very big name in the industry. The impact she has had on the music industry changed many things forever. And the army of "Swifties" throughout the globe came out to her support after Lady Gaga started the conversation. Taylor Swift now reflects,
"I don't care as much if somebody points out that I have gained weight, it's just something that makes my life better,–The fact that I'm a size six instead of a size 00, that wasn't how my body was supposed to be, I just didn't really understand that at the time, I don't really think I knew it."
Taylor Swift is glad that sooner or later she realized her mistakes. And thus wants to help others in similar situations. Just sharing her experiences and talking about them has made many realize and gave them the courage to start the journey towards betterment. Her words will probably save many from developing an eating disorder by breaking the myth of our "ideal" world.
Also Read: 'And his fans have the nerve to say Taylor Swift is a capitalist?': $120M Rich Harry Styles Slammed for Milking Money Out of Suing Online Sellers Selling Fake Merchandise
Source: Page Six
# Lady Gaga# Taylor Swift
Sampurna Banerjee is an ardent pop-culture enthusiast. Thus, working as a writer for Animated Times and have written over 100 articles. The latest tidbits about the entertainment industry never go past her eyes. She also shared her insights with multiple popular Instagram pages before joining Animated Times. She is currently pursuing a Bachelor's degree in Computer Science.
Previous Post "I don't know if I was a good actress": Baywatch Fame Pamela Anderson Admits Her B**bs Made Her Career – "I was just part of the package"
Next Post "Suddenly all these headlines pop up… All of this attention on my book": Kelly Ripa Roasted Kathie Lee Gifford, Said Her Insults Helped Her Sales, Made Her Millions

redpajama_set_name: RedPajamaCommonCrawl


text:
package com.communote.server.model.user.security;

/**
 *
 *
 * @author Communote GmbH - http://www.communote.com/
 */
public abstract class AuthenticationFailedStatus implements java.io.Serializable {
    /**
     * Constructs new instances of
     * {@link com.communote.server.model.user.security.AuthenticationFailedStatus}.
     */
    public static final class Factory {
        /**
         * Constructs a new instance of
         * {@link com.communote.server.model.user.security.AuthenticationFailedStatus}.
         */
        public static com.communote.server.model.user.security.AuthenticationFailedStatus newInstance() {
            return new com.communote.server.model.user.security.AuthenticationFailedStatusImpl();
        }

        /**
         * Constructs a new instance of
         * {@link com.communote.server.model.user.security.AuthenticationFailedStatus}, taking all
         * required and/or read-only properties as arguments.
         */
        public static com.communote.server.model.user.security.AuthenticationFailedStatus newInstance(
                int failedAuthCounter, com.communote.server.model.security.ChannelType channelType) {
            final com.communote.server.model.user.security.AuthenticationFailedStatus entity = new com.communote.server.model.user.security.AuthenticationFailedStatusImpl();
            entity.setFailedAuthCounter(failedAuthCounter);
            entity.setChannelType(channelType);
            return entity;
        }

        /**
         * Constructs a new instance of
         * {@link com.communote.server.model.user.security.AuthenticationFailedStatus}, taking all
         * possible properties (except the identifier(s))as arguments.
         */
        public static com.communote.server.model.user.security.AuthenticationFailedStatus newInstance(
                java.sql.Timestamp lockedTimeout, int failedAuthCounter,
                com.communote.server.model.security.ChannelType channelType) {
            final com.communote.server.model.user.security.AuthenticationFailedStatus entity = new com.communote.server.model.user.security.AuthenticationFailedStatusImpl();
            entity.setLockedTimeout(lockedTimeout);
            entity.setFailedAuthCounter(failedAuthCounter);
            entity.setChannelType(channelType);
            return entity;
        }
    }

    /**
     * The serial version UID of this class. Needed for serialization.
     */
    private static final long serialVersionUID = 5011969570906014980L;

    private java.sql.Timestamp lockedTimeout;

    private int failedAuthCounter;

    private com.communote.server.model.security.ChannelType channelType;

    private Long id;

    /**
     * Builds a string showing the current attribute values
     */

    public String attributesToString() {
        StringBuilder sb = new StringBuilder();

        sb.append("class='");
        sb.append(this.getClass().getName());
        sb.append("', ");

        sb.append("lockedTimeout='");
        sb.append(lockedTimeout);
        sb.append("', ");

        sb.append("failedAuthCounter='");
        sb.append(failedAuthCounter);
        sb.append("', ");

        sb.append("channelType='");
        sb.append(channelType);
        sb.append("', ");

        sb.append("id='");
        sb.append(id);
        sb.append("', ");

        return sb.toString();
    }

    /**
     * Returns true if the argument is an AuthenticationFailedStatus instance and all
     * identifiers for this entity equal the identifiers of the argument entity. Returns
     * false otherwise.
     */
    public boolean equals(Object object) {
        if (this == object) {
            return true;
        }
        if (!(object instanceof AuthenticationFailedStatus)) {
            return false;
        }
        final AuthenticationFailedStatus that = (AuthenticationFailedStatus) object;
        if (this.id == null || that.getId() == null || !this.id.equals(that.getId())) {
            return false;
        }
        return true;
    }

    /**
     *

     * type of channel
     *

     */
    public com.communote.server.model.security.ChannelType getChannelType() {
        return this.channelType;
    }

    /**
     *

     * counter of failed auth attemps
     *

     */
    public int getFailedAuthCounter() {
        return this.failedAuthCounter;
    }

    /**
     *
     */
    public Long getId() {
        return this.id;
    }

    /**
     *

     * time of locking a user account for a specific channel
     *

     */
    public java.sql.Timestamp getLockedTimeout() {
        return this.lockedTimeout;
    }

    /**
     * Returns a hash code based on this entity's identifiers.
     */
    public int hashCode() {
        int hashCode = 0;
        hashCode = 29 * hashCode + (id == null ? 0 : id.hashCode());

        return hashCode;
    }

    public void setChannelType(com.communote.server.model.security.ChannelType channelType) {
        this.channelType = channelType;
    }

    public void setFailedAuthCounter(int failedAuthCounter) {
        this.failedAuthCounter = failedAuthCounter;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public void setLockedTimeout(java.sql.Timestamp lockedTimeout) {
        this.lockedTimeout = lockedTimeout;
    }
}

redpajama_set_name: RedPajamaGithub


text:
TV ReviewsHow To Get Away With MurderSeason 4
How To Get Away With Murder's midseason finale features its most graphic scene ever
Kayla Kumari Upadhyaya
Filed to: RecapFiled to: Recap
liza weil
TV ReviewsAll of our TV reviews in one convenient place.
How To Get Away With Murder dedicates its midseason finale to Laurel and company's ill-devised plan to bring down her father and Antares. In typical How To Get Away With Murder fashion, it unspools the story in a nonlinear fashion, starting with a big tease and then jumping back 24 hours and then repeatedly jumping back in time every so often to show what the various characters are all up to in the same moments. How To Get Away With Murder doesn't always understand that there is a law of diminishing returns when it comes to shock value. Between the tease at the top of the episode and the disjointed temporality, the show works overtime for the shock factor. How To Get Away With Murder doesn't foreshadow so much as drop bombs and then jump back to show, in tedious detail, how the bomb was made. "Live. Live. Live." is a chaotic mess that goes from a failed heist to a horror show in the blink of an eye.
How To Get Away With MurderSeason 4
"Live. Live. Live."
The failed heist aspect is actually pretty well done, especially considering how wobbly the build up has been. By the time of the actual party, Laurel, Michaela, Oliver, Asher, Frank, and Connor all have pretty clear roles to play, and their motivations are varied but convincing. All season, I've been thinking that Laurel's plan is reckless and poorly thought out, and thankfully the finale doesn't pretend it's not. Asher and Michaela's initial attempts to get Tegan's keycard comically fail. Asher and Laurel hastily change the plan in the middle of it, which has deadly consequences. The plan is doomed from the start. Oliver increasingly becomes a reluctant participant, empathetic for Simon, who also confesses his love for Oliver in a troubling twist.
The fact that it's Simon's body on the floor isn't exactly surprising. It was always their plan to make him the sacrificial lamb and even though they didn't think that meant actually killing him, their plan to frame him as a whistleblower always seemed far-flung. The hasty character development of Simon has been frustrating. His undocumented status and his questioning of his sexuality become last-minute efforts by the writers to make him a more sympathetic character, to manipulate viewers into caring about his death. Those details never surfaced in previous seasons, and the fact that they do now, just before Simon becomes the show's sacrificial lamb, is transparent manipulation rather than genuine character development. And having a character come out as queer and then immediately die plays into harmful tropes.
And that's a big reason why so many of How To Get Away With Murder's biggest shockers are hollow shells that fizzle out quickly after their initial impact. They shock just to shock rather than engaging with the emotional fabric of the narrative or compelling character work. There isn't suspense in "Live. Live. Live." so much as just a blanket sense of destruction and dysfunction.
There are a few interludes that aren't a part of the Antares party from hell, like Bonnie going to Annalise to tell her that she loves her and that she now sees that every bad thing they've ever done to and with and for each other has been because of love. This season has leaned into Bonnie's obsessive love of Annalise. Bonnie and Annalise's arc—and the contextualization of their co-dependent behavior that this season has provided through flashbacks—has been one of the more captivating parts of the season. Bonnie and Nate bonding over being addicted to Annalise is interesting in theory, but Nate has been so flattened that he is far from a compelling character.
Toxic co-dependent relationships are a huge part of this show. Annalise's interactions with Isaac here show that she can't even have a healthy patient-therapist relationship. The way they argue about whether or not they can still see each other sounds an awful lot like a fight between a troubled couple. Isaac's purpose on this show is still hazy, but Annalise insisting that they're bound together does touch on her tendency to form unhealthy relationships.
Then, in its final act, How To Get Away With Murder turns into a haunting theater of horror, outdoing itself with just how dark it can go. Laurel's elevator scene is one of the most disturbing things I've ever seen on network television. The rest of the episode has such dizzyingly fast pacing and then hits the brakes on this moment, dragging it out in a way that expresses her agony, her slow sink into complete and total despair. Even the music is more terrifying than usual. A single drop of blood becomes a splattered pool of it. Everything about the scene signifies tragedy and violence. The fact that it was potentially Frank's accidental blow to Laurel's stomach when she was trying to get him off of Connor that could have caused this unnervingly suggests that Connor was right, that Frank continues to put the people around him at risk.
As the mid-episode content warning suggests, it gets so much worse. Laurel's bloodied, lifeless, premature baby is seen on-screen. By the time Annalise pries the elevator door open, Laurel's unresponsive. Guided over the phone, Annalise has to cut the umbilical cord and perform CPR on the tiny baby that looks so disturbingly real. It's so gratuitously grotesque that it's hard to even fully absorb Viola Davis' performance, which is, of course, brilliant. Davis' acting prowess is the most consistent part of this show. Both Davis and Karla Souza make the horror of it all feel very real. The episode's final act is demented to the point where it feels like the show is trying so hard to shock, to one-up itself in the gory twist department. "Live. Live. Live." goes from frantic to grueling. The elevator scene starts out as a moving, immersive scene but then quickly becomes far too much. And by doing too much, How To Get Away With Murder accomplishes very little.
Stray observations
I suppose there could be a possibility that Simon is miraculously saved in surgery?
Oliver is the only one of this gang who has never seen a dead body before.
Aja Naomi King and Karla Souza are both having fantastic seasons.
No one should let Laurel hatch plans anymore. She's very bad at it.
The elusive Dominic appears again, this time eavesdropping on Connor.
On that note, I'm worried about Connor!
How To Get Away With Murder returns on January 18, 2018, along with the rest of the TGIT lineup. I'll be spending this break thinking about how Laurel and Michaela should be endgame and avoiding my friends in law school who love to explain to me how unrealistic this show is.
Recent from Kayla Kumari Upadhyaya
Angelica Ross injects life into an emotional but disorienting Pose
Angel and Lil Papi's love story shines in an uneven but important Pose


Students use creative tools in the Seesaw app or website to complete classroom activities like "Day and Night by MC…"
Yesterday you started to learn about MC Escher and the style of his art. You spent some time researching the techniques he uses in his art, as well as how they apply to change. Please use the drawing and text tool to do the following: 1. Type the title of the artwork and the artist. 2. Symmetry: Define what it is and find at least two examples . Please use the drawing and text tools to label them. 3. Tessellations: Define what it is and find at least two examples. Please use the drawing and text tools to label them. 4. Using the microphone or caption button, please explain how these relate to change. 5. Share at least one other thing that you notice about Day and Night.


Start spreading this news: the Longhorns are headed to New York.
Forget Hamilton, skip "The MET." Coach Shaka Smart's club is headed to Madison Square Garden next week in search of two wins to cap a roller-coaster season on a serious high.
Thanks to a huge first-half outburst, Texas rolled up a 25-point lead and cruised to a 68-55 win over Colorado in the NIT quarterfinals on Wednesday at the Erwin Center.
Senior Dylan Osetkowski had 15 points on 7-of-10 shooting, sophomore Matt Coleman III had 14 points and sophomore Jericho Sims had 10 rebounds. Everybody played a role in the huge win before an announced crowd of 3,982 fans as Frank Sinatra's famous tune was played on the arena speakers.
Texas hasn't been in the NIT since 1986, but the school won this tournament in 1978. Now, the Longhorns have a chance to extract some revenge over a Big 12 foe and possibly win a postseason tournament, giving them a huge lift into the offseason.
Texas (19-16) will meet TCU (23-13) in the NIT semifinals on Tuesday at Madison Square Garden. Wichita State (22-14) will meet the winner of the Lipscomb-North Carolina State matchup in the other semifinal.
The NIT championship game is scheduled for Thursday, April 4.
Of all those wearing burnt orange, the best player this postseason has been Osetkowski. Who knows if these are the last competitive games of his basketball career, but he's sure playing like they are. He had 18 points against Kansas in the Big 12 tournament and then 26 in the NIT opener against South Dakota State. He cooled off with only five points against Xavier but had 13 in the first half against Colorado. Osetkowski's 3-pointer from the left corner to give Texas a 37-15 lead in the first half was a straight heat-check.
It was a two-point game with 11:42 left before halftime. Then, Kerwin Roach II hit a long jumper. After two misses, Osetkowski shook off his defender and scored on a nifty reverse layup. Courtney Ramey followed with a 3-pointer, and suddenly the Horns put the hammer down. Freshman Gerald Liddell hit his first 3-pointer of the season, followed by a Roach 3-pointer and then a Coleman trey from the left corner. Texas went on a sizzling 23-2 run and had a 25-point lead by halftime, it's second-biggest lead of the season.
That must've been some halftime pep talk. Texas wilted when the second half began, starting the period 0-for-6 shooting and fouling practically everyone in sight. The Horns committed five fouls before the first media timeout with 16:22 left in the game. Smart looked at his bench and pointed at one, two, three, four, five players and sent in wholesale substitutions. Eli Mitrou-Long finally got a runner to fall with 14:54 remaining and ended UT's 0-for-6 start. Still, the Horns led 46-23.
Coaches love to talk about how resilient college athletes are, and for the most part, they are correct. But Colorado came into Wednesday night having played 35 games this season while traipsing all around the Pac-12. The Buffs played Monday night to win a second-round matchup and then traveled to Austin. NBA teams can handle that kind of rigorous schedule. College teams not so much.
Colorado was 7-for-24 shooting in the first half and 1-for-4 from 3-point range. Big man Evan Battey had two fouls in less than two minutes and had to go sit down. The Horns shot 50 percent in the first half and had a plus-6 edge on the glass.
Typically, postseason tournaments are a chance to play teams you haven't seen all year. Not this time. Texas will go all the way to New York and face TCU, the same team that beat UT twice during the regular season in Big 12 play. TCU won 65-61 in Fort Worth and on Jan. 23 and 69-59 on March 9 in Austin. Longhorns get beat a third time, their season is over.


Most attacks against printers are enabled because there is no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Potentially harmful commands can be executed by anyone who has the right to print. Thus there is no silver bullet to counter such design-immanent flaws. There are however various short- and long-term recommendations, best practices and workarounds to mitigate the risks.
Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers, and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented PJL extensions, service codes and further proprietary features. In general there is a lot of security by obscurity in the printing industry. Reverse engineering however is not black magic anymore. Vendors need to accept that – sooner or later – someone will discover their 'hidden functions' and should instead focus on open, well-studied standards to improve printer security. When it comes to firmware updates and software packages, digital signatures are often advocated as the single countermeasure. If used correctly, only files originating from the entity in possession of the private key can be installed on the device.
Code signing however also means technically restricting users to run vendor software . Certainly there are legitimate reasons to execute custom code on a printer. An example has been given by  who extended HP LaserJets to support load-balancing. The OpenWrt success story demonstrated how to improve the often limited functionality of embedded devices and there is no valid reason why printers should be excluded from the benefits of free software. Vendors should therefore take secure alternatives to code signing into account. For example the window of vulnerability can be limited to a local attacker if firmware updates required a confirmation key pressed on the printer's control panel. Further non-code signing based approaches like unique default passwords can be adapted from best practices in the world of home routers.
Most attacks are based on malicious print jobs. If the device supports authentication, it therefore should be configured to accept print jobs from authorized personnel only. Furthermore, if supported by the device, strong passwords should be set for PostScript startjob and system parameters, PJL disk lock and control panel lock as well as the embedded web server. Additionally, malicious PJL commands can be blocked using an IDS/IPS. Note however that such signature-based approaches are doomed to fail for PostScript which offers various code obfuscation techniques.
Employees should be trained to never leave the copy room unlocked and report suspicious printouts like HTTP headers to the administrator as they may be traces of a cross-site printing attack. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data.
This page was last modified on 24 March 2017, at 12:52.


text:
What Is Ultimate?
Job/Internship Opportunities
About the Pittsburgh Thunderbirds
History - Team Records - Staff
The Pittsburgh Thunderbirds is a professional Ultimate Frisbee (Disc) organization in the American Ultimate Disc League (AUDL). The team is part of the Atlantic Division and plays against the Atlanta Hustle, DC Breeze, Philadelphia Phoenix, Raleigh Flyers, and Tampa Bay Cannons. The AUDL's 12-game season commences in April and ends with the AUDL Championship in late August.
Our mission is to grow interest in Ultimate Disc in the Pittsburgh and Western Pennsylvania regions, develop an elite team of athletes, encourage participation in the sport through community involvement, and provide fans with high entertainment for an excellent value. We will work to improve visibility of the sport in the region and promote youth participation in recreational and competitive environments.
Our vision is for Pittsburgh to become nationally recognized in the Ultimate community. We want Ultimate Frisbee to become a staple in academic, recreational, and competitive environments for youth and adolescents. The Thunderbirds will become a regionally recognized team by major media outlets and by Pittsburgh sports fans.
Pittsburgh is a hotbed for Ultimate. The city may be small by population, but it's big by passion. Here, success starts with introductory youth programs, rises with middle and high school development, climbs higher with championship college programs, and takes off with national-caliber club teams. This progressive system is a source of pride for the community and will help the Thunderbirds succeed at the professional level. The Thunderbirds aim to add to Pittsburgh's success stories and will work to improve each component of the Pittsburgh Ultimate community.
The Pittsburgh Thunderbirds will be playing AUDL home games at J.C. Stone Field, located in North Park.
Buy Tickets / 2021 Season
Buy Gear / Pittsburgh Thunderbirds
Team Records / Pittsburgh Thunderbirds
Pittsburgh Thunderbirds is a professional ultimate frisbee team in the AUDL Atlantic Division. We are entering our fourth season in 2018 representing the Steel City.