Product Management Is Not Project Management [Mind the Product]

As a product manager, it’s easy to get caught up doing the wrong job. With so much time and energy going into shipping great products, the project management demands of it all often create a center of gravity that’s hard for even the most veteran product managers to escape.

But the most successful product managers know how to stay focused on what matters most. They understand that while go-to-market teams are always looking for support, nobody is necessarily asking whether it’s the right product in the first place. That’s the product manager’s job.

In other words, product management is not about making sure products ship on time – it’s about understanding the needs of the customer and defining the right product to meet them. The very best product managers also know how to evangelize internally. They are masters at sharing insights across the organization and helping everyone to understand the product they are building and why.

The best way to become a great product manager is to focus on the basics:

Listen Constantly

There’s no better predictor of a product manager’s success than how much time they spend talking with current and prospective customers. Great product managers spend as much time as they can (ideally, at least half of their time, although I realize that is aspirational) connecting with customers and listening to what they have to say. They also know how to peel back the onion and really dive deep with customers to understand the problems they are trying to solve. This may vary by industry – most B2B product managers are in more regular conversation with their customers than B2C product managers, however the impact of this feedback on B2C businesses can often be greater.

Step one is carving out the time: block out the time on your calendar and stick to it. That’s easier said than done, of course, but establishing a routine and workflow is critical. One of our product managers has developed a set of hacks to make this process easier, including having a learning objective for customer conversations instead of an agenda, emailing from your personal email instead of an email service provider, and using a calendaring app to avoid scheduling back-and-forths. Without an easy workflow, all that time you earmarked for talking to customers quickly gets bogged down in admin work or, worse, just gets ignored – and that won’t cut it.

At Amplitude, the product team sets goals for the number of customer conversations per week and then tracks progress against that goal. Additionally, we make sure that each of our product “pods” has two-to-three customer development partners that the entire pod – including engineers – meet with every two-to-three weeks. Lastly, we share product ideas and mocks directly with those customer development partners for their feedback, which they are excited to provide – in fact, sometimes they even leave comments on each other’s feedback.

Step two is asking smart questions that lead to meaningful answers. This is how you get below the surface and tap into what’s really driving your customers. One tried-and-trusted approach is asking “why” five times. Essentially, as you click down deeper and deeper, you cut past the symptoms and get to the heart of the problem.

But “why” alone will only get you so far. To truly understand your customers, you need a 360-degree view of their world. Let your customer drive the conversation, and continue to drill down until you truly understand the root cause of their problem or pain point. Great product managers don’t just read through a questionnaire but enter these conversations from a place of curiosity.

Measure Religiously

Talking to customers is key to understanding how to build the right product, but conversations alone are not enough. While they provide important depth, broad visibility matters too – especially as a company grows and the user base becomes more diverse.

That’s why we have product analytics. In a world where data is the voice of your users at scale, product analytics software is the translator. It helps you to understand what users are collectively trying to tell you through their actions, and there’s really no other way to get that insight, even at relatively modest scale.

But great product managers understand that it’s not enough to just buy some analytics software and plug it into the product. Without context, all the data will tell you is that some specific action happened in the application – not why they did it or whether the action had the intended effect, just that it happened.

Where does the additional context come from? Talking to customers. The more conversations you have, the better read you have on user behavior and the easier it is to connect the dots between analytics and intent.

One of our oldest customers is Intuit. We now work with three different business units at Intuit, and it has successfully created a culture of proactive data democracy using Amplitude that has allowed Intuit to become a leader in product innovation. But it clearly didn’t happen overnight.

When Intuit originally launched an invoicing feature within its Quickbooks accounting product, it didn’t get the result it wanted. A majority of its customers weren’t emailing their invoices to get paid on time, which is a big problem. In talking to customers, Intuit discovered that the workflow was not optimized for Gmail, which has over one billion users worldwide. The Intuit team used this insight to develop and launch a Gmail plug-in that immediately improved the rate at which customers are getting paid as well as their experience in Quickbooks.

Evangelize Internally

While gaining a deep understanding of customers is critical, it’s not valuable until it’s shared. Remember, your job is not to build the product, it’s to provide those teams with the insights they need to build it right.

For that reason, product managers must learn to become expert evangelists. That means spending a lot of time communicating internally within the product development team, engineers, designers, and other product managers. At Amplitude, our product organization doesn’t just present at company all-hands meetings, but also shares notes after every customer call in a dedicated Slack channel so they can be read by the entire product organization. The goal is to clearly define the problem the product is looking to solve.

I cannot overstate how critical this evangelization is. Often, it’s even more important than defining the solution itself. That’s because if people understand the problem really well, chances are they will figure out the optimal solution all on their own, and sometimes even come up with innovative ways to get there too.

This is in part why we divide our product organization into “pods,” small teams that work closely with our customers to address a specific problem or feature. They work in a maximum of 12-week cycles and vary in size between one and five people, but no more than five. They typically include a product manager, a designer, a technical lead, and an engineer, although sometimes they can just be a product manager, engineer and designer. Our product leadership team identifies the core problems we want to solve for customers and use that to set our “problem roadmap,” and then we align our pods against that. The pods then come up with innovative ways to solutions to address those problems. The entire Taxonomy package we released back in September came out of this process.

Feedback Loops

And this underscores perhaps the most important lesson of all: there is no defining the problem and calling it a job well done. Great product managers continually develop their understanding of the problem by talking with customers, measuring how those customers use the product, and evangelizing those insights to the entire team. Instead of looking for the finish line, they create feedback loops between products and their customers and do everything they can to keep it running.

Project management, to be sure, is a component of the product manager’s job, but it’s not the focus. Too often, product managers spend their time building Gantt charts, writing specs and worrying about workflows, instead of obsessing over customer problems, studying customer data, and articulating those insights across the company.

The post Product Management Is Not Project Management appeared first on Mind the Product.

Source: Mind the Product http://ift.tt/2m9iYoP