What product managers should do in their first month

Congratulations! It’s your first day at your new product manager job. You’re excited about the company and its mission. You’re looking forward to meeting your team. Your new hire orientation is done. Now what?

Starting a new job can be overwhelming. It can feel like a firehose of information is hitting you in the face every day. Where should product managers focus their time in their first month? Here’s my list.

Meet the right people

Product managers need to learn to be effective in their organizations. That is hard to do without knowing and working with the right people. This goes beyond your immediate team of engineers and designers.

On your first day, talk to your manager and find out two things:

  1. Who are the people outside your team you should work with?
  2. Who are the stakeholders that are interested in making sure you succeed?

#1 may include people in marketing, business development, operations, data science, and the field. They will help you figure out what products to build and how to deliver them to customers. #2 may be leaders in these or other parts of the organization. You may not work with them every day, but they are good sources of feedback on your plans.

Know your customer

To build great products, you need to know your customers and what they want. It’s good to spend time reading customer research that your colleagues have already amassed. But, there’s no substitute for doing your own research. Reading product reviews, driving usability studies, traveling to field offices, and doing first-hand interviews are all good ways to know your customer. Don’t forget to bring what you learn back to your team. Often, you’ll have something new to share.

Ship a quick feature

The best way to figure out how to get things done at your new job is to go through the motions of researching, designing, building, and shipping a feature. Even if you’re a manager, shipping a feature will reveal how decisions are made in your new organizations and highlight the strengths and weaknesses of your team.

This is especially important for managers; if you don’t go through the process of building product first-hand, you won’t be able to judge first-hand what is and isn’t working well.

Get a mentor

Mentors are invaluable in giving you feedback and showing you a perspective you won’t have when entering a new organization. Find someone who’s an expert in what you’re not, and ask them if they’re willing to mentor you. If you’re not sure who to ask, get advice from your manager.

Read a book

There’s likely one or two books everyone around you has read and values highly. Ask your manager or mentor to name them. Maybe it’s a book about being a good manager, or staying innovative, or the trials and tribulations of running and scaling startups. Whatever the book is, if it’s in the headspace of your colleagues, it’s probably a good one for you to read.

. . . . .

The first month at your new product manager job will start slowly and end quickly. If you do the above, I bet you’ll exit the month will a lot of groundwork that will set you up for success in your second month and beyond.

Get ahead of the FUD

Screw-ups are inevitable. Sometimes, our screw-ups are behind closed doors, with a small number of people. But sometimes they’re done in public, in front of customers. When public screw-ups happen, it’s important to correct the mistake quickly and publicly. Any delay will hurt you and your product through the fear, uncertainty, and doubt (FUD) created through negative word-of-mouth, news articles, and social media.

Xbox One

I was on the Xbox team when the Xbox One was announced. When you read the press release, there’s a lot to like: new games, new controller, new Kinect. Looking beyond the PR, customers quickly learned the initial product was always-online, restricted support for used games, required a purchase of a Kinect, and cost $100 more than Sony’s PlayStation 4. Customers were surprised at the changes, and took to the Internet to complain, including members of the military.

Articles were written immediately after the announcement adding to the FUD of what the console did and did not support.

The result is that instead of collecting the accolades, and maybe even getting an early leg up on Sony’s PlayStation 4, Microsoft is already on the back foot. It’s come out early, and laid down core “features” of its console that are wildly unpopular with people who you may call vocal forum goers, but who are also the preorder customers, the early adopters and product evangelists.

About a month later, Xbox backtracked. But the damage was done; PlayStation 4 has gone on to beat Xbox in sales.

Revolv and Nest

I was an early adopter of Revolv, a home automation hub. It cost $300 but promised lifetime service and support for dozens of different home automation devices. It worked well, and the company was regularly releasing updates to its software. Then, in October 2014, Nest acquired Revolv and ceased sales of the hub and updates to its software, but support for the hub’s service was continued. However, in February 2016, Revolv announced they were disabling support for the hub’s service, rendering the device useless. Emails to the company were responded to with robotic sympathy and no recourse.

This went largely unnoticed given the small user base of Revolv, until articles appeared referencing first-hand accounts of the situation and shining light on the larger question of products tied to services, and what happens if a company decides to stop those services.

All of those devices have software and hardware that are inextricably linked. When does an expired warranty become a right to disable core device functionality?

Imagine if you bought a Dell computer and Dell then informed you that when your warranty ends your computer will power down.

Imagine if Apple put out a new policy that not only won’t they replace the device for defects, but they will actually be bricking your phone 12 months after purchase.

Is the era of IoT bringing an end to the concept of ownership? Are we just buying intentionally temporary hardware? It feels like it. I own a Commodore 64 that still works.

After two months, Nest backtracked, and offered full refunds to its customers. But the damage to Nest’s reputation, at least for me, was done. Before this, I had pondered buying a Nest thermostat or camera. Now, I am unwilling to buy anything from Nest, out of concern for what their policies are around product support and sunsetting.

Beat the FUD

It took a month for Xbox to change its position on Xbox One. It took two months for Next to change its position on Revolv. This is an eternity, given media like Facebook, Twitter, and Medium and the speed at which they transmit information. In the absence of information during those one or two months, Xbox and Nest customers were given lots of FUD to think about.

If you make a product decision that your customers react negatively to, take steps quickly to fix the decision. Else, FUD may set you in a position that’s hard to overcome.

Don’t be busybored

More than once in my career, I’ve been busybored. This is when you are both very busy and very bored at the same time. It’s not a good feeling, working hard but not being engaged in your work. How is this state possible?

Busyness is a measure of how many things you have to do, and when you have to do them. Being busy means having a lot of high-priority items due around the same time. Often this manifests as switching often between tasks, dealing with interruptions to address pressing issues, and being worried about finishing everything on time.

Being busy is not inherently bad. Busy can be exciting. Launching a new product can be busy. Preparing to speak at a conference can be busy. Completing a merger or acquisition can be busy.

So when is being busy also boring? It’s when the things you are doing are very familiar and are not challenging you. The fifth time you’ve solved the same problem, negotiated the same contract, or written the same kind of document is less interesting than the first. The tenth time can be tiresome.

Being busybored can impact productivity. If you’re used to delivering great work, but aren’t being challenged, you’ll notice productivity fall as the intrinsic rewards for pursuing and engaging in work fall.

Are you feeling busybored? If so, it’s probably hard to fathom making time to reflect on this feeling when there are problems and meetings and phone calls and deadlines, but it’s really important that you do make time. Even 15 minutes at the bookends of the day to think about how to fix busyboredom will pay dividends.

Here are some ideas on how to get out of this state:

  1. Do less. Sometimes, the solution to being busybored is to spend less time on the things that are familiar, and more on the things that are novel and challenging. Make a list of what you’re working on that’s keeping you busy. Flag the things that you find less engaging. Then, triage the less-engaging items. Can some things wait? Can you delegate some of them?
  2. Coach someone else. Delegate a task to someone who wants the experience, and coach them through it. Teaching is different than doing. As a teacher, you’ll look at the work from a different perspective.
  3. Talk to your manager. Don’t keep the feeling bottled up. There may be a really interesting project sitting in the wings that your manager knows of. If you let him know you’re feeling busybored, he may help pull things off of your plate to make room for the new, more interesting work.
  4. Think bigger. Look for ways to make the work you’re doing bigger than what you’ve done before. Is your work solving a symptom? Solve the root cause this time. Did your boss ask for the same thing again? Figure out how to deliver something extra that she didn’t ask for.
  5. Find something new. Sometimes, being busybored is a sign that you’ve outgrown your role. If there are no new challenges in sight, it may be time to find something new. This is not a quick fix and has lasting implications, so I wouldn’t suggest it unless you’ve exhausted all other avenues.

Most importantly, don’t wait for this feeling to pass, or expect someone else to make it go away. Use the opportunity to find your next challenge that will re-engage you in your work.

 

Performance is a feature

People pay for performance. Fast cars are pricey, next-day shipping is more expensive than having to wait a week, and the speedier CPU in your new laptop costs more.

Performance is also a feature of a product, and something that should be traded off with other features when deciding what is in scope for a release. It should not be taken for granted or considered an after-effect of all other product decisions.

Dieter Bohn’s recent article on smartwatches highlights this pitfall:

How long are you willing to stare at it as it chugs along trying to achieve the thing you actually want to do? One second? Two seconds? Surely not more than three. Let’s call it the Three-Second Rule: If something takes more than three seconds on a smartwatch, they blew it.

On most smartwatches, a lot of things take more than three seconds. When that happens, you shouldn’t spend those seconds dreaming of a future smartwatch that will be faster thanks to the inevitable march of progress. You should spend them being annoyed by the product managers who created software that was designed for some mythical future processor instead of the thing actually inside your watch.

Fast is relative

Assuming it’s ticking along, an analog watch can show you the time in about as long as it takes you to glance down at your wrist. A paper notebook is instant on, never runs out of batteries, and the pen or pencil lets you write extremely quickly and accurately.

A smartwatch and a note-taking app can do a lot more things than a Timex or a Moleskine. However, when it comes to performance, smartwatches and note-taking apps are judged relative to the performance of existing products. 3 seconds may be extremely fast for what the smartwatch is doing on the hardware it’s doing it on, but that doesn’t matter if customers expect 0.3 seconds.

The reverse is also true. Consider email compared to writing a letter. Email is much faster than writing out a letter and sending it by post. Years ago, people were happy to send and receive email even if transmitted via a slow, 14.4K modem (if not an even slower 1200 baud!), because email plus a slow modem was still faster than snail mail.

Making the tradeoffs

It’s easy to say performance is the most important feature of a product, and must trump all others. It’s also easy to ignore performance and hope that the features of a product don’t slow the experience to a crawl or cause it to consume an excessive amount of resources. The right answer is somewhere in the middle, and also involves having a plan.

Here’s one high-level outline of a performance plan for your product:

  1. Set performance goals. You need to figure out what is considered adequate performance for your product or feature, as well as the range from exceptionally good to exceptionally bad. You can do this by studying competitors’ products, traditional solutions, as well as prior releases of your own product. Set these goals with the customer’s expectations in mind, not with your feature list, dev costing, or architecture in mind.
  2. Anticipate performance issues. Before a new feature is built, you should try to predict performance issues it may raise. Steps should be taken to mitigate if not outright remove these issues. Here, tradeoffs will occur. Sometimes addressing performance issues will come at the expense of more engineering work, other times at the expense of scoping down a feature, and still other times at the expense of adding resources to the device and charging customers more.
  3. Measure as you go. With your goals set, you need an efficient way to measure your product’s performance, and you need to alert people when features are falling below goal. Often the right answer here is something automated and objective; stopwatches and your laptop connected to a public wifi access point will only get you so far.
  4. Invest time to fix the issues. It’s important not to underestimate the time it will take to fix performance issues. Tradeoffs will occur here as well. You’ll need to decide whether it’s more important to fix a performance issue versus a functionality or UI problem at any given time. And, sometimes, you may be forced to delay shipping a feature in order to have more time to fix its performance issues.

Keep performance top-of-mind

On my first product team, we had someone focused on performance testing. He had this giant, ugly trophy that was the performance trophy; I believe it was called the Joey Award, and had a caricature of a kangaroo on it. You, the developer, won this trophy if you happened to own the slowest feature in the product. You had to place this trophy on your desk for everyone to see. The only way to get rid of the trophy was to improve the performance of your feature such that it wasn’t the slowest feature anymore.

This trophy made it very obvious who had the slowest feature at any given time. But, more importantly, it kept performance visible and top-of-mind among everyone on the team. Seeing this visible marker of slow performance every day, and receiving regular emails about who the new recipient was, kept everyone on the team thinking about how to make their feature faster and consume less resources.

Performance is delightful

Delivering a product with great performance doesn’t just mean a better user experience. Great performance lets customers get things done more quickly, builds loyalty, and gives customers a reason to brag about your product to friends. While not always easy to pull off, a product with great performance is a path to a delightful product.

 

A product manager’s most important job

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.

Don’t hide the customer

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.