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.

What to look for when interviewing a Product Manager

If Product Management is both an art and a science, evaluating candidates cannot be something which is 100% objective. That hasn’t stopped people from making millions writing books about acing the PM interview at places like Google or Amazon. This guide isn’t for job seekers, it’s for interviewers, though it could be used by either. It’s particularly targeted at CEOs and other leaders who have not hired a product person before.

You’ve read Ben Horowitz’s Good Product Manager / Bad Product Manager, but what should you look for when the candidate is sitting in front of you?

The psychologist next to me on the plane as I blog says that you should look for eye contact. I agree with her, but that’s really something you should look for in any potential hire. Let’s focus interviewing on a product manager.

Depending on your product, the amount of industry or technical experience required will differ, but all product managers should be good story tellers. That is what the rest of this post will center on, what to expect in the stories that a quality candidate tells. The reason why this is important is because how a product manager communicates with you and your team will define their success.

The ideal PM Interview story format:

1. Starts with a problem — Product people are problem solvers, so you should expect their stories to start with an issue they observed or were presented with.

2. Researches the problem — You don’t want to hire someone who jumps straight to a solution, instead look for an individual who invests in understanding the problem first.

3. Collaborates on solution — If the interviewee doesn’t talk about the other people who worked with them to design a solution, it is a big red flag, collaboration is key.

4. Validates problem/Solution match — After problem investigation and solution ideation, they ideally talk about how they validated there was a problem/solution fit.

5. Evolves the idea — Good product managers will leverage the feedback they received while validating their solution to advance the product feature to best match the problem.

6. Empowers builders — Listen for how they talk about working with the developers and note if they only giving instructions or working with the engineers to create the best options.

7. Enables sales/marketing — Whether it’s through a B2B sales team or B2C consumer marketing group, an advanced PM will describe how the feature or product was sold to the market.

8. Measures success — Data driven decisions are what separates average PMs from great ones; an ideal story will include how they collected metrics to define whether the released solution actually solved the user problem.

9. Follows the data — Unless the candidate includes information about how the metrics guided them towards next steps, what was the point of collecting the information?

10. Iterates on product — Launching new things is fun, but a lot of the role will consist of iterating on the same product over and over again, it’s important that they are excited by later versions too.

Though the list of things above seems long, the last thing to look out for is the person’s ability to tell the story in a succinct way. You as an executive and other leaders within your organization will not have time to invest in long drawn out narratives.

What do you look for when PM candidates are answering questions?