What’s the best way to break down a large scope of work?

/
Sticky+Notes.jpeg

I contribute to an ongoing series called Ask Women in Product. In this article, I address how to get your head around large scope without becoming overwhelmed (or how to get out of the overwhelm if you’re already there!).

First, breathe!

First, take a breath! Everything will be okay! A few quick reminders:

  1. Don’t panic! Your team will always react to seeing you panic.

  2. Block off some time to think and work through the problem. “Thinking Time” is absolutely critical in product management!

  3. Don’t aim for perfection. Instead, aim to keep things moving forward.

It’s sticky note time!

I’d suggest doing a version of story mapping. Depending on the situation, you could do a first pass by yourself (to get your head around the scope), or you could include the broader team if you think that’s appropriate for your situation. Keep in mind that you don’t have to get it perfect on the first pass.

The quickest way to get started with story mapping is to get a white board or empty wall, a large pile of sticky notes, and a couple of markers. When you think of the large scope for your new module, what’s the first thing you think of that needs to be done? What are the foundational elements? Write them down. Continue writing all the scope ideas down until you run out of ideas.

Build your story map

Now that you have a big pile of sticky notes, draw a large “T” on your whiteboard. Above the top line, you only put the essential items necessary for your first release. Everything above the top of the “T” becomes your initial concept for your Minimum Viable Product (MVP). You’ll continue to refine this, so don’t be afraid of commitment at this point.

Next, you’ll take the rest of the sticky notes, and on the left side of the vertical bar put the items that are high priority. On the right side, place the items that are any priority other than high. Congratulations — you have your first story map!

The next thing you’ll want to do is get your team involved (if they aren’t involved already). Your team will be able to help you fill in the gaps, give additional ideas, and start further decomposing what you’ve already come up with. Also, your team may have ideas about which order makes sense, what could be taken out of the MVP, or what needs to be added to the MVP. They can also weigh in on the technical feasibility and the level of effort, both of which are factors that may impact your order of operations.

Use story slicing to decompose further

With the team, you may get to the point where you have stories firmed up but they are still too large. When you see a need to decompose the scope even further, a story-slicing workshop may be helpful. A story-slicing workshop focuses solely on decomposing existing stories. There are several techniques you can use during this workshop, and there is even a cheat sheet available online!

When you are slicing stories, it’s normally more effective to focus on vertical slicing rather than horizontal. By focusing on the vertical slice, you maintain the ability to deploy working software instead of falling back into the waterfall trap. Here is an example user story and the resulting slices:

  • Original user story: As a user I am able to checkout my cart by paying for my order.

  • Slice 1: As a user, I am able to pay for my cart by credit card.

  • Slice 2: As a user, I am able to pay for my cart by gift card.

  • Slice 3: As a user, I am able to pay for my cart with PayPal.

By using this story slicing technique, we are able to take one user story and break it up into three smaller stories that each deliver value. For our MVP, we may choose to deploy credit card payments only. Even if you end up deploying all of them at the same time, you have managed to break them down into more achievable, testable stories.

Making sense of it all

When you’re dealing with a large scope of work, getting overwhelmed only complicates things more. Stay calm, break big things into smaller pieces, and leverage your team. Remember that you are never aiming for perfection; instead, you are aiming to keep moving forward. This work does not fall solely on you as the product manager — your team should be active participants, and you should be devoting time in every sprint/iteration to refining (grooming) the backlog.

*Thank you to @mdy for editing this article.

This article was originally published in the August 27, 2018 edition of Ask Women in Product. The original, complete article can be found here.

What are the dos and don’ts of running a Focus Group?

/
Focus+Group.jpeg

I contribute to an ongoing series called Ask Women in Product. In this article, I talk about tips for running an effective focus group.

Focus groups can be immensely valuable for gathering feedback and ideas directly from your users and stakeholders. The thoughts in this article apply to either of these scenarios — user feedback groups or discovery-type sessions with your key stakeholders or even your own team.

Conducting a productive, valuable focus group session takes preparation. If you get a group of people in a room without a plan, you are bound to have a miserable couple of hours! Focus groups should be fun, both for the participants and for you! The best sessions I’ve participated in have had a variety of activities to keep the group active and engaged. And sometimes the best ideas and opportunities are discovered through these activities!

Things to consider before the session

Have a good cross-section of participants. Sometimes, as with internal stakeholders, you will not have a choice in your attendees. However, if you do have a choice, a group with a variety of product knowledge, technical skill, and backgrounds can help give you more well-rounded results. If you know your participants, balancing communication styles (introverts vs. extroverts) can also be beneficial.

Set the room up for comfort and efficiency. I like to use a room with lots of whiteboards. If I can’t find one like that, I’ll use the large sticky note flip chart pages instead. I always make sure to have more sticky notes that I think I’ll need, along with at least two sharpies per person. Also, plan for materials necessary for any other activities you’re going to have the group work on.

If you’ll be demonstrating your product, you’ll want to check the audiovisual equipment in advance to make sure you know how to hook your laptop up. If you are projecting, you’ll want to ensure that all chairs have a clear view of the screen. No one wants to be the participant sitting directly in front of the screen, with their back to it!

Depending on the length of the session, you may choose to provide refreshments. For a shorter session, coffee and other drinks are inexpensive, and the participants appreciate the effort. For longer sessions, ordering in lunch is always appreciated. By providing refreshments, you also get to keep your participants in the room, instead of having them leave for lunch or breaks. It can take valuable time to get back on track after a break if participants leave and focus on something completely different for half an hour!

Thank your participants. Your company likely has rules on what’s allowable in terms of rewards. Some companies issue payment to participants, while some others use small gift cards or company logo items as a small token of appreciation. Talk with your team to find out what your company normally does.

Things to do during the session

Know your goal and stick to it. Determine, ahead of time, what your goals are for the session. Is it greenfield ideation? Is it getting feedback on an existing product? Or is it defining opportunities or problem statements? Whatever it is, you’ll have an easier time keeping your group on track and will get more valuable information from your participants if you stay focused on your goal.

Use an impartial facilitator if one is available. The facilitator could be another product manager or anyone with an understanding of the discovery and feedback process. When you have someone else keeping track of the time, taking down notes, and leading the activities, you can be free to learn as much as you can during the session. Note: If you rely on a colleague to facilitate, you should also be willing to reciprocate when they need a facilitator.

Use tactile activities to keep your participants engaged. There are many types of activities available to focus group facilitators, and I’ll list a few of my favorites here:

  • Crazy Eights sketching exercise: Great for getting people loosened up and creative; gives you great perspectives on your product as well as potential design ideas.

  • Sticky-note brainstorming: This technique can be used for problem identification, pain point identification, and solution idea generation.

  • Dot voting: I picked this one up in my community-organizing work, but it works equally well in software development. Use this technique to hone in on your brainstorming ideas and get clarity on which ones to explore further!

As the activities are in progress, it’s important to encourage participation from all attendees. Some will be more comfortable participating, while others may need extra encouragement.

Keep the session light and engaging. The attendees are volunteering to be there to help you and your product, so make it fun!

Common Pitfalls

Taking product feedback personally. This trap can very quickly derail a session. The focus group needs to be a safe space for people to freely share their opinions and ideas. We all know you love your product — but you are here to find out what other people think and what their ideas are. Please see their feedback as the gift it is and use it to make your product even more awesome.

Debating technical feasibility or level of effort. Your attendees are unlikely to have the skillset to discuss that, so please don’t respond to ideas with comments like “We can’t do that” or “That’s way too hard!” You will have plenty of time to sort out the feasibility and level of effort later, with your engineers. Don’t put that burden on your stakeholders and don’t stifle their ideas by making them guess at how hard it might be to implement their idea.

Becoming frustrated. Focus groups are full of people. People are unpredictable and often don’t do exactly what you want them to. The one thing you can count on with a focus group is that it will not go as planned! Use this as an exercise in patience and flexibility. Even groups that don’t go as planned can give you valuable insights into your product. Take what feedback you can get, be thankful for it, and move on.

Wrap it up cleanly

Review what the group accomplished in today’s session. Let the group know what you plan on doing with the information you’ve gathered. Thank them for their time and input.

Take photos of your completed activities. This form of documentation will prove useful as you look back on the results. If you take photos, you usually won’t have to save all the sticky notes and sketches.

Take the results back to your team and determine how you’ll handle them — incorporate them into your backlog, file them away in your icebox, or use them to conduct further sessions with your own team to refine them further.

Use these resources to learn more

Thank you to Vidya Venkatesh for editing this piece.

This article was originally published in the October 1, 2018 edition of Ask Women in Product. The original, complete article can be found here.

How do I establish a compelling value narrative for my product?

/
value narrative.jpeg

I contribute to an ongoing series called Ask Women in Product. In this article, I outline my approach for establishing a value narrative for products that don’t generate revenue.

Many products have an easily-defined value proposition. For products that increase sales or generate their own revenue, the value is very easy to quantify. For the purposes of this article, we’ll call those traditional-value products. What we’ll be discussing in this article are products that don’t have such an easily-defined value proposition. We’ll call those non-traditional-value products.

As product managers, we sometimes have a product that isn’t easy to place a traditional value on. For example, I once worked on a suite of products focused solely on reducing phone calls into a business. The product met this requirement by allowing customers to perform self-service transactions instead of calling customer service on the phone. Non-traditional value products like this self-service suite require PMs to take a fresh look at how to define value, both from the perspective of the business and of the customer.

Questions to ask when you determine value

What problem are you solving?

In the case I described earlier, the customer’s phone calls were coming into a department that was a cost center for the business, and the company wanted to better manage its operating costs by reducing the number of calls that required a call center agent. While there was no opportunity to generate revenue by reducing the number of calls, a lower incoming call volume for agents meant that the call center needed a smaller staff and a smaller office space even as the business continued to grow.

What is the value to the customer and the value to the business?

Both value propositions are important. In product management, we often get caught in the trap of thinking we should only advocate for the customer value. While the customer should always be at the front of our minds, there needs to be a balance. Often the business value is an increase in the efficiency of the business because routine tasks are automated. Rarely is the customer directly concerned with the efficiency of an organization. Thus, it is reasonable to call out both types of value when they are different.

In my earlier product example, a customer who was making the call would get value from the new product because they spent less time waiting on hold. Another increase in value for the customer was the ability to answer their questions through the self-service option at any time of day, whether or not the call center was staffed.

Some other examples of non-traditional value that you might use:

  • Time savings

  • Eliminating single points of failure / improving business continuity

  • Improvements in fraud detection

  • Increase in productivity through a decrease in non-value-adding tasks

  • Reduction in paper costs through digitization

  • Increase in the customer’s value perception

How will you measure the value?

If you can’t measure it, don’t bother to claim it. Even when you’re dealing with non-traditional value, you must be able to measure it. Time savings can be measured by monitoring improvements in transaction times. Improvements in business continuity can be measured by time elapsed since the last failure event. We can count the number of fraudulent cases detected and calculate the length of time that has elapsed from the fraudulent act to detection. An increase in productivity or throughput can be measured by counting the number of transactions processed per unit of time. A customer’s value perception can be measured through quick and simple online surveys. You must be able to measure the value, and sometimes this requires an immense amount of creativity on your part!

Decide on your key performance indicators (KPIs)

Why do you need key performance indicators? The KPIs will be your way of demonstrating the value of your product. Since you want to deliver value either to your customers or to the company, your KPIs should be aligned with the goals of your business. KPIs let you communicate the value of your product in terms that your co-workers and leaders can easily understand. Use the SMART criteria to help make your KPIs a valuable tool for both your product and your business.

Specific. What, specifically, will your product achieve? For example:

  • Reduce inbound phone calls by 20%

  • Reduce mailing costs by $10,000

  • Generate 30,000 completed transactions

Measurable. How, exactly, will you measure your progress?

  • Reduce inbound phone calls by 20% (measured by monitoring inbound call report)

  • Reduce mailing costs by $10,000 (measured by analyzing mailing cost expenditures)

  • Generate 30,000 completed transactions (measured by system data)

Attainable. It’s great to be aggressive when defining your goals, but they do need to have a reasonable chance of being achieved. Measures that you or your team have no chance of attaining are bad for your morale and the morale of your team. Unrealistic goals also undermine the confidence that your leaders have in your ability to deliver results. When you formulate your measures, estimate the benefit your product will provide. What is reasonable? For example, you are not likely to eliminate all phone calls; however, is it reasonable to reduce them by 20 percent? The answer depends on your customer demographics, how entrenched their phone habits are, and how much functionality your product can replace. After thorough research and testing, often you are left making an informed guess.

Relevant. Your KPIs need to matter. If no one in your organization cares about reducing inbound phone calls, will anyone care when you meet that goal? By aligning your product KPIs to the goals of your business, you ensure that your measures are relevant. Examples of relevant KPIs would be an overall reduction in inbound phone calls, or a desire to reduce mailing costs.

Time-specific. In agile software development, we often talk about getting rid of timelines and letting the team focus. But with KPIs, your audience needs to know when you will achieve the results. What’s the general time frame? For example:

  • Reduce inbound phone calls by 20% in the first month

  • Reduce mailing costs by $10,000 in the first year

  • Generate 30,000 completed transactions per month

Summary

Every product that solves a problem has the potential to deliver value to the right customer or the right business. When you’re working on a non-traditional-value product, you need to start with a clear idea of the problem you are solving and who you’re solving it for. Call out all the benefits that arise from solving the problem, then define the key performance indicators that will help you measure that value. Be SMART about your measures; doing so will ensure that your work is aligned with business needs and will enable you to deliver what you’ve promised within the committed time.

I hope this article and the additional resources below help you communicate the impact of your work and the value of your product.

Use these resources to learn more

Thank you to Louise Heatley for editing this piece.

This article was originally published in the October 29, 2018 edition of Ask Women in Product. The original, complete article can be found here.

How can I manage multiple scrum teams at the same time?

/

I contribute to an ongoing series called Ask Women in Product. In this article, I outline my approach for managing multiple scrum teams at the same time.

Answer from Stephanie Muxfeld, Consultant at Slalom

scrum.jpeg


This is a great question! In a perfect world, product managers would always be aligned with a single team and a single product. In the real world, however, we sometimes get spread across multiple products. I’ve also seen products so large that they needed multiple teams, aligned to the same product manager. The good news is that different team structures have the potential to be successful at producing a quality product.

As with many things involving agile and product management, the answer depends on the team and the situation. To tackle this question, we’ll look at the question from a few different angles.

  • Team Setup

  • Backlog Management

  • Stakeholder Management

  • Technical Considerations and Tools

Team Setup

Why are there multiple Scrum teams? Is it a case where you are the product manager over different products, or is your one product so large that you need multiple teams?

In both cases, you’ll need to consider the impact on your schedule:

  • Are the teams using the same sprint start and end dates? If so, how is that working for the teams? It can be a challenge for a product manager when multiple teams have ceremonies on the same days, but not impossible.

  • Can the teams conduct their ceremonies at different times of day, so that you can attend both? The advantage with this is that you get all your ceremonies done, with the rest of the sprint left for you to divide your time between your two teams.

There is no reason why you can’t succeed as the product manager for two different products at the same time, but you’ll need to prioritize organization, documentation, and dedicated time with each team to succeed.

You will also need to grow your ability to change contexts (products) on the fly, as your teams need you. But being organized and taking excellent notes can make this much easier.

Backlog Management

What’s the situation with the backlogs? Do the teams have separate, distinct backlogs? Are both teams pulling work from a single backlog?

In most situations, it is imperative that each team have a unique backlog that they own, without dependencies, so they can pull work as they are able without coordinating with another team.

If you are in a situation where two teams share a single backlog, I’d recommend looking for ways to split them up. If the teams are working on the same product and you cannot reasonably split the backlog, having a combined planning session is likely your best bet.

Consider sharing showcases as well. I am a firm believer that retros should always be team-specific, but in the scenario where teams are working on the same product, it can be helpful to occasionally hold combined retros. The communication between the two teams is critical to avoid them working on top of each other.

Stakeholder Management

What are the expectations of your stakeholders? How involved are your stakeholders in the day-to-day work of your team? Do stakeholders require your teams to be on the same start date, have a shared showcase, etc.?

The best-case scenario would be that our stakeholders let our teams determine their own way of working, and focus solely on results. However, I’ve heard enough stories about overreaching stakeholders and I’ve also experienced them first-hand. If your stakeholders are dictating things that your team should be deciding for themselves, I suggest taking a hard look at where you can push back on the stakeholder.

Sometimes stakeholders are used to dictating to their teams, but if you push back and make your case for the team being self-directed, it may turn out in your favor. Sometimes our stakeholders need to be educated about the value of self-directed teams. And then other times they will not relent, and you have to manage that and protect your team from the distraction. I find stakeholder management to often be the hardest part of being a product manager!

Technical Considerations & Tools

Are your multiple teams working in the same code base? If so, do they have a defined branching and merging strategy? What is your approach to QA/testing and fixing defects/bugs?

If you have two teams working on the same product, you must work with your engineers to ensure they have a strategy to avoid working on top of each other.

They will, at a minimum, need an approach for branching and merging that will allow them to work together while not driving each other crazy. You’ll also need a strategy for production deployments. Can each team deploy independently, or do they need to coordinate deployments? Are they going to test each other’s changes? It’s always better to develop working agreements on these topics before it’s time to push to production!

Do you have a backlog management tool that you use? If so, that’s great. Learn it inside out and make it work for your team. I’ve also managed backlog successfully using a tool as simple as a spreadsheet. The specific tool is irrelevant, as long as it works for your team!

You Can Do This!

If you are the product manager for multiple teams, you can absolutely drive success for both your teams and your product(s). While it usually isn’t an ideal situation, you can — with proper organization, documentation, and time management — deliver awesome products while having some fun along the way!

Use these resources to learn more

This article was originally published in the January 28, 2019 edition of Ask Women in Product. The original, complete article can be found here.

What structure or process do you use to understand a new product?

/
Structure.jpg

It’s exciting to start work on a new product! When I start a new effort — whether it’s for a greenfield product that I get to influence from the beginning or if it’s a product that I am taking over mid-stream — the beginning feels so full of hope to me. It’s like the first day of school; anything is possible! While different product managers have different favorite times in a product’s lifecycle, my favorite is always my start with the team.

You’ll no doubt do your best to get up to speed quickly so you can map out your plan or approach. To accomplish that, I suggest doing these four steps, which can happen in parallel:

  • Understand the problem your product is meant to solve

  • Get up to speed on available documentation

  • Bond with the Team

  • Establish a healthy relationship with your stakeholders

For the remainder of this article, I’ll share some pointers that will set you in the right direction for each of these steps. My hope is that you’ll use this as a starting outline and that you’ll add to or subtract from it to meet your specific needs.

Understand the problem your product is meant to solve

When you come on board at the beginning of a brand-new product, part of your work will almost certainly include guiding the team through the discovery process. This means you will learn about the product as part of that discovery.

Here’s a starter list of questions to ask. If you’re lucky, some of these answers may already be known and documented.

  • Have we tried to request funding or is there a charter available to view?

  • What problem are we aiming to solve with this product? Is there an initial problem statement?

  • Who is the target customer for the product?

  • Has any preliminary research been done that every team member should read?

To arrive at the answers, consider the following approaches:

  • Conduct discovery activities, which may include problem definition workshops and user interviews. These activities will allow you to learn about your problem space and determine how the product can solve these problems.

  • Ask to talk to existing subject matter experts who are likely to give you valuable information.

  • If the product is in a problem space, industry, or technology that you are unfamiliar with, check if there are industry and customer research studies that can add to your overall understanding. You should also consider adding some independent research and learning.

  • If you are coming into a product that is already in flight, use the product yourself. Whether this means downloading the app, making a purchase, or going into a store for a visit, find a way to use the product so that you can truly understand it.

Get up to speed on available documentation

When it comes to documentation, my philosophy is: the more available the better.

If it exists, I’d like to review it. Aside from the charter, the backlog, and the roadmap, I would also review any work that pertains to the problem definition and the hypotheses for solving these problems.

In addition to the more obvious product documentation, I ask to look at some things that might not immediately be obvious as valuable or useful:

  • Standard operating procedures (SOPs) can help me understand how the user interacts with the product and what constraints they have.

  • Knowledge items (KIs) are useful to assess prior questions about the product.

  • Service tickets are a fantastic way to review past problems, anticipate future issues, and understand how those prior problems have been solved.

Bond with the Team

There’s no substitute for bonding with the team that you’ll be working with, whether they’re a newly-formed team or one that has been in existence for a while. A great part of conducting these fact-finding conversations is that you can build relationships while you are learning.

I like to spend a small amount of time with each team member, asking them several open-ended questions about the product.

Consider these questions as a starter set:

  • What is the most valuable feature this team has implemented (and why is it so valuable)?

  • What are you working on right now?

  • What future feature are you most excited about (and why)?

  • Can you explain this product’s problem space to me?

  • What is your favorite thing about this team?

  • What is one thing you’d like to see this team do differently?

You should absolutely change the questions to meet your specific learning goals. The key with this team-interview approach is to go into the meetings prepared, leave plenty of time for small-talk, and ask open-ended questions.

Using this team-interview approach achieves two goals. First, you gain valuable information on the product at the team level. Secondly, you get to know your team members and how they feel about the product. You’ll get a feel for team morale and energy, which is important for you to understand as the product manager.

Establish a healthy relationship with your stakeholders

Aside from bonding with the team, you’ll also need to talk to your stakeholders. In fact, you may have stakeholder ideation sessions as part of the discovery stage, especially if you’re working on a brand-new product.

Consider inviting stakeholders out for coffee if you’re co-located. Use these interview sessions to build relationships with stakeholders by getting to know them as individuals as well as understanding what they’d like to see from your product.

As you speak to each stakeholder, ask yourself: does it look like the team and the stakeholders are in alignment? If not, you will need to figure out where the disconnect is and work to get the two groups into better alignment. The team needs to understand what the stakeholders are asking for and expecting, and the stakeholders similarly need to understand the work the team is going after and why they are choosing that work first.

This outreach will give you a network of stakeholders that you can call upon for research or validation later in the life cycle. Also, you can use this research to create baseline documentation for the product, and then add to it as you make enhancements or change the product moving forward.

Wrap-up

Becoming the new product manager for a product can be intimidating. There is always so much to learn, and you have a new team to build relationships with. Although it can be challenging, it’s also exciting. You are starting a new journey, full of opportunities to learn and add value.

Make the time to learn as much as you can about the problem your product is solving. If the product is already in flight, learn as much as you can about what has already been done. Read whatever you can get your hands on and ask as many questions as you can think of! Build relationships with your new team and your stakeholders while you learn about the product.

Once you have the foundational knowledge of the problem and the product, you’ll be able to quickly add value to the team and help them deliver value!

Use these resources to learn more

This article was originally published in the March 25, 2019 edition of Ask Women in Product. The original, complete article can be found here.

#PMSkillsAreLifeSkills: Plan for the Unexpected and De-escalate like a Ninja

/
1_0kFfIFwwaNmTicZQxsFEHABaby.jpeg

I contribute to an ongoing series called Ask Women in Product. In this article, I outline some tips for de-escalating sticky situations.

There are a lot of similarities between product management and parenting. Don’t get me wrong; I know plenty of people who do one role without the other and they are wonderful at it. I do believe, however, that there is a special advantage to be gained by those who have both roles and know how to leverage the lessons learned in one role when they work on the other. In other words, I believe that PM skills are life skills.

Aside from the obvious parts of both roles — such as taking care of your family/team and setting them up for success — many of the highest-value activities we handle as product managers are also vitally important as parents. To explain what I mean, I’ll use the remainder of this article to talk about why people react poorly when their expectations aren’t met, how to set appropriate expectations, and what the task of determining value looks like. I’ll also share a tried-and-tested technique to de-escalate situations when it becomes apparent that expectations have been missed.

Life is full of expectations

We expect our coffee to be ready when we’ve mobile-ordered it. We expect our package to arrive on the day it’s scheduled to arrive. And we expect our car to start when we turn the key or push the engine button. In our minds, we’ve already determined how things will go — that is our expectation. Any deviation from what we’ve already decided in our minds causes us discomfort.

As a parent, I’ve had to learn how to manage expectations. When my daughter was a toddler, it seemed like my entire life revolved around managing expectations. When we entered a store, I’d need to explain that we were there for groceries, not toys. When we went to grandma’s house, I’d need to prepare her for the fact that we’d be leaving later that day and not spending the night. The practice of setting clear expectations didn’t always prevent the toddler tantrums that every parent dreads, but they sure reduced them. Those toddler years taught me the importance of clear communication, and that taking the time to explain what was to come was essential to create a smooth experience.

At work, the same principle applies. Our stakeholders expect our software to be in production when we tell them it will be ready today. A Sales Manager expects a polished sales presentation when someone on their team pitches a proposal to a client. And yes, we expect our stellar contributions at work to be recognized and rewarded by our boss through a glowing performance review, a bonus, or a promotion.

Clearly, the better we are at setting expectations, the more likely it is that we will establish and maintain great relationships, both at home and at work.

Set the appropriate expectations

The most effective way to avoid missed expectations is to be careful about setting them to begin with. Most product managers don’t have the luxury of keeping their commitments open and flexible. Often, we will be asked to commit to a scope of work, state our target delivery date, and then plan backwards from it.

Consequently, we product managers need to understand the factors that affect the likelihood that we will meet our commitments. The better we understand them, the better we’ll be at setting the appropriate expectations.

The primary factors include:

  • Elapsed time until the team is finished. When we estimate our delivery dates, we should pay careful attention to how far into the future our delivery is expected to occur. If it’s only a few weeks from now, we can likely make an estimate to within a day or two. But if we’re talking about a delivery that is months into the future, it’s difficult to accurately estimate completion down to a single date. Delivery estimates are a question of probability. As you get closer to the end, you’ll be in a better position to refine your estimate and make it narrower based on the information you have. The same is true for planning in your personal life — planning events far into the future creates risk. You can mitigate that risk by planning to revisit your progress closer to the actual date.

  • Scope changes. How solid is your scope? As we start development and begin iterating, we will often discover something that had not been previously accounted for. How likely is that to happen in your situation? The same question applies to parenting; things are always coming up — someone gets sick, someone is grumpy, playdate plans change. When the kids are still young, the potential for scope change is especially high.

  • Maturity of the team. Experience matters when it comes to estimation, so more mature teams generally make better estimates. if your team is newly-formed, their estimates will be less accurate. With parenting, as your child matures, they become better at planning and being accountable for themselves. They can also better estimate how long things like homework or instrument practice will take. Trust me when I tell you it gets easier as they get older!

  • Interruptions. How often is your team interrupted during a sprint? Are they frequently moving away from committed sprint work to focus on production outages or other emergencies? If so, you should consider building a buffer into your sprint capacity to deal with interruptions. The same is true for parenting; when the kids are young, you need more interrupt buffer. I’ve long since learned to use time ranges (“We’ll be there between 2 and 2:30 PM”) to account for last-minute diaper changes and tantrums. I still remember a few solid years as a new parent where I couldn’t eat, much less finish, a hot meal. Mealtimes were constantly interrupted and it’s just a part of the job.

There are other factors that affect delivery outcomes for both PMs and parents (think sick days!), but the ones that I’ve outlined above are good places to start. By getting a handle on these considerations, you can formulate an estimate that will help you set realistic expectations. It takes practice to create quality estimates, so don’t be disappointed if things get off to a rocky start. It will get easier over time as you and your team do it more frequently.

Choose your work based on the value

So much to do; so little time! As a product manager and as a parent, I advocate for value-based decision-making when it comes to defining your scope of work. This approach works in software and in real life! If we are working on the highest value item at any given point in time, we know we’re focusing on the correct thing. And when priorities inevitably change, there is no guilt because all decisions are informed by value.

In software development, a focus on value means working with your business partners to understand the value of each feature. Then, together, you’d prioritize the features based on their value. If you do this, your team will always know what to work on next. No one ever needs to ask, “What should I work on now?” because the entire team is aligned around value.

In parenting, you make value-based decisions when you know what’s important to you and your family, and you make choices based on those values. It also means saying “no” to activities, invitations, and time-wasters that don’t align with your values. This approach allows you the freedom to pivot amongst your priorities as needed, without feeling any guilt about missing out on things that really don’t matter. But to have that freedom, you need to get clear about what your values are.

De-escalate when you must

Inevitably there will be circumstances where, as a product manager or as a parent, you’re faced with a situation that’s gotten out of control and you must de-escalate. These situations are often tricky because your stakeholders can be disappointed, frustrated, or angry. This is true whether you’re wearing your product manager hat or your parent hat!

When you’re faced with one of these difficult situations, consider giving these tips a try:

  • Stay calm. It’s important that you remain the calm voice in the room. If you get emotional or angry, there is almost no hope of resolving the situation in a healthy and productive manner. Delay the conversation, if you can, until you’re ready to tackle it.

  • Start by agreeing. Get the conversation to a good start by focusing on a point that you and your stakeholders have in common. In your product manager role, this step may mean expressing agreement that the features which have been delayed are valuable to the customer and that you, like your stakeholders, want these features in the product as soon as possible. As a parent, it might be that you agree that broccoli isn’t the best-tasting vegetable.

  • Acknowledge their point of view. After you have established common ground, focus on acknowledging the other person’s point of view. Even if you don’t agree with them, people find comfort and validation in being heard.

I’ve found that, in some cases, it can take several attempts until you find a point of agreement that your stakeholders will respond to while they are upset. Once you do, however, it’s usually enough to de-escalate the situation. Keep looking for points of agreement until you can turn the conversation into a collaboration and all the parties involved can work together to find a solution that will be agreeable to everyone.

Conclusion

There are a lot of similarities between product management and parenting. The skills and experiences you gain in one role can absolutely be to your advantage in the other. By setting the appropriate expectations, you can reduce the risk of stakeholder frustration and disappointment. Doing estimates in ranges gives you and your team flexibility and peace of mind to handle unexpected circumstances. And when you make decisions about your scope and time based on value, you can rest easy knowing that you are always working on the most important activities. If you have to, employ de-escalation tactics and take away whatever lessons you can for the next time!

Resources

This article was originally published in the July 15, 2019 edition of Ask Women in Product. The original, complete article can be found here.