What is churn?

If you already know what churn is, then feel free to skip to the next section. For everyone else: there are two types of churn – customer churn, and revenue churn.

Customer churn (also known as logo churn or customer attrition) is the measure of how many of your customers are no longer paying for your product. It is represented as a percentage and is calculated like this:

Churn Rate = (Total number of churned customers / total number of customers) x 100

There are then two ways to calculate and track revenue churn. Those are:

Gross Monthly Recurring Revenue (MRR) churn is the measure of how much money you have lost from customers leaving or downgrading their service. It’s calculated like this:

Gross MRR Churn Rate = MRR Lost from Churn / Starting MRR x 100

Net MRR churn takes into account how new customers and people upgrading have counterbalanced the negative impact your Gross churn has had on your revenue stream, and is calculated like this:

Net MRR Churn Rate = (MRR Lost from Churn and Downgrades – MRR Gained from Upgrades and Add-ons) / Starting MRR x 100 

If you really want to get to grips with these metrics, and the other product metrics you’ll want to be tracking to get the best from your product, download our free eBook, The Complete List of Product Management KPIs.

What is churn prevention?

Churn prevention is like a secret recipe that you use to keep your customers happy and keep them sticking around. It’s all about understanding what makes those customers tick. You need to address any problems that crop up before they get big enough to make them want to drop your product.

Think of it as more than just keeping people from leaving, though. It’s about building a real bond with your customers. You’ve got to look at everything from the product itself to how they feel when they call for help, and make sure that you’re staying on top of what they want as it changes.

It’s like mixing all the different ingredients of a complex recipe together to make sure you get the perfect dish that keeps your customers smiling. To do it right, you’ve got to dive deep into your customer data.

Watch out for any signs that someone might be thinking of waving goodbye. That’s your chance to jump in with solutions before it’s too late. Or to sweeten the pot to keep them around long enough for you to make the fix they’re looking for.

Again, it’s not just about holding onto customers, no matter what. It’s about keeping your product or service as cool as a cucumber, as hot as a chili, and matching what your customers want in their product bellies. It’s about staying in tune with what they need and making sure you’re delivering the goods.

In the end, churn prevention isn’t just some business mumbo-jumbo. It’s the key to making your business last. It’s about knowing your customers inside out, staying ahead of the game, and always changing with the times. Give it the priority it deserves, and you’ll be building lasting relationships, making your brand shine, and setting yourself up for success.

Who is responsible for churn prevention?

Customer Success

Let’s be real: the entire team has a spoon in the churn pot. It’s one of those things that’s everyone’s business. But usually, it’s the Customer Success squad that’s on the front lines, building those vital connections with your customers once they’ve hopped on board. They’re the ones making sure your customers are digging what you’re dishing out.

Being there in the trenches (or is that trenchers, to continue the food metaphor?), Customer Success is usually the first to spot the signs – like when someone’s app usage is dropping off, or if they’ve started grumbling. But hey, if someone does decide to jump ship, remember, it’s not all on Customer Success’ shoulders. We’re all in this churn battle together!

Marketing

Marketing can contribute to keeping churn low by making sure they reel in the right kind of folks to begin with. Those who’ll really get a kick out of what you’re offering. No sketchy sales tactics, no promising haute cuisine then serving up a hot dog. Just honest-to-goodness value.

Product marketing, who usually own customer comms, can also help keep your users engaged and happy through supporting a multi-touch communication strategy. While the Customer Success people will be hands-on and often one-to-one with customers, Product (or Customer) Marketing will be responsible for the mass communications and ongoing nurture emails that can help your entire customer base feel like they’re in the loop. 

Sales

Sales also have to make sure they’re not promising champagne and delivering Mountain Dew. They’ve got to match the right product to the right people. Otherwise, those customers are out the door quicker than you can say “Wait, what’s churn again?”.

Product & Development

Then there’s the tech folks, the Product and Development crew. They’re the guardians of the product kingdom, making sure there’s no hair in the food, and that service is glitch-free. Can’t have a wonky product scaring off your precious customers!

Support 

Of course, you need Support to swoop in, flag bugs, and make sure your customers feel the love when they reach out.

So, just like getting a fine meal from fridge to table, and making sure no one pukes it up and writes you a terrible review… it’s a team effort. We’re all in the business of crafting an amazing customer experience together. At any moment, a sour taste can send customers packing. I really should have had lunch before writing this!

How to prevent churn as a product manager

Ok, so now you know what everyone else is doing to keep your churn under control, what can you as a product manager do to tie all of their efforts together?

Keep your eyes on your ICP

Right from the get-go, you have to know who your dream customers are. That’s your Ideal Customer Profile (ICP). Get that down pat, and you’ll be drawing in the right crowd, the ones who’ll stick around. Because trying to fix a poorly conceived ICP later is like trying to unscramble an egg.

If you’ve got a bunch of folks signing up but scratching their heads, wondering what they signed up for, that’s a problem. You have to know who you’re building your product for, aim for customers that’ll stick around for the long haul. They’re the ones who’ll keep that revenue gravy train chugging along.

That’s why it’s so important to know your ICP like the back of your hand. Shout it from the rooftops! Understand who your buyer persona is and work closely with your Sales and Marketing teams to make sure everyone’s on the same page. That means clear messaging, killer sales pitches, and marketing strategies that draw in the perfect match for your product. Quality of leads over quantity is the name of the game here.

Get them onboard, then make sure they stay there

Then comes the onboarding – not just a one-time deal, my friends. It’s a continuous journey, making sure your customers feel supported long after day one. Your Product and UX teams need to work their magic, ensuring customers see the value they were promised. And, of course, Customer Success is right there, reinforcing that message every step of the way.

You see, it’s not just about getting them on board. Churn prevention’s about keeping them jazzed up about your product. After all, the opposite of churn is repeat business more engagement – retaining customers and their continued payments. If you can get 95 happy diners to come back for more, they’ll make up for the 5 who decided to go for a McDonald’s next time. That’s how you build a rock-solid cohort of customers. That’s the secret sauce.

Get to grips with churn indicators

Read between the lines of your customer data. Dive deep into the usage stats of those who’ve churned. Look out for any signs of decreased activity, neglected features, or a sudden surge (or indeed fall) in support calls. These are just some of the red flags that could be your early warnings.

However, no two products have the same churn indicators – so you’ll have to do the analysis for yourself and work out what the unique signs are that your users are losing interest.  Catch them and work your magic with the Customer Success team to win those wavering hearts back.

On a practical level, once you’ve determined what those churn indicators are in your usage data, make sure you’ve set up alerts that shout at you if a customer starts to display these patterns. It’s no good knowing how churning customers behave in the run-up to canceling if you don’t use that intel to pre-empt churn and work to mitigate it! 

Get ahead of the game

It’s all about pipping churn to the post. Use the insights shared by your most dedicated users and the churn indicators you’re tracking to create a special radar for those who are slowly slipping away. Reach out with tailored solutions, show them some extra love, and watch as those churn risks get handled before they even realize they’re thinking of leaving.

Plus, once you find out a reason for your customer churn, share that insight across the business! One way we do that here at ProdPad is with a regular cross-functional meeting. We look through all the churn reasons that have come up lately, to discuss what (if anything) needs to be done to stop it being a problem in the future.

Price it right to prevent churn

Sometimes it’s not about the product, it’s about the price tag. During these wallet-tightening times, you can be the hero with flexible pricing options and sweet discounts. But you’ll need to keep an eye on the long game – you want happy customers and a thriving business, not just a quick fix that’ll leave you in the red down the line.

You’ll need to box clever, though, because pricing is a tricky one! You don’t want to devalue your product, or rush in and cut prices if you’re not certain that is definitely the reason for your churn. No one likes leaving money on the table.

Be the feedback whisperer

Listen, really listen, to what your customers have to say. Their gripes, their suggestions, their praises – take it all in. Then, roll up your sleeves and get to work. Show them you care by acting on their feedback.

Never forget to close the loop – make sure you have that baked into your process. Whenever a customer submits feedback, respond to it. Then come back and inform them of the solution to their problem whenever a related feature or improvement ships. Trust me, a little TLC goes a long way in keeping those hungry churn wolves from the door.

Map out a clear path ahead

Let your customers peek into the kitchen – show ’em what’s cooking with a clearly presented public roadmap. Lay out the plans, the fixes, the shiny new features and solutions you’re bringing to the table.

It’s all about building that trust, showing them you’re always hustling to make their experience top-notch. When they see you’ve got their backs, they’ll stick around for the long haul.

What are the best ways to reduce customer churn? 

If your churn prevention attempts aren’t landing, then you need to start minimizing your losses. When your customers start bailing on you, you’ve got to dig deep and find out why. Don’t be shy! Give them a ring, and ask straight up – why the sudden goodbye?

Get to the bottom of it. Sometimes, it might be a glitch in your system that needs fixing, or maybe you just weren’t clear enough with what you’re offering. You might even have to go drawing board and ask yourself, ‘Are we even aiming for the right crowd?’

But the best way to reduce your churn? Talk to the folks who are sticking around, the ones who are loving what you’re dishing out. Find out why they’re vibing with your product. 

Let your happy customers do the talking for you

Ask them exactly what problems they had before they found you. Find out how it feels now that they’ve got your magic solution. Get into their heads and use the way your happy customers talk about your product to attract more of their kind. It’s like having your own little fan club writing all of your ads for you!

Let’s say 10% of your customer base is all in for your product. Well, what if you could bump that number up to 20%, or maybe even 50%? That’s when the real party starts. You’ll be pulling in more folks who are nodding along, saying, “Yep, you’re giving me exactly what I needed.”

Instead of running around like a headless chicken trying to fix things for those who’ve already left, focus on the ones who are cheering you on from the sidelines. They’re your best friends. Get them happy, keep them happy, and watch your revenue grow.

Trust me, it’s the happy bunch you’ve already got that’ll show you the way to more success and help you to really nail your churn prevention efforts. So, go on, find your happy diners, and let them guide you to even more wins!

Is it too late when a customer clicks “cancel”? 

In a word: No!

This is exactly why it’s so worthwhile to set up your exit interview process and find out what’s making them leave.  One thing, though: never hold somebody hostage! You really don’t want to be telling people that they can’t cancel, or making it difficult for them to finish the cancellation process.

That right there is some shady, black-hat behavior that is sure to damage your reputation. Rather, you could try offering a win-back as part of your on-site cancellation flow.

Don’t just shrug your shoulders and move on

What you want to do is pick their brains. Try to truly understand what’s going on, and why they’re done with your product. You might get some positive results from offering a targeted win-back offer as part of their exit interview.

If there was a misunderstanding, correct it and show them how to do the thing they think can’t be done. Maybe they’ll be happy enough to come back on board. If you’re talking to them and they say, “Oh, I’m canceling because you don’t do this thing we need”, then you can point out: “Actually, we do help you to do this! Here’s how…”

Or with a bit of luck, their problem might be something that you are just about to fix. It might be something you could choose to prioritize next. Perhaps it’s something where, with a bit of communication and support, they might change their processes or learn how to use your product more effectively.

That’s why it’s always worth having that conversation if they’re willing. And that’s why it’s important to ask them what’s up, because it might be something you can fix.

Don’t expect to save all of them! But every customer rescued from the brink will help your bottom line, and teach you something about what your userbase needs.

A last note about preventing churn

One thing that a lot of PMs don’t realize is that your actual churn rate at any one time doesn’t really matter, as long as it tapers out eventually. In theory, as long as you’re keeping some people, and they’re sticking around for the long term, then you can run a healthy business.

Your results may vary depending on other factors in your business, but it’s more about making sure that you don’t consistently lose customers until your graph hits zero. It’s okay if you do lose a bunch, as long as your predicted losses taper out and flat line.

You could be losing 90% of them, but as long as you’re keeping 10%, and those 10% are big earners for you, then you might still be perfectly sustainable.

PayPal constantly loses most of its paying pals

Matt Lerner, a former Marketing Director at PayPal, recently pointed out that PayPal, which made over $11 Billion in gross profit in 2022, is in exactly that situation.

Pretty much everyone who signs up for a business account with PayPal turns off – within a year, they’re inactive. But the people who do stick around become big, happy sellers, and PayPal makes tons of money off them. Once you’re a successful PayPal seller, you’re not going to leave.

So, there you have a business that’s losing 90% of its customers regularly. Yet they’re making billions of dollars a year. Clearly, then, churn rate isn’t everything.

Ride the curve

What can you learn from this? Look at your own numbers. Figure out where your churn rate flattens out, and then what you can do to build value from the customers who have stuck around. If you can continue to keep those folks on board and grow revenue from them, then you might be just fine.

While churn prevention is a vital part of keeping your head above water, and keeping your customers liking the taste of what you’re serving them, the first thing on your agenda should always be to make a product that your users actually want and need.

If you’re not doing that, you need to either change your customers, change your sales pitch, or change your product!

The post Churn Prevention: A Product Manager’s Guide appeared first on ProdPad.

While it may not be obvious at first blush, there is a recurring theme across all these value paths: productivity.

The highest form of leverage that B2B software can offer to an enterprise is productivity. An improved ability to effectively and efficiently run the business is the intended outcome of all B2B software purchases. And running the business could manifest as any number of workflows, across any number of personas, involving any number of tools. So where does one begin?

As always, research is the ideal route, but we need to scope down the problem space from something as broad as enterprise productivity. In this post we identify an emerging organizational shift that product managers building B2B software should be aware of; more and more companies are becoming aware that team-level (vs individual-level) productivity is the real point of leverage. The team (vs a user in isolation) has become the atomic unit in an enterprise, and there is tremendous product opportunity in enabling intra-team and inter-team collaboration. An example of intra-team collaboration would be a product pod consisting of a PM, UX designer, and an engineer reviewing wireframes as part of a scoping discussion, while an example of an inter-team would be a product pod and marketing team coordinating on a blog post that includes a recorded product demo.

When conducting research into potential new product opportunities for your B2B software, consider not only your core user but also adjacent personas. Power users don’t operate in a vacuum; for every creator and champion heavily using your product, there is a consumer and beneficiary also being pulled into your ecosystem. In fact, this adjacent user may not even be part of the org chart at your customer, but they are part of the workflow that spans the extended enterprise (think contractors, partners, integrators).

As a product builder in B2B software, identifying points of intersection between core-user friction and team-level collaboration can turn up opportunities for enterprise-wide value. And such problems to dive into and innovate around are great items to put on a roadmap once you’ve ditched the timeline view.

If embarking on an exploration around team-level productivity, one thing to keep in mind is an inherent tension between user-perceived vs buyer-perceived product value in the realm of B2B software. This is a longer topic for a future post, but trends like the decentralization of purchase decisions, usability expectations of enterprise software, and product-led growth all point to a future where users wield more power in the ultimate purchase decision.

If you’re interested in learning more about what ProdPad has to offer with regards to synthesizing feedback and lean roadmapping, please check out the ProdPad Sandbox, a pre-loaded product management setup where you can see ProdPad in action at your own pace.

And if you enjoyed this guest post from our former and future webinar collaborator Ibrahim Bashir, you can read more of his writings here, as well as sign up for his upcoming cohort-based course on scaling B2B products here. 

The post Product Value in B2B Software appeared first on ProdPad.

We’re all familiar with the term, ‘passing the buck’ and how people evade or reassign responsibility to somewhere or someone else. Senior execs do it to product teams all the time. 

I’ve seen it happen to many product people in different ways over the years.  Perhaps you can spot some of the patterns below in your own organization and take action before they have an impact on your work.

Product management always takes the hit

You see it in companies where the bosses set expectations like unrealistic deadlines and then pressure the product team to stick to them. The team then has to struggle to get things out on time, even though it wasn’t their call in the first place.

Product teams could pass the buck to the development team – after all, they’re the ones who build and come up with the estimates that always seem to slip. But PMs always seem to take the hit for everyone else – and I think proudly so – I wouldn’t want to be advocating for a role that was known for throwing its teammates under the bus. Rather, PMs are known for defending the time of their developers (and designers), helping to get them breathing room and much-needed air cover. 

On the flip side, however, product managers often don’t get the same consideration from the rest of their organization, with the most notable offenders being sales teams and the executive team.

Sales teams may well ask for features to be built, rather than selling what they have. Saying they can’t sell the product until X feature is delivered puts all the pressure on the product team – but the sales team should take responsibility and learn to sell or reposition what they have. It’s easier for salespeople to expect the product team to add what they feel is missing. (And don’t get me started on the salespeople who sell things that don’t exist and dictate the roadmap!)

Executives with a badly formed business plan or model put the product team in a difficult position. A classic example is the agency trap, where the company (usually for short-term cash gains) accepts custom project/client work, while also expecting the product to develop at speed. But the product team only has so much time, and can’t do client project work and product discovery and development work at the same time, especially if the client work leads to a stream of deadlines to hit. And it’s not the product team’s decision or fault that they’ve ended up in a delivery-focused way of working. It’s been foisted on them by poor decisions at the executive level.

Unreasonable reliance on the product team

To be clear, the management team is responsible for creating a viable business and workable company strategy. But sometimes they over-rely on the product team to create something that doesn’t yet exist, in timeframes that they can’t know are reasonable (let’s be real: you and the dev team are still working out the scope of this thing, never mind how long it will be before you’re able to deliver). By doing this, management absolves itself of the responsibility of creating and maintaining a viable business, brushing it off as the product team’s problem with no consideration of whether it’s achievable. I’ve seen some teams given ridiculously tall orders.

A company strategy should encompass a realistic product strategy (plus realistic marketing strategies, tech strategies, and so on). It’s not a good strategy if it relies on miracle workers to make it happen or if it’s dogged by insurmountable problems.  The execs shouldn’t just ‘pass the buck’ on their bad decisions or bad planning to their product team and hope that the team figures it out. 

How do you stop it?

The product team must call out this passing the buck when they see it. To be able to do this product people must understand the wider company strategy and where the product strategy fits in it – it’s one of the most valuable things a product person can do. 

They should also understand who’s had a say in product strategy and where some of its assumptions came from. Was the strategy handed to the product team, or did they play an active role in defining how they could help the company reach its goals? 

If there’s a sense that others are ‘passing the buck’ to the product team, then call it out and set boundaries. If you don’t, then the product team risks having more work pushed at them, setting them up for failure further down the line. For example, if you keep agreeing to custom client work, to the detriment of discovery work, you set a precedent that you will always accept project work…  and the core product will never progress and the company won’t move towards its ultimate goals. 

Calling it out helps management and other team members to see the broken parts, like missing resources or misdirected efforts, so that they can help to correct them.

The post How Passing the Buck Sets a Product Team Up to Fail appeared first on ProdPad.

Adding product features is fun and addictive, and it’s how the product management lifecycle works in many companies. If you’re measured in velocity and burn-down rates, then you’re optimized to deliver features. But we know that a bunch of features doesn’t necessarily make the best product. There’s more to do once the last lines of code are pushed out and developers have closed that ticket in Jira.

Let’s look at the steps involved in launching a product feature, from release to post-launch, and at how feature flagging and feedback can maximize your chances of success.

Beta modes and the definition of Done 

Development teams often refer to the “Definition of Done” to describe a completed piece of work. It might include unit tests, documentation, and any integration work that needs to happen. But although it’s done in development, that doesn’t mean it’s done. There’s a lot more to do before you can call the feature a success.

For example, you might want to manage the feature as part of a Beta test with a select group of customers. You can glean many insights in a relatively ‘safe’ space by releasing features behind a feature flag, and many product teams build this in as an essential ‘post-build’ stage in their product workflow.

Beta modes are a great way to test criteria for your product feature’s future greatness:

1. Does your product feature work as expected? Do customers use it as expected?

Use Beta mode to check that customers use the feature as expected. Sometimes users have surprising workarounds or use your product in ways that you didn’t think about! You should also check that it functions as expected, from a customer’s first log-in to when they get the feature to work.

There’s no test quite like production, and it’s your chance to see how your new addition fits into the bigger picture.

2. Can it be accessed as expected? Is it easy to navigate to and activate?

Features often flop because they’re not easily found. Launching a feature in Beta first allows you to see if users can find it in the product.

Don’t just rely on a marketing push to tell the world about your product feature. Marketing campaigns have time limits and may not hit your users at the right moment. Instead, the feature should be discoverable as part of a customer’s existing journey. If they skip over it, you should think about how to identify when the customer is likely to have the problem, and put access to the feature somewhere more obvious.

This doesn’t mean you put all your features at a user’s fingertips at all times. That would make for a hugely busy interface! Think about when the user is likely to need to use the new feature, and progressively disclose more functionality as they dive deeper.

3. Does your feature solve the problem? Do users find it valuable?

Many teams use their Beta phase as a staging period, and not as a huge opportunity to dive into learning mode. Don’t waste your chance! Talk to customers to find out if they’re getting real value out of the product feature. Ask questions like ‘How would you feel if you could no longer use this feature?’ to figure out if there’s a fit.

Connect your Customer Feedback Portal to your product, and capture feedback on new features right where they sit in your app. It’s important to make this flow as smooth as possible so you don’t miss valuable insights.

Learn about what customers love, and what irks them. Your first try at a new feature won’t be perfect, so embrace the feedback and learn from it. If customers find it valuable, listen to how they describe it. This will be the baseline for your marketing material later.

If they don’t find it valuable, either iterate until they do, or kill the feature!

4. Are you able to support it?

While developers might have a Definition of Done that includes technical documentation, a Beta phase will teach you what you need to do in order to support the feature. 

If the feature turns out to be too complicated to support and maintain then be ready to turn it off. It’s a lot easier to determine and do this at this stage, rather than later.

5. Are they willing to pay for it?

Most of the Beta programs I’ve seen involve the free use of the features in order to collect feedback and start to get customers on board.

But this doesn’t mean you can’t and shouldn’t ask questions about pricing. If customers find your product feature valuable, find out if they will pay for it, either as an add-on to your usual pricing or as part of a larger price increase that represents the growing value your product will soon provide.

Are there other business drivers that you can attribute to the new feature? Perhaps you can see research and usage data that indicates users will churn less, or that referrals will increase, as a result of your feature.

Compare your insights about the potential upside to the costs you’re also learning about, and paint a picture of whether this is a healthy feature to bring out of Beta and on to the next stage.

Beyond Beta is just the beginning…

Once you’ve thoroughly aired a feature in Beta, you must make the call on whether it lives or dies.

If it dies, record your decision and the insights that led to it in your ProdPad account. You never know when you’ll need to look back on these again. You can revisit the feature in the future or prove a point that something’s been tried before, so you don’t repeat your mistakes!

If it lives, it’s time to take it to your marketing team.

You can use the customer feedback which describes how the feature is valuable to craft a compelling story. 

After all, the best way to speak to your customers is to use the voice of your customers. 

Your launch material should cover things like:

• What is the feature?
• Who does it benefit?
• How will this make their lives easier, or better in some way?
• Why should they care about it now that you’ve built it for them? How do they start to use the new capability?

It’s no good making a great product that neatly solves a problem for users if no one knows about it. You should test and iterate on the marketing copy just as much as you do your features themselves.

Don’t worry if you have to iterate after your ‘big launch’. Any initial marketing will likely increase traffic over a couple of days, but the spike won’t last. The real value is in whether the feature continues to attract people to your product as a whole.

Your features aren’t there to drive spikes in your traffic, but to build the case for why your product is the right solution to your customers’ problem.

So use your launch-day data and beyond to measure how well your product feature is received and understood. Be ready to change your feature pages, on-boarding emails, and in-app guidance to reshape how you talk about the feature, so it has the best chance of living a long, healthy life.

We’ve all been there. We build a feature, launch it and forget about it because we’re too busy building more new features or tackling other marketing initiatives. Building is only the beginning. To succeed, you need to be able to iterate in both development and marketing.

That’s why it’s important to take time to consider how new features will fit into all aspects of your post-development workflow, including your beta phase and launch phases, before you release them. It means you can make sure every decision – from positioning and pricing through to customer on-boarding and user experience design – is in line with what customers want most from your company.

Want to get better outcomes for your feature launches? See how ProdPad can make sure your feature experiments come to life and provide you all the insights you need to continuously improve your products.

The post Don’t waste your new Product Feature – Tips for a Successful Launch appeared first on ProdPad.

The job of a product manager is to discover market problems, and then define what should be built within their product to solve these problems. Their goal is to improve outcomes for the people who use their product. They must identify those ideas that should provide value for the business, and then help the rest of the business to turn those ideas into reality. 

Sounds simple enough, right? The problem is that there will always be a wide range of opportunities to pursue, and each one of them will take time, money and effort. So product managers must use their skills, knowledge and the tools at their disposal to help their organization make good decisions about what to do next.

Product managers must ask the questions needed in order to make tough business decisions about new product features or enhancements. Marty Cagan, product management guru and partner at Silicon Valley Product Group, explains that a product manager should always consider value, usability, feasibility and business viability. This means that they should look at the following when deciding what to work on:

• Will this provide value to our customers?
• Is this change usable?
• Can we deliver it – is it feasible?
• Can our business support this change – is it viable?

The answers to these questions will help the business to decide where to invest in order to get the best return on investment.

What does a Product Manager do?

Day-to-day, a product manager communicates with different people, both inside and outside their organization, either to learn, or to share their learning. This means that it’s important for them to understand the organization’s different business functions. This is because they must facilitate and broker discussions between technical and business stakeholders. Product managers also need to have conversations with customers and end users of their product, and to be able to communicate at both a strategic and a detailed level, depending on the conversation. Finally, it’s important for product managers to document what they learn as they go, so they can easily use what they’ve learned to make the best decisions.

In general, a product manager is responsible for:

• Carrying out research on market needs by collecting feedback, reviewing data and examining the market landscape
• Discovering problems to be solved, based on the research they’ve carried out
• Identifying the most valuable opportunities for the business – which bets are most likely to pay off?
• Working with their product team to identify potential solutions to those valuable opportunities
• Defining what success looks like. For example, what outcomes should be expected, and how can they be measured to assess whether they’ve been achieved
• Experimenting to determine the most successful solution
• Measuring success and determining next steps

A product manager’s goal is to provide the best outcomes for customers, with the smallest possible investment. 

Product Manager’s day-to-day job

It sounds like a lot, doesn’t it! But there are some key tasks that product managers carry out on a daily basis:

• Collect feedback on market needs (in person, on zoom, via surveys or via customer-facing team mates)
• Define the product strategy based on the needs of the market and business objectives – this is known as creating the product roadmap
• Communicate the strategy to others, and seek to understand how it could be improved
• Break down the strategy into executable pieces
• Work with design and development teams to create product specifications
• Collaborate with customer-facing functions to help with their go-to-market activities

Product Management vs Project Management

A product manager’s responsibility is discovery rather than delivery. The skills that deliver a successful project – resource management, capacity planning, budgeting – are very different from those needed to uncover opportunities. Product management is not project management – that’s why we also say that a roadmap is not a release plan. In short, a Product Manager defines “what” and “why”, while a project manager defines “when”, “how” and “who”.

What makes a Great Product Manager?

A great product manager brings together a diverse, cross-functional team of people so that they solve a problem. They’re entrepreneurial and know how to to break big problems down. And they can see how to provide value in a way that reduces business risk. They use tools that help them to gain insights and make good decisions. Above all, they’re data driven and are excellent communicators.

If you’re looking for ways to ensure you stay up to date with Product Management best practice within your work start a trial now to see how ProdPad can help you.

The post What is a Product Manager? appeared first on ProdPad.

In the first installment of Hot Takes, Janna talks to John Cutler, Head of Product Education and Practice Research, at Amplitude about measuring to learn vs measuring to control. John trains teams on the best practices of product management. He has written extensively on the matter over on the Amplitude blog. Watch the video to understand the difference between measuring to learn and to control. You might end up with a craving for a bagel or two…

Read the full transcript below.

Janna Bastow:
Hi everybody, I’m Janna Bastow from ProdPad and I’m here with John Cutler who is the Head of Product Education and Practice Research at Amplitude. 

And we’re going to be talking about measuring to control vs. measuring to learn, So, John, really interested to hear your take on that. 

John Cutler:
Yeah, I’m super excited to be here. I’m reminding myself of breakfast, I’ve got the bagels in the back, and you’re reminding me of like a sunny afternoon so, yeah, I’m super excited to jump into this.

Janna Bastow:
Okay, so we’re talking about measuring to learn, vs measuring to control, which I thought was a really interesting topic and I thought sort of jived with some of the stuff that I’ve talked about in the past, but I’d love to hear from you why you think this is a difficult topic that product people need to hear about. 

John Cutler:
I think that the problem is how ill defined this is. So,you’ll talk to teams about frameworks… Actually I’m just off doing a three hour workshop and I think that, up until the last five minutes, someone thought that I was trying to describe a way to measure their team and decide whether their team had done a good job or not. And that’s how hard this can be for some people to grapple with. The leader was actually on the call and they’re saying “no, this is going to be great and we’re going to use OKRs and we’re going to use this North Star thing…” and it makes sense to me and I think I got what the leader was saying, but part of their team, for a good two hours and 55 minutes, were sort of cowering in the corner of the Miro board wondering what did this mean for them and would it mean that their team would make or not make their particular goals. 

I think it’s a very, very important thing to talk about because, especially at Amplitude, in talking to teams, you see teams terrified to measure anything because they think they’ll get it wrong, and if they get it wrong they won’t be able to prove something 100%, and if they can’t prove something 100%, then somehow the metrics are dangerous and that they are going to be used to backfire on them. So it’s sort of about metrics of use. 

I think it does have to do with when you’re measuring to learn, you’re sort of exploring uncertainty and you’re hoping to just reduce it by a bit and be asking better questions tomorrow than we did today, or today vs yesterday. 

And when you’re measuring to control or goal setting, that’s when you get the things like “by the end of this quarter, we think we’re going to move this metric from here to here”, or, “our team’s particular thing is to do that”. 

It’s just two different mindsets when it comes to measurement and so I think it’s important to distinguish the two. 

Janna Bastow:
Do you think that this measuring to control thing is sort of  more of an old school mindset that you’re finding some companies are taking on?

John Cutler:
Maybe, but no, I wouldn’t say… and using the word ‘control’ probably sets it like that but I would say that, you know, let’s say that you’re a team, I mean I’ve done this when I was part of a startup, we’re like “hey, we should have some goals, it’s going to help hold each other accountable, it’s going to kind of keep us focused” and it came from the healthiest place. So I don’t think there is something inherently wrong with goals, right, or trying to add some control or alignment to what we’re doing. Now certainly in larger organizations this just becomes a stick to beat people with, it’s like no one… let’s just take something like NPS and let’s just say no one in the company believes in NPS except the person who dreamed it up, like they were going to use it three years ago. And you’re actually seeing this out there, that like teams are measured on their ability to move a metric that no one really believes in and people have a lot of problems with, and that’s that kind of like… so I would say that measuring to control ranges from “hey, we’re in this together, we’re a team, let’s set some goals. Or even, like, you know, I told Sharon upstairs who’s taking care of our baby, that I’m going to exercise for ten minutes a day, that’s my goal, and it comes the best place. So there’s a spectrum of that, from that all the way to, you know, very, very malicious use of measurement. And then the measuring to learn is it’s almost like, sort of separate idea about what we’re trying to learn, you know, are we trying to learn more about what our customers value, or are we trying to learn more whether our strategy is clicking the way we thought it was. And the whole idea there is it’s very open to challenge and open to refining, you know, and I think that’s a really important point. 

Janna Bastow: That’s a really good point, and I see that this happens to so many measurements that we create, and I say “we” in term of, like, the whole sphere, the whole industry, and we tend to create these things. Like KPIs I think were created from a good place, but then were used by management as this stick, and people just shied away from them. And then OKRs became the new thing, and now they’re starting to get a bad rap here and there because they tend to be used in the wrong way. So how do we make sure that this concept of measuring to learn doesn’t get turned into something more insidious?

Book yourself in for a demo with one of our product experts. They’ll be able to help you with your product strategy and show you how ProdPad is perfect high-flying product leaders.

The post Hot Take – Measuring to Learn vs Measuring to Control appeared first on ProdPad.

Creating your own custom workflows

Head over to the company settings and under “Workflow” edit your stages.

To create a new status, fill out the form under “+.” You can rearrange your workflows in the correct order using the drag/drop handle.

If you need a little inspiration, we recommend the following setup:

• New idea (default)
• In Review – Indicates you are reviewing/validating the idea.
• Needs More Info – Indicates the idea requires more information/is being spec’d out.
• Approved for Development – Indicates the idea has been approved for development.
• Queued for Dev – The idea has been sent to the dev team and is being prepared for a sprint.
• In Development/In Progress – The idea is with the dev team and is being worked on.
• QA – The idea is being QA’d.
• Released – The idea has been released.
• Not Doing – The idea won’t be done.
• Duplicate – There is a duplicate in the system.
• Failed Experiment – The experiment failed.

Creating a custom workflow view

This is where the magic happens.

Once you have created your own custom workflows, you can create your own custom view with a few preselected workflows.

This means you can preselect workflows and only see the ones that fit your needs.

For example, if you only needed 5 of 10 workflows created for one team, but another team needs 8 of the 10, each team would have the ability to create their own custom view.

To do so, begin by viewing your filters and selecting all the workflows for your custom view. Once you’ve selected your workflows, create a saved filter. You will be able to share this saved filter with other users.

The post Working Together with Custom Workflow Views appeared first on ProdPad.

Initial Q and As

Q: Many product managers talk about the need to be close to users, and to understand user problems clearly. What techniques work best to convey this key information to you?

A: I’m lucky enough to have direct contact with our amazing users through our Slack community. If users have a problem, they generally tell us. When we have a new feature we want to test, we’ll ask our community if they want to be beta testers then once I’ve prototyped something our UX designer will run them through a series of user tests. The feedback we get from our users is essential for both iterating and even sometimes deciding if we should scrap a feature idea completely!

Q: Have you seen benefits from developers engaging directly with users? How should this be managed?

A: Sure, it has a direct impact on our feature prototyping, but it can also help when debugging a particular difficult issue. I know some companies aren’t keen on their developers having direct contact with customers, but for us at ProdPad it’s invaluable. It’s worth discussing the benefits you think your team and company could gain from talking directly with your everyday users.

Panel: As a UX developer, I’m quite involved with our users because it’s relevant to my role, but we were all a little divided on this one. Being “shielded” from customers was more important for some of the other dev’s productivity and sanity! I know not every developer feels comfortable talking to customers, so don’t go throwing your developers into direct customer contact without asking first.

Q: At what stage should developers be brought into ideation?

A: All developers should be involved from the beginning of ideation if you want them to feel valued! We play the Product Tree game at ProdPad, where the whole team writes down everything they feel is important to make our app a successful and engaging product. Together we place them on the tree with the idea that roots are the infrastructure, and the trunk and branches are suggestions of ideas/features that we could work on soon, right up to the tree tops which are more future features. When I get to work on a feature that I had personally suggested or contributed to, I feel like I am directly improving the product and am genuinely excited to work on it.

Panel: The others had similar processes to the Product Tree game but we all agreed that giving your developers a voice makes them feel more valued (which seemed to surprise a few people in the audience!). This is an invaluable feeling for any developer and I would highly recommend doing this for any company.

Q: What role could/should developers play in prioritizing dev work?

A: When I look at bugs (which we track via Trello), I would personally rather have them prioritized for me so that I know what exactly should take priority. When you have lots of bug reports and features coming in and you’re not sure what to work on next, without prioritization the wrong things could end up being built. When a product manager (or the person prioritizing work) doesn’t share their reasons for prioritizing in the way they do, then developers can end up feeling that they’re just churning out work and constantly fighting fires rather than understanding the importance of what they’re working on.

Panel: We all talked about the need for complete (as possible) functional specifications and documentation. It’s hard to get the balance of how much information should be included as documentation can date quickly, but I’m of the opinion that the more detailed a specification is, the better your development process will be. By having a definitive spec, there will be less ambiguity and misunderstanding around how something should work, preventing in less time spent at the QA stage, as well as that dreaded scope creep.

Q: How would you like to see the overlap between design and development managed?

A: When I worked for an agency, we would sometimes use freelance designers and their initial designs weren’t always built in a way they envisaged. This was down to a number of reasons – including designs being handed over without interaction specs or something being designed that was technically impossible. Because the designer wasn’t involved in the development process they weren’t there to work with developers to answer questions or work on technical restraints with them. Sometimes the build phase can be beneficial for tweaking designs/UX, so things work better than originally designed.

Panel: There was a complete split here. Some agreed about working directly with a designer, but others felt they just wanted to be left to build something that was fully specced out. But unless the work handed over includes a full spec, you could end up with a bit of a mish mash.

Q: How do you approach testing? What should be done by you / your peers / separate QA specialists? Do you get enough info on how testing is being done and who by?

A: Testing phases and bug fixing can be one of the most frustrating things for a developer (we all nod). It’s so important to have a set of criteria and process when logging bug reports. If we can’t replicate something, it’s very difficult to fix it! Verify the bug first and add information such as steps to replicate (arguably the most important), the user’s environment, screenshots etc. These are all helpful, and I urge you to please make sure this information is supplied to your developer before asking them to work on a bug. I promise you it will improve your relationship with any developer, they won’t have to spend time going back and forth for more information or waste time trying to replicate something that may even be reported incorrectly.

Panel: We all agreed that bug testing / QA process can be one of the most exasperating parts of our jobs. How you report a bug is vital, it’s often distracting and unproductive to have to developer constantly switching context, so this is where prioritization is important.
It’s also worth keeping in mind that while other colleagues may be recognized for the great things they do, developers are more often than not recognized when there’s an issue with some code rather than the work that goes into making something a seamless experience.

If you make one change, remember to thank your developers!

Q: How much does post-launch feedback matter to you? How does knowing (or not knowing) the impact of your work affect you?

A: I want to hear that people love what we build, but I also want to hear when they don’t. If you don’t have a good relationship with your customers, it could negatively affect your product. If you’re just churning out features, not knowing if what you’re building is any use, how can you justify what to build next. At ProdPad, our roadmap is a mixture based on our product tree sessions, our users’ feedback and business decisions, and not just because our CEO says so!

Q: Developers need solid periods of work to solve complex problems – but the rise of electronic interruptions (Slack messages, browser push notifications etc.) doesn’t help. What tips can you share that might help your Product person work better with your periods of focus?

A: If my headphones are on – I am generally focused and don’t want to be interrupted if it’s not important. You’re likely to be greeted with a grumpy developer if you’re constantly breaking their “flow”. If developers have the option to work from home when they need to get their head down that’s great, if not, being able to set themselves as busy on Slack or turn off email notifications for a couple of hours will help. But you need to make sure all team members respect the “headphones on” or “away from Slack” approach..

Panel: We all felt that solid blocks of time spent coding a particular thing was much more productive than lots of little pieces of work.

While you don’t want a developer to feel like they can’t concentrate on a complex piece of code, you also don’t want a frustrated PM to feel they can’t talk to a developer. Instead of asking lots of questions throughout the day, try and ask them in groups of questions, e.g. in a morning daily stand up, late afternoon or a single email. I also always appreciate a bulleted email rather than a rambling of paragraphs

A few audience questions…

Q: As a PM, how do I treat my dev team without being condescending. I use stickers but is this silly?

A: I personally love stickers, so this wouldn’t be a problem for me! Stickers aside, I recall a time at my previous company when I’d been plugged in and coding for four hours and needed a breather so went to spend five minutes googling cat videos (as you do). I noticed my PM was hovering. He instantly questioned me, asking why I was looking at cat videos and if I’d completed something yet. Needless to say it was really frustrating for me, because I often find that tiny break helps me to clear my mind and perhaps think of a better way to implement something. Sometimes we just need to unwind for five minutes when switching between code as it’s hard to get your mind from one code base to another!

Q: How do you cope with deadlines?

A: I personally work better when I have a deadline to aim for. At ProdPad, while we don’t have dates on our roadmap, we do try to release twice a week. This continuous deployment approach gives us something to aim for and helps to keep focus.

Q: How do I talk to my developers?

A: This made me laugh, but my answer was just like you talk to anyone else!

Aftermath

At the end of the session, several people came up to us individually to ask more one on one questions and overall I think the panel topic was great, everyone, not just PMs, seemed to get a lot out of it.

In summary, I think there are some small things you can tweak to improve your product manager and developer work relationship including:

1. Listen to your developer’s ideas and include them where possible. Even if it’s just playing the Product Tree game or similar ideation approaches. You could get some great suggestions.
2. Appreciate and work around the fact that developers need solid blocks of time to focus on work. Encourage a work from home day (where possible) or use a temporary busy on Slack /offline approach.
3. Most of all, say thank you to your developers! They like to feel appreciated too. <3

Watch the AMA we hosted with our Dev team

The post What do Developers want from a Product Manager? appeared first on ProdPad.

This was the problem I faced when I left a large corporate product management team and joined a SME. And I had exactly the same experience when I joined a startup a couple of years later.

What could I do that would make a difference? As the first and only product management hire, I had a lot of self-imposed pressure to make an impact, so I was keen to find a silver bullet!

Both times, it became apparent that having the right product management process in place would be a great place to start.

3 Tech Team Problems in Any Business

I’ve worked with lots of different tech teams since then, and I’ve seen the same problems again and again:

• Large, unmanageable backlogs in the development team’s tool (Trello, Jira, Pivotal Tracker etc)
• Bottlenecks in story development, preventing development teams from working on chunkier, high-value features
• Difficulty in prioritizing which ideas should be worked on by the product and development teams

The symptoms of these problems are pretty clear to spot – lots of work started, little work finished. Lots of bug fixes and small changes delivered, but the high-value changes seem to fester and never quite get released. Frustration by business stakeholders (and customers) that their feedback isn’t acted upon. A general feeling that the product backlog is a place where ideas go to die.

A few simple changes and a good process can help!

Breathe Life Into Ideas Outside Your Development Backlog

First, get that big list of ideas out of the development tool. They don’t belong there, and just act as a distraction for a team that needs to focus on delivery of high-priority changes. The development toolset is about delivery, not ideation and discovery.

Turn Ideas Into a Manageable Backlog

Second, think about how you can work that big bucket of ideas down to a manageable backlog. Prioritization isn’t just about deciding what the development team should work on, it’s also about working out where to spend product management time. The product manager is expected to spend time in the marketplace, to understand user problems and work out where changes could have a big impact on user satisfaction, adoption, retention and ultimately revenue. How is that possible if you spend all your time writing user stories and specifications?

This is where process comes in. The first step in your process is to identify which ideas are potentially of high value to the business. Of course, you already have a vision for your product and you know your company objectives, so you can use those as a guide for which ideas score highly. If it helps, work with your senior management team to define a set of criteria for your impact score – for example, ideas that fill a competitive gap or are likely to be revenue earning could score highly, whereas a single request from one customer might result in a low score – until you get more requests, anyway.

Once you have that impact score, you can decide which ideas need a development estimate. After all, there’s little point asking for an estimate where the feature isn’t likely to be developed. Straight away, you’ve reduced the burden on your developers – they’ll love you for it! You’ve also reduced that bucketful of ideas down to a more manageable list – good news for everyone.

Hone Your Prioritization Technique

At this point, let’s cast our minds back to an old story that appears in lots of different guises, but is designed to help with prioritization. A philosophy professor stood before his class with some items in front of him. When the class began, wordlessly he picked up an empty Mason jar and filled it with rocks about two inches in diameter. He then asked if the jar was full.

They agreed that it was full.

So the professor then picked up a box of pebbles and poured them into the jar. He shook the jar lightly and watched as the pebbles rolled into the open areas between the rocks. The professor then asked the students again if the jar was full.

They chuckled and agreed that it was indeed full this time.

The professor picked up a box of sand and poured it into the jar. The sand filled the remaining open areas of the jar. If you put sand into the jar first, there is no room for the rocks or the pebbles. Finally, the professor opens a bottle of beer and pours it into the jar, where it soaks into the sand, filling the final gaps.

The story goes on to talk about making the big things in your life (family, friends, health, happiness) a priority before the small stuff like cleaning your house – a philosophy I heartily support! It also points out that after prioritizing everything you need to do, there is always room for beer with a friend!

The same principle applies to prioritizing your workload. If you spend all your time on “sand” tasks – bug fixing, small usability changes – you won’t have enough time to take on the high-value, complex tasks like refactoring an inefficient piece of code, or developing that big new feature you’ve discussed for months. The point here is that it’s important to prioritize the high-value ideas first, even if they represent significant effort.

So let’s regroup! We had a big list of ideas, and by assigning an impact score we’ve reduced it to a list we’d like to get estimated. We now have a list of ideas with both impact and effort, and can start to plan which ones we tackle first – we’re going for the rocks first, and filling in with pebbles and sand where it makes sense. Who knows, at the end, maybe we’ll get that beer when we celebrate the release!

By taking this approach we are focusing our product management time on ideas that make sense, rather than every idea on the list. Hurray, we have more time for customer interviews, competitive research and the myriad other ways of collecting market feedback!

Let’s fast forward a little. We’ve identified the right ideas to be working on, and we’ve worked with UX, customers and business stakeholders to prepare user requirements, user stories, designs, wireframes and anything else we need to hand over to development.

What do we do Next?

It’s highly beneficial to have a formal kick-off meeting, one which sets the scene for the entire team to succeed in building the right thing, and building it right. The meeting should take the form of a 30-60 minute call, and only go ahead where there is representation from product management, UX, development and QA. It’s worth making a particular point of including the developer(s) who will be working on the change, and include a lead developer or architect – whoever is responsible for the technical design.

Start the meeting by reviewing the idea, focusing on the problem to be solved and the expected outcome. Review user stories, specifications, designs etc, and generally ensure that everyone has a shared understanding of WHAT is required, WHY it is required and HOW it is to be built and tested.

At the end of the kick-off meeting, when everyone is happy with the path forward, the user requirements/designs etc can be pushed into the developer’s backlog – likely to be in Jira, Trello, Pivotal Tracker or similar. From this point on the team are focused on delivering a well-defined change, and the chance of rework due to misunderstanding is vastly reduced. Of course, questions will crop up during the development process, but that’s all part and parcel of agile development.

Let’s fast forward again, to the point of release. The development team have worked hard to deliver a new, valuable feature, and everyone has agreed that they’re getting what is expected. Does the process end there? No, of course not! We need to learn about how successful our new feature is. Is it well adopted? Does it solve the problem? That product management process should cover steps for validation and measurement – going back to check on success is an essential part of the product management process, and not to be forgotten.

The post How to Make a Big Impact as a New Product Manager in the First 30 Days appeared first on ProdPad.