I'm a big fan of my gut. I trust my instincts and generally lean towards being a feeler more than being a thinker. In fact, I usually begin expressing myself with “I feel…” as opposed to “I think…” I'm pretty sure I've been doing that my whole life and only just began to notice it.
In Lean practice the is an axiom, “test your assumptions”. I love this and feel like it makes a ton of sense. I've learned over the years that it's good to test and validate your ideas, decisions, thoughts, etc. Even if you initially have a strong gut feeling that you're on the right track.
And, honestly, I'd bet most of the time your gut is right! Even so, there is a lot of value in testing your assumptions, regardless of what they are and how confident you feel. I used to be very proud of my gut, but now I see there is a lot to be said for stopping to think, even when you trust what your instincts are telling you.
There is serious value in thinking. Even for feelers.
First up, you'll be wrong more that you'd like and you'll have an opportunity to change your mind. You'll be able to adapt. And, hey, changing your mind in light of more information is cool!
Second, and probably even more important: you'll learn. Instinct is something that can be learned and honed over time. (Thank goodness.) And sure, you can develop it “naturally” through failure, but taking the time to think about and test your assumptions, as opposed to moving forward on instinct alone, will give you valuable information that failure alone will not.
Third, unless you're alone on deserted island somewhere, you'll likely be working and living with other people. Taking the time to work through your thinking (and feeling), will help you better engage with others. At the same time, you'll better be able to defend your decisions.
Fourth, let's face it, you can't rely on instinct alone to help you call yourself on your own bullshit. Our instinct often feels right even when it's not on target. Have you ever come across something that doesn't sound right, only to learn later that it's totally legit? Turns out that's a natural feeling; we tend to reject things we don't understand. The way around that behavior is to acknowledge, think and move on.
And, lastly, it's awesome to see your gut feelings validated. Sometimes, while basking in the light of perceived success, we're not sure why we were successful. Taking the time to question, analyze and test our intuition can help us better understand how our gut got us there, and that just feels good.
So, next time your tempted to go with a snap decision, stop for a bit, back up and think about it. Chances are you'll come to the same conclusion, but now you'll have a bunch of new leanings to work with.
I'm curious what you think. Do you trust your intuition? Or are you more of a critical, analytical thinker? Head on over to Branch to discuss.
A few days back my friend Cap wrote a great post about curiosity. In that post he postulated that curiosity is a must for (I assume) creative professionals, but, as I'm sure he'd agree, it applies to anyone.
In this I agree with him 100%. I had, coincidentally, been writing a similar post about Kickstarter and how much it inspires me. (And how much it drains my wallet.) My (as-of-yet not entirely formed) point was that we need things like Kickstarter to encourage and help those folks out there who are taking risks. By supporting ideas, even wacky ideas like some of what you'd see on Kickstarter, we allow for us to be inspired, educated and entertained, even if some of those endeavors don't come out the other end as planned. As well, too many people are content with letting life pass them by. Those of us working in tech often forget that we're not representative of the masses when it comes to taking risks and being curious.
But, back to Cap's post. He concludes with the following:
It’s not a nice-to-have. It’s not optional. It’s required. Put it on your job postings, make it part of your interview loops, embrace it as part of your companies' cultures. When you’re surrounded by driven and creative people with a constant thirst for knowledge, you’ll be glad you did. And when you’re surrounded by apathy, you’ll be sorry that you didn’t.
Apathy. Such a horrible word. Say it out loud and try not to cringe. Apathy… eww.
It's the worst possible emotion I can think of. Anything we can do to root apathy out of our lives is a good thing. But I think the real value healthy curiosity brings relates to learning. There are many things that go into learning: focus, motivation, discipline, but I see curiosity as a big, big part of what drives continual and lifelong learning.
If you've followed my writing at all, you'll probably have noticed that learning is a big theme for me. I see learning as something that makes everything about life more fun and interesting, but it also works as a key competitive advantage, for me, those I work with and within the context of what I do.
In thinking about Cap's post, I couldn't help but draw the connection between learning and curiosity.
Curiosity and learning: two sides of the same coin.
When I moved down to San Francisco a few years ago, I took a chance on a position as a lead game designer for a very small startup. I'd never designed a game, and knew very little about game design, but I was very curious. I mean, I'm a gamer, and while I didn't know much, game design has always been an interest.
I dove in began to learn all I could. I started experimenting with what I was learning and before I knew it had designed several games. One of those games, Shadelight, won a bit of critical acclaim and helped my small company get acquired. More importantly—for me anyway—it was totally fun, both the game and the experience of learning about game design. To top it off, it was played and enjoyed by tens of thousands of people before it was shut down about a year ago. Overall, in my mind, a great success.
If there is one thing I feel has contributed the most to the successes I have enjoyed over the years, it's that I've always been flexible enough to learn new things when needed. Hell, I taught myself to do what I do! I bet many of you can say the same.
As with curiosity, I feel the ability to learn new things is a must. And they go hand-in-hand. A big part of continual learning comes down to being curious about things and truly enjoying the act of learning.
Of course, it could be argued that having too much curiosity could be detrimental; trying to learn everything, for example, could shatter your focus and distract you from the important things.
So while curiosity can be a great motivator for learning, it needs to be tempered with focus and discipline. And that can be hard. In my role as a product designer, for example, there are so many things I can learn. I want to know how everything works, and I have a genuine interest in almost everything that relates to my role. And that doesn't even touch on my interests outside of work. I want to learn everything. Seriously, it's pretty rare that I'm not at all interested in something.
I've often wondered if narrowing my focus even more, and putting a bit of a lock down on my own curiosity, would help me in my career. I've wondered if it would allow me to get really good at one thing. But then I remember that I'm pretty good at a lot of things, and I am really good at one thing: learning. And I can thank curiosity for that.
I honestly feel like I could learn how to do almost anything, and I think the reason why is that I've proved it to myself over and over again. I'm also pretty much unafraid of learning new things. Sure, I might not be mastering those things, but being an accomplished learner, especially in today's ever-changing world, allows me to fairly often get decent at something new. That has to be worth quite a bit. And I think a curious mind is—if not a prerequisite—a solid part of that capacity for learning.
Of course, I think there are many other benefits to having having a solid dose of curiosity in your life. I also think it's something you can—and probably have to—work at. Digging into things, even things you're interested in, takes effort. That may be why some people aren't all that curious; it's hard work.
So, finally, to tack on to Cap's point: curiosity is your number one defense against apathy (and boredom!) but it's more than that, it's a very valuable skill that can help you learn anything you put your mind to. I suppose there might be such a thing as too much curiosity, but, hell, the way I look at it, there's always retirement and knowing how to learn will probably help in the pursuit of that bestselling novel. :)
What do you think? Is curiosity a valuable skill? Or, is it a costly distraction to focus? What are some ways you keep your curious mind active and learning? I've started a Branch to talk about this post, head over here to check it out.
I'm not a huge fan of personas, at least not in the traditional UX sense. They're kind of a “fuzzy” deliverable that often ends up taking more time than they're worth and, if taken too seriously, can become a pretty poor stand-in for your actual customers.
Personas aren't all bad though; I like to think of them as the coffee table book of UX design deliverables, and that makes them a least a bit interesting. They're great for getting a conversation going—for setting a user-centric tone and keeping customers front of mind—especially among a group of diversely skilled people.
Regardless of my own personal bias, almost every team I've been on in has used them in some way or another. Some take them very seriously and others use them as a starting point to frame a discussion around customers, which is my preferred way. Probably because of that bias, I've got some ideas of how to make the most out of them. Here they are:
Involve everyone in their creation. This way you can quickly identify and work out misconceptions and biases about who your customers are. This is a great way to do personas. I think this is also a good general rule to follow with any kind of user research.
Do them quick and dirty. The “meat” of customer research lies in actually talking to customers. Personas can be a great way to communicate and conceptualize your findings, but spend most of your time listening to customers.
A company isn't the same as a customer. That should be obvious, but it's actually pretty easy to co-mingle customer (user) traits with company traits. Of course, they can be related and you can build personas for both, but be sure you know which is which as they are different.
Avoid getting caught up in semantic debates around the details. Details are important, but don't go overboard. You'll want them to be an accurate representation of your customers and their goals and behaviors, but don't get bogged down by semantic disagreements. Along those lines….
Don't use real people as personas. While they should be an accurate representation of your customer, you should keep them somewhat general. Putting too much reality into your personas can make them inflexible and skew your discussions.
Finally, if there is one bit of advice I could give regarding personas it'd be this: Don't obsess over your personas. Obsesses over your customers.
(If you're not familiar with personas, and want to get a good overview, I'm kind of a fan of Luxr's method and they've got a good cheat sheet here.)
I'm a big fan of lists. I've got lists everywhere: multiple to-do lists in multiple formats, item lists, shopping lists, people lists, goal lists, etc. One of my lists, and a favorite trick I use to remain focused, is to keep what I call the don't do list.
The don't do list is a list of things I'm not doing, or things I was doing and have eliminated from my to-do lists. It might seem silly, but the act of going through your projects and to-do lists and moving them to a don't do list helps you prioritize and focus on the important things you should be doing. It also helps to shed light and add clarity to your process and workload. It's pretty amazing to see all the things you could be doing but aren't.
Keeping a don't list is pretty straight forward. For me, I just have a big list in Evernote for when I record those things I've killed or said no to.
I do have a few rules:
It's only things that I've either rejected or killed. Never anything I've finished. Those stay on my to-do lists in a completed state, which is another little trick I find helps keep me motivated and productive.
It's not a back-burner. I try to only put things there that I never, ever plan on doing or working on again. Of course, this rule can be broken, but the goal is to try and keep it to things you've quit or said “no” to.
It's just a list, I don't keep artifacts or reference items here. Those I move into an archive. I'm a bit of an information horder, I keep everything, but I like to keep reference items, deliverables, etc. away from my lists.
I review it every once in awhile, just to give myself some perspective. This is great when I'm feeling stressed or overwhelmed.
Of course, the prerequisite here is learning how to say no to things, and when to sunset a project. (Or, something I've been working at recently, keeping those zombie projects dead and gone for good.) I work really hard at those things and I still struggle with them; even though I know how important it is. I'm a do-er and I like to think of myself as a finisher. “No” and “I quit” are often really hard for me to say, even when there is overwhelming evidence telling me to do so. The don't do list helps me make those decisions.
Bottom-line: Amazingly enough, keeping a list of things you don't do can really help you focus on the things you do need to do.
Just the other day I was talking to one of my fellow Desk.com co-workers about our product and I mentioned that I thought we needed to be vigilant in maintaining our product's opinion.
As you may imagine, a product like Desk.com has some significant challenges when it comes to meeting and exceeding the expectations of our user base. While we do have a few key customer types we design for, there is a great variety within those customer types as far as how they work, the kinds of customers they service and the needs they have for our product.
Desk.com is very flexible in some ways and while we've got a professional services team that—with a bit of magic and hackery—can bend and shape the product to suit some of our more demanding customers, one of our goals is to keep things consistant and maintaining a core product that is opinionated.
Products with a strong vision, that put forth a “right way” of doing things, are better products. Just ask Apple. Or 37signals. Or go and look at your favorite products, chances are they're doing something that just kind of fits for you, but might not fit for everyone.
In my opinion opinionated products are also easier to use—even if they may require a bit more upfront investment. When making product and feature decisions you're constantly having to choose between keeping things consistent and designing for a particular context or user behavior. My general rule is to do what is right for the core user, and this often means sacrificing some consistency to make sure something works well in a particular context, for example.
What it doesn't mean is designing for edge cases and/or building features to address very particular use cases. There are times when you'll have to do just that, and usually you can, with smart design thinking, do so without watering down your product for everyone else, but these times should be few and far between and treated with caution.
So, can it be done? Can you build an opinionated product that works for a wide, diverse range of people? I think you can.
How do we do it? Well, primarily, we put a lot of effort into understanding our customers as a whole.
I've been fond of saying that my job is often similar to being a lawyer. I do a bunch of research, gather my argument and then present it to a jury. In my case the jury is made up of co-workers from various areas of my company, all of which have their own biases and opinions on how our product should be designed. It's my job to take the relevant information from everyone involved, mix that up with what I know about our customers as a whole, and turn that into design decisions that do the right, best thing for most of our customers.
(Having said all of that, I'll be honest, it's an always and constant negotiation. There are so many people involved and so many moving parts that there are times when there is no option but to compromise. And that's ok, as long as you know that going in and you do your best to do what's best.)
Look for patterns.
We're constantly looking for patterns in how people use our product. As well, our customers have to accept a certain amount of “my way or the highway” when it comes to using our products. Thing is: they'd probably expect that even if we tried to be everything to everyone, so we've got that working for us.
Embrace the learning curve.
Powerful software is often complex and can't always be made to be simple or easy. In fact, there is some danger in trying to remove friction. In our product, for example, we have complicated rules and macros. These things are often hard to grasp, and can be overwhelming at the best of times, but it's because they're really powerful and very useful. When educating our users on their use, we have to be careful not to dumb them down to much, or make too many decisions for them.
We want to make them easy to understand, and showcase how they can help, while at the same time give our customers the tools they need to get the most out of them. We want to make that complexity digestible.
Discoverability—making users aware of features, while not forcing them—and education can help you maintain a strong, opinionated product that services users of many skill levels.
Test your assumptions. Be all right with being wrong.
There are often times when a clear solution just doesn't present itself. You can have a bunch of great data, which might lead to a variety of solid solutions—and still not be sure what to do. This is why you test.
It's fine to take a stab at solution, get it infront of people, and see how it plays. In fact, this is probably the best way to decide between conflicting or—sometimes harder to deal with—similar solutions. Prototype something, get it in front of people, look for patterns, iterate and, eventually, release to everyone.
Which brings be to my last bit: allowing yourself to make mistakes. It is impossible to be right all the time and even if you're somehow good, or luckily enough to be right some of the time, it's really hard to be right the first time.
Even very informed design decisions can be wrong, and sometimes I take that as a sign that we're on the right track. Be ok with making mistakes, fix your problems, learn from them, get better and improve your product along the way.
If we were constantly “right” with our product decisions, my guess is we'd be just clearing a fairly low bar, and that's not how you make great products.
This fall, Square will begin processing all credit and debit card transactions at Starbucks stores in the United States and eventually customers will be able to order a grande vanilla latte and charge it to their credit cards simply by saying their names.
This is big news and a clear indicator, to me anyway, that leading by design is the way to go.
I'm sure I'm not the only one to make this observation. If you've been following Square, you know they're a design-focused organization. Clearly they've got the chops there. But, if you're living in San Francisco and used their products you also may notice they've got the process down as well.
Before they hooked up with Starbucks, Square hooked up with a smaller, local shop: Sightglass. It was big news back in 2010 when Square launched their service there and since then they've had the perfect proving grounds for their product. If you do a Google search, you'll see that the Square/Sightglass connection has been a strong one over the last couple years.
Square has been working up to this for many months; researching, experimenting, testing and iterating on their products down at Sightglass. Honing it, getting feedback and making changes over time.
Clearly, it's now ready for prime-time and ready to be scaled up.
This is a great example of leading with design, doing experiments and research to uncover real problems, iterating on the product and starting the process over again.
Kudos to Square for showing us how it's done! I'd wish them luck, but my guess is they'll continue doing what they're doing and as such won't need it.
People occasionally ask why I write more about process than I do design.
The answer: great work comes down to execution.
Execution is first and foremost about people, process, discipline, focus and communication. It's less about ideas, feasibility, knowledge, skill or tools. Those things are important, but without the former, you'll have a hard time getting anything done with the latter.
As well, if you don't have ideas, knowledge, skill, etc. you'll need to work (practice) to gain those things. I believe that with enough hard (and smart) work you can learn just about anything.
Wouldn't it be cool to work on one project, or task, finish it completely, take a break and then move to another? Well, yeah, but it's not very realistic.
Even if you're focused on one larger project you've probably got numerous tasks within that one project that require you to regularly switch contexts. And don't forget all the day to day distractions you've got to contend with.
Context switching is difficult. (And don't get me started on “multi-tasking.”) The more often you have to do it, the less you're going to get done. That's a fact. :)
But it's not just about productivity. What kind of hits to your stress level are you taking if you're unable to focus? How much better would the quality of your work be if you weren't having to jump around so much?
I've been reading Thinking Fast and Slow by Daniel Kahneman and while it's much deeper in its analysis of how we think, it's got some really compelling evidence on how anxiety and stress effect how we think, AND how constant task switching and lack of focus effect our stress level.
There is a lot of convincing evidence out there that complicated tasks are done better, and faster, with deep, focused thought. You may think you're able to watch TV and code a web application at the same time, and maybe you could literally do that. But it's not a good idea as you'd do it faster, better, and likely with less overall anxiety, if you focused on that code.
But focus is hard to come by and we all have to switch between projects and tasks all the time, for a variety of reasons. I mean, it comes with the job—any job really. I don't think many would argue that when you eliminate distraction and focus, you'll get better work done faster.
So how can we make that transition easier? I'll tell you a few of my ideas. In a second.
But first: a story.
This past week I found out that my primary project—a project I was leading—was being, effectively, shut down. I had been on it for several months and had devoted most of my time and energy towards it. In fact, I'd worked on little else during the work day. So a pretty big shift for me.
(And, in case you're wondering, I was disappointed, but it comes with the territory, it wasn't the first time and I totally understood why that decision was made. It could have been worse. Haha. Anyway, moving on.)
So, with that project ending, I had to move on to a new project. I got with my team and we sorted out a plan to move forward. There was a bit of role shuffling and I was placed onto a new project. One that was already in motion.
I was handed a bunch of documents to review and told I'd be participating in a meeting about the project the next day. I cleared some time and sat down to review the docs. Figured, sort of stupidly, that I'd just dive in and everything would be fine.
My mind just sort of blocked. And I was really stressed. There was the disappointment of having so much work go to naught, but when I really thought about it, the stress came more from anxiety around the massive switch. Could I get caught up in time? Would I be able to learn what I needed to to succeed on this new project? Etc. I tried to ignore these questions and plow through, but it didn't really work well.
I was having a really hard time adjusting. I couldn't really grasp what the project was about at first, and asking questions was just making me more confused. I kept turning back to the stuff I thought I'd be working on and had spent so much time on. I was also having a horrible time focusing. I just could think about the new project.
I realized I wasn't going to be able to turn this one over quickly, so I stopped trying, which I was not keen on doing and took a bit of effort iteself , did some thinking and research and came up with a plan.
What follows are the action items I came up with, all of which sort of apply to any context/project switch, it's just a matter of scale:
Find a smaller “bridge” project. For me this was doing the actual planning for how I was going to make this switch. The goal was to help me get in the proper mindset for a new project. Oh, and this here blog post. :)
Take care of small, easy tasks. This is one I tend to use quite a bit, even on smaller things. If I'm in-between focus times or changing from one smaller project to another I'll tackle mundane tasks like lingering email, running errands, or, my favorite, cleaning. In this particular instance, I took care of some pretty major lingering tasks. I wanted to make sure I came in with a clear, undistracted mind-set.
Change your environment. This one is great for dealing with “fast” context switching. A good, simple example would be using Spaces on OSX to separate different functions of your job, but the same can be applied to larger projects. Work at your desk for one project and in the conference room for another. For a really big context switch you can think about rearranging your desktop, or adding a new plant, for example.
Take a break. Take a bit of time to yourself before jumping into something new. I took a long walk after I got “blocked” and that helped a lot. For small projects this can be a small amount of time, for larger, a few days would help a lot. (I could have used that!)
And a few that helped me specifically in this case with a more consuming switch:
Change your routine. Making a conscious effort to switch up my routine helped a whole lot. I have a lot of rituals and routines to help keep myself on track, focused, creative and productive. I has some that were specific to the previous project so I changed them. I switched my schedule around a bit, moved some standing meetings and made plans to start a few new daily rituals. Really helped put me in a good frame of mind for starting something new.
Clear your schedule. Context switching can be taxing in many ways. I find it's always best to start something new with a clear, open mind and one thing that has helped me numerous times is to reduce the amount of “stuff” I have going on. This means, for me anyway, setting aside some extra time for work, as well as some time to reset.
Archive or hold old projects. I moved all my old files, research, to-dos, etc. into active folders and pretty much as out of view as possible. This brought some closure and provided a clean, symbolic break.
In thinking about it, many of this could probably do well to help anyone though any change, not just the changes we encounter in our work. For me many of these are tried and true, and some of the more extreme stuff seemed to work wonders for getting me back on track. I know I'll try them again next time I'm off to a new project.
(Just a quick aside: I've worked on many product teams over the years and I think once of the primary reasons why a product's quality goes down hill is related to lack of focus and constant context switching. I'll talk about this in the future, but the gist is this: shifting back and forth between projects/features/etc., usually over long periods of time and with lengthy breaks, causes us to be in a constant state of having to re-learn something we've worked on, re-learn it quickly, make a overly quick decision (due to time constraint) and get back to what we were doing before. It's hard to build a quality product that way.)
Here's a fun way to look at running projects: like a tamalada, which is a tamale making party. :)
A couple weeks ago I went to a tamale making class, or, as our instructor “The Tamale Princess” called it, a tamalada. The tamalada is essentially a party where you hang out with people you love, drink wine, chit chat and make a bunch of tamales.
Sounds fun, right? It is!
But it's fun with a very clear purpose. The goal of the tamalada, historically, was to prepare food for soldiers out in the field. Clearly, that's an important job! Now-a-days the purpose of the tamalada is more about gathering friends and family together, to make a lot of delicious tamales for everyone. The product, in some ways, is the process.
But let's be clear. The tamale making process is work. And as I sat there, stuffing masa into my husk, I couldn't help think the tamalada was similar to a very well run product project.
You'll need a good host.
Every tamalada needs a host. This leader is in charge of assigning roles, making sure everything is going smoothly and, importantly, entertaining everyone and making sure they're having fun while at work. They're focused on coaching and helping and moving things along.
Oh and making everyone do a “princess wave” when they need help with something.
Everyone has clearly defined roles and purpose.
Each person needs a clear role. There are quite a few “jobs” to choose from; making the filling, preparing the husks, mixing the masa, gathering ingredients, pouring wine, playing music, assembling the tamales, etc.
The tamale making process needs to be organized. It's sort of like an assembly line where each person executes their role and then moves the tamale-in-progress along down the line.
You should be loving your work.
There is one additional thing that's clear when it comes to the tamalada: you're supposed to make your tamales with love. If you're at all familiar with tamales, for example, or if you've ever heard of The Tamale Lady here in San Francisco, you've probably heard the L word mentioned. Those who make tamales for a living often work it into their marketing materials and I think there is something to that. Making something with love can be fairly simple, but, unfortunately most of our projects aren't set up like the tamalada.
We've all worked on projects that we don't love. Sometimes (often) even work you love is hard. Making tamales isn't exactly hard, but it's not super exciting either. Without the love—the conversation, purpose and camaraderie—it'd be fairly boring and torturous. The reason why people love making tamales and can make those delicious tamales with love is that the process itself is specifically set up to enable that love.
Why not?
I think more projects should be run like the tamalada. It has a leader, a clear vision and purpose, it's organized, encourages care and focus, everyone has a clear role and direction, it's done with (and for) people you enjoy and, maybe most importantly, it's fun. All of that facilitates putting care, hard work, and love into your work.
Which, IMHO, makes for a much more delicious tamale. And a much more enjoyable working experience.
A few more quick hits about why I think this is a nice, fun approach that could work:
It's about people.
It's lightweight and flexible.
Leadership is focused on coaching, cheerleading and helping.
Promotes cross-functional involvement.
It's fun.
Focused on a clear purpose.
Allows for asking for help without judgement.
Seems smart to me. Next time I find myself running a project I'm going to think about the tamalada and how much fun I had stuffing corn husks full of masa.
There is one particular passage from Evan Williams responding to Jason Goldman that really caught my eye. Goldman is talking about how you need to build something that delights you and that before you have users, you—and your team—are the user.
I've been thinking about this a lot over the last few weeks or so, as I've been immersed in the “Fail Fast” ideas of Lean. On thing that really didn't work for me was the idea that you can just throw any old thing out there and learn from it.
A few months ago I heard this great interview with Ryan Singer where he talks about designers looking at and thinking critically a design before they build/show/ship it. I really agree with this. There are times when a designer can critically look at their own work (or ideas) and realize they're not ready. Or no good. In a way you can fail quicker by evaluating your own work.
But the point I'm trying to make here is that you can learn more from something you've taken the time to work through than you can from something you just throw out there. Give your idea a chance and make sure what you're testing is good enough to bring back valuable learning.
Sure there's a breaking point where you see diminishing returns, and knowing where that point is; that's the trick, isn't it?
Anyway, here's the passage:
@goldman - That's really well put. If it's something you would use even if you didn't have to, launch it.
I generally agree with the other points, as well. Good to push yourself to launch sooner than you're ready. With a couple caveats…
The bar has been raised in general in the industry. There is more and better competition for every bit of attention in every segment. As a result, users have less tolerance for lack of polish than we used to be able to get away with. They're more likely to just move on if something is janky. This may be extra true in mobile apps (much harder to get people to try something a second time—but not impossible).
I worry about the mantra of “fail fast.” I think there's too much churn through ideas by entrepreneurs who are just looking for a hit instead of following a vision or trying to solve an important problem they're passionate about. It's good to fail fast on approaches or implementation but solving hard problems and creating really revolutionary things takes a long time, and they're usually rejected by the market at first.
