What to learn from Audible to avoid Payer Churn

After focussing some broader advice for product people in the past couple of weeks, I wanted to be very practical with this post by sharing a best practice regarding churn prevention: Audible.

I recently noticed that my Audible subscription got renewed besides me currently not being able to catch up on further audio books.

By completing the necessary steps to cancel it, I couldn’t help but admire how well this was done. But not only from the viewpoint of an optimizer but also from a user’s perspective.
It just felt…worshipped.

So, without further ado, here are four steps of churn prevention worth memorizing. Unfortunately, my language has been set to German, and I didn’t think of switching it in time. I’ll give some context in English in the captions to help most of you out.

Audible Churn Prevention - Step 1
Ok, nice. You’re repeating what I’m missing out by canceling now (which is a credit of three free audiobooks per month) and provide some recommendations (which are pretty much on point) for what to spend it on.
Bonus Point: Primary CTA is a positive one (‘Redeem Credit’), and you have to look twice to continue with the cancellation.
Audible Churn Prevention - Step 2
Oldie but Goodie: Asking why I want to cancel. The available options seem to be quite a lot but need to capture a lot of possibilities as well. I’m curious if the next page will react to my choice…
They’re now also dropping the CTA confusion and offer only one button to proceed with the process. Very honest and straightforward.


Audible Churn Prevention - Step 4
Subtle, but positive confirmation of my cancellation and I’m back on the page where it all started – My account settings. Well done, Audible!

Would you like to see more from that kind of teardowns from me? Specifically not on onboardings but rather not so popular processes like churn.
If so, just send me an e-mail and let me know which product or service you’d like to see assessed.

Why Product Managers need to embrace Lateral Leadership

I recently got some food for thought for relevant challenges in product management from a fellow product owner who reported on the following situation:

‘The development team didn’t accept the problem I gave them to find a solution for.’
While I wouldn’t say that that’s a very common challenge for product people, the skill it requires to solve is among the top 3 qualifications it takes to succeed as a product manager: Lateral Leadership.

What is Lateral Leadership?

In short, lateral leadership means leading other people without having hierarchical power. As mentioned, it’s the exact opposite of hierarchical or top-down leadership which is (unfortunately) the most common way of managing.
And even though lateral leadership was by no means originally developed to fit the leadership position product managers are in, it’s exactly what you need to embrace if you want to lead team members and stakeholders which don’t report to you.

Why is Lateral Leadership relevant and how to apply it?

To understand why product managers are lateral leaders instead of hierarchical leaders, I want to emphasize how the company structure around product managers is usually structured:

Product Managers lateral leadership organizations

What you see here, is the result of a so-called ‘matrix organization.’ Even though (SCRUM) teams are intended to work as a unit by itself, the team members taking care of engineering and design are most often only ‘led’ to the product owner within the construct of a development team.
They all have other people managers who are overseeing the respective departments across multiple development teams and sometimes even business units.



What that means is that your team needs to accept you as the one who defined what is done, but someone else is responsible for the how.
And that’s where the point of lateral leadership comes in. While the heads of department have managerial tools to lead people (even though that should be the exception), you have to convince your team members to follow you without administrative ‘super powers’

Quite the contrary, key factors for achieving lateral leadership are furthermore things like:

  • Strong and explicit communication
  • A clear vision
  • Empathy
  • Passion
  • Trust

There’s an excellent book by Daniel Pink called ‘To sell is Human.’ In it, Pink even refers to this skill as the ability to “move” people from one mindset to another.
Successful product people need to spend time and effort on these ‘moving’ activities, bringing everyone together around a shared understanding of the customer or business problem so that everyone can be involved in helping solve it to further the business goals.

Sounds familiar? Good, then you recognized the pattern of alignment. Closing the loop on the fundamental challenge the product owner faced, a likely reason for a development team not accepting a task is the lack of context. More precisely the context around why this task matters in the greater scheme of things and how it’s execution moves the needle.

Even though you may have paid attention to alignment using one of the several available tools, I highly recommend either revisiting the initial alignment document with the team or even going back to the drawing board to get everyone’s motivational drivers considered.

What to do when Lateral Leadership tools fail?

Of course, alignment and other lateral leadership techniques can only do so much. If everything fails, I recommend 1:1 discussions with the individual team members to get to the bottom of what’s causing the resistance.
Maybe you get a handle on individual factors (e.g. an unresolved conflict from a personal situation), or you simply have to involve the respective heads of department for advice or even escalation.

Why Stakeholders mostly talk in Feature Requests

Almost every product manager knows the situation (if you don’t, please let me understand how you avoid it right from the beginning): Some of your stakeholders just always come up with very specific features (aka solutions and not problems) they want you to build into your product.
While some of them may have learned and agreed to the concept of building an MVP first and no stuffing the first product release with more functionality, they a least insist on storing them as they are in the product/feature/idea backlog (here’s why that’s not an approach to pursue).

That’s because they’re like users – They don’t know what they want. And talking about particular features is their way to remain involved in the product development process continuously.

The key for you as a Product Manager is to determine where the urge of some stakeholders to be a regular part of the day-to-day product development process originates. You have to reverse engineer your stakeholder’s feature requests back to ‘jobs‘ they want you to fulfill for them or your target user.
The most likely reason though is that they think hat the product output becomes proportionally better with their involvement.



Unfortunately, this misconception is the result of a lack of trust these stakeholders have that the delivered output by you and your development team matches their expectations.
Why that may seem like a very unfortunate situation, the best way to resolve this issue is to focus on alignment early on in the product discovery and the commitment to a particular outcome rather than feature idea.

A better way for stakeholders could be e.g. to drop in inspiring snapshots they’ve seen in other products with the apparent accompaniment that the way this product approached an individual problem may be helpful for your work.

Remain the most clueless person in the room – But be the most enlightened one

Being a Product Manager is not about being the ingenious front singer and songwriter of a band everybody adores. It’s more about being the quiet but confident maestro orchestrating an orchestra of proven experts (without the usual top-down attitude).
As a result, a Product Manager is also not the right person to name the next shiny killer feature. You’re rather the one who shows the path and sets the stage for discovering it together.

Over time, I became deeply convinced that great Product Managers are no single domain experts. Furthermore, an in general considered ‘good’ Product Manager can succeed across a vast playing field of areas – whether it’s e-commerce, finance, mobile apps or machine learning projects.
There’s even a certain risk in being too deeply intertwined with the domain you’re tackling. By having deep domain knowledge, it’s so much easier to get caught up in seemingly great feature ideas. By having a certain distance or even naivety towards the industry, you’re much better suited to avoid confirmation bias.



And by relying on your education about user-centered product development, you’re more than set to build a strikingly successful product in whichever domain you want.
Without the need of building up too much domain knowledge which, in an era of ongoing disruption, seems nowadays like unnecessary waste anyways.

Guidelines for measuring success in Product Management

When I started out in Product Management, the role, in general, was considered to be a bit more stakeholder-focussed project manager. It was all about facilitating requirements and keeping the (mostly outsourced) ‘IT department’ busy for a low daily rate.

The main success criteria to measure Product Managers again back then was basically to ship a particular feature (mostly determined by a HiPPO) in a given time and extremely budget. How essential or even reasonable a feature was, leave alone measuring the impact it may generate, were seen as unimportant factors.

Time Quality Budget Product Manager

Thanks to the influence and popularity of product-centric companies like Facebook, LinkedIn, Airbnb or XING, this perspective is now dismissed from modern product development.
Instead, Product Managers are empowered to truly take responsibility for that they were building in strong collaboration with design and development teams.



Comparing the guidance provided to Product Managers for moving forward with the “time-quality-budget“ approach, it’s now more something like:
Build the right feature for proven user needs with the leanest approach to generate a significant impact which is in line with pre-defined KPIs.

Modern Product Management Success

This lens of looking at the success of a product manager is not only important for individual people managers but also the product manager herself.
Don’t get caught up in “time-quality-budget” madness when it comes to reflecting your performance. Take a smarter approach looking at your work.

Product Management Vlog 001 – Mind the Product Engage 2017 in Hamburg

Welcome to the first episode of my Product Management Vlog.

Follow me throughout my day as a visitor of the Mind the Product Engage conference in Hamburg and get my take on a couple of talks I attended.

(Sorry for the partially bad video and windy sound. This stuff will get improved with the very next episode!)

Alignment doesn’t need Agreement

When I talk about the importance of alignment and several frameworks to create it, I often hear questions regarding what those are for and what the goal of the invitee/creator should be when walking key stakeholders through an alignment process.

When I then explain that, at the very end, it’s all about getting commitment/buy-in, a typical response is something like that: “Ok, so, I need to convince everybody to agree with my point of view.” And this way of thinking often leads to the initial rejection of an alignment process, because people then don’t see any chance at all, to get individual stakeholders to agree with them on the process ahead.

That’s why I wanted to use underline the importance of not confusing alignment with an agreement. The way more important part of alignment is commitment. And it’s way easier to get the commitment from your stakeholders, then making them agree.
I stole a nice phrase from the most recent shareholder letter Amazon CEO Jeff Bezos just recently published and which I’ll cite blow in a minute: disagree and commit.

Third, use the phrase “disagree and commit.” This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, “Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?” By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes.
This isn’t one way.
If you’re the boss, you should do this too. I disagree and commit all the time. We recently greenlit a particular Amazon Studios original. I told the team my view: debatable whether it would be interesting enough, complicated to produce, the business terms aren’t that good, and we have lots of other opportunities. They had a completely different opinion and wanted to go ahead. I wrote back right away with “I disagree and commit and hope it becomes the most watched thing we’ve ever made.” Consider how much slower this decision cycle would have been if the team had actually had to convince me rather than simply get my commitment.



This example perfectly outlines a position a manager should take when working together with an empowered team: It’s fair to have a different opinion in your mind and articulate it.
But when your team of experts then chooses a different path to pursue anyways, you must have their back as if they’d follow your suggestion in the very same way.

So, coming back to the difference between aiming for agreement and commitment in an alignment process, a proper comparison is also to take bets, close the process and back them 100% compared to endless rounds of discussions to get harmonizing everybody’s opinions for the sake of it.
If you’re facing the latter one frequently during internal discussions, it’s also a very fundamental cultural issue within your company. Focus on consensus instead of embracing conflicting opinions.

Do Product Managers need a Portfolio?

It’s almost funny how much focus the specifics of individual projects get during the hiring process of a designer. A CV on the other side is not much more than a necessity to check for some known names.
And in the end, everything boils down to their portfolios. It’s, on the one hand, the perfect place for the designer to put some love into the representation of the work one has done. On the contrary, it’s ‘perfect’ for judging the capabilities of a person based on pixels.

The situation is then often, that most design portfolios look pretty, but completely lack context or outcome of a project. And because everybody (involved in the hiring process) of course has a (strong) opinion on design, the portfolio gets judged subjectively as shit.

That’s a real problem as at least I favor an approach to the application process which removes subjectivity and focusses on outcomes (read this book for more input on this topic). So, if portfolios, in general, are already an established part of the hiring process for designers, shouldn’t a more outcome-oriented version of the portfolio play a significant role in a Product Manager’s application process as well?

To me, the answer is yes. At least, if you’re beyond the junior job level and have a couple more projects to talk about under your belt.

Way more important than the actual medium you’ll use to showcase your work (since there’s no Behance for Product Managers yet) is the real content to put in.
As a Product Manager, your success is often measured by the numbers/impact your product has generated. It’s a bit unfair to say, but while designers can hide behind beautiful pixels and bouncy animations, you need to come up with the naked truth and objective facts.



That’s probably the main differentiator when compared to the current state of design portfolios being part of the hiring process. As outcomes should be a part of a Product Manager portfolio, you won’t hear that many ‘opinions’ on that part. And it’s certainly not a matter of taste on how to judge it.

While I currently don’t maintain a product portfolio myself, I made a weak attempt back in 2014 on my personal website. If you’re looking for a better example, I highly recommend the way my fellow product superwoman Petra Wille is presenting her work (German only).

So, when you’re assembling your product portfolio as a continuous representation of yourself or for a particular application process, I recommend something loosely following this structure:

  • What was the objective of the project/product?
  • Which stakeholder environment did you face?
  • How did you structure the discovery and delivery process?
  • Building up on that: Which frameworks & tools did you chose to apply and why? Would you pick those again (for the same context)?
  • What was the measurable outcome?
  • In hindsight, what was your biggest personal learning from the project?

Some additional thoughts on the criteria of a Product Manager’s portfolio are included in this neat article by Sachin Rekhi.

If you’re interested in developing a template for Product Manager portfolios, just say hi to me, and we get the conversation going. I’d love to see something like this happen and spread across the community.

Getting the Product Manager job done from your Smartphone

Mark Benioff, CEO of Salesforce.com, once famously revealed, that he’s running his whole company purely from his smartphone. While those claims may have sounded a bit adventurous a couple of years ago, I can totally see all the ‘normal’ management stuff being done on your iPhone or Android.
But what about people who are working more ‘hands-on’ all day long? This is why I dug deeper into the usual routines and tasks of a product manager and wanted to go through the mobile productivity solutions for your daily challenges!

Team Communication

Working as a product manager means communication. Whether it’s about keeping your stakeholders up to date, being available for questions from your development team or triaging the latest design review process, communicating with other people is key.
Luckily, apps have evolved the most in this area.

Thanks to Slack & HipChat, are tools stemming from very product-minded companies. This also shows in their mobile apps. From my perspective, both apps have evolved a ton over the last couple of months so that I don’t see any huge feature gaps when purely working through group and direct messages on your phone.

But especially if your company is a bit more ‘old fashioned’ when it comes to communication or you simply have to talk a lot to external stakeholders, you most likely rely on e-mail as well.
If your e-mail service is based on GSuite (which it really should be), the answer here is easy: Inbox by Gmail. Just make sure your admin has enabled the feature for your organization. But after taking that hurdle, you’re up for a top notch mobile e-mail experience.

For everybody not being on GSuite, the best overall experience is getting delivered by Outlook. It gets constant updates and works really well with basically all important providers. I also shared my personal inbox management system a couple of months ago, if you’re looking for inspiration.

Task & Ticket Management

For a very long time, this was achilles’ heel of mobile productivity for product managers. But especially in the last couple of months, a lot has happened in here.

First, not only got Trello bought by Atlassian they also finally added offline support for the mobile apps. This was probably the last missing piece for all product teams relying on Trello for issue management.

JIRA, the now rightfully considered bigger brother of Trello, was a long-time famously non-mobile tool. There only was a crappy mobile web version available and making serious changes from your smartphone was pretty much impossible.
But with the introduction of the official app last year, product managers were enabled to work through the whole flow of creating, defining, assigning and following through on issues.

By recently going almost mobile only for entire days, I can ensure you that working with JIRA on an iPhone 7 Plus is almost more fun from the performance side of things than in the browser…

Personal task management has never been a real issue on mobile. Quite the contrary, the incredible high amount of productivity apps led to a lot of consolidation a couple of months ago. While indy players like OmniFocus and Things are still in the game, they were a bit overengineered for my needs and I still rely on Wunderlist. I truly hope Microsoft keeps it around as a standalone product.



File Sharing, Documentation & Office Productivity

As with e-mail, a lot of your mobile apps of choice depend on your company’s infrastructure. For me personally, the microsoft office apps currently have a slight edge when it comes to native experiences, but I like the collaborative aspect of GSuite way more.

For file sharing, you’re probably bound to the service which is the closest to your office infrastructure (mainly GSuite vs. Office365 = GDrive vs. OneDrive), but I like to have Dropbox in place as well, as it still delivers the best performance and reliability for syncing and applying changes.

For documentation purposes (e.g. meeting notes or collections requirements), you can never go wrong with Confluence – Especially since the native mobile apps became real productivity enhancers.

While you have more choice in that domain, I highly recommend staying away from pure notes applications for company wide/cross-company documentation. Evernote, Bear, Apple Notes or Google Keep work well for your very own writing, but lead to a way too fragmented account landscape when trying to be forced upon teams.

Design Reviews & Wireframing

Reviewing or sometimes even creating interaction and visual design output is fairly common for product managers orchestrating a team of experts. And while tools like Sketch or Adobe XD really pushed design processes forward on the computer, mobile devices still feel a bit left our here.
Thankfully, your main task shouldn’t be creating visual designs, but rather critiquing and facilitating them. Therefore, I highly recommend InVision and it’s native mobile app. By using at, it’s easy to have almost GSuite-like design discussions right from your phone. Due to the tight integration with Sketch, it shouldn’t be a problem for your product designer to provide you her visual designs in there for some feedback while being on the road.

Zeplin, my very favorite desktop tool for that process unfortunately hasn’t come up with a native mobile app.

For occasions when you actually have to illustrate your thoughts about a new feature idea or user flow, you can’t go wrong with OmniGraffle for iOS. While I switched to Sketch for wireframing on the Mac, I’m still humbled by OmniGraffle for my phone. I really like the reduced complexity here and how quickly I can create flows and wireframes – Leaving alone how easy sharing them is.

What was the last product management task you wanted to solve on your phone but couldn’t because the lack of a proper tool?

My biggest mistake when conducting User Story Mapping workshops

User Story Mapping is an incredible powerful exercise to dismantle product ideas into tangible value drivers and derive an MVP-oriented prioritization from it.
And even though it has become a default framework within my product management set of tools through numerous repetitions, I often times make a mistake which interferes with some of my most important foundations of product development.

Focus on Jobs, not structuring the Product

The most common situation during which I applied user story mapping was when a product idea was already more specified and a lot of workshop participants had a clear image of the product itself in their head.
I am then tempted to directly structure the product itself, instead of using story mapping the way it is intended to be used: Focussing and prioritizing necessary features by working through the user journey expressed in jobs.
While this may doesn’t sound that different at first, it becomes more obvious when I tell you that my first level on the map doesn’t consist of user jobs (like ‘Manage E-Mail’) but product sections (e.g. ‘dashboard’ or ‘settings’).

This way, the stage is set for complete chaos. All participants start to argue in which section a feature needs to be put and thereby inevitably touch on design discussions as well.
While the lower levels and the release/mvp prioritization of the story map then look the same as by the book, a group of people which absolutely shouldn’t design the product, did so just because I set them up to do it.



If I had focussed on the jobs on the first level, the structure of the product would have remained a neutral exercise to be tackled by the product designer later on. We would have focussed on user value and the right prioritization for a high chance to reach problem-solution fit.

The Alternative: The Story Slicing Workshop

The problem is that when you’re that late in the product creation process (late meaning lots of specific images in the heads of stakeholders), it’s hard to lead them back to start with user jobs. After doing some research, I stumbled upon a different framework which might be better suited to help structuring specific product features: A Story Slicing Workshop.

While this is definitely intended for a much later stage which is closer to development start, I think its structure and setup could work a bit better.

The other alternative (which I’ll pursue as well) is of course to just be much more strict with the facilitation of a user story mapping workshop or respectively pushing for an earlier point in time of a product discovery to conduct one. But I wanted to include the story slicing workshop anyways to point out other hands-on frameworks as well.

What are your experiences with User Story Mapping? At which point in time have you used it and what have been your most important personal learnings?