Показаны сообщения с ярлыком guide. Показать все сообщения
Показаны сообщения с ярлыком guide. Показать все сообщения

пятница, 8 ноября 2024 г.

The Ultimate Guide to Statements of Work — Here's Everything I Know

 


I have been freelancing for nearly 6 years now (gosh, time flies). Initially I didn’t formalize my agreements with clients — no signed documents or contracts.
But as I gained more experience, I realized that if I wanted to grow my business I had to set ground rules and put them in writing. Once I introduced contracts, which included a statement of work, working with clients became much easier.

There is something about contracts that encourages (most) people to follow the rules. The more work you take on, the more important it is to organize it properly.

Trust me, scaling your business without a contract is hard, if not impossible, to do. So in today’s post I am going to discuss what a statement of work is and how to create one.

What is a statement of work?

SOW vs. Contract

A contract is a legal agreement between two companies, or an employer and employee, that describes the completion of specific work for an agreed rate.

While both SOWs and contracts are crucial in business and project management, they serve different functions.

Let’s take a more detailed look at how these two documents differ.

Purpose

An SOW acts as a detailed project plan that explains what must be done. It mainly focuses on tasks and deliverables.

A contract, on the other hand, creates a legal framework for the relationship between parties. It sets terms and conditions, which guide the relationship along with rights and responsibilities. It explains in detail what will happen if one of the parties fails to deliver on the agreed terms.

Content and Structure

An SOW covers project details, including tools, methodologies, timelines, acceptance criteria, etc. Unlike a contract, it’s written in easy to understand language, without any jargon.

Contracts include broader terms and conditions like liability, termination clauses, payment, and dispute resolution procedures. They use formal legal language to guarantee enforceability.

Legal Binding Nature

On its own a SOW is not legally binding. It mainly acts as project guidelines. A contract is a standalone legal agreement, which if breached can draw legal consequences.

Level of Detail

An SOW is project specific and therefore very detailed. It describes what needs to be done and when, and can include technical specifications. A contract is more generic, offering a high level overview of the relationship. You can use one contract for multiple projects.

Flexibility and Changes

SOWs can be modified if needed; if the scope of work changes or more work is required, you can simply add it to the SOW.

Just bear in mind that you might need approval from relevant stakeholders. It’s not as easy to modify a contract. It usually requires formal amendments and adherence to legal protocols. Also, changes can only be made through mutual agreement.

Use Cases

A SOW is often used in project management contexts, such as marketing campaigns or IT projects that call for specific deliverables and timelines. They’re particularly useful when multiple stakeholders are involved.

A contract can be used virtually in any context, including vendor contracts, employment, and service agreements. It’s especially beneficial to have one in place for long-term collaborations.

Statement of Work vs. Scope of Work

A scope of work is usually part of a statement of work. Occasionally, it can act as a standalone document. It includes information on project size, team goals, and steps required to finalize the project. While these two terms are often used interchangeably, they refer to different project management concepts. Here are the main differences.

Purpose

The main aim of an SOW is to give a detailed overview of the project and make sure that everyone involved understands their responsibilities and expectations.

The scope of work, as the name suggests, defines what a project includes — what’s covered and what’s not. Defining specific tasks and deliverables prevents scope creep.

Content and Structure

An SOW covers project objectives, roles and responsibilities, timeline, payment terms, etc. It focuses on both the “what” and “how” (i.e., the methodology).

The scope of work contains detailed information on the tasks and deliverables, such as a description of the work to be performed, project objectives and goals, key milestones, constraints, and exclusions.

Legal Binding Nature

Both of them can be legally binding if they’re included in the contract. As standalone documents, they have no legal power.

Level of Detail

Since an SOW covers many project details beyond the scope, it’s more comprehensive.

The scope of work focuses specifically on the work to be done, and includes high-level timelines and deliverables without going into depth on management and execution.

Flexibility and Changes

Modifying an entire SOW can be more challenging, as it covers multiple aspects of the project, and a single change can impact various components. It might also require formal approval.

The scope of work, on the other hand, is easier to change as it only applies to the work involved. While it might still require stakeholder approval, a change won’t necessarily impact other parts of the project.

Use Cases

The scope of work is part of an SOW, and both are used in complex projects that need detailed information to guarantee successful delivery. For simpler projects, the scope of work can be used as a separate document to define a task.

Both of these documents are often included within a contract to provide a full overview of the agreement.

Purpose of a Statement of Work

The main aim of the statement of work is to make sure that all parties clearly understand their roles and responsibilities. Whenever I start working with a new client, I sign a contract that includes a statement of work.

I outline when they have to deliver project briefs, how many revisions they’re entitled to, what will happen if they fail to provide feedback on time, and so on.

Including such details not only helps me deliver projects on time, but also helps avoid misunderstandings. It also allows for some flexibility in how we work together.

Types of SOWs

Design

Design SOWs revolve around the design and development of services or products, but you’ve probably figured it out on your own. They list specific design-related tasks, like research, prototyping, and testing.

The contractor’s role is to deliver a design, which is in line with client requirements. The SOW outlines milestones for design evaluations and approvals.

The website design template below gives you an idea of what this type of SOW could look like.



Level of Effort

If you’re unsure how long it will take you to finalize the project, or what resources you’ll need, it’s best to go with the level of effort SOW.

Also referred to as time and material, this approach involves paying for the hours worked along with any materials used to do the job.

This type of statement of work is usually used in consulting services or agile projects, which are prone to changing requirements.


Performance-Based

Performance-based SOWs prioritize project outcomes over the process. They provide an overview of the goals and objectives that contractors are obliged to achieve. Payments depend on the achievement of the predefined metrics.

This type of SOW is best used when you have a specific objective in mind, for example, increasing online sales by 30%.


Components of an SOW

Let’s take a look at what should be included in a statement of work. Since I am a freelance content marketer, I’ll use examples from my own projects related to SEO blog writing.

Introduction

This section explains the work that will be done and gives general information about the project, including who will be involved.

In my case, the introduction could be:

“This Statement of Work outlines the SEO blog writing services to be provided by Anna Rubkiewicz for HubSpot. The project involves creating optimized blog content to improve organic search rankings, drive traffic, and engage target audiences. Both parties agree to the terms outlined in this document.”

Purpose Statement

The purpose statement addresses the reasons for starting the project. It discusses the main objectives, covers deliverables, and defines what success looks like for different stakeholders.

Here is an example:

“The purpose of this project is to enhance HubSpot‘s online presence through SEO-focused blog content. The key objectives include increasing website traffic, improving search engine rankings, and providing valuable information to the target audience. The project aims to deliver 12 high-quality blog posts over the course of 4 months that align with the client’s content strategy.”

Scope of Work

This section lists all the tasks which should be completed on the project. It provides a detailed overview of the processes, including time frames (they can be estimated), and a project scope which includes all the vital information.

“Anna Rubkiewicz will provide the following services:

  • Research and identify relevant topics based on SEO keywords provided by the client.
  • Write 12 blog posts (approximately 1,500 words each) optimized for search engines.
  • Include internal and external links where appropriate.
  • Provide meta titles and descriptions for each blog post.
  • Include graphics with alt text.”

I complete projects on a monthly basis so if I agree to deliver three articles per month, I state in the SOW that I will deliver all articles by the end of the month.

Where the Work Will Be Done

This part explains where the work will be done, remotely or at a specific location.

It also details all the equipment and software that will be used. I work remotely and communicate with my clients via email or Slack, and deliver all articles in Google Docs.

Tasks

This section breaks down all the steps you included in the scope of work into more detailed tasks. Here is an example:

  • Keyword Research. Collaborate with the client to identify target keywords and topics.
  • Research and Outline Phase. Research the topic and create an outline.
  • Writing Phase. Draft and submit the blog post for client review.
  • Revisions. Implement feedback and finalize the blog posts.

Milestones

This is where you include the project timeline, such as the start and finish dates, billable hours, and any other scheduling specifics.

Since I usually work with clients long term, instead of including a finish date, I ask them for one month's notice if they wish to end our cooperation.

Deliverables

This section lists project deliverables with their due dates and detailed descriptions. It helps set expectations for all the stakeholders. My deliverables would include:

  • 3 SEO-optimized blog posts per month (approximately 1,500 words each).
  • Meta titles and descriptions for each blog post.
  • A report summarizing keyword research and topic selections.

Schedule

In the schedule section, you can include a detailed timeline for each deliverable.

Personally, I don’t include exact dates. Instead, I tell my clients how much time they have to complete a given step.

For example, I give them three days to provide feedback on the outline and three days to review the draft. From my perspective, setting a time limit is the only way to guarantee timely project completion.

Project Success

This part of the SOW defines the success metrics. It could be the delivery of high-quality blog posts that are well-written and SEO optimized and generate organic traffic after publication.

Project Requirements

List everything you need to successfully deliver the project, including tools and equipment.

Whenever the project involves keyword research, I ask the client to grant me access to Google Analytics and export the keywords they’re currently ranking for.

I also put a strong emphasis on regular communication and timely feedback.

Payment Terms

This is probably one of the most important sections for any freelancer or business owner. It outlines how you’ll get paid — upfront or after delivering the project — and details how much time the client has to settle the invoice.

I issue all my invoices at the end of the month and give my clients two weeks to pay via bank transfer.

Here is a ready work-order template from HubSpot that you can download to document the work you’ve performed and ask for payment.

Closure

The closure part explains how deliverables will be accepted and signed off. My clients simply have to email me to confirm that the final draft has been accepted and no further revisions are necessary.

If I submit the final draft and don’t hear back within five days, I assume the article requires no additional revisions and close the task. Naturally, this is something that my clients are aware of and have agreed to.

Start every project with a statement of work.

At first, you might think that creating a SOW is a lot of effort.

But when you consider all the benefits — such as avoiding misunderstandings, setting clear expectations, dividing tasks efficiently, and ensuring timely payments, it quickly proves to be worth it.

Believe me, you cannot grow your business or deliver work on time without creating some ground rules. And if you put those rules in writing, they'll have even more impact.


https://tinyurl.com/y3rjvm3z

пятница, 11 октября 2024 г.

The Ultimate Guide to Product Management

 



The question, “What is product management?” comes up pretty often, even from experienced business people. One reason is that product management encompasses a wide-ranging area of responsibilities. Indeed, the role itself means very different things in different organizations.

Here is the most concise response we’ve come up with for the “What is product management?” question: Product management is the practice of strategically driving the development, market launch, and continual support and improvement of a company’s products.

Of course, that is an abstract explanation of the role. So what is product management? What does the job entail?

What is Product Management?

The day-to-day tasks include a wide variety of strategic and tactical duties. Most product managers or product owners do not take on all these responsibilities. At least some of them are owned by other teams or departments in most companies. 

But most product professionals spend the majority of their time focused on the following:

  • Conducting Research: Researching to gain expertise about the company’s market, user personas, and competitors.
  • Developing Strategy: Shaping the industry knowledge they’ve learned into a high-level strategic plan for their product—including goals and objectives, a broad-strokes overview of the product itself, and maybe a rough timeline.
  • Communicating Plans: Developing a working strategic plan using a product roadmap and presenting it to key stakeholders across their organization: executives, investors, development teams, etc. Ongoing communication across their cross-functional teams throughout the development process and beyond.
    • Coordinating Development: Assuming they have received a green light to move forward with their product’s strategic plan, coordinate with the relevant teams—product marketing, development, etc.—to begin executing the plan.
    • Acting on Feedback and Data Analysis: Finally, after building, testing, and introducing the product to the marketplace, learning via data analysis and soliciting direct feedback from users, what works, what doesn’t, and what to add. Working with the relevant teams to incorporate this feedback into future product iterations.

What isn't Product Management?

Product managers owning the day-to-day details of a product’s development is a common misconception. As we describe on our product management vs. project management page, this is the role of a project manager.



Product management’s strategic function

Product management is a strategic function. Tasking product managers with determining a product’s overall reason for being—the product’s “Why?” 

They’re also responsible for communicating product objectives and plans for the rest of the company. They must ensure everyone is working toward a shared organizational goal. 

Product management encompasses a broad set of ongoing strategic responsibilities. They shouldn’t be responsible for the ground-level details of the development process.

Innovative organizations separate this function and assign tactical elements to project managers, such as scheduling and managing workloads. This distinct division leaves the product manager free to focus on the higher-level strategy.



What is the Product Management Process?

There is no single “right” way to manage a product. Processes will evolve and adapt to the organization, the product lifecycle stage, and product team members’ and executives’ personal preferences.

But the discipline has developed some consensus regarding best practices. So while rigid adherence isn’t required and there isn’t the same level of zealotry as one might find when discussing Agile, the basic tenets are widely accepted.

Defining the problem

It all begins with identifying a high-value customer pain point. After that, people or organizations are trying to do something, and they can’t. Or, if they can, it’s expensive or time-consuming or resource-intensive or inefficient, or just unpleasant.

Whether it’s moving a person or thing from Point A to Point B, finding the perfect gift, reaching the right audience, keeping people entertained, or some other objective, what’s currently available isn’t quite cutting it. People want something better or something they don’t have at all.

Product management turns these abstract complaints, wants, and wishes into a problem statement looking for a solution. Solving that problem and easing that pain is the spark and motivation for everything that comes next. Without a clearly articulated goal that directly impacts that pain point, there’s not much hope that the product will gain traction or staying power.

Quantifying the opportunity

There are many problems and pain points, but not all are worth solving. This is when product managers swap their customer-centric hats for a business one.

To justify investment in building a new product or solution, product management must answer the following questions and be able to build a business case based on the answers they find:

  • What is the total addressable market?
  • Is the problem or pain severe enough that people will consider alternative solutions?
  • Are they willing to pay for an alternative solution (or is there another way to monetize the solution)?

Once product management has evaluated the potential market, they can then try to address it if there’s a significant enough opportunity.

Researching potential solutions

With a target in mind, product management can now thoroughly investigate how they might solve customer problems and pain points. They should cast a large net of possible solutions and not rule anything out too quickly. For example, suppose the organization already has some proprietary technology or IP or a particular area of expertise to give the company an advantage. In that case, those potential solutions will likely leverage that somehow.

However, this does not mean that product managers should start drafting requirements and engaging the product development team. They’ll first want to validate those candidates with the target market, although it is prudent to bounce some of these ideas off the technical team to ensure they’re at least feasible. Product management will often develop personas to see whether there’s actual interest among those cohorts using any of the table’s ideas. 

Skipping this step and jumping right into building something can be a fatal flaw or cause severe delays. While there are no guarantees, getting confirmation from potential customers that the idea is something they’ll want, use, and pay for is a critical gate in the overall process and achieving product-market fit.

Building an MVP

After validating a particular solution’s appeal and viability, it’s now time to engage the product development team in earnest. First, the bare minimum set of functionality should be defined, and then the team can build a working version of the product that can be field-tested with actual users.

Many bells and whistles will intentionally be excluded from the Minimum Viable Product, as the goal is to ensure the core functionality meets the market’s needs. Nice-to-haves can wait for a later stage in the product lifecycle since there’s little point in expending additional resources on an unproven product.

MVPs can test how the product works and the overall messaging and positioning of the value proposition in conjunction with product marketing. The key is finding out whether this nascent product is something the market wants and if it adequately meets its core requirements.

Creating a feedback loop

While customer feedback is essential throughout a product’s life, there’s no time more critical than during the MVP introduction. This is where the product management team can learn what customers think, need, and dislike since they’re reacting to an actual product experience and not just theoretical ideas tossed out in a conversation.

Product management must make it easy for customers to provide feedback and create frequent prompts soliciting it. But, just as importantly, they must process, synthesize, and react to this feedback, turning this input into actionable ideas that make their way into the product roadmap or backlog.

And, not to be forgotten, product management must also establish a method for closing the loop with customers so they know their complaints and suggestions were heard and, when applicable, have been addressed.

Setting the strategy

Assuming the MVP is well received, it’s time to invest in a product strategy. The team now knows they’re onto something that can get some traction, so goals and objectives must be established to improve the product, bring it to market, expand its reach, and align with the overall company strategy and desired outcomes.

The strategy should be based on reasonable, incremental progress toward achievable goals, with key performance indicators and other metrics defined to evaluate success. These measurables should track with the organization’s general objectives and complement what the company already does well (assuming it’s not a startup still in its infancy).

More than anything else, the strategy is where product management must secure stakeholder alignment and buy-in. If there’s no solid, shared understanding of this fundamental element of the product, then the groundwork is already being laid for future conflicts and disagreements.

Driving execution

With a viable product concept, a scalable feedback management system, and a sound strategy, it’s time to turn ideas into reality. This means prioritizing potential development items and plotting out the product roadmap.

Product management can utilize various prioritization frameworks to decide which development activities will help the product meet its most important goals quickly and efficiently, cueing things up for near-term work. Of course, everything can’t be first, so basing these decisions on which items have the greatest impact on critical objectives is key, including representatives from across the organization. With the initial priorities set, product management can then build out their product roadmap. This powerful tool enables stakeholders to visualize what’s on the horizon and why it’s relevant to the strategy, particularly if structured around themes and outcomes versus specific features and delivery dates.

The People of Product Management

Product management doesn’t have too many subspecialties, primarily because product people are expected to do a little bit of everything. However, this career has some variety, along with expected tiers of seniority and additional responsibility.

First, some jobs often get lumped in with product that doesn’t belong there. This includes project management, program management, product marketing, and scrum masters.

Each of those critical roles interfaces with the product management team quite a bit. Some organizations may even arrange those jobs into the same groups, such as making product management and product marketing part of the overall marketing organization. But these positions aren’t product management jobs, as they don’t actively define what is in the product or report to the people who do. 

Product Management Jobs

The ideal product management job is—unsurprisingly—being a product manager. A product manager will usually own one or more products or a horizontal function across multiple products, such as “user experience” or “e-commerce.” 

Associate product managers and junior product managers are typically new to the domain and have more limited responsibilities. A senior product manager will have a little more seasoning and a broader scope of their role. But these are essentially slightly different flavors of your basic product manager.


Technical product managers are another critical variation of the role. These individuals are often transitioning from a role in the engineering or IT teams and tasked with managing aspects of one or more products requiring a deeper understanding of technical issues, such as infrastructure and APIs.

Agile product managers

In an Agile organization, product owners also may be part of the puzzle. While there’s some debate, product owners are often considered part of product management. However, they are distinct from product managers. A product owner is embedded in one or more scrum teams, but their focus is mainly tactical, helping ensure the strategy laid out by product managers is appropriately executed. 

As one moves up through the ranks, more senior product management roles have more significant distinctions. For example, a product line manager will own multiple products that are typically related to each other, sometimes overseeing individual contributor product managers that manage a single product or sub-component.

The Product Executive Track

The executive track begins with Director and Senior Director roles. Depending on the company’s size, this may be a loftier title for a “lone wolf” product management professional. But, on the other hand, it may indicate an even broader portfolio of products and the corresponding direct reports to support that. 

Vice President and Senior Vice President are similar escalations up the corporate ladder. Those holding these jobs may see more diversity on their staff as they may also end up owning business analysts, UX, product marketing, or other related functions. The apex of a product management career is Chief Product Officer. Although not as common, this increasingly seen role elevates product management to the C-suite. It gives the product the same political weight as Engineering or Marketing, which often indicates an organization is committed to product-led growth. A CPO is typically supported by a larger team and provides directional guidance and coaching rather than diving into the nitty-gritty details of particular products.


What are the Most Important Product Management Skills?

With a shared understanding of product management’s scope, we can dig into what it takes to be a product manager. Product managers find their way by following the paths of those who came before them. And those more experienced in the profession have plenty of lessons to offer their peers and newcomers

You can’t get a degree in product management. There’s no single career path to get there. It’s more about the skills required to do the job well than a particular pedigree. Here are some of the key hard skills in product management.


Communication 

Communication skills leap to the top of the list when considering what it takes to be a successful product manager. So many aspects of the job rely on prowess in this domain. 

To solicit and gather feedback, product managers need to be great listeners. They must also know how to work those relationships and exhibit significant customer empathy.

Of course, customers aren’t the only source of input to the prioritization process. Product managers must also work with various stakeholders to understand their goals and needs

After that, product managers must succinctly convey the product’s mission. It should be a synthesis of all those inputs turned into something easily consumable that others can be inspired by.



Evangelizing and alignment

With vision, goals, and the roadmap defined, product managers must socialize and evangelize these pillars of the product to the entire organization. It’s all about creating alignment, generating buy-in, and getting the whole company on the same page, including leveraging public forums such as all-hands meetings, as well as smaller forums and one-on-one sessions.

Once the product plans begin taking shape, product managers must work extensively with the product development organization. This collaboration includes engineers along well with product managers, architects, and quality assurance teams. 

Collaboration

To create a fantastic user experience, product managers must also collaborate with UX designers. Nurturing a true partnership and not being merely transactional is key to delivering exceptional products. 

Finally, as the product gets ready to launch, there’s another round of communication and coordination. Product management must educate and edit marketing plans for the product. They also must provide the sales team with the necessary training and talking points they’ll need.

Technical skills 

There may be no debate quite as polarizing in the product management community as this subject. Just how technical must a product manager be? Will non-technical product managers become extinct?


There’s no debating that a product manager must have some level of technical understanding. Luddites don’t make great product managers, at least not for software products.

Product managers must be conversant enough in the fundamentals for meaningful dialogue with engineering. They must understand if they’re creating a massive amount of technical debt with their decisions and managing down existing debt. And they should probably be knowledgeable enough to use their product and relate to the customers it’s intended to serve. 


However, there’s no rule that product managers must know how to code or run an SQL query on a database. While those might be practical skills, a product manager won’t be doing those things daily.

And in organizations where there is an actual need for product managers with in-depth technical know-how, they can always hire a technical product manager to fill that role. 

Business savvy

When product managers dub themselves the “CEO of the product,” they’re generally referring to this category of skills. Product managers may or may not carry responsibility for a product’s revenue. But they’re integral to making sure the product is financially and strategically successful.

It starts by defining a vision and goals for the product. While these may come from the founder or executive team, product management must own them once established. Then, translating those abstract ideas into the tactics required to make them a reality is all part of the job.

Other duties, such as finding product-market fit and assessing requests from customers and prospects, also require keen business smarts. 

To do so, product managers must think strategically, even when dealing with minutiae. No choice is inconsequential. They must dynamically consider all possible repercussions to avoid negative impacts on the customer experience or sales.

And then there are the numbers. Product managers must be conversant in the metrics that matter. They must use data-driven decision-making to propel the product forward. Growth, revenue, and profitability all fall under product management’s purview, even if they’re not directly responsible for them.


Product Management and Roadmaps

We might be a bit biased, but there’s no single aspect of product management as pivotal as a product roadmap. It’s the culmination of countless hours of research, negotiations, strategizing, and consensus-building.

Watch the webinar, Key Ingredients for Successful Product Roadmaps, for more on what goes into a roadmap.

Product roadmaps set the agenda and set expectations for the entire organization. They set a course for the future and provides a point of reference to inspire the whole organization. They turn the mission and vision into a concrete plan for making grand ideas a reality. 

But what’s on the roadmap is only half the battle. The other part is figuring out what kind of roadmap makes the most sense for the audience, the product’s maturity, and the timeframe it covers. One size does not fit all (although one tool can help you with every kind of roadmap you might want to create).



The first step is prioritizing the various initiatives and features using a prioritization framework. Define the parameters of your roadmap. Will it be feature-less? Based on themes

Setting the ground rules for the roadmap’s scope and level of detail are the hard part. Plugging in everything is easy. Then it’s time to rely on those communication skills and showcase the final product.


Product Management Tools

Product managers have more options than ever when it comes to tools. They cover a wide range of tasks and areas that product managers are responsible for.

But a product manager’s job involves a lot more than gather product insight, tracking the backlog, and reviewing the product roadmap. Whether you’re a new product manager or a seasoned PM just wanting to make sure you’re not missing a key component of your role because you’re lacking the proper tool—the following is a list of product management tools to help you excel in your role.

These include solutions for tracking user behavior, including heat mapping and session replays. Plus, there are surveying tools for gathering feedback. There are also a host of new options for collaboration. It encompasses asynchronous messaging, voice chats, file sharing, and document editing.

For demos, presentations, and onboarding, product managers can turn to web conferencing tools that support screen sharing and recording. These can also be co-opted for low-budget usability testing, as product managers can “ride-along” while users complete tasks using their products. Quickly visualize concepts and workflows with wireframe tools and flowcharts.

Project management tools have also made a massive impact on how product managers keep track of things. There’s no excuse to be managing your life and projects in a spreadsheet.

And, of course, there’s a pretty good tool for creating roadmaps we’re quite fond of. By relying on some of these solutions, product managers can increase their efficiency, become better collaborators, and make sure nothing falls through the cracks. Roadmapping software is a must-have item on any list of product management tools. Using any non-native roadmap application to draft and maintain your product roadmap (such as spreadsheets or slide decks) will create far more work, be far less flexible and easy to share, and more prone to version-control issues that can slow your product’s progress. This is exactly why we built ProductPlan.

Asking for a tools budget

Product managers shouldn’t be shy about asking for a tools budget; their time is just as valuable as other contributors. Requesting budgets for a tool is still a relatively rare occurrence for product teams, who traditionally haven’t had any dedicated budget and rarely ask for anything financial other than approving travel expenses or a new laptop. So, how do you successfully broach this subject with the executives holding the purse strings?

1. Make assumptions

2. Strength in numbers

3. Acknowledge the alternatives

4. Try the free-trial

5. Overcome the uncomfortable ask

B2B vs. B2C Product Management

One common belief in product management is that there is a vast difference between working on B2B and B2C products. While there are certainly some distinct aspects between those two worlds, they have plenty in common.

For B2C, your users are generally also your buyers, and you’re serving a single persona. For B2B, the person controlling the budget is often unrelated to the person who regularly uses the product. After identifying each persona, product managers can tailor the product and the pitch for each one of them. 

Both situations require multiple value propositions. Even single consumers are looking for numerous reasons to buy and use a product. Therefore, messaging should always speak to practical, emotional, and financial justifications for taking the plunge. 

It impacts the sales process, as B2B sales take a lot more convincing and win over many hearts and minds for a single transaction. And the cost of acquisition will be higher, and the growth rate slower for a B2B product.

But with proper expectations, there’s no reason the same skills and experiences can’t be transposed from one market to another. Product managers shouldn’t feel pigeonholed into only working in one market or the other. It just might take a little more convincing during the hiring process to shake them out of their false preconceptions.


Optimizing Product Management Operations

Product managers have an often overwhelming amount of obligations. Time is a precious commodity. They must be efficient and organized to conduct the necessary conversations and meetings while still having enough bandwidth actually to get some work done.

Process around decisions

Making decisions—and getting internal consensus on those decisions—can be a huge time suck. To get through them all promptly, product managers must find a scalable way to get to an agreement quickly. Clearly defined roles and a consistent process let the parties involved focus on the subject at hand.

A divide-and-conquer approach is another tactic for getting more done in less time. Recognizing the core strengths of everyone available, splitting up tasks, and delegating things lets product managers focus on what they do best while not neglecting anything else that’s important. 

Product managers can also borrow some useful skills from their project management counterparts. This includes defining explicit scopes and sticking to them, cutting down on diversions and ratholes. It’s additionally helpful to create clear action plans and communicate them to relevant colleagues to be sure everyone knows what they’re responsible for and understand the expectations.

Even how product managers schedule their day can lead to increased output and higher-quality working sessions. By minimizing context switching, product managers can cluster similar tasks together to maintain focus and limit distractions.

This includes making time for strategic thinking. It’s tough to take a deep dive into a particular subject when there are constant interruptions. Product managers must carve out time for this critical task and create an environment where they can concentrate.

Product Management Meetings

Meetings are unavoidable for product managers. They have the potential to offer tons of value. But when mismanaged, they can turn unproductive and suck up time they don’t have to spare.

Among our meeting tips for product managers, the focus is on efficiency. Whether it’s limiting attendance or defining a narrow scope, the goal is to have a purpose, stick to the plan and get it over with as fast as possible.

Follow-through is also essential. Product managers should take notes, circulate key information, and clarify any action items before everyone leaves. Of course, the best advice might be skipping the meeting altogether if it proves to be more distracting than beneficial.

Capitalizing on Customer Meetings

While internal meetings may seem like a chore, meeting with customers is one of the best parts of the job. It’s an opportunity to capture an unfiltered influx of feedback, ideas, and inspiration that can help product managers power through the less-than-awesome aspects of the situation.

Meeting directly with customers is always preferable to relying on coworkers in sales or support to funnel information back to the product team. Of course, this may not always be possible, but product managers should seize these opportunities when they arise. 

While sales and support might bring back valuable tidbits, they’re conducting conversations with customers through the lens of their particular jobs. The sales team is trying to gin up more business; support aims to solve the customer’s problems and move on quickly.

As a product manager, the only goal is to understand the customer better so the product experience can be improved and enhanced. These conversations can yield invaluable context for using the product and where they’re encountering challenges. Product managers should also take some worthwhile detours to explore other ancillary opportunities where the product could potentially be even more valuable or helpful to users.

Product management needs an established process for handling this feedback. First, ideas worth pursuing must be captured and tracked. Whether they’re eventually slotted into a release or discarded, customers who provided suggestions should be informed either way. This follow-up will encourage future feedback, and it shows customers their input is appreciated.

And while it may not always be pleasant, it’s also great to have conversations with ex-customers. Using “exit interviews” to collect churn feedback can shine a spotlight on key product flaws or shortcomings that might cause other users to call it quits. It may also uncover disconnects in product-market fit or pricing that motivate some customers to abandon the product.

Agile Product Management Operations

Agile has been around for a while in the product development world. However, Agile Transformation is a newer concept that brings the dynamic, nimble, responsive qualities of Agile to the entire organization.

One permutation of this approach is the concept of product squads. Pioneered by Spotify, they are autonomous teams with a group of developers and one product owner. Assigned to a particular functional area of the product, they’re able to attack the challenge freely. As a result, they can rapidly deliver value to the market while building in-house expertise on the subject.


Product squads may or may not make sense for a particular company or product. But they’re a great example of how product teams can reconfigure themselves to respond to opportunities more dynamically. Freed up from bureaucratic oversight, ad hoc or permanent groups can take ownership and drive rapid innovation.

Product Launch Responsibilities

After the product ships, product managers don’t get to kick up their heels and relax. There’s still plenty of work to be done.


Before the dust settles

Quickly following a launch, product managers should lead a product retrospective session. This post-mortem meeting looks back on how the release went. It ensures lessons are captured and brought forward to improve things the next time around.

These aren’t just sessions for finger-pointing and blaming others for what went wrong. Instead, it’s an opportunity to offer praise, recognize good work, and collaboratively identify best practices and the areas needing improvement.

As things mature

While everyone’s always excited about version 1.0, a product’s lifespan will include many ups and downs along the way. Likewise, the role of product management also evolves as a product matures and travels through the various phases of its lifecycle.


Before launch, subject matter expertise was the priority for product managers. So they’re trying to learn as much as they can from as many sources as possible. In addition, they’re prioritizing features for the MVP to make sure they’re delivering something with real benefits to the market. 

After the initial launch, the focus quickly shifts to growth. Product management worries about scale while adding functionality that continues to propel growth.

Once all those new users are onboard, the emphasis transitions to retention. It’s all about what’s required to keep customers happy and minimize churn. 

Most products inevitably begin to decline in usage, which presents new challenges. Product managers must consider how the product can be repurposed, extended, or pivoted toward new verticals. This maximizes the company’s value for an asset they’ve invested time, effort, and dollars into over the years.

Final farewells

Sadly, sometimes it’s time to say a final goodbye to a product. Product managers don’t get to skip out on the tasks related to the end-of-life process, either. They must take the lead, bringing the same consideration they spent on the product’s birth and subsequent iterations. 

A proper shutdown requires extreme attention to detail. Product managers must map out all possible ramifications that may arise from pulling the plug. From contractual and financial obligations to data portability and migration assistance — there’s plenty to juggle.

Most important of all is how the event is communicated. Customers must be handled carefully (particularly if you want to retain their business with other products). Stakeholders, customer service, strategic partners, and sales all require education, talking points, and escalation plans.

Conclusion: Product Management Strategy

Ultimately, our answer to the “What is Product Management?” question is that the role is all about strategy. First, product managers develop the product’s strategy and persuasively communicate it. Then they ensure all decisions concerning development, marketing, etc., reflect and support the strategy.

If you are interested in what makes a competent, successful product management professional, read the “Five Traits a Successful Product Manager Needs” section on our What is a Product Manager’s Job? page. Also, check out our ultimate guide to resources for product professionals to help you in your career development with all the best books, podcasts, and conferences our team recommends. Curious to learn the trends of product management in the upcoming year?


https://tinyurl.com/bdwf9cez