AT THIS POINT, WE’VE established the value of Calm Technology in an abstract sense, but making the case for incorporating it into a specific project or embedding it in an organization is another task entirely. To begin with, it’s worth asking why Calm Technology is valuable as an organizational principle.
Why do you need Calm Technology in your organization? Most directly, it’s a powerful organizing idea that can provide clear goals for setting limitations and reduce the risk of overdesigning the end product. This ultimately reduces costs for assembly, support, and use.
You might think you’re saving money by getting to market as quickly as possible, without spending a ton of effort calming down your user experience, but think of the longer-term outcome. A less calm, fussier interface means more confused users, more calls to tech support, and more need for patches and updates down the line. Design for calmness now and you’ll save money later, when it really counts.
Calm Tech is best worked on using lean principles, which means, more than anything, reducing the number of stakeholders involved in a project. Teams with fewer stakeholders get things done faster, are more likely to take risks, and have the ability to make mistakes without fear of career failure or retribution from colleagues or higher-ups.
You can reduce stakeholder numbers in several ways. One tactic that’s proven surprisingly effective is to set low expectations for the project, which tends to discourage executives from getting involved. As the project comes to a close, you can then invite stakeholders to join in, allowing them to share in the credit without feeling the need to provide input just for input’s sake.
Key stakeholders, on the other hand, should be sold on the principle of Calm Technology as much as possible, allowing the team something to fall back on when the inevitable request for additional features arises. Find someone on the client side or in your organization who has a knack for advocating, and task them with winning over individuals who could potentially shut you down. Managers who are in a position to become jealous of the project should be involved as much as possible early on, as a way of preventing them from hijacking it further down the line.
It’s crucial to remember that, no matter how promising the program, it only takes one person at the managerial level to start or stop it. This isn’t usually a sign of malice or incompetence, either—most often, it’s because they want to build something and feel important, too.
Why five? Teams larger than five are prone to run into communication difficulties and operational constraints. There’s an overhead associated with conducting communication among multiple members, and each additional person on a team increases it. Ultimately, too many people on a team fosters a slow, meeting-oriented culture with less autonomy. Until you scale the team up, a team of fewer than five can do a lot. In many cases, even two competent, self-directed people are plenty to get a project started.
What if you have a project so large that it needs more than five people just to get the work done? Split the team up into smaller working groups and be forthcoming on what each one of them needs to do on the project. Make sure there are people who love to communicate on each team, and have them blog or write internally about what each team is doing, so that everyone stays in the loop.
What if you can’t get a team down to five because of “internal stakeholders”? Sometimes you might get into a difficult spot where managers and stakeholders get involved in your project. Often this takes the form of a boss telling you that “we know you want to have a lean team focused on this feature set, but we need you to have these people involved in the process.”
This is a tough issue. With many stakeholders needing buyoff on a project, it may be difficult to get anything done. It’s difficult to get the people you need on your team to do work without the expectations of fitting into the existing structure. One way to help is to beta test your people.
Think of your project team like a band. Bands need to practice before their first big show, and so do you.
Do a small test project first to see how the team works together. Even an hour-long exercise of designing a new toy or a product for fun will expose your team to the experience of creating something within a time limit, and will give you some inkling of what conflicts might exist among them. It also helps the team learn how to work with one another, and gives you the chance to address friction points before they turn into inescapable political roadblocks. You can then work on any conflicts and reduce them together, or minimize interaction between incendiary people on a team.
Start by asking your team members what they’re interested in doing and how they might contribute to the project, and then launch into the test project. Sometimes anxiety is produced by projects that are too big where there’s too much at stake, and sometimes people want to be part of project teams without actually putting in the work, for reasons of political safety. Employees can be concerned for their reputation if the product fails, so they might be hesitant to work on a product in any other way than what they’re used to, or to implement new features that are foreign to them. In these cases, it is important to carve out a sense of creative safety on the team. Create a place where people can explore ideas that differ from those they’re used to, without fear of managerial reprisal.
A team should have diverse perspectives, or else you’re missing an opportunity to spot better solutions. You want to make a team that respects the differences and allows for everyone to be at their best.
You need people. You also need people who will call your bluff when you try to make something that’s only usable by those who make a six-figure salary. You need people who live in messier or cleaner environments than you, and people from countries and ethnic backgrounds different from yours.
Additionally, you might find someone at your company who understands the industry but does not know how to speak the language of stakeholders. Find someone else to translate it for the stakeholders, or be the translator yourself.
Regardless of who they are and where they come from, take what your team members have to say very seriously, especially if they’re passionate about it. If upper-level management can’t handle honest feedback, then work as a translator so material is presented in a way that is more “managerial and safe.” Setting low expectations for the product, as discussed earlier, makes this job easier—translation’s not so hard when the reputations of managers aren’t on the line.
Organizational politics are often tedious and get in the way of teams doing their best work, but they’re a reality in even the most effective organizations. Find a supporter for your project who can act as a political buffer so you can get your work done. Either add them to your team so that they share the load, or meet with them frequently. This small investment of effort and time will free up you and your team to actually get things done. If you’re in a traditional organization, consider having someone write weekly reports to managers.
Often you might be tempted to write reports that contain only positive outcomes, but in reality, managers need to know the negative as well. If you don’t tell management anything, their minds will likely wander into a negative and paranoid zone that can be far worse than the reality you’re trying to sugarcoat. Instead, show slow, measured growth over time—they’ll sleep easier knowing you’re on your way to achieving your goals. And that weekly report is ammo for them to bring to the board, to keep the project going if it comes to that.
Weekly update reports are also a good way to ask managers for help. It’s all about making it easier for your managers to work. If you tell them what is bad, it’s not a surprise. Make sure they find out before their supervisors do.
Privacy is one of the most important considerations today and will become increasingly important in the future. As we transition from the industrial society to the information society, we’ll see more and more examples where people’s real lives are affected by privacy and security breaches. As I’m writing this book, the Ashley Madison hack is still front-page news, raising the specter of privacy violations seriously impacting people’s lives on a grand scale.
Practice privacy by design versus privacy by disaster. Privacy considerations should be incorporated into every aspect of an app’s lifecycle, as well as your product’s web presence, legal agreements, user experience, messaging, and development.
It’s no longer about whether your site or product will be attacked or not. It’s a matter of when. Large or small, your product or service will be messed with at some point in time. Get used to it! This is the future, and the future comes with bugs, viruses, and hacking attacks. Act now or be forced to act later. Don’t be afraid, be prepared! The consequences will be greater if you aren’t. Be careful out there. It’s going to get even hairier as more and more devices become a part of our lives. Keep abreast of the current industry and its regulations. Fight for your users and they will fight for you.
The following guidelines can help you to design a product with privacy and security in mind.
Great privacy user experience means that your users will understand the privacy policy you created when they start to use your app. A well-built app will let users know what they’re opting into when they use your software.
Though your app or product might require access to a person’s photos, locations, and contacts, they’ll likely not want to share this information every time they interact with the product. Allow them to turn sharing on or off at the point of interaction or content creation.
Present privacy controls at the point of content creation. Display these controls for every piece of content that can be created or shared in a given system. Instagram does this reasonably well, as users can choose whether to place a photo on a map when they create a piece of content. You should follow these guidelines:
Empower your users.
Offer on/off switches and simple settings.
Make it easy to access controls such as alert styles or tones and volume levels.
Don’t hide it all behind complex menus; create physical buttons when possible.
Think about it. Running an Internet-connected product or service isn’t the same as just providing a physical product to someone. You’re taking and caring for a piece of them at the same time. You’re not just hosting their data—you’re hosting them! It’s a big responsibility. Hosting user data is a privilege, not a right. Privacy policies are regret-management tools. Legislation being put in place will increasingly require these.
People need to be able to read your policy and understand what they can expect by using your product in under a minute. The best way to do this is to separate your privacy policy into two sections: plain English and legalese. Write the policy in English first, then get your lawyer to write it up more formally, as well as helping with the plain-text version. Post both on your site or include them with your product.
The most basic privacy policy should at the very least answer the following questions:
What data does your product or service collect, and why your product or service need to collect that data?
What will this user data be used for? Why should your users share it?
Where can your users go to permanently delete their accounts and ensure their data is removed from your servers?
Where can users go to download the data that’s been gathered by your product? Users need to be able to migrate if your service closes. It is your privilege to temporarily host user data. It’s their data, not yours. And as a provider of a product, you are in your user’s debt. Your users allow your company or product to exist, and they should be respected. Respect them, and they’ll respect you.
What precautions have you taken to ensure your users’ personal lives will not be affected if your company is hacked?
How do you notify users of updates to your privacy policy? Consider creating a practice of notifying users of any changes to the privacy policy at least 30 days before the new policies are put into place. Show abbreviated changes to the privacy policy and track them so that users can see the differences in the policies.
What are you doing to ensure transparency? Use transparency to build trust by telling people what their data will be used for.
This outline is a good start. And it will also bring up questions to your engineering team on how data is stored and protected to begin with.
Security breaches are organic manifestations, not mechanical ones. They come from two places: people looking for ways to take advantage of or get data and personal information out, or people simply playing with systems to see if they can work around them or break them. A lot of this is done unofficially, not by people with nine-to-five hours, but by people playing in their free time. The best thing to do is to get to know and respect these people. And hire them! Security is a difficult thing to get support for, even with all of the hacks that are currently going on, because investing the money doesn’t net returns. Most companies don’t allocate resources for attacks until they’ve happened. Then they spend a lot of money fixing hacked systems, when the hacks could have been prevented if security principles had been adopted in the early stages of product development.
The typical management response to Calm Technology, or any way of doing things that’s different from the norm, is skepticism. That’s fine—they’re just doing their jobs. It’s your job to get them past their skepticism and into a place of advocacy.
Most of this task lies in anticipating objections, and responding in a calm, reasoned, and sympathetic way. I’ve included a few of the most common objections here, and ways you might respond to them.
Why do some executives push for so many features to begin with? Often they see successful products that have been around for a long time, and have already proven themselves in the market.
What they’re seeing is a mature product. What they don’t see is the lower-featured, often-messy product that the company originally released, before it got big. Things always start small and grow; what we see later is the finished product. There’s nothing wrong with starting with the end in mind, but it’s important to recognize the steps along the way. In the same way that you don’t see all of the revisions of a painting at a gallery, you don’t see the revisions a successful product has gone through when you purchase it or read about it in the press.
In this case, management needs to be educated about the history of successful products and how they really grow: sustainable development, one or two main features per season, and an interaction with their community.
The best approach, then, is often to develop a presentation that gives examples of products with few features that make a lot of money. It may sound very simple, but this is often exactly the “insurance” managers need in order to sign off. The key to getting it right is providing a sense of understanding and comfort: that other companies have done a good job of this, that what you’re doing is not unknown or wild, and that there is a planned path for success. Sometimes this means incorporating a feature schedule into the project so that you space out feature releases well into the future. This is often a good strategy for staving off adding features until there’s time to incorporate them thoughtfully.
How can this go wrong? The executive might have already sold all of the features through the sales team, and now you need to incorporate all of them. In this case, you don’t have a lot of leeway, and may have no choice but to make the product that’s already being paid for. But if you have any hand in initiating the design and user experience of the product, and can show a feasible roadmap, then showing fewer features and getting executives comfortable is a good approach.
Have you ever had an executive on a project who has “pet features” or encountered a product with legacy features that “absolutely must stay in”? This can be a difficult situation. Legacy features have a bad habit of preventing newer (and often superior) approaches from being implemented. More often, they make for a cluttered user interface or product usage flow. On the other hand, there are a few tricks available for making legacy features easier to deal with.
Often what you really need to do is show someone the product is wrong without forcing them to take responsibility for the decision—some outside, objective force needs to do the telling. The first thing to determine is whether the market is actually using all those elegant features; product trials, user testing, and statistical analysis can help here. You may discover that some features are useful and others are not, and you’ll have the data to back up your opinions. Some features might be used by a small number of people but be crucial to them. In this case, it may be possible to demote the legacy features in the user interface if they’re not as important for everyday use.
Another way to solve this problem is to create a “light” version of the product to help users get into it without overwhelming them. Adobe used this idea to great effect, releasing a cheaper version of its full Photoshop product called Photoshop Elements. It worked well enough to introduce people to the basic concepts of photo editing and some of Photoshop’s tools without overwhelming them. This allowed for a new generation and section of the market to pick up Photoshop and integrate it into their workflow, more than doubling Adobe’s addressable market in just a few years.
At the last company I worked at, a single stakeholder had complete control over one page of the website. He loaded it with as many features as he could. Then we launched the site with our design and included his single feature-laden page in the launch. We ran statistics to see if anyone was using the page, and when we found that no one was visiting it, we were able to present a data-backed argument to remove the page (and eventually to release a pared-down, redesigned version in line with the rest of the site).
Big projects almost always bring significant expectations, and often back themselves into the corner of not being able to fail. Such projects can also be significantly overfunded, which—counterintuitively—can often lead to poor resource allocation. Risks are not taken if the project is too high profile, for fear of job loss. Sometimes people are so wrapped up in a project that they forget about the outside work, especially in very large, political organizations. In short, the more stakeholders you have internally, the more you are building a product for your managers, not the users outside of the company.
Many managers may have input on a product, each with something at stake. Therefore, they must be involved.
Encourage the team members to help you with research, or bring them into the field while you test the products.
There’s no time for user research, or testing can only be done in-house with a lab of people paid to come in and use the product under sterile conditions, because the product must be kept absolutely secret.
Set up an in-house environment that replicates the use of the product in the real world as much as possible (e.g., a checkout lane, living room, office, school, playground, parking lot, museum, etc.), and use your own team members as testers. You can use cardboard and paper prototypes to reduce costs.
“You can’t show this to anyone, even outside testers, until we know we got it! You could get fired if you show this to anyone outside of the company!”
More often than not, extremely secret projects result in products that flop. What we now know as the Microsoft PixelSense was originally introduced in 2007 as a massive, table-sized tablet with a 30-inch rear projection display. Dubbed the Microsoft Surface, the product was kept under tight controls. It had a hefty price tag (over $10,000) and was inaccessible to developers. When the 9.7-inch Apple iPad was released in 2010, I joked that it was a “miniature” Microsoft Surface. The form factor was smaller, it was cheaper, and it had a multi-touch screen. I lamented that Microsoft had kept the Surface so close to its vest. It made it more difficult for the product to catch on in the market. In October 2012, Microsoft released its own smaller tablet device, retaining the Surface name. The larger Microsoft Surface was renamed the PixelSense, and served by Samsung SUR40 with Microsoft PixelSense, and the name Surface was reserved for the smaller tablet. Though Microsoft reported $853 million in revenue from Surface sales during the 2013 fiscal year, it spent over $900 million on marketing and advertising for a product that consumers didn’t respond well to. In addition, Microsoft had recently risked redesigning its core operating system, capped by the release of the ill-fated and difficult to use Windows 8. Microsoft learned its lesson, though, and didn’t give up—the Surface 2 and Surface 3 did much better, and so did future releases of Microsoft Windows. By January 2015, sales of the Surface had reached $1 billion. The Windows 10 operating system debuted in July 2015 and was a stable release perfectly suited for mobile tablets. The future of Microsoft Surface and its other new products such as the Microsoft Surface Book (a laptop offering) and the Surface Hub (an interactive smartboard) are yet to be seen, but Microsoft slowly improved on its products.
This is one of the most difficult arguments to battle. Many companies, in fact, have intellectual property (IP) issues and a legitimate concern about product leaks, so showing the product to the outside world might not be allowed by corporate policy. On the other hand, the longer a product is developed without external feedback, the more likely it is to fall into an echo chamber of features and interfaces that make sense to the developers, but not the users.
So, rather than fighting a losing battle to show it to the world, work instead to get feedback internally. An organization that’s large enough to have IP concerns is large enough to have coworkers who are completely unfamiliar with the project.
Internal usage is a good litmus test for the outside world. If a product is good enough that it spreads internally, and people voluntarily use the product at the company, then the product may well succeed outside of the company. That is how Gmail spread, in fact: first internally at Google and then as an externally released product.
Technology might be ready for humans, but humans are not always ready for tech.
Shortsightedness and a misunderstanding of how long it takes to get something to market, or how long it takes to get users to understand a new concept, often get in the way of organizations actually getting a real product to market. When elevators were first introduced in modern skyscrapers, for example, they had to be artificially slowed down so that humans could handle them.
How can you make sure that the product you’re building is a fit for the people who are going to use it? We can tackle this question by examining successful product launches. Very rarely does a product initially hit the market in its final, successful form. Instead, it evolves with users over time to eventually fit into their lives. By doing user research and understanding what the market needs, you can save yourself the disappointment (not to mention cost) of a failed product launch.
You might have a great product, but the way you introduce it to the world matters just as much. Release it too soon or don’t explain the product well enough, and people may be confused by it, or worse, fear it. You might have a product that sits on supermarket shelves and is never purchased. Or you might release too many features at the same time without understanding who your market is or how people will use the technology.
Launch processes are important because they rely on an understanding of social norms. When we said in Chapter 3 that technology should respect social norms, we were talking about the launch process as well. Showing the device used in its intended environment is good, but it’s even more important to allow people to play with it, and come up with their own solutions and uses for it.
How does a product launch work? It’s important to determine where it will be launched, to whom you will launch, how much of the product will be tested, and how you’ll price it. It’s important to have a small group of people test the product in the real world, and not to be especially secretive about it. If fans spread the information for you, it’s priceless.
If good design reduces the number of steps to get to the goal, Calm Design reduces the amount of attention to get to the goal. For every feature or system you add to the product, ask yourself, “Is this really necessary? Is there a better or cheaper way we could do it? Something less resource intensive with fewer moving parts or lines of code?” It often works to assign steep constraints when designing something. Limitations lead to cleverness and a lot of thought around what can and cannot be done. Often teams with too much time and too many resources overdesign a product, whereas some that are forced to build with limited resources end up doing very well.
You must also have a lot of passion around the product. Apple cofounder Steve Wozniak wanted his own personal computer badly, but didn’t have the money for it. He thought about computer design all of the time. What if he could make a working computer from cheap components? The more he thought about it, the more he developed a model of the computer in his head, and then he began removing components until it became very cheap. The result eventually became the Apple I and II, revolutionizing the home computer industry and igniting a whole new generation of software developers.
The products that do things the most efficiently will win in the future. Reduce the steps required to get to a goal. Find out what people are trying to do with your product or service, and map out the interaction.
Don’t settle when you reach the really hard work. The more you put into the design process, the less you’ll have to support the system in the future—and the less money you’ll have to spend on it over time.
I’ve often encountered companies that postpone launches until the product is “perfect” for fear of competition and copycats. This often harms the company and the launch.
Consider the social network space. Friendster, Tribe, and MySpace all preceded Facebook, and numerous other social networks have tried to challenge its success. But Facebook is the dominant social network, not because it was the first to market or because it copycatted someone else, but because it rapidly implemented new features and grew with its users over time. It was the best implementation because it didn’t stop implementing. This gave it the best user experience.
Fears of predatory competition in the tech sphere are often overblown. Stagnation is where you should direct your fear. The distinct advantage that a startup has over a larger company isn’t necessarily that its ideas are better, but that it can act more quickly. A larger company might spend six months deliberating over a launch process, whereas a startup might try something for two days, figure out whether it worked or failed, and try another entirely different process by the end of the week. Decision paralysis has killed more companies than knockoffs.
Letting a product gain fans organically means it is more real than a glossy marketing campaign. Use real pictures of people using the product and let them tell their own stories. You may have personas you’re developing for, but how the product is actually used and by whom may surprise you. And finally, honor your customers and remember that you’re making products to serve them. Routinely check in with your support team to see what the top problems are, and learn from them how you might be able to solve them with a better interface or product design in the next release.
William Gibson famously wrote “the future is unevenly distributed.” The best way to ensure your product doesn’t fall prey to the mistakes people have made in the past is to study it.
I’ve spent the majority of my career doing some kind of user experience work. I later built a startup that made products used by millions. A lot of my life has been spent predicting whether products will work or not and advising companies on those products, and getting paid to do user experience analysis means thinking deeply about the entire experience of a product.
I often see entire systems and industries going back in time because they don’t learn from the past, they try to enter too many new products and features into the market at once, or they make false assumptions about design. These are very costly mistakes. Google Glass is an extreme example, but there are thousands.
Research is not a “luxury”—it is a crucial part of the design process. In addition to saving money and time, good research gives certainty to what is “real” versus what is assumed. Once you begin looking at and understanding how to do the research around the product you’d like to build, you might find that much of the research has already been done.
Many academic institutions have created products and services before, and startups too. Then they write about them. Using academic archives and the Internet Archive (https://www.archive.org) is very helpful, as is asking established people in the industry whether they’ve seen or built products like yours in college or at companies.
It may seem counterintuitive when you’re trying to make technology that works in the future, but going back in time is very helpful. Yes, some research papers may not be so readable, but you’ll be able to get the gist quickly once you get used to it. Some are from capstone projects, others are from people who spent four or five years working toward a degree and then left for a full-time job or to work on something else. Many of these research papers were written for educational purposes, so students could get a handle on concepts before turning professional. Consider Georgia Tech, Carnegie Mellon, NYU, Stanford, the MIT Media Lab, and RISD. Also look at PARC research and try to contact those who generated the original ideas or made the mistakes. Sometimes you may be able to work with them!
It is crucial for executives and managers to allow enough time after a product has been built for real-world testing, small beta test groups, and code reliability testing. Often executives sell customers on features, not functionality, and the features don’t have enough time to be tested before they go to market.
A company can easily get caught up in building a product, but forget to sanity check with the outside world. One of the ways to ensure that a product will be successful when it is launched is to do a small product launch before going into larger production.
It is best to test products while you’re making them, instead of doing all of the testing at the very end. Doing so can save lots of time and money, because you may be able to catch design mistakes early on. If you can’t get the go-ahead to test your product, put someone in a room with it and tell them to figure out how to use it. What they don’t immediately figure out can be designed better or shown to them on the front of the box.
Do you have a system in place that’s already useful that people are already trained on? Many companies fall prey to the “let’s redesign everything!” catch. This can come from executives and developers in equal parts. Perhaps developers are sick of the time it takes to maintain and test code, and stakeholders want to add new features or cut costs. But be forewarned. A complete redesign can be one of the riskiest things a company can do. Redesigning an entire system or piece of software means that the old product still has to be supported, and the new product will have bugs and have to be supported at the same time. Edge cases will double, and it could take years before the system is stable again.
It’s often better to improve a system slowly over time than to redesign it and replace it with a more complex, newer system. Having people stop to learn new systems can lead to mistakes, but learning a new workflow one piece at a time gives people a chance to get comfortable with changes.
Call your customer service department and figure out what the most frequent issue is. Tech support probably encounters the same issues from people again and again. What are the most common complaints? Solve those first, and make your way down to the bottom, bit by bit. It’s often the hardest stuff to fix that makes the biggest impact, but fixing simple items can sometimes improve the product greatly. You’re not trying to replace tech support; you’re just helping them do a better job with the calls that come in. Work with your designers and developers to address and fix the first issue. Then tackle the next issues in support.
If you get enough of these issues and are skilled and experienced enough to do a complete redesign, then go through with it, but be aware that some major sites (such as Digg and StumbleUpon) have completely lost user traction after overarching redesigns.
Temptation is strong to use tech to replace people, rather than improve and streamline the interaction between people—and yet this is often tech’s most useful role. How many times has the muscle memory of your own fingers taken you to Google? What does Google do but connect human knowledge to other humans? What does Facebook do but connect people to one another in a faster way? Slack allows people to connect to one another with less friction and overhead than email. In these systems, the technology dissolves and becomes invisible.
The most powerful human technology brings people together. Early examples might be the written word, ritual, or song. Each of these systems was designed to connect people. When you’re really into a book, you don’t notice the pages anymore. You imagine what the writer is trying to tell you. You’re connected to the mind of the writer. That’s what the best technology does. The interface of the tech disappears and you interface with another person, community, or idea. Early bulletin board software didn’t have images, but it brought people together.
Battery life will improve over time, but the best way to preserve it is to design simple, efficient systems. You don’t want to leave someone stranded when a battery wears out.
For instance, I use a digital key code door locking system at my house. I quickly learned to rely on the digital system. It’s so convenient that I stopped bringing my key. I don’t have to worry about being locked out of my house when the batteries on the door lock run out—which happens about once a year—because the keypad flashes red when it’s nearing battery depletion, giving me plenty of time to change the batteries.
Hopefully this chapter has helped you to understand more deeply the concept of a calm product launch and some of the strategies you can employ to ensure a product is adequately tested before giving it to the public. There is no right or wrong path for product design and development as long as you consider who is going to use it, the ways in which it could go wrong, and the areas of people’s lives you’re going to affect. Paying close attention to user needs and rapidly iterating with respect to your users will always serve you well. The products that respect users the most win.
Some things to keep in mind:
Team size matters. Teams with fewer stakeholders get things done quickly, and are more likely to take risks. Each additional person on a team increases communication barriers.
Discover your team’s strengths and weakness and see how they work together through a test project. Just an hour-long exercise of designing a new toy or a product for fun will expose your team to the experience of creating something within a time limit, and will give you some inkling of what conflicts might exist among them.
Perspective matters. Find people who work differently from you. A team should be made up of different kinds of people from different backgrounds, or you may miss edge cases. Not all users are alike, and your team shouldn’t be either.
Internal support is important. If you work for a bureaucratic or political company, make sure to get support from internally trusted people for your project. Find a way to explain it in the language understood by the company. Translate your vision into theirs.
Constrain requirements. For every feature or system you add to the product, ask yourself, “Is this really necessary? Is there a better or cheaper way we could do it?”
Do your homework. Most projects that have failed before failed for a reason.
Respect user privacy. Your product is a service to them, not you.