The method for building successful products should never, as product guru Marty Cagan likes to explain it, feel like playing darts blindfolded. With companies like IDEO, Cooper, Adaptive Path and 37 Signals sharing their industry secrets, there’s really no excuse anymore for building products haphazardly. It’s my hope the following will help, in some small way, to guide early startups on the right path to creating the next killer app.

Engineers Designer Wanted
10 years ago, it wasn’t uncommon for engineers to both design and build an application. “Graphic designers” were just starting to get their heads around the digital space and for the most part, products were designed and built from start to finish by engineers. While many products “functioned” correctly, often the result was a user experience that lacked empathy for the user (a design skill) and a frustrating process where everyone from product manager to CEO was at the mercy of the engineer’s discretion.

Flash forward to 2010 and what we find are designers doing a lot of the up-front work in order to ensure the usability and perceived value of a digital product. More than anything, what designers bring to a project at the beginning is insurance that what you’re about to build will be successful. How do they do this? They apply design thinking:

• Take risks at the early stages when there’s room for error
• Conduct research to understand the target audience’s goals, behaviors and attitudes
• Test ideas to gather immediate feedback and make any course changes early
• Challenge a product or service’s usability, feasibility and perceived value

All this begins before one line of code is ever typed. Rather than hiring a bunch of engineers to start building from the get-go, the focus is on product discovery via a high-fidelity prototype (HTML with light scripting or Flash) that mimics the user experience. Like building a house, the first step isn’t to begin pouring the foundation, but to work with the architects to create a plan and test the design (with a prototype) before the construction team shows up.

Start out with a good product manager and designer and consult the rest. Between your product manager and designer, you should be able to get your vision off and running, keep costs down and hopes up.

Fail quickly and early (and cheaply)
One of the design thinker’s mantras is “fail quickly and early.” That’s right, go ahead and fail—just do it while it’s cheap and easy to do so.

Prototypes, both low-fidelity and high-fidelity, are a great way to safely test out ideas early in the process. Have a whacky idea that might just be the next Twitter? Test it. Had a heated argument about the validity of a certain feature? Test it.

With interactive prototyping tools like Axure and the soon-to-be-launched Adobe Flash Catalyst, you can put together a wireframe prototype in no time in order to test your vision. And if your idea turns out to be a complete flop? Well…better now than later when it could cost you weeks of code or sending an apology letter to your user base.

Feasible, usable, valuable
So, you have a prototype that matches your vision perfectly and (in your mind) appears to be a Facebook killer. Now’s the time to be asking yourself the following:

Is the product feasible? Somebody grab the technologist because we need find out if what we’re proposing is even technologically possible or if we are light years away. Bringing a technologist into the equation early has both its advantages and disadvantages. In this case, it’s important to understand now, whether or not your concept has wings. A good technologist will also provide insight into what else is possible (i.e., “Did you know we could…”).

On the other hand, some technologists may have a narrow view of what’s possible and you can run the risk of killing innovation. The initial iPad feedback coming from the tech community is an example where technologists don’t see the value in what could be a game-changer for the industry. A good strategy in the early stages is to “shoot for the moon”, drafting plans that are creative and uninhibited by barriers (within reason, of course).

Is the product usable? You “get it,” but will your users? Designers like to use fancy words like heuristic evaluation to describe testing the usability of a product. Some quick heuristics to test are: user control and freedom, consistency, error prevention, efficiency and aesthetics. Again, a prototype along with direct observation of test participants are used to grade the usability of a product.

Is the product valuable? What is the perceived value of the product in the eyes of the user/customer? In other words, will anyone care? An invention only becomes an innovation once others recognize the value of it. Does the world need another Facebook or My Space?…probably not.

I (heart) users
Everyone knows the key to success is building a product people love. Steve Jobs likes to reminds us of this. Are Apple products more expensive that their competitors’? Sure, but it doesn’t matter. We still buy them.

According to the book The Design of Sites, there are four types of design styles. The first is company-centered design where the priorities of the company are put before those of the user. In return, little thought is given to what customers want to do. An example of this is making users register before giving them access to an application’s features.

The second style is technology-centered design. Here, technology is an end rather than a means of accomplishing and end. Just because you can build it, doesn’t mean you should or that anyone will want it.

Thirdly, there’s design-centered design. In design-centered design, “the needs of other people are given less importance than the creative and expressive needs of the design team.” An example is the designer who is only concerned with the emotional impact of the user experience and ignores other key elements such as usability.

Lastly, there’s customer-centered design. This is the sweet spot that “emphasizes customers and their tasks above all, and sees technology as a tool that can empower people.” While it’s important to meet business goals, it’s equally as important to show empathy for the user by deeply understanding their needs, behaviors and attitudes. Lose site of the user and you’re lost. In any case, if you build a product people love, many of your business requirements will already have been met.

Test it, test it, test it

Test it at the beginning, in the middle and at the end. A common misconception is testing wastes a lot of time and money. In the hay day when focus groups were lead by over-inflated marketing agencies, it did. Welcome to the 21st century. Usability testing can now be done in a variety of ways that are both relatively cheap and fast. Sites like UserTesting.com allow for quick turn-arounds and for about $50 a user, you can hire live participants to try out your product at your work place and gather insights. A morning of usability testing at about $150 (3 participants) is time and money well-spent assuring your team they’re on the right track. Learn to enjoy testing and do it frequently. Not only will you find it a nice distraction from looking at documentation and mockups all day, but it could save you a lot of money and everyone headaches along the way.

Build a minimal product
“Build half a product, not a half-ass product” – 37 Signals

Start by building a minimum product to ensure you can get something out sooner rather than later. Build a good foundation and add later as your product gains traction with your users. Many times I’ve witnessed what could’ve been a very nice product launch, turn into something that only the business owners thought was a success. The feeling is “We’ve worked very hard on this and we deserve to feel proud about it.” Unfortunately, your users could care less how many hours you’ve put into it. That’s why it’s important to plan well and bite off only as much you can chew.

“Perfection” is a word people don’t like to use in product meetings. It’s time to bring the perfectionists back with the caveat that the team work on less rather than more in order to achieve both a product that is elegant and do-able by the product team. In the long-run, you’re users will thank you with rave reviews and you can return the favor with frequent updates as you check-off one new feature after another.

Feedback comes in many flavors
While usability testing and free beta versions provide invaluable feedback to your product team, so does social media. Companies now have a variety of ways to gather feedback from their customers, whether it be comments to their blog posts, Twitter feed or Facebook page. Jump on the social media bandwagon early to pick up on the vibe from your users and get people’s reactions to your product early. Consider social media your focus group.

Common pitfalls
As mentioned at the beginning of the post, startups are often lead by people that might not have a lot of experience when it comes to product development. An MBA might buy you business credentials but that doesn’t necessarily equate to being a great product designer. Here are some areas entrepreneurs often get stuck:

“We’ll see what sticks”
The mindset is to throw several concepts at the wall like spaghetti and see what sticks with your users/customers. This brings us back to the throwing-darts analogy. The idea is to test all concepts before they reach your audience. Not only will this save you time and a wad of cash, but it will help maintain a fickle user base while you experiment with other ideas. “We’ll see what sticks” isn’t a plan, it’s a last minute desperate measure to find the right solution.

“Build it and they will come”
Just because you can make something doesn’t mean you should. Just like the Facebook example…does the world need another? Test your concept early to see if people care and whether or not it’s worth spending other people’s money on.

“We don’t have time for user testing”
With all the tools available for usability testing these days, there’s no excuse for not doing it. A little goes a long way with this one.

“We’ll let the users tell us what they want”
While usability testing offers an invaluable means for directly observing your users as they try out your product, it can also turn into a design crutch. Usability testing should only be used to confirm the validity of your concepts and not as a means to arrive to them. The customer doesn’t always know what they want.

U. of Product Design
Lastly, we’re fortunate to live in a time when knowledge is so easy to come by. Many of the top interactive design studios and universities offer courses for those who would like to become better product leaders. Here are a few, all located in the Bay Area:

Cooper Cooper | U
Adaptive Path In-house Training and Virtual Seminars
Silicon Valley Product Group Public Workshops
Stanford D. School Exec Ed

Related Posts:
Why Some Startups Fail
Design Thinking 101
Help! My Designer Wants a “Discovery Phase”

Frustration runs both ways: designers are disappointed when the client doesn’t value the discovery phase. Client’s attitudes of just “seeing what sticks” or “build it and they will come” can seem naive and reckless to designers.

On the other hand, clients may interpret a discovery phase as “busy work”, a “nice-to-have”, “paralysis analysis” or even worse—a means for the designer to squeeze a few more dollars out of their budget! There might also be a feeling that designers are “artists” and their place isn’t in the conference room helping to strategize the best way to build their product or service. Whatever the reason or bias may be, there’s often confusion around what added value, if any, the discovery phase brings to a project.

Think of the discovery phase as laying the foundation for everything that follows: features, page flows, screen details, branding, copy, coding, launch dates, user traffic and ultimately, business success. Designers like to call this phase of product development “discovery” because what they’re doing is finding out what really matters. Most importantly they’re confirming that what matters to the client is in-line with what matters to the client’s users and customers. Through a discovery process designers are able to rule-out certain directions that show potential for failure and help increase chances for building a successful product. A professional designer isn’t just interested in creating something that looks good, but also something that functions well and that resonates with users and customers.

Some fears clients may have are that a discovery phase will take too long, cost too much and will only produce “opinions”. The attitude might be that any discovery phase should be done on the designer’s own watch and that it’s really for their benefit anyway.

While it’s true that a designer will need to spend some time getting up-to-speed with the client’s business, this is not their biggest challenge. More time will be spent understanding what the users’ needs, behaviors and attitudes are. You might be asking, “Can’t Marketing just provide that information?” Marketing can usually provide demographics, brand assets, copy and sometimes even survey results relevant to the project. However, Marketing may not have answers to specific questions around what kind of experience users are looking for. Also, what customers say is not the same as what they do. A discovery process may also include observing users in their own environment to gain more insight into what the user is thinking. Lastly, Marketing is often good at providing qualitative measurements, but not quantitative measurements such as how the user or customer “feels” about a particular feature.

Clients who wish to see product building initiated immediately may be aggravated by any extra time and money spent doing research. However, in the long run doing your homework could save a lot of time, money and maybe even the company’s life. Not only could it save a company from launching a product that nobody cares about, but it could also save a company from wasting resources in the more expensive coding phase of product development where the burn rate goes up. Another thing to keep in mind is that a discovery phase can easily be customized to match your budget and schedule. In this case, a little bit goes a long way and is exponentially better than doing no discovery at all.

The goal of the discovery phase obviously isn’t to share with the client information they already have (although it might help to confirm it). Typical deliverables include a competitive audit, personas, user scenarios, a project plan and a design brief.

A competitive audit is a deliverable that provides the client with information on what the competition or near competition is doing, what users are already accustomed to, and any areas for differentiation. It’s putting a magnifying glass to the competition and might even go so far as conducting usability testing of their products and services in order to find out what their customers like/dislike about them. Competitive audits are typically delivered with three sections with the first including a summary of the findings and recommendations; the second being a summary of each competitor’s site plus screenshots; and a third being a comparison chart which acts as a tally sheet for who has what. The idea is to not only identify what the competition has, but what they don’t have.

Beyond documentation, the discovery phase also is a time to create some great tools to aid the design process going forward. User experience designers find it helpful to use personas, or fictitious characters that personify user scenarios, to unify the product development team around a central vision and give a voice to the user. Personas are only half-made up—that is, they’re based on audience demographics and research. A product or service might have multiple personas each representing a different category of user. Nevertheless, there’s always 1-2 primary personas. Personas help the product team focus on who really matters versus trying to satisfy everyone. The persona’s demographics, needs, behaviors and attitudes are laid out on a single sheet of paper and taped to the wall for quick reference. It’s not uncommon for team members to challenge each other by asking what a particular persona would do in a given situation.

Lastly, a discovery process gives the designer time to gather technical specifications, prioritize and rate features, create schedules and summarize everything in a design brief—all which is important for demonstrating there’s a process, rallying the troops and making sure the design or build doesn’t go sideways.

Of course, there may be times when a discovery phase needs to be augmented with usability testing or another form of direct observation such as a day-in-the-life study. A new product or service always warrants a thorough discovery phase. If anything, it’s used to reduce the risk of designing and building something that nobody cares about. A discovery phase is also appropriate for re-designs, as the competition has mostly likely changed as well as the attitudes of users. What better time to make sure you understand your users and make any changes than when re-designing your product.

In summary the discovery phase helps to:

• Reduce risk
• Unify the product team under a central vision
• Provide context for the product team
• Advocate users’ needs, behaviors and attitudes
• Know the competition at a granular level
• Justify decisions
• Discover something the user or customer didn’t know they needed/wanted

Related Posts:
Design Thinking 101

Cagan argues that startups work terribly inefficiently in spite of limited funding and time. Not only does this inefficiency cost money and time, it may also cause many startups to never reach it to market!!! According to Cagan, this is why many startups fail. They ”simply don’t have the funding to go to two years before they gain traction in the marketplace. So they hire engineers, take their best shot, and see what happens. Ready, fire, aim.”

Here’s the complete scenario as he describes it:

Someone with an idea get some seed funding, and the first thing he does is hire some engineers to start building something. The founder will have definite ideas on what she wants, and she’ll typically act as product manager and often product designer, and the engineering team will then go from there. The companies are typically operating in “stealth mode” so there’s little customer interaction. It takes much longer than originally thought for the engineering team to build something, because the requirements and the design are being figured out on-the-fly.

After six months or so, engineers have things in sort of an alpha or beta state, and that’s when they first show the product around. This first viewing rarely goes well, and the team starts scrambling. The run rate is high because there’s now an engineering team building this thing as fast as they can, so the money is running out and the product isn’t yet there. Maybe the company gets additional funding and a chance to get the product right, but often it doesn’t. Many startups try to get more time by outsourcing engineering to a low-cost offshore firm, but they’re still left with the same process and the same problems.

So as Cagan states, engineers are typically brought into a project at an early stage and they’re running around like chickens with their heads cut off trying to code and test new ideas at the same time. Sometimes weeks of coding are thrown out the window as the company “feels” itself through the unfolding product. For small startups it’s like pouring a house’s foundation and at the same time, deciding where the walls go.

But Marty Cagan isn’t some cranky product manager trying to wreak havoc on the startup community. He continues to describe what a more efficient process might look like:

Here’s a very different approach to new product creation, one that costs dramatically less and is much more likely to yield the results you want: the founder hires a product manager, an interaction designer, and a prototyper. Sometimes the designer can also serve as prototyper, and sometimes the founder can serve as a product manager, but one way or another, you have these three functions lined up—product management, interaction design, and prototyping—and the team starts a process of very rapid product discovery.

Cagan emphasizes that the focus is on product discovery via a high-fidelity prototype that mimics the desired user experience. But this isn’t enough—you must validate the product design with real users that fit your target audience. Without testing real users, you’re still in the dark when it comes to understanding how your users may respond to your product or service.

What then continues is a refinement process that includes several versions of the prototype in order to get closer to a winning product. The end result is that you have:

(a) identified a product that you have validated with the target market, (b) a very rich prototype that serves as a living spec for the engineering team to build from, and (c) a much greater understanding of what you’re getting into, and what you’ll need to do to succeed.

The engineers are then brought on and they’re able to build something based on a clear vision of the product and a stable spec. Not only does this make the engineers’ job much easier, but the company has reduced the risk of shipping a flop and has also saved a lot of time and money on development. The startup is building a successful product “on purpose”.

Cagan finishes his argument by asking:

So why don’t all startup teams do this? Because we’re such an engineering-driven industry that we just naturally start there. But any startup has to realize everything starts with the right product, so the first order of business is to figure out what that is before burning through $500K or more in seed funding.

…Definitely something to think about for your next startup.