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. 
Translations:
Italian
- Illustration by Kevin Cornell
RSS readers: Don't forget to join the discussion!