A product manager has many jobs, but one is most important: she must ensure her team delivers the right product, to the right customer, at the right time.

While her entire team can and should help, this job ultimately falls to the product manager. A designer may create an amazingly simple and intuitive user interface, but if it’s not productized for the right customer, it won’t get used. A developer architect may design a scalable, high-performance architecture, but if it’s something that ships two years too late, it won’t matter. A QA engineer may develop automation to ensure the product’s features are infallible, but if the customer doesn’t care about those features, it doesn’t matter.

Right customer

Product managers need to clearly identify and describe the customer, understand his problems and goals deeply, and make sure the product is focused squarely on him.

In 1992, Pepsi launched Crystal Pepsi, a cola that lacked caramel color. Pepsi told customers the product’s clear appearance reflected purity and health. Customers didn’t want a health-oriented soda from Pepsi; they expected a cola that was dark in appearance, and they expected a product that looked so different than regular Pepsi to have a different taste. Crystal Pepsi delivered neither.

Also in 1992, McDonald’s launched the Arch Deluxe, a hamburger targeted at adult customers who valued more sophisticated ingredients. It was higher-priced and had more calories than McDonald’s other hamburgers. However, it was quite similar to their existing products; the only real differentiators were a round piece of peppered bacon and a mustard-mayonnaise sauce. Customers didn’t care for a burger that tasted like a McDonald’s bacon cheeseburger but cost more.

Right time

Product managers must know when it makes sense to deliver a product. This often translates to a question of technology and market maturity. Is the technology you are using ready to become a product? Does it make sense to enter the market with your product now?

Sometimes a technology isn’t quite ready. Microsoft’s Tablet PC came out in 2002, 8 years before the release of the iPad. The devices were bulky, battery life wasn’t great, and the pen input wasn’t very accurate. Microsoft’s SPOT watch came out in 2004, about a decade before smartwatches became mainstream. The FM-based devices showed you sports scores and weather reports but weren’t very interactive. Apple’s Newton Messagepad came out in 1993, but its handwriting recognition was so bad that customers quickly abandoned it.

Sometimes a market is crowded, and it’s hard to compete with established products. HP’s Touchpad launched in 2011. It cost about as much as an iPad, and did some of the same things as an iPad. But, its lack of differentiation from iPads led to its discontinuation 49 days after launch.

Right product

Once you identify the right customer and the right time, it’s still easy to build the wrong product. Which features do you build? How do you position the product?

The answer is usually to test a product as quickly and cheaply as possible. Minimum viable products (MVPs) are useful because they tradeoff completeness for data, and teach you things that are hard to know in advance, such as how customers actually use a product. But, even before you build an MVP, you can test ideas with usability studies and interactive prototypes. These are quicker and cheaper than building an MVP, and can give you a surprising amount of information.

Doing the job

To find the right customer, talk to lots of them. Understand their problems, goals, and aspirations. To find the right time, study your market. Understand your competitors, and understand how your product will fit into (or disrupt) the market. To find the right product, test your ideas early, and deliver an MVP quickly to get data.

And, most importantly, make sure you’re transparent with this job. Bring your team along for the ride. It does your team no good if you’re the only one that can answer why your product is the right product, for the right customer, at the right time.

I worked in an incubation group for a few years at Microsoft called Office Labs. While I was there, I had the chance to interact with lots of people across different teams in the company who were working on version 1 projects. One of those teams was up a floor in my building, and they were trying to solve some of the same problems I was trying to solve. So, I set up a meeting with the team’s software architect in his office to see what they were doing.

What’s a software architect? It’s the person who figures out the standards and practices that dictate how engineers in a team will build the product. A software architect makes decisions about tools, platforms, how different components will work, and how different pieces of the product will communicate with each other.

As I sat in this architect’s office, he proceeded to describe what he was trying to build. He showed me some diagrams. He demoed a couple of prototypes. And, he listed the decisions he had made up to then. The goals were ambitious, and the technology, while nascent, looked promising.

At one point near the end of our meeting, I asked this architect a question: “So, what customer is this technology for, and what are they going to do with it?”

The architect paused. He looked at me, and said, “You know, I’m not really sure. You’ll have to talk to a PM on our team about that.”

I politely wrapped up our meeting and headed back downstairs to my desk. My head was spinning. How was this very experienced engineer with decades of experience not clear on who his product was for, and how it was going to be used?

At first, I thought that this architect was at fault for not being able to answer my question. But then, as I thought about it more, I realized the real blame fell on the product managers on the team. If the product managers were not clearly describing the customer and his or her goals to everyone on their team, how was this architect or any other engineer supposed to evaluate whether the team’s work was contributing to a successful product?

It’s the responsibility of a product manager to make sure everyone on the team knows who the customer is, what they’re trying to do, and how the product is doing to help them do that.

If you’re a product manager, make sure everyone on your team knows the answers to these questions.

Often, I get questions about what it means to manage products, how to develop as a product manager, or what I think of product decisions in the software we use. Based on the feedback from those hearing my answers, I thought I’d start a blog to capture and share my thoughts.

While I welcome all readers, I believe those who work in a technology industry or those in a product management role will find what I write most interesting.

I welcome all (non-spam) comments! And, feel free to subscribe by clicking on “Follow” or entering your email address under “Follow Blog via Email”.