The Path Forward is Clear, Stop Acting Like It Isn’t

Now that you’ve set your vision of where you want your company / portfolio / product to be, gathered data to better understand where you are (or how far away you are from your goal), and generated ideas on how to get there, it’s time to make some tough choices. I’ve always summarized the role of Product as “the people who decide what to do next” and this holds even more true during annual planning. Other team members inform the decision, but it is the product person’s responsibility to make it.

How do you choose what to invest your precious R+D resources in for the next year? The simplest answer is: the strategic initiatives with the highest value towards your vision, we’re going to dive in to how to evaluate that.

Some common prioritization frameworks that we DO NOT recommend:

1. Whatever CEO wants to do

2. Whatever the team wants to do

Each of those parties is an input — one top down, one bottom up — but neither should have the full sway of the roadmap. That’s because both groups are incredibly biased towards their particular goals. It’s the job of the product to strike a balance and include other perspectives into the final decision.

So how do you pick the winners? In Prioritization doesn’t need to be hard, Melissa Perri talks about how as a product leader, it is no longer your role to select the features to be built. Doing so is just as bad as if the CEO did. You have to enable your team with the strategic vision which acts as guardrails for them to perform some of the prioritization options below. Your role is to create frameworks within which they can evaluate their options and then to insist that they back up their decisions with data.

She discusses how one thing often overlooked as product teams compare the alternative routes to achieving goals is the Cost of Delay. When a product manager thinks about with this lens, they ask questions like:

• What is the urgency associated with building a particular feature from a competitive landscape perspective?

• What will you gain by releasing it sooner and serving customers faster?

• Does the value of what you are going to deliver diminish as time passes?

If you can encourage your team to think about potential features in this way, they will be far more advanced than their peers at other companies. Generally, most product managers use Weighted Scoring, to rank the ideas they have collected, a process detailed below with the twist of data validation. We at ProduxLabs want to emphasize that without considering cost of delay, validating with data, and thinking about the impact on key accounts, big pieces of the prioritization puzzle are missing.

If your product team is going to use a weighted scoring protocol, here’s how we suggest it should be done. When you collect inputs from various teams, you might assume the “high priority” items list would get very long, but as Helmut Steuber, who leads Product Operations at the Continuous Testing platform Tricentis, said to me the other day: “Once we consolidated and ranked items, the winners were clear.”

First, connect all of the collected ideas to your strategic intents by simply tagging which options will impact on those items. If you have a spreadsheet with all of the requests, add columns for New Logos, Retention, Cost for Acquisition etc. and start marking each row appropriately if the initiative would positively impact that goal. This will allow you to sort for the options which generate value for each strategic intent. You can also see which options will have the broadest impact if they are tagged in multiple columns.

Alternatively, you could look at how often an idea was brought up by the various groups you gathered information from, but that should only be directional. It’s your responsibility to check what they are requesting for biases and to validate opinions with data. This is crucial with comments from the sales team, who often say they’ve lost a deal because a particular feature was missing. If you dive deeper, you learn that the prospect was not the target customer and would have had many other unmet needs beyond the showstopper they encountered.

To help decide which items will have the biggest potential value, rank each of them as High, Medium, or Low for what has been identified they will impact. Ideally your team can quantify the options with dollar amounts, but if the information is limited, that can prove to be difficult. That is where often we resort to something called weighted scoring — which is only effective if you have data that backs up your reasoning. Each option is given a numeric value and higher numbers are assigned if specific focus areas are selected to outweigh the others. Again, this is only effective if you have data to back up why you have selected the score.

This brings us back to the importance of looking at that data you gathered. As you have looked at the segments where you are winning and losing and the research around those groups needs, do the ideas presented match up? Can you look at frequency of customer service tickets with specific tags to validate the concerns are real? One option is to take the options which are rising to the top of the rankings and send a survey to Sales and Customer Service representatives asking them how often they encounter that request (once a day, week, month, quarter, year) to attempt to quantify the impact of fulfilling it.

Data is more informative and concrete than consensus and gut feel. You want to lead a team of product manager who rely on cold hard facts to support their choices, not subjective rankings filled with bias.

The last item to include in your prioritization framework is Impact on Key Accounts. In order to do this, data is utilized to identify which customers drive the biggest revenue (and potentially referrals) for you. Then, see if there multiple key customers who are threatening to leave unless a particular feature is added. Because it will cost you a lot to acquire another similar large customer, it’s probably worth considering building that feature, especially if a competitor has it available so there are obvious alters available.

Before we conclude this week, it’s important to share some more BAD reasons to prioritize something:

1. An individual customer has been waiting a long time for something

2. It’s already on the roadmap, AKA you’re in the Build Trap

3. We said we’d do this last year and didn’t (there’s that Build Trap again)

The bottom line is that whatever is selected should fit within the product strategy. What that means is that in reality, as a product leader, you deploy a strategic framework so that your team can perform the steps above and evaluate options. Then, hopefully when they present their selections to you (and the data that backs them up) it will be easy for you to support their choices for the path forward.

Next up is working with the development team to estimate the effort involved in each initiative and fitting the puzzle pieces onto a roadmap. Stay tuned! If you missed some of the earlier pieces, click on the links below to catch up.

Week 1: Planning Starts with Setting a Vision

Week 2: Smart Product Bets Start With Data

Week 3: Generating the Best Ideas

Creating a Strategy? Start By Generating the Best Ideas

Now that you’ve set your vision and gathered data to understand the state of your product portfolio, it’s time to think about how to go beyond your current situation.

First, identify key customer segments and their needs. Review the data and see where you are winning and retaining customers. Is there room for improvement? As you surface cohorts that are not doing as well (low retention, engagement or NPS), are there any which you think can be flipped in your favor? Choosing where precisely your product portfolio should move the needle is what will guide what strategy you select.

Then, connect with your fellow executives. Make sure that the segment and need you’ve identified as important to improve is something that resonates with them. Then listen to the issues their teams have surfaced that product might be able to assist in alleviating.

List of execs for you to align with:

• CEO, COO, and CFO (though probably talk to them after aligning with everyone else below)

• Head of Sales

• Head of Engineering

• Head of Customer Success / Service

• Head of Onboarding

• Head of Marketing + Product Marketing

Now you’re ready to choose a strategy. Hooray!

Below are the 16 Product Strategies for Growth that every leader should know. You should run through the list as you are generating options to make sure you’ve exhausted all paths available to you. If you know you want to add new customers, grow lifetime value, or increase profitability, look at those columns to find strategies which produce that result.

The most common strategies are targeted at adding new customers and tend to be options that will expand the market for your product. You’ve probably thought about going up or down market, expanding to new geographies or verticals, or building out new features or complementary products to fulfill additional customer needs.

Often, product leaders focus on what can be created by the current or expanded in-house team. We forget to evaluate options like partnerships and acquisition opportunities to increase available offerings. Similarly, you could consider becoming an open platform for other companies to build auxiliary products. Remember, some of the most successful companies (Salesforce, Facebook, Apple, etc.) only got to their current state by leveraging the strengths of others. Where would the iPhone be without the AppStore? If something isn’t core to what you do, look into alternative options to building it yourselves.

The last group of strategies focus on optimizing LTV/CAC (the ratio of Lifetime value of a customer to the cost of acquiring them). This is a proxy for profitable growth which should be considered as well. What can you be doing to better retain existing customers or to lower friction to purchase your product? Is the price of your product well correlated with the value you deliver to different segments? Keeping these questions in mind and running through the full list of options above will guide you to the best strategic choice.

Also remember… Don’t choose your strategy in a vacuum! Go back to your executive peers whom you chatted with about the priority problems and check in with them about their thoughts about the strategy you are leaning towards to solve them. They have insights into what is possible given their team’s constraints and have direct visibility into prospect and customer behaviors which will impact the success of your plans. As a product leader, you have the skills to balance their opinions, the data you’ve collected, and the cost of delay to make the right choices.

How To Manage Remote Teams

Keeping remote teams connected is a challenge for any distributed company, but what if EVERYONE was remote? That’s the case at Invision a 100% distributed company, and their employees LOVE it.

We spent time with some individuals at Invision, to learn about how they keep their teams connected and engaged across the globe. These tips and tricks are a great addition to the list we’ve already shared about managing remote workers.

1) Repeat, Repeat, Repeat

Repeat yourself, because when you have no water cooler or coffee machine to produce spontaneous conversation. You need repetition for messages to land and stick. That will mean repeating what you’ve said in different mediums (Slack, Email, Video calls) as well as overtime emphasizing the same message over and over again to build context.

2) Be HUMAN

Make in efforts to make yourselves ‘human’ to each other at a distance.

To show off their individual work spaces, Invision does a ‘Cribs’ style walk-around your home video stream to build bonds across long distances. Amazingly, 1/3 of the company tunes in each day to see the ‘Cribs’ zoom! I’m sure there have been some very interesting things to see.

3) Coordinate Synchronous Work Time

They do lots of synchronous work by coordinating working hours when possible and utilize Zoom and Slack to do it. That means they try to help collaborative teams not be spread over too of disparate of timezones. If they can’t, they manage expectations about how asynchronous work will happen and utilize the DACI framework for decisions making.

4) Create Knowledge Repositories

This is good practice independent of whether you have remote employees. Having centralized places for anyone to find information is key to any scaling company. At Invision they use Confluence and the to help build corporate knowledge about their product and company history.

5) More Skip Level Meetings

As a manager, one of your primary responsibilities is to conduct 1:1s, but they are are not only for your direct reports. A skip-level meeting allows you to connect with individuals who your team manages and to keep a finger on the pulse of what’s going on on the ground floor. When you don’t see the next strata of employees around the office, you have to set aside time to do so.

Anything you and your remote team do to help stay connected?

How to NOT mess up your SaaS Migration

I’ve often said that one of the biggest benefits to being a Product Manager for B2B SaaS products is that your customers generally stay with you for at least 3 years, if not 5 or more. That “stickiness” is inherent for a business tool because large companies don’t want to invest in change management every few months or even every year. Why? Because migrating between systems can be a huge time suck for IT teams and the other individuals who use the tools. It’s rare the the ROI for switching makes sense.

But, when the business case for switching SaaS providers is strong, a migration will happen. It probably won’t be fun for anyone involved. That’s why there are companies who are migration specialists or system implementers who get paid hundreds of thousands of dollars to do the work for enterprises. It’s a tactical job that few people want to do.

I’m currently helping with a migration for a B2B SaaS product that manages closed communities (think internal Facebook sort of thing). There are a few things that have surfaced that I thought were worth sharing with a larger audience.

1. Like any product / project, stakeholder management is key. It is integral to identify your stakeholders, what their goals are and to prioritize the migration according to delivering maximum value within a short time frame. Additionally, sending our regular status updates about progress will put them at ease that work is being done.

2. The time-resource-scope triangle applies. You can’t do “all the things” with limited resources on a tight time frame (as is common with migrations because you don’t want to pay for two systems for too long). Prioritization will make or break the success of the migration and delivering the most important functionality on time is often enough to make those stakeholders happy. As long as they know when the “nice to haves” are coming.

3. Not everything will be migrated. This one can be hard to grasp, but chances are there is a lot of bad data/content in your existing system that you don’t want to clog up your new one with. Think of it like moving apartments, do you really want to bring that piece of art you hate or the shoes you never wear? They’ll only add clutter in your new space, and the same applies to the old stuff you’re thinking of copying out of fear of losing “historical data”.

4. Something will need to reorganized. Keeping with the apartment move analogy, your new space has a different floorplan that your current one, which means your desk may move from your bedroom to the living room or that plant may end up in the kitchen. Understand the same thing about the new system you’re implementing. The data structure, user interface, and functionality are different (it’s why you are switching) and it’s worth investing some time in thinking about how your data/content should be bucketed in light of the new opportunity to rethink workflows and processes.

What else do you think is important to keep in mind when migrating from one tool to the other? Are any of the things I mentioned above not true when it’s on premise software?

Engineer Responsibilities During Design Phase

This past week I was chatting with one of our clients about getting the development team involved earlier on in the product design. I’m a huge advocate for engineers having input early on and think it adds a lot to solution design.

But they had had a different experience. They had invited the engineering team to discovery and design sessions, but then when it was time to kickoff the project many new risks surfaced and the developers expressed a lot of angst about the plans. What went wrong they wondered?

This issue reminded me of a story I read in elementary school.

This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry that Nobody did it because it was Everybody’s job. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn’t do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have.

Hopefully, you see the point. When people’s roles are not specified, they don’t know what they are supposed to do and things fall through the cracks. This also happens when a group of people collectively share a role and the individuals aren’t clear about what their personal contribution is supposed to be or if others will cover for them.

Which is what happened at our client who invited the entire dev team to their meetings. I suggested that in the future if a single engineer was included and their role was defined for them that they would have had more ownership and accountability.

Some things that should be part of how engineers contribute early on:

1. Raising red flags when things will be difficult to implement

2. Suggesting simple ways to implement or test ideas

3. Following up with other engineers about details they are less familiar with (back-end or front-end stuff, etc.)

What else do you think should be part of their role during discovery and design phase?

Most Important Product Metrics

We write a lot about product metrics and things to track with product operations, but today I heard

Ken Surdan

talk about the simple things every product leader should know.

1. How many customers do you have?

2. How long do they stay?

3. How much do they pay?

Ideally, if you have a portfolio you’d know each of these metrics by product and other relevant segmentation to your company such as geographic or customer size diversity, but I thought this was a solid starting ground for most conversations. You may also notice that #2 and #3 are a nod to retention/churn numbers, ASP and LTV. I enjoy that he puts it into practical terms so that you can focus on ensuring you are maximizing what you can get out of each of customer.