UIEtips: The Dirty Dozen Roadmap Roadblocks

via UIE Brain Sparks http://ift.tt/1lV3XSA

BY BRUCE MCCARTHY

Originally published: Jun 18, 2014

This article was originally published in Sept 2013 on Bruce’s blog, Product Powers. The original post also offers more in-depth information on the roadblocks.

A good product roadmap is one of the most important and influential documents an organization can develop, publish and continuously update. It’s the one document that steers the entire organization in delivering on the company strategy.

It’s key to success, and yet many organizations struggle to produce effective roadmaps. In fact, many organizations don’t create one, even to publish internally. Or they do, but it is simply a collection of unrelated features and dates.

What Is a Product Roadmap?

A roadmap is your vision for how a product (or product line) will help achieve your organization’s strategic goals. In that sense, it is literally a map of the steps involved in getting your business where you want it to go. To make it even more concrete, I also like to think of a product roadmap as a timeline view of your priorities.

A good roadmap inspires. It inspires buy-in from executives, inspires confidence from customers and salespeople, and inspires development teams to produce the groundbreaking products that drive significant growth.

A good roadmap keeps your organization on course toward its destination. Stating what you will do and when makes it easy to judge when you fall behind schedule or get detoured by good ideas that just don’t fit your strategic vision.

The Dirty Dozen

In my experience, though, there are some specific areas where companies commonly break down in developing roadmaps, hitting roadblocks that often keep them from getting where they want to go. I call these roadmap roadblocks the “Dirty Dozen.”

1. No Strategic Goals

If a roadmap is the path toward your goals, you obviously need to set those goals before you start. Yet many companies fail to sit down and explicitly describe the destination they are driving toward.

Is your product roadmap aligned with your strategic goals? Have a conversation with your CEO or another exec in the know. It may clarify a lot of your prioritization dilemmas.

2. Focusing on Features

A lot of roadmaps are just a list of features in upcoming releases. This is meaningless to most people outside of the development team. A roadmap should make it obvious how things will improve for your customers, organization or shareholders. Like any good sales pitch, it should focus on delivering value.

Look at your roadmap from the point of view of a board member or a customer. Would they see their interests reflected?

3. Inside-out Thinking

Focusing on features can be a symptom of failing to understand your market. Yes, priorities should be driven by internal goals, but those goals must also respond to market reality.

Ask yourself whether your roadmap priorities are driven by the needs of the people and organizations you intend to serve. Strive to bring that message from the outside in.

4. One Size Fits All

You probably serve more than one market segment. When you are talking to customers or partners in one segment, the roadmap you show should focus on how you will address their needs.

Make sure your roadmap is not one-size-fits-all. If a customer sees their interests in only 1 of the next 6 releases, they’ll get the message that you are not focused on them.

5. Trying Too Hard to Please

That said, many roadmaps are simply lists of customer requests prioritized by number (or size) of customers requesting or voting for the feature. This may help with retention for a while, but will not drive your company into new markets or to invent anything new.

Rather than just taking requests, listening for unsolved problems in your market (and doing something about them) is the best way to avoid a roadmap that’s really just a popularity contest.

6. Playing Catch-up

It’s often a mistake to focus on matching your competition feature-for-feature. All this does is commoditize your market. Instead, focus on creating unique value by developing solutions your competition can’t easily duplicate.

How many items on your roadmap are “me too” features designed to close perceived competitive gaps? How many of those have actually lost you business?

7. Not Getting Buy-in

The best-conceived roadmap won’t get you where you need to go if you can’t get anyone else to come along for the ride. You’ve got to get your development, sales, marketing, finance and other stakeholders involved early so it becomes their plan, not just yours.

If people use words like “intellectual,” “cerebral,” “theoretical,” or “ivory tower” to describe you or your work, this is code for lack of buy-in.

8. Prioritizing on Instinct

Good product people develop good instincts for their market. As a company grows, though, it’s hard to get the buy-in you need from all players based just on your instincts.

Can you tie everything on your roadmap back to your strategic goals? Can you show the ROI calculations that put priority 1 ahead of priority 2? A little data settles a lot of arguments.

9. Being Too Agile

Agile was developed as a response to lack of consistent direction from business execs. That doesn’t mean it’s incompatible with good direction. Yet many companies fear to map out a course thinking it’s not allowed in Agile.

Don’t let being agile become an excuse for indecision. You may choose to adjust course down the road, but you’ll move a lot faster if you first take your best guess at a destination.

10. Being Too Secretive

Some organizations have a roadmap but shy away from sharing it with anyone. It might be fear of revenue recognition issues, lack of confidence in the company’s direction, or just not wanting to look foolish if things change.

A good roadmap is not a contract. It can and should be designed as a statement of direction and intent, but customers and investors expect you to accept and act on feedback from the market. They expect your roadmap to change, so stop worrying.

11. No Buffer

One reason an organization might be reluctant to share is if their roadmap is too detailed. A roadmap consisting of 40 bulleted features in each of 10 precisely-dated releases is impossible to read, and can really constrain your options for adjusting course down the road.

Your roadmap should consist of problem-solving themes and broad time-frames. This gives you the leeway to cut or defer a specific feature without risking on-time arrival at your destination.

12. Over- or Underestimating

ROI is a critical consideration in prioritization, yet many product teams make the mistake of setting business priorities without considering development costs. Conversely, some teams spend months estimating every possible product initiative without first considering which are likely to be worth the time.

Approach your technical partner for a quick, high-level estimate of the work involved in your 10 most wanted. What if #4 turns out to be trivially easy compared to the 3 ahead of it? Wouldn’t you like to know that up front?

Want to hear more from Bruce?

He's presenting our next virtual seminar on June 26, Lean Roadmapping: Where Product Management & UX Meet.

About the Author

Bruce McCarthy is a founder of three startups. He’s invested in helping product managers and UX designers work smarter. You can get a taste of his fun, teaching style at his blog, Product Powers. You can follow Bruce on Twitter @d8a_driven.

A Matter of Character: Knowing your users and their stories

Go to article

by Sarah Doody

Comments (2)

Print

Share on deliciousShare on diggShare on email

58

I’m fascinated with the concept of applyingstorytelling principles to the processes of productdevelopment to create great user experiences. Of recent interest is the similarity between making a film and creating a digital product or service.

From what I can gather, when you create a film (which I have not!) the most important part is the screenplay. Informing that screenplay (and some argue more important than the screenplay itself) are the characters. Of course, there are literally hundreds of people that help bring that film to life. But ultimately, it’s the screenplay—the story of the characters—that becomes the firm foundation holding the entire film together.

User experience is still relatively immature in terms of its value being understood and embraced by all levels of teams and organizations. Adding confusion to the already misunderstood field is the increasing amount of material that focuses on process, pixels, and product. This can quickly overshadow a focus on specific people, their unique characteristics, and how a product fits into the stories of their lives.

I know, right now you’re thinking, “isn’t this a persona?” Well, sort of. The problem is that personas are often polarizing—people either love them or hate them. This is likely due to the fact that there are so many poorly executed personas, to the point that they almost become a joke for some teams! Vague generalizations like “soccer moms” and “entrepreneurs” don’t to provide enough detail. Elements such as fears, desires, needs, and feelings are not addressed, thereby failing to identify triggers that could impact their interest in, and decision to engage with, your product.

Context is often neglected, and we zoom to a moment in time rather than taking a step back to understand someone’s greater experience. On top of all this, personas are created at the beginning of a project and then often times simply disappear. We start out designing for a specific person, hopefully calling them by name, but quickly our “Jennifer” gets replaced with “soccer moms” or worse, “people,” “someone,” or “users."

So how can we rework or move beyond personas? I think it starts with trying to see through the lens of a screenwriter and take time to truly develop characters, and deeply invest in understanding their culture, context, conversations, and challenges.

While I was watching the 2013 Oscars, I noticed a greater focus on writing and story than I remember from past years. When honoring people in the movie industry that passed away in 2012, a clip was shown of Richard Zanuck (producer of films such as Jaws, Driving Miss Daisy, and Alice In Wonderland) talking about his devotion to storytelling: “The most important thing is the story; not the script, but the story.”

Building on this theme, Quentin Tarantino spoke about the important impact that the characters have in making movies memorable. In his acceptance speech for Django Unchained, which won Best Original Screenplay, Tarantino said: “If people are knowing about my movies 30 or 50 years from now, it’s going to be because of the characters that I created. And I really got one chance to get it right. I had to cast the right people to make those characters come alive and hopefully live for a long time.”

In the same way, people will remember your product not because of how beautiful it is, or how fast it was, or how cheeky your error page was. No. They’ll remember your product because of how at some point in their life’s story, your product just “fit” perfectly—it fulfilled a need, solved a problem, or afforded them a new opportunity that hadn’t been evident before. Creating this perfect fit for a product within the context of a character’s life can only be achieved if you’ve taken the time to understand your characters’ story.

We can all probably remember a time when we turned off a bad movie, likely because at the heart of it, the story just didn’t captivate us. Most people don’t walk out of a movie because they don’t like what the actors are wearing, or because they thought the art direction was awful, or because they didn’t like the music. My guess is that most people walk out of a movie because it didn’t capture their attention, it didn’t connect with them, and they had no emotional investement in the story.

When it comes to digital products and services, the same hypothesis applies. Think back to a time when you were checking out a product you heard about, but quickly stopped using it or became disinterested. While there are variables, such as site speed and performance, that influence our opinion of a product, let’s take them away for a moment.

Assume that the product is accessible and isn’t having technical issues. What’s the real reason that people abandon it? I’d argue it’s for the same reason people walk out of a movie: because it failed to connect with them. It didn’t show potential for fitting into the story of their life, and didn’t impact and add value to their world and experience.

To create a great product, you must have a great product story: a story about how someone is going to use that product and how that product or fits into an existing story (problem, need, behavior, goal) in their life. Without that story, no amount of sexy looking buttons, linen backgrounds, infinitely scrolling pages, clevercopy, or rich photography is going to keep them engaged and excited about the product.

Imagine if the film industry decided to take cues from the way digital products and services are developed. What would that look like? Instead of having a screenplay, they’d have a paragraph or two, some bullet points in a Keynote presentation, or a spreadsheet of scenes and shots, but no story to tie it all together. There would be people discussing lighting, framing, cinematography, music, and locations before the story had was even complete. They would start designing the movie posters before they’d ever shot a scene or even cast the actors. I imagine that if this process were followed, it would not result in a great film.

The screenplay is the basis of the entire production. It’s what actors use to help in their decision process about whether or not to accept a role. It’s what composers use to help guide them as they develop the score. It’s what the cinematographers use to outline the shots. A great film cannot exist without a screenplay and the well-developed stories of its characters.

Why then, when it comes to creating digital products and services, do so many teams often skip over the elements of story and character development? I’d argue that it’s largely due to increasing pressure to get a product into market quickly, or at least have a prototype so you can have a better chance at raising money, attracting the right talent to your team, and start building an audience and customer base. Of course, not everyone does this. However, a focus on how it works and what it does (prior to really understanding why it should exist) is a common trend that I wrote about in a past article called “Why We Need Storytellers At The Heart Of Product Development.”

While researching for this article, I stumbled upon Scott Myers’s page “Go Into The Story” on the website The Black List. In a post that took its title from Joseph Campbell’s The Hero’s Journey he writes about how he’s a fan and student of Campbell’s work, but worries the principles from The Hero’s Journey have almost become a recipe or formula for a great film. He writes: “I am concerned when a writer’s focus on this paradigm is so absolute because it’s possible to write a script that follows its every jot and title, yet not succeed as a story.” Of course, the natural question then is why? What ultimately creates a great story? Myers goes on to explain this (emphasis mine):

First, for readers to connect with a script, they need to have some level of emotional resonance with the story and its narrative elements. When a writer uses mostly left-brain muscles to craft a script that fits specific plot requisites—and frankly this pertains to any screenplay structure/paradigm—what can result is an inert object, a story bereft of a heart or soul.

Second, it is—in my view—more important to delve into and develop the story’s characters. That work should have primacy over everything else if for no other reason than that is where the emotional, psychological, and spiritual life of your story lies.

Story structure is hugely important when writing a screenplay. After all, a screenplay is a blueprint to make a movie. However it’s your story’s characters with whom a reader will (hopefully) connect. It’s your characters who give the story its emotional, psychological, and spiritual meaning. And I believe by developing characters first, the plot of your story will emerge organically, thereby infusing it with the vitality and personality of your characters, ensuring your story will have a heart and soul.

So, next time you set out to work on a product idea, review some new features, or start a design project, take a step back for a moment and ask yourself if you really know who the people are on the other side of the product and what their stories are. Consider the characters and the story of how your product fits into the context of their lives.

Eliel Saarinen, a Finnish-American architect and furniture designer said: “Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan.” In the same way, we must consider our products in the context of the stories of our characters.

As an industry, I believe we can help our clients, colleagues, and customers better understand what we do, and the value of user experience, if we get better at helping others understand why an investment in characters and story will ultimately lead to a product that fits into the story of a user’s life.

Image of wood rings courtesy Shutterstock.

Product Management for the Web

JULY 31, 2012

Go to article

by KRISTOFER LAYON

• Published in: Business, Project Management and Workflow, User Research
• Discuss this article » | Share this article »

Whether we prototype, write, design, develop, or test as part of building the web, we’re creating something hundreds, thousands, or maybe even millions of people will use. But how do we know that we’re creating the right enhancements for the web, at the right time, and for the right customers? Because our client or boss asked us to? And how do they know?

Enter product management for the web.

For the web, product management bridges the gap between leadership and customers on one side, and the user experience, content strategy, design, and development team on the other. Product managers develop and maintain close relationships with customers and colleagues that help them identify and plan for new product or product enhancement opportunities. Product managers express these opportunities as user stories and present them to the UX, writing, design, and development members of the team, who then identify and produce solutions to address the user stories.

So how does a team or organization get started with product management for the web? It needs to start with people.

People and relationships: the sources of knowledge for product management

Writers, designers, and developers often prefer to work alone or in small groups. Creative and detailed work requires focus and isolation to be done well. We prefer to get our work done quietly at our desks, but when we’re evaluating UX and usability we must step away from our desks and spend time with customers.

The importance of anyone and everyone—regardless of their role on a team—doing UX and usability evaluation will never go away. But practically, we know there are limits to how much evaluation writers, designers, and developers can do. That’s why there’s a growing community of user experience practitioners who focus exclusively on user‑centered analysis and prototyping. On many teams, they fill that role exclusively.

But there’s more work to do before user experience analysis and even writing, design, and development should begin. It’s product management work.

The product manager forms and maintains the extensive network of relationships required to make sure the team understands problems so that it can propose, prioritize, design, build, and test the right solutions. For this, you need diplomacy, time, and communication skills. And that’s on top of being able to relate to leadership, customers, writers, and developers to earn everyone’s trust.

For example, the range of people included in the product management process is wide. As the product manager, you meet regularly one-to-one with the president, chief information officer (CIO), chief marketing officer (CMO), and, perhaps most importantly, the director of technical support or customer service of your own or your client’s organization. Documenting these meetings thoroughly is critical—the product suggestions and pain points you discover become your data for making product decisions.

The other value of these relationships is that these are the people to whom you need to communicate and evangelize your product throughout its lifecycle. These people serve a dual role: they’re not just sources of key ideas and information; they’re also the audience for your communications about priorities and, later, product performance. So how does all of that get done?

More communication!

Data and communication: the credibility of product management

What and how you communicate is a critical aspect of being a product manager:

• Research: If writers, designers, and developers spend most of their time at their desks and supplement that with time spent with customers, product managers do the exact opposite. Product managers spend most of their time meeting with others to discover new needs, and research the needs that others have voiced.
• Analysis: Product management also involves using surveys and web analytics tools to reveal more product data. Analyzing results reveals trends that will help you prioritize everyone’s work.
• Reports: Product managers should write short reports regularly, and long reports quarterly. Fill them with graphs, charts, and summaries of your findings and opinions. Filter all of the data you collect and share it with the people who’ve informed you. This makes your analysis and growing expertise visible, which builds trust in your product decisions.
• Presentations: Finally, don’t underestimate the value of face time in front of your organization’s leadership, customers, and creative and development teams. To complement your research, analysis, and reporting, be sure to schedule plenty of time to present your findings, ideas, and product priorities in person.

Giving equal weight to these tasks ensures that your product management process is a valuable and visible layer for the organizations and teams involved in satisfying user needs. The better you do this work, the more trust everyone will have in your product decisions.

So besides relationship building, data collection, analysis, and communications, is there a secret sauce of product management?

Yes, there are actually two secret sauces: user stories and road maps.

User stories: the currency of product management

Writers, designers, and developers are always concerned about deliverables, and web product managers are no different. The product manager's main deliverable is the user story.

User stories are not requirements, specifications, or designs. In fact, they’re explicitly not any of these. They can’t be—because then they wouldn’t be user stories. They’re a lot simpler than that, yet the work required to create good user stories should be substantial if you’re being thorough. Here is an example of a good user story:

As a Type G customer, I need to be able to register for Program Q in both office and mobile contexts.

For comparison, here’s a poor user story:

Customers need to use a jQuery-enhanced web form for online registration, and a link to the form should be on every page in the top nav as well as in a big red box on the homepage.

Here are some of the elements that make the first example a good user story:

• The customer is identified as a specific type. Sometimes a product enhancement is not for everyone. So if it isn’t, it’s important to identify the customer or audience.
• Similarly, we’ve described the task with comparable detail. This category of customer needs to register for something online, and a particular type of something—Program Q.
• There is some additional clarification about the context in which this work needs to be done—in this case, regardless of whether they’re at a desktop computer in the office or using a mobile device.

Just as important to note are the things that are absent. It bears repeating: there are no detailed requirements, specifications, or design details in user stories. That’s because as a product manager, you craft stories based on people’s needs. It’s everyone else’s job to create solutions that address the needs articulated in the user story.

Be sure to avoid expressing design solutions as in the second example. The second example is also poor because it addresses customers in general, and registering for any program. General customer and task types can be okay, but the more specific a need definition can be, the better. Once you’ve created a few user stories, you can assemble them into a road map.

Road maps: the itinerary of product management

Uncovering the need for new or enhanced products, and capturing those needs in user stories, is one thing. How about when there are a lot of new products or enhancements, and it’s too much for a team to get done at once?

This is a problem, but it’s a good problem. And it means that as product manager, you have more work to do. You must set priorities. But this isn’t like dealing with a bushel of Halloween candy after trick or treating: the designers and developers don’t just get to reach into the user story container and choose the ones that look good to them. That is not very objective, and personal preferences shouldn’t be the source of priorities for team members.

As the web product manager, it’s your job to set user story priorities, and to organize these priorities in road maps and release schedules. A road map is a visual representation of the top user stories in the user story backlog, and it depicts priorities and groups of related priorities, called “epics.” A release schedule is a version of a road map, sometimes not as visual but always in some kind of timeline format. As the name implies, a release schedule is where you would communicate your intent to have Improvement A available to customers in the first quarter of year 20XX, Improvements B and C in the second quarter, and new Product D available in the third quarter.

Also, it’s important to understand that you can objectively set priorities, even if they are actually subjective priorities to your customers and stakeholders. In fact, this is where the art and science of product management intersect: you must be passionately committed to your customers and colleagues, yet objective about setting priorities that help them. Choosing the right tools and mechanisms for making decisions can help with this process. The Kano Model is one such tool.

The Kano Model: a tool of product management

The Kano Model is a theory that was developed in the 1980s within the Japanese automotive industry. It’s a great tool that product managers can use to analyze and compare product attributes in three categories:

• Basic: A basic product attribute is one that is essential for a product. Using the automotive industry, a basic product attribute for a car would be a steering wheel or an engine. A car needs both to function.
• Performance: These attributes are ones that can be compared between examples of a product because they differ substantially. A performance attribute for a car is fuel efficiency, or how well it performs using a gallon of fuel. People tend to prefer cars with a better fuel efficiency attribute.
• Delightful: Delightful attributes are ones that go beyond basic or performance attributes, and sometimes they aren’t necessary at all but can excite customers. For a car, a delightful attribute could be a convertible roof. On the right sporty car and for the right customers, a convertible roof can be really fun. But it’s not essential for the car to work, and also doesn’t enhance the car’s performance.

Using these three attributes, a product manager can analyze a variety of potential enhancements using a metric such as a five-point scale. And the more customer and analytics input you have, the better.

For example, if you want to make a website mobile optimized, you might have the following list of user stories you’d like to implement:

• Users on iPhones should be able to use the website without pinching and zooming.
• Users on Android handsets should be able to use the website without pinching and zooming.
• Users should be able to complete web forms on mobile devices with minimal effort.
• Users of seven-inch tablets should be able to use the website comfortably, with navigation scaled to the screen and their fingers.

I’m not going to tell you which user stories should have priority over others because those priorities should be specific to the needs and preferences of both your organization’s leadership and your product's customers. But if you’re getting input from your organization, asking your customers how they use your web product, and verifying activity via analytics, a product manager should be able to discern which enhancements will deliver the most value and whether that value is basic, performance-enhancing, or perhaps even a delightful improvement that will surprise your customers and generate some enthusiasm for your product.

This example shows how you can take a longer list of user stories and break it down into smaller amounts of work that can be spread across a team. Those smaller amounts of work can be communicated in release schedules, and you can report on those schedules in a product road map. All of this helps organizations, design teams, and development teams navigate product markets with more intention and certainty.

Minimal viable product: a goal of product management

The goal of product management is to deliver smaller improvements more continuously to those who use your website, mobile app, or other software. When design and development teams bite off more than they can chew quickly, a website or app can stagnate.

In a world of constantly changing web technologies, product management can provide the clarity you need for design and development to take place more efficiently. It aims for a minimal viable product: one that meets people’s needs as best as possible, and meets them today. But then on the very next day, you don’t just sit back and call the product complete: you user-validate what you’ve done, and see what needs to be improved next. Then the product manager prioritizes new user stories and sets new release dates to continue improving the site or the app.

The web is a big place, and it’s only going to get bigger. But people do not need a bigger web, they just need a better web. Product managers help the web get better, and keep organizations and teams focused on what people need the most. By investing in relationships with people inside and outside an organization, web product managers learn what’s needed to set smart product priorities that gradually but steadily make the web better.

Because the web is never done. 

• Illustration by Kevin Cornell