1. "Worthless" product
1.1. What is it?
1.1.1. You make something that doesn't actually generate value for your organization
1.1.1.1. For for-profit companies, this can happen a couple ways
1.1.1.1.1. You make something that isn't actually profitable
1.1.1.1.2. You make something that can't even be monetized effectively
1.1.1.1.3. You make something that doesn't actually serve your brand or educate your customers meaningfully
1.1.1.2. For nonprofits, I see this frequently
1.1.1.2.1. You have information that you want to get out to the world, but you don't necessarily connect it to your organization's goals, direction, vision, or needs
1.1.1.2.2. You have a vanity project that just serves an executive's profile instead of actually raising money, creating activists, or educating the public.
1.1.2. Along similar lines, you might make something where you can't measure the value to your organization
1.1.2.1. With a product, this seems strange, although it's certainly possible to have internal problems such that you don't know for sure whether a product is actually profitable or not
1.1.2.2. With an educations site or a brand experience, this is perfectly possible; if you don't think hard about measurement throughout the process, it's going to be hard to staple in at the end
1.2. What do you do about it?
1.2.1. For us, the key has been to actually focus on it up front
1.2.1.1. Ask questions like how will we know this is providing value
1.2.1.2. Push on statements about the value of the site until you can figure out a concrete way to confirm or measure them
1.2.1.3. Figure out who will be impacted by the site's success or failure
1.2.1.3.1. We are inclusive in who we ask to help us understand value
1.2.2. We talk
1.3. Resources
1.3.1. Design for the digital age:
1.3.1.1. <a href="http://www.amazon.com/gp/product/0470229101/ref=as_li_ss_il?ie=UTF8&tag=modulus09-20&linkCode=as2&camp=217145&creative=399369&creativeASIN=0470229101"><img border="0" src="http://ws.assoc-amazon.com/widgets/q?_encoding=UTF8&Format=_SL110_&ASIN=0470229101&MarketPlace=US&ID=AsinImage&WS=1&tag=modulus09-20&ServiceVersion=20070822" ></a><img src="http://www.assoc-amazon.com/e/ir?t=&l=as2&o=1&a=0470229101&camp=217145&creative=399369" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />
1.3.1.2. Gives a ton of useful information about stakeholder interviews
2. "Useless" product
2.1. What is it?
2.1.1. Typically, you start a web project because you think people need something you have (or intend to have)
2.1.1.1. This is either a product you're going to create to help people do something
2.1.1.2. This may be knowledge and resources you've developed in the course of other work or intend to develop
2.1.1.3. It's not uncommon, however, that the people you intend to offer your app or information to aren't the same as you: you are a web developer or a nonprofiteer, and the audience you're targeting are random voters or people who eat dinner
2.1.1.3.1. This is where you get into trouble — you hav a lot of choices to make about what features you create or what copy you write, you could pick wrong.
2.1.2. It's perfectly possible to spend a lot of time and money making a website or app that no one actually wants
2.1.2.1. For product companies, this is a real risk, since if no one actually wants your product, no one will buy it
2.1.2.2. It's perfectly possible in non-profit though, too, even if your cause is righteous
2.1.2.2.1. The wrong tone can make people feel put off by your message
2.1.2.2.2. It's easy to be very internally focused, assuming that your way to conceiving of your issue is right
2.1.3. Along similar lines, you can fail to understand what people would actually find useful
2.1.3.1. You may have resources that you think people will find useful, and you decide you want to put them online to help the world
2.1.3.1.1. Unfortunately, the way you present your resources matters -- launching with the wrong level of detail, or wrong tone for a content-centered site can make your project useless
2.1.3.2. You may have a lot of resources to offer on a subject; the trouble is which ones do you put work into getting online?
2.2. What do you do about it?
2.2.1. We talk
2.2.2. The trick you need to figure out is what problems other people need to solve that you can help them with
2.2.2.1. Note: This is different from asking "please describe the product you want"
2.2.2.1.1. We need to know what people need; it's still up to us to design the actual solution to their problems.
2.2.2.2. By understanding the real problems that our real audience/market faces, we have a much better shot at offering something that can help them, instead of just offering what we have any think we'd find interesting.
2.2.3. We have tools to keep the end users of our products in mind
2.2.3.1. We can create user proxies, or personas, to help us capture what we learn about our audience when we talk to them. It's important that these personas focus on the users' goals first, as well as attitudes and beliefs
2.2.3.2. We can create mental models to help us keep in mind the way our users actually conceive of the problem space and to force us to link features to their conceptions
2.2.3.3. We can model our software using scenarios and stories that talk about our user proxies actually interacting with our product from start to finish, forcing us to consider whether a real person would actually ever find and use the features we're describing
2.2.3.4. We can use keyword research and some SEO techniques as a reality check: if you can't conceive of what a person would search for to find some aspect of your site, or there's no search volume for what you come up with, that should force you to ask yourself, "does anyone actually want what I'm offering here?"
3. What are these risks?
3.1. You could fail to
3.1.1. provide value to yourself
3.1.2. provide value to users
3.1.3. provide an actually usable experience
3.2. Thankfully, there are mitigations
3.2.1. In my world, I try to help clients manage risk around their projects
3.2.2. In the end, you cannot eliminate risk; if there weren't risk, what you're doing probably wouldn't be worth doing
3.2.3. We mitigate by talking and testing
3.3. There are definitely other risks
3.3.1. You could pick the wrong technology for your project
3.3.2. You could do a terrible job implementing the product, such that it costs a fortune to change or maintain
3.4. We're focusing on the risks that you might run into in conceiving and designing your product
3.4.1. There has been much written on mitigating the technology risks; today, I'm writing for a non-developer audience
3.4.2. I want to focus on the risks that you face early in a project, as you're conceiving it; what I don't think people realize is that they can doom a project before a line of code is written if they don't start with the right mindset
3.4.3. I will throw in one post-launch risk
4. "Unusable" product
4.1. What is it?
4.1.1. Even if you make something that will benefit your organization and that solves real problems for users, you can make it in such a way that it is so hard to use that people won't stick with it
4.1.1.1. Your risk here isn't too dissimilar to the "useless" software risk: You design something that doesn't actually make sense to your target audience
4.1.1.2. For any website, there is going to be some sort of interface with navigation, labels, and areas that you want to direct people's attention
4.1.2. The trouble is, again, typically you and your team are experts in your domain — your audience may not be
4.1.2.1. It's easy to use jargon that your audience may be unfamiliar with
4.1.2.2. The way you organize information is likely influenced by the culture of your organization and may not actually make sense to outsiders
4.1.2.3. The way you think about a process (say, requesting access to documents) may be very different from how your audience in the outside world expects it to work
4.1.2.4. Things that your knowledge make obvious to you could be confusing to regular website visitors
4.2. What do you do about it?
4.2.1. You talk to people
4.2.1.1. For organizing information, you can perform card sorts where you have members of your target audience show you how they'd organize the information themselves
4.2.1.2. When writing, draw on the insights (especially into the language your audience uses) you gained in making your personas or mental models
4.2.1.3. Use keyword research in SEO tools, or even better, your company's search logs, to see what the most common ways to refer to key terms within your domain
4.2.2. You test prototypes and development versions
4.2.2.1. Once you think you've got an idea of how you want your product to work, prototype it and put it in front of some real members of your audience
4.2.2.1.1. This is called a user test
4.2.2.1.2. You can start early with paper prototypes, and then work your way up to testing interactive prototypes or even development versions of your product.
4.2.3. You keep testing with A/B and multivariate tests after launch
4.2.3.1. Once you have a site launched, you can run A/B tests where you make two version of a page or feature and serve them to visitors to see which performs better. This a great way to get insights into what actually works.
4.2.3.2. Your web analytics, if thought-through correctly, can be a great source of insight into *what* to test after launch.
5. Bonus: "Invisible" product
5.1. What is it?
5.1.1. Spans the whole project
5.1.2. Even if you make a great product, you run the risk that no one ever finds it
5.1.2.1. If you build it, they won't necessarily come
5.1.2.2. One of the biggest problems on the web is connecting people to the resources they actually need
5.1.2.2.1. This is why Google makes so much money, and honestly, they're not even great at this
5.1.2.3. You need to plan how to reach your audience, because your audience likely doesn't just want up knowing the domain for your site
5.2. What do you do about it?
5.2.1. Leverage what you learned in talking
5.2.1.1. Where do people start their process for solving the problem that you solve?
5.2.1.2. Where does your target audience hang out online? Go to them there
5.2.1.3. What does your audience read? Reach out to those publications and sites
5.2.1.4. What does your audience search for? Optimize against those keywords, or buy them as ads
5.2.2. Watch your efforts in analytics and iterate
5.2.2.1. You should work to track your site marketing efforts in analytics so you know what's being effective and so that you can tweak it
5.2.2.1.1. Just as you test your site to make sure people can actually use it, test your marketing to make sure people are actually hearing and following it
5.2.3. Think about these factors early in the product design
5.2.3.1. You'll want to make sure you design around being found — don't let it be an after thought
5.2.3.1.1. Imagine if the videos on YouTube didn't have easy to share URLs, and the whole site were in some opaque flash app. How would YouTube have spread if people didn't share the individual videos?