[ad_1]
The answer might surprise you.
A month back I was asked to speak with a young digital product team within my company. The team’s Director that reached out to me had a very simple request…
“Can you please help me explain to my team what a product manager is and does, exactly?”
This felt like a simple request, right? After-all, I write about the craft of Product Management weekly on Medium, have launched many successful digital products myself, and coach new PMs all the time…so how hard could it be to put together a quick introductory lecture on the topic?
Spoiler alert: it was hard.
But, eventually I arrived a decent enough primer to put forth the core ideas. The ideas that are worth having on sticky notes on your desk to reflect on throughout the week. While you may feel you know exactly what a Product Manager is, you might be surprised to hear that many of this team thought they did, too. With this in mind, I’d encourage you to read along.
I’m going to borrow from Marty Cagan for a moment, and put a little spin on his now famous description of the job:
The job of a product manager is to discover a product that is valuable to your customers, usable for your users, and feasible for your business.
There’s a lot of reasons why I love this quote, but the thing I love the most about it is that right out of the gate it shows you that a Product Manager is someone that sits in the middle of a lot of people, teams and organizations. This Venn diagram further clarifies the idea:
To put it in even plainer language: your customer wants a problem solved and your business wants value added back to the business. Your “tools” for delivering this customer solution and enterprise value is the enabling technology and the user experience (design). The Product Manager has the unique role of sitting amidst each of these groups to ensure that (in a collaborative way with designers and engineers), a customer problem is solved in a way that is valuable to them, that is useable by them, and is feasible (both operationally and financially) for your company to build and support.
Before we continue, I think it would be helpful to talk about what a Product Manager is NOT. Given the complexity of the role and how nuanced it is, in some ways it is easier to see the role by first tracing the outline made by all the negative space around it.
#1: A Product Manager is not a Project Manager
Yes, as a Product Manager you will have features that need be managed like projects to ensure successful delivery. Yes, as a Product Manager you will likely use some form of task management tooling and have to report out on and analyze a release plan. But unlike a Project Manager, the buck stops with you. You are the one that is held responsible for not just the delivery of the feature, but everything else as well. Was the right problem selected to solve? The right user type to solve for? Can the business make money on it? How will we learn from it once it is in the wile? Etcetera, etcetera. A Project Manager is typically responsible for ensuring the thing gets delivered on time and in the right sequence, but if the thing that is delivered failed, that isn’t on the Project Manager. They did their job. This is not the case for Product Managers — they are held responsible for both output and more importantly, outcome.
This is not the case for Product Managers — they are held responsible for both output and more importantly, outcome.
#2: A Product Manager is not a Product Owner
Product Ownership is super important, so please do not misread this one as a critique of this role. Many Product Managers ALSO share the responsibilities of a Product Owner, so let be clear up front…someone has to do this job, or the product won’t be responsible.
With this out of the way, let me get to the point. In a nutshell, a Product Owner is a member of a SCRUM team, within an Agile context, whose goal is to manage a product’s backlog to ensure the success of a product. While there is undoubtedly some overlap with Product Management, here is the big distinction I want you to take away: Product Ownership exists only within the context of Agile/SCRUM, and is tethered to the development team. This means, if your team changes the way they operate and adopts a different framework, the role of a Product Owner could vanish. Additionally, the role carries an intentionally tight focus on the development team, and lacks the wider view of a Product Manager. A Product Owner cannot start their work if a Product Manager never identifies the right users pains and business opportunities to begin with.
A Product Owner cannot start their work if a Product Manager never identifies the right users pains and business opportunities to begin with.
#3: A Product Manager is not an executive’s feature coordinator
There’s some overlap here with point #1, but I wanted to call this out specifically because of the unique dynamic here. It is very common, especially at companies that have only recently adopted digital products, for those in charge to believe that they know exactly what the digital team should be releasing, and so they simply dictate feature requests to the Product Manager, and expect them to coordinate the development team as a project manager. Here’s the even bigger challenge with this…sometimes these executives get lucky. The feature might get released, and it might actually move the needle a bit…but here’s the rub. Here’s the thing I want you to remember: Features are not released in a vacuum — they are released at the expense of other features. Those 4 sprints it took to release this thing…they are gone, you will not get them back. So maybe the solution your executive wanted you to release had some kind of impact on your KPIs…but at what expense? What did you not release in it’s place, and what would the impact of this have been?
Features are not released in a vacuum — they are released at the expense of other features.
OK, fair enough. Let’s get tactical. Let’s look at some of the main responsibilities of a Product Manager, and what activities are done in each of these areas.
#1: Study the customer, business and technology
Without a deep understanding of your customers, your business and what technology your team has at your disposal, you will be unable to do execute any of the other responsibilities in this list.
Activities for studying your customer: Conducting customer surveys, reviewing user analytics (funnels, trouble points, etc.) and replay sessions in your analytics tools, conducting/observing user interviews, assisting your design team in User Experience research, reading market analyst reports on your industry/target user, building and maintaining user personas.
Activities for studying your business: Studying the business’ financials and KPIs, meeting with and learning from your network of stakeholders, studying the funnels for your products and business as a whole, spending time with the various dashboards to understand how other metrics relate to the overall strategy.
Activities for studying your technology: Learn what tools and technologies are on the rise and in use in yours and other markets, review tech design maps of your products architecture, review the data models and data definitions your products use.
#2: Develop the product vision and strategy
Once you have an understanding of these three main areas, you will be ready to start working to define or refine the vision and strategy that guides and governs your product/feature area. Starting with the vision is absolutely critical, as it makes up the foundation upon which everything else is built. The article below goes into more detail about why setting a strong product vision is so important 👇
Your vision paints the picture of where your product and business want to go, and your strategy describes how you will get there. There’s no one way to go about creating and evangelizing these, but are some activities that I find myself doing in this area:
Your vision paints the picture of where your product and business want to go, and your strategy describes how you will get there.
Activities for creating a product vision: Researching other companies vision statements, talking with various leaders internally to hear where they see the business going in 10+ years, writing the vision statement, building a vision “prototype” that shows (visually) where your product is headed in the future, and taking every opportunity to share this vision with your team.
Activities for creating a product strategy: Identifying key initiatives and themes that the rest of your feature work will roll up to, working with product owners to analyze existing backlogs to ensure work aligns with this strategy, meeting with tech leads to ensure technology architecture/infrastructure points towards this future state.
#3: Define the problems and solutions
This is where the rubber really meets the road. Once you have an understanding of your customers, business and tech-stack, as well as a strong, future-facing product vision and associated strategy, it’s time to decide what specific problems your product is actually going to try and solve for, as well as what those solutions look like in practice. Can I share with you something that might be a bit new to you? Listen close: Understanding the problems you could solve is more important than understanding the solutions you could deliver.
Understanding the problems you could solve is more important than understanding the solutions you could deliver.
You could have the most rock-solid, beautiful, customer-focused solution in the world…but if it’s designed to solve the wrong problem, it might end up as a giant waste of time. Don’t get me wrong — solutioning is really important, but if you really want to stand out amongst your PM peers…spend more time than you do today thinking through, discussing and documenting the “problem space” of your customers.
Activities for understanding customer problems: Interview customers and client success personnel, build a Gap Anlaysis matrix, write and socialize problem briefs, build a competitor matrix, build and annotate a problem backlog, begin talking about customer problems with your stakeholders and product development teams early in the process, long before solutions are being designed.
Activities for understanding solutions: Write a written narrative for your solutions, develop multiple hypothesis per problem and socialize early with customers and internal team members, determine the KPIs you want to measure/influence as a part of this solution and determine what high level success or failure looks like, build an operations plan to determine if your current organization could handle launching and supporting this feature (what teams does this feature impact, and what impact will it make on them?), build hyper-lo-fidelity prototypes or screen mockups to validate these early pre-design concepts.
#4: Build the Roadmap
Oh, roadmaps. We put up with them, our stakeholders demand them, and our engineers hate them. But they are a necessary evil, as they serve an important purpose: They help align both internal and external expectations, and build some degree of accountability into the product development process. “The role of roadmapping” is it’s own article, but at a high level it’s important to understand that having a roadmap that is general enough to give your product development team the space to do agile development right, as well as specific enough to hold the team accountable to delivering key solutions at key times, is really important.
Activities for building a roadmap: Manage, scrutinize and rank your backlog by multiple factors, host quarterly cross-squad planning initiatives where squads get to deeply collaborate and map dependencies (for large organizations), collaboratively build roadmaps with stakeholders and engineers, understanding business needs and development realities, build multiple roadmap “views” (tailored to the audience).
#5: Lead, inspire and teach
Even though you might be an “individual contributor” product manager (meaning you do all the work yourself and do not have PM’s reporting to you), you are still the face of your product/feature area. Despite my reservations about this phrase (read the article below to learn more), you are the CEO of your product.
This means you are expected to lead your team, passionately communicate your customers needs (and the associated business opportunities) and inspire those around you with your product’s grand vision. This isn’t just a “fluffy” part of the job — this is material work that is worth you spend time on, and has very real results in the form of better designed products, and lower attrition.
Activities for leading, inspiring and teaching: Constantly review and refine your product’s strategy and how it aligns to your vision, use team ceremonies (like the retrospective) as a platform to give brief updates on key work happening across the company or the product, host kickoff meetings where you invite the entire product, development and engineering teams to explore upcoming work, invite these same people to story mapping sessions where you build a shared understanding of what you are looking to tackle for your customers, and take every opportunity to celebrate launches and wins, highlighting individual developer/designer accomplishments.
Let’s go back to this diagram for a second, as it will help me make this very simple point, one that I think by this point in the article you will agree with. In order for a successful product to exist, someone has to sit in the middle of these three circles. This isn’t my personal opinion — it’s a cold fact. Lightning might strike once, and maybe you luck out and get a feature into the wild that does marginally well without any centralized owner, but I can promise you this won’t happen two times in a row. Or three times. Or four. So this begs the question…if this person is not a Product Manager…who is it? I can think of really only three scenarios where a titled “Product Manager” isn’t needed:
#1: At a new startup, often the founder carry these responsibilities…but for any kind of scale to happen, ultimately there will need to be dedicated product oversight, with the founder focusing on the other (MANY) areas that require focus to build a company.
#2: If your customer base is VERY small (a handful of people), and their needs are perfectly known throughout the entire organization. (This one is a stretch)
#3: Your customers are internal and you basically get your roadmap from another internal team that you support (like a backend services team within a larger technology company).
To better illustrate this point, let‘s walk through something I built called the “6 Questions Exercise”. There are six questions we have to answer to ensure success, and missing even one could/likely will result in the product’s failure:
Why?
You understand the needs of your business (the “Why?”), and so you build a solution that simply is designed to increase those key metrics…but you failed to realize what problems the customer wants solved, and so the product is a failure.
What?
Now, you understand the needs of your business AND what problems the customers wants solved, but you failed to recognize that you focused all your efforts on the wrong user and missed the actual customer and so the product is a failure.
Who?
Now, you understand the needs of your business, what problems the customers wants solved, and who the right customer is, but you failed to recognize that you released your product at the wrong time (bad market, competitive releases, technology trends shifting, etc.) and so the product is a failure.
When and Where?
Now, you understand the needs of your business, what problems the customers wants solved, who the right customer is, and what the right release timing is, but you failed to understand how challenging this solution would be for your organization to support operationally, and so the product is a failure.
How?
Now, you understand the needs of your business, what problems the customers wants solved, who the right customer is, and what the right release timing is, and are ready to move forward with your solution…but what other questions could we be missing?
[ad_2]
Source link
