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, 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?

Why Deep Learning is the most important discipline in Product Management to tackle right now

I can’t really say what the exact trigger was for me this week, but I had a huge flashback to 2010 when I started to go down my path as a mobile product manager.
Adding the only ‘minor’ difference that I actually had abandoned the concept of ‘disciplines’ in product management a while ago, that mobile is now absolute commodity and we’re confronted with technologies like deep learning and neural networks which will shape and iterate features autonomously.

While the challenges emerging from this shift potentially couldn’t be bigger for my professional development, the circumstances leading up to this point are frighteningly similar.
By 2010, a lot of people were already using smartphones and their potential for daily consumer needs was clear to see. Nevertheless, the impact on existing business models was neglected my many companies. Leave alone the rare number of people in product, design and development being able to actually build and ship excellent mobile products.

While it may not seem as obvious to everybody how omnipresent deep learning is already in some of the world’s most used digital products (my favorite example from are the suggested replies in Google Inbox) it kind of feels the same to me. The value for users is already somewhat tangible, but few companies beyond the  GAFA players can see and adapt to the potential for their business model. Leaving the complete lack of talent out of scope of this equation as well for now.

So, even though I myself was a ‘domain’ product manager (being focussed on a certain discipline), I personally rejected this way of thinking about 1 year ago. It wasn’t a particular experience which led to this insight, but rather the professionalisation of product management in general.
I then believed (and still do to a certain extend) that a good product manager is able to deploy it’s skills against every discipline she gets presented with. Whether it’s ecommerce, payments or mobile.

The domain-specific knowledge can normally be learned fairly quickly. But before for example mobile became a natural part of all digital products, it was common sense to have mobile specific product people which knew the pitfalls and levers of mobile operating systems. The ‘other’ product managers were then left focussed on their existing products and rather asked for consulting from the specialists.
Over time, the advantage of mobile (and other domain-related) product managers became less relevant and working in disciplines is more like a simple addition to your job title.

But now I think we’re at the threshold of seeing the necessity of domain focussed product managers again. Products which will be mainly driven by deep learning algorithms not only need skilled engineers, but also product managers and designers which are familiar with those technologies.
While I will touch on some of the specifics of what this shift means for the tasks we’re facing today later on, I think the biggest changes will take place in how we’re going to discover and test the critical hypotheses of new products.

If you’re sharing this gut feeling (of course it’s not more then that at this point) I highly recommend Ken Norton’s perspective on what machine learning means for product managers.
And while you’re at it, why don’t you join me for this great educational series on coursera?

MVPs are about prioritized Depth, not crappy Width

Even though product people now already start arguing about whether to focus on the riskiest assumptions instead of a viable product, the good old term MVP is still a good conversation starter. Especially within companies which may not be exactly ‘cutting edge’ when it comes to product development, the intent to launch earlier and ‘leaner’ poses a huge mindset shift.

The biggest pushback I often hear about the MVP approach of a new product is the assumption that it is a shittier version of the overall vision gets shipped. This fundamentally wrong misconception then leads to huge concerns about the negative impact of a broken product for the brand which then leads to a ‘build everything and build it perfect’ attitude before any iteration of a product idea gets into the hands of actual users.

To condense the real intent of an MVP in the context of this wrong perspective on the subject, I liked the following conclusion the best:
An MVP is about building the most critical value proposition (meaning feature) to prove your product idea’s potential first and shipping it in the best possible quality to your target users. It is not about building slimmed down or extremely compromised versions of all your feature ideas and bringing those to market.

While probably every product manager out there enters compromises as part of her regular product iterations, those are not meant to decrease a product’s quality, but are the result of necessary trade-off decisions to make the biggest impact within the (given) constraints of time or resources.

A great visualization of what the difference between a shitty version of an overall product vision and sufficient qualitative iterations of the main value propositions can be found at the top of this post.(intellectual property of Spotify).

Hopefully, this helps you the next time you are in the midst of a discussion with stakeholders (or even yourself) about what it means to build an MVP after the general intent of a project was expressed and aligned.
The best food for thought from the image above is from my perspective that an MVP doesn’t even necessarily need to be in the same format or channel of the overall vision. For example, a manually curated newsletter could be the MVP of an app-based community platform (yes, that’s precisely the story of Product Hunt).

What’s your elevator pitch stating what an MVP is supposed to be and what it’s not?

Productish Podcast Episode 32: Explaining Product Development to the Management – With Ralf Westphal, One Man Think Tank

In our second episode of 2017, Tim and I are talking to Ralf Westphal about the difficulties he faces when trying to improve the way product development teams work – Especially in relationship to upper management.

Note: This episode of Productish is in German.

Listen to it on iTunes or SoundCloud and don’t forget to subscribe via RSS or directly on iTunes.

5 A/B Split Testing Mistakes Product Managers are responsible for

A/B Split Testing is the most powerful tool of a product manager for getting from gut feeling and HiPPO driven product decisions to actual progress based on measurable outcomes.
But while it’s comparably easy to asses a tool and implement your first testing setup, there are a couple of meta mistakes I see being made from time to time among product managers (and which I’ve made myself).

Here’s my personal selection and how to avoid them:

Sharing results too early with stakeholders

While ‘too soon’ is measured in two dimensions (more on that below), let’s just says there’s a certain point in time during which you just should not talk about the preliminary results of a running A/B test. Especially when you’re testing around a critical business KPI there are just too many dreams and visions emerging from (mostly non-technical) stakeholders – even though the test result doesn’t stand on solid ground.

In the past, I shared ongoing progress of a test we’ve implemented with my engineering team, in order to make their efforts implementing it transparent as possible. But when it came to upper management and marketing, I learned to wait a lot longer before I communicated a result. Best case is, you get approvals from two expert perspectives: A mathematical one (e.g. Digital Analyst/BI Manager) and a practical one (e.g. Director of Product or Product Management buddy).

A/B Testing for the sake of it

While A/B testing is something to aim for because of the above mentioned reasons, you shouldn’t run any testing idea which is floating through your regular stakeholder alignment meeting. While the costs of implementing and cleaning an A/B test up are important, it’s more about the environment you want to test in.

Do you actually have enough traffic flowing through your area if product in order to generate significant results within 4 weeks? Do you have the freedom to test variants which are differentiated enough from each other? Do you have the commitment from upper management to also implement the ‘unpopular’ version and they just let you A/B test in the first place because it’s a ‘modern approach’?

Solely relying on Significance Calculators

As I wrote earlier, the mathematical expert view on your test setup and results is a crucial one. But don’t let numbers alone influence your decision when a test is finished. You’ll run into scenarios in which a significance calculator will spit out a significant result after two days or so. But seriously, two days? Common sense should tell you to at least run a test through every day of the week twice in order to balance-out ‘seasonal’ impacts.
Also, significance calculators don’t know every twist and angle of your product and its dependencies like you do. So only you will be able to spot outliers and potential bugs influencing your testing setup.


Confusing A/B Test results with user feedback

‘Version A won, so our users like this one more!’ While this assumption doesn’t seem far-fetched, it’s quite misleading. It’s the perfect example why quantitative and qualitative testing (and research) need to go hand in hand for a complete picture.
Even though A/B testing tells you what users are doing (like clicking 5 times more likely on the yellow button instead of the red one), it doesn’t tell you why people are doing it. It’s the unfortunate discrepancy between what people say they do and what they actually do.

So, be happy about the measurable uplift your latest winning version has caused, but make sure to check back it’s mid- to long-term impact on your product by conducting some 1:1 user interviews digging into what users actually made them click more. E.g. in the worst case you just locked the users tighter into a checkout process and they had no other choice then to proceed. Again: Correct action to impact your target KPI, but it’s helpful to know the context around it.

Focussing on the wrong KPI to influence

Speaking of KPIs: When setting up your test, it’s important to only work towards an increase or decrease (e.g. when working on a churn topic) of the very metric you can directly influence with a test. Especially when implementing a test within a multi step funnel, you can never be sure to impact the very last checkout metric when only testing improvements within the address data step.
It’s intriguing to assume that all conditions before or after your area of testing stay the same, but then again you perform an A/B test to stop assuming, right?

What were you’re most impactful when designing, implementing and analysing A/B tests? Personally, my biggest learnings not only originated in practical doing but also tons of support from my former colleagues Patrick, Timo and Gudrun.

Why you always need a Plan B when you’re validating

As a posterboy Product Manager, you of course always include a ‘Validation’ phase in your outlined product discovery. Being lean-as-fuck, you aim for a fake e-mail test or a simple teaser in your existing product in order to validate customer interest of your killer feature idea. But wait, you’re not going to meet the conditions you need in order to apply your kick-ass validation idea? Puh…then I guess it’s straight do development, right?
Well, even though this story sounds a bit over the top, it provides me with the perfect trigger, why you should always have a plan b (in fact, multiple plans) in place when it comes how to validate during a product discovery.

While validation in general is broadly used, I personally like to differentiate two types of validation: Validating the user need and validating your problem-solution fit. Both kinds of validation feature opportunities to either use quantitative or qualitative methods.

So here’s some food for thought about to get creative when your default methods can’t be applied:

  • When you’re building a new product, is there a similar product sharing some characteristics with your idea live?
  • If so, are any analytics insights available?
  • If not, is quantitative data available?
  • If not, can you talk to the users of this existing products now or send them a survey?
  • When you dive right into execution, make sure to bring contrasty versions of your solutions to your usability testings.
  • If you can’t reach the users from within your target group face-to-face, reach out via e-mail and combine questions with wireframes of your solutions (make sure to randomize the order of your displayed solutions).
  • In case you don’t have access to users from within your target group at all (likely in the context of b2b or internal products), try to recruit users with common characteristics and talk to them face-to-face.

Even if you now roll your eyes and have heard some of these approaches before, I hope to at least inspire you to come up with creative alternatives to validation again and again and again…