3 Common Misconceptions about User Testing

Meanwhile, a lot of company’s building (digital) products have embraced (or at least accepted) the positive impact user testing can have on the product development process. But just because you somehow involve users into your processes, doesn’t mean you’re doing it right.
Personally, I had the luck to get great teaching into the art of user testing from my former colleagues Britta and Anne. And while you can and have to divide user testing into its separate domains (research, deep interviewing, usability testing), I want to point out 3 very common misconceptions which I stumble upon in early discussions.

Focus Groups are the shit!

Nope, they’re not. They’re actually one of the worst ways to get feedback on your product or getting to real user struggles (right behind building assumptions just on your own behavior). When it comes to pointing out failures of a product or negative struggles, people are her animals. They’ll follow the most common opinion in the room and will be too embarrassed to be the first ones acknowledging a mistake or flaw.
Only personal situations and a comfy and trustworthy environment will bring you closer to see the real behavior of people and hear about their true struggles.

If you want to have the room full of like-minded customers of yours as part of your product creation process, I instead recommend the format of Co-Creation Sessions.

Personas are a great way to figure out my users needs

While personas are already quite an improvement for user-centered products, I still think they have a huge flaw: They focus on the wrong things and distract you!

Building up on what the smart guys behind Inside Intercom have written about why Job Stories beat the format of User Stories, I want to apply to the format of personas. Conducting the corner stones of a ‘traditional’ persona (age, hobbies, family status, hopes & dreams) takes way too much time (or is purely based on imaginative stereotypes) and doesn’t give you any tangible entry points for figuring out around which problem your product should be built.
Instead, you start chasing constructed touch points in a user journey far off a users core problem (you’re able to solve). Instead, you should almost entirely focus on the context and core problem which will inevitably lead to a certain ‘job‘ people hire a product/workflow for. After figuring those two things out, the demographic data of your target group becomes highly irrelevant.

If you want to apply a persona-style approach at the beginning of your product discovery anyways, I’m a strong advocate of Proto-Personas. This format will keep your efforts focussed on demographics reduced to a minimum and will include some reality checks.

We’ll just ask them what they want and how much they’re willing to pay for it

While I can’t stand the iPhone comparison when it comes to user research (‘Steve Jobs never asked anybody, whether someone wants an iPhone), there’s a certain point in it: Users are not able to articulate the right solution to their problems. This is why you are a tasked with building products which serve their needs. But in order to get there, you have to entirely focus on problems and not potential solutions, when talking to users before even sketching a first wire frame. Don’t ask them what they want (even if it itches you to shout this question at them after they’ve neglected 6 of your fancy prototypes) and rather focus on what makes them happy or grumpy.
And while you’re at least able to derive some valid qualitative data from talking to users about problems, you won’t be able to when it comes to monetization. Sure, you’ll get close to figure out a person’s most important product attributes which makes them paying (e.g. quantity over quality or cross device availability), but whether they’ll pay in the very moment for your product needs to be determined outside of that interview room (I’ll talk about quantitative validation at a later point).

Which misconceptions about user testing are you giving you a hard time to get out of people’s heads?

Frequently asked product questions when building native mobile apps

Since last week’s column was the first with real ‘hands-on’ advice, I recognized that a lot of you out there are battling with quite some operational questions around building native mobile apps.
Based on the feedback I received, I wanted to answer some of your more popular questions directly in this week’s newsletter. Again, I hope that you find value in it and keep the questions coming!

iOS or Android first?
Totally depends on your target group – start with the OS which is most popular amongst your most relevant group of users (business decision). In general, I highly recommend shipping an Android and iOS version in the end, but starting with an offset of at least one or two sprints.
This way, you’ll only make mistakes regarding general logic/usability and backend connection once.

What’s iteration 0/the first spike in app development?
Very technical, but I always try to get to a first iteration of tangible user value right from the beginning. Other approaches are feasibility checks for the apps most challenging areas (technical aspects). Again: totally valid and probably a better fit for incredibly technical-focussed projects, but I personally like to shoot for the basis of an app from user perspective (e.g. login)

How to come up with a nice app icon?
Get a great Visual Designer and provide her distinct cornerstones regarding your branding and the core job you want to communicate with the app. Great design resources for creating app icons on various platforms can be found right here.

Does an app’s JTBD need to be reflected in its name?
Speaking of jobs. For answering this question, you have to distinguish between two scenarios: apps with an already strong brand and upcoming new apps (which is likely what you out there have as well). In general I always recommend to set an app name based on a users search behavior for completing a task/job. This is not only relevant for the App Store itself, but also for a quick start of your app later on when it’s accessed via e.g. Spotlight (iOS).
So, while nobody searches for ‘self destructing messages social network’ but goes for ‘Snapchat’ instead, you’re much more likely to get into a users relevant set when including ‘gas station finder’ next to your brand name (a pretty common job and App Store search term).

How to conduct remote user testing?
Personally, I’m a huge fan of invision for assembling mobile prototypes. A neat workaround for walking someone through it would be a mix of those tools (Mac/iOS focussed):

Let me know, how this setup works out for you. A decent and more straightforward solution for Android can also be found checking out lookback.

How to get better at asking for Push Notification Permissions

Inspired by a (German) video my friend Marcel published a couple of days ago, I’d like to talk about push notifications this week. While Marcel focussed on how apps sometimes carelessly misuse the precious push notification permission, I’d like to focus on one step prior to that: asking the user for the permission to send push notifications at all.

Thereby, I want to focus on 4 important aspects of getting this opt in, I often times see just being done incredibly wrong or are just huge opportunities most app creators miss out on.


You know what sucks? Getting presented with a pop up asking me for a system-wide permission before I even had the chance to get a glimpse of an app’s content. Seriously, this not only reflects bad user experience decisions but also engineering ones. Just because the app has the technical capability of sending pushes, you shouldn’t use the default timing for asking for permission right after the app has been downloaded for the first time.

Instead, bring up the permission after a moment during which the user wants to get actual value from your app and which can then be enhanced by a push notification. For example when a video on YouTube is favorited and you get asked wether you want to get reminded when new videos from that channel get published or not.

Use custom opt-ins for more chances

While you can often times use a ton of marketing mechanics in order to make a bad user experience kind of ‘unhappen’, you can’t do so with push notification permissions. Especially when you’re using the standard iOS dialogue for getting the opt-in, a ‘no’ in that very moment can’t be reversed. You won’t get a second chance to ask again – Even if you considered my tip on timing from above.

This is why I highly recommend building your own ‘pre permission’ dialogue. This doesn’t have to be fancy, but by putting (really low) effort into your own pop up, you don’t miss that one shot to get the opt in should you ask the user in the wrong moment. Instead, it’s up to your (ideally backend-steered) logic when to ask again and again. And only if you pre qualified a users intent for receiving pushes from your custom dialogue, you let her access the official iOS one. You’ll be amazed how much higher your opt in conversion rates will be.


Speaking of conversion rates, another disadvantage of the standard iOS dialogues is the lack of analytics within that dialogue. The only rough estimations you can derive from a standard permission implementation is if the ratio of sent out push notifications (a number which should be present in your backend) increases in parallel to the number of new acquired users. A pretty muddy estimation game.

Having a custom ‘pre permission’ dialogue (I kind of start to like this term) in place also let’s you track the interaction with it in more detail – e.g. within certain user groups. You still don’t get the final numbers from the iOS system dialogue, but you’ll learn much more about when and how to ask for it.


Even though I personally consider timing the much more important aspect of getting a push notification opt in, the actual design of you asking for it plays a huge role as well.

And by design I not only mean the actual Visual Design but also the copy. Customizing the push notification permission gives you the opportunity to deploy multiple variants of how to actually ask for it at the same time. AB/Multi-variant testing is an incredible opportunity by itself – But deploying it for figuring out how to unlock one of the strongest engagement mechanics of your mobile app is HUGE! Regarding the actual pixels I personally think you should just carry-through your product’s identity (like Candy Crush is clearly doing blow).

Candy Crush Push Notification Permissions

Nothing too fancy, but I think a clear differentiation from the then followed default dialogue is a plus.

So, how is your app currently asking for push notification permissions? I hope you can derive some concrete improvements for your own work. Let me know what you’ve found out!

Investing in your skills pays off in the long run

I recently had to run a two day workshop in order to assess new product visions and plan the needed discovery phases accordingly. Due to some scheduling fuck-ups on my side, I hadn’t been really able to put in the preparation time for the workshop I usually intend to have.
So I expected to have a rather mediocre workshop itself, not matching my usual aspiration for a fun thing like that.

Contrary to my expectations, the workshop went pretty well. We had a great time, produced exactly the output we needed and were after all pretty aligned on the outcome.
Despite being happy about the results, I couldn’t help to think about why it worked that well, lacking my usual load of preparation time and thoughts. I almost felt guilty that I was ‘lucky’ and the scenario, day and time just played for me and led to the great results.

After putting some thoughts in it, I definitely think it was something very simple which led to the situation: experience.
By doing stakeholder-heavy product work for 6 years and being in challenging environments managing high-scale products, I can now benefit from this year-long learning and refinement of my skills. This is what allows me to now being able to run workshops or discovery phases with fewer upfront effort.

When I arrived at that conclusion, a neat comparison came to my mind which was often times articulated by my former swim coach back in the days. As you can imagine, putting a lot of mileage into swim training with a high share of endurance work isn’t exactly what you crave for as a short distance specialist (like I was).
Observing the training plans of older world-class sprinters, which focussed much more on intensity and had an incredibly low number of endurance sessions, we then raised the question towards our coaches why couldn’t train the same way.

The answer was simple, yet unsatisfying for me back at that time. Those athletes did put a lot of effort into laying endurance foundations when they were younger (e.g. during junior years) and could now still benefit from this high level they’ve built up for themselves. So they only had to put in quite few endurance effort right now in order to simply maintain this threshold.

It’s basically the same process which I described observing my own actions – I can now benefit from the hard work and investments I put into my abilities the years prior to now. Other examples are my efforts to ramp-up in coding, design and even online marketing to now being in a much better position to orchestrate those disciplines to form a great overall product.

The most crucial thing when arriving at this insight is though, to determine what the skills are you need to invest in today, in order to benefit from in a couple of years. For me, it’s for example public speaking and leadership – What are yours?

Why I don’t believe in ‘Idea Backlogs’

Hello and Happy New Year (just in case we haven’t seen each other yet in 2017). I hope you enjoyed the holidays and have been able to take some time off to recharge for whatever is next on your agenda.

Especially the beginning of the year we find ourselves in the middle of quarterly or even yearly planning discussions regarding which product initiatives to tackle next.
Often times, the few items which find an actual slot on the short term roadmap are the essence of a so called ‘long list’ of ideas. But what happens with all the other brainstormed output? They get thrown into a so called ‘idea backlog’, right next to that great idea you had last year and tried to bring into development. Especially when it has been a close call regarding prioritization, it feels like a good excuse for all participants to not entirely dismiss an idea but to ‘save it for later’.

Let me tell you what: Don’t do that. If an idea is just not good enough to outperform ‘competitors’ in the very moment and is so unbelievably full of value for you and your key stakeholders that you immediately want to dedicate your best resources to it right now, it won’t be any better the next time you revisit that list of broken dreams in your excel file.
Instead, I highly recommend to make a clear cut below the very top product ideas which find their ways into execution and just start a new ideation process from a blank sheet the next time a roadmap slot is up for discussion.
And if an idea is truly so good that it’ll appear again and again on your lists, it’ll find its way into production mode when the time is right. Trust me.

Let me give you another example for this way of thinking: I  did the same thing when 2016 ended with all my blog post ideas and ‘books to read’ resolutions. When they were just not that good that I wanted to immediately sit down and dedicate writing or reading time to them which I otherwise probably would have spent working out or watching YouTube, I deleted them. No more drafts and plans to ‘read this book very soon’.
When a topic or book is really really relevant to me, it’ll somehow resurface somewhere to me and will then get tackled.

What’s in your (personal or work-related) idea backlog? And how long have some of those items been in there? See, just kick them out and just execute on the next things which is driving you for real.

This article appeared first on my e-mail list for product people, ux designers and entrepreneurs.

My Personal Review of 2016

Can you believe it’s already the end of 2016? In a couple of days, we’re about to celebrate 2017 and boy has this year been a ride…Let’s take a (non-chronological) look at what’s behind:

  • First and foremost, I became a dad. Describing this experience would break all formatting space of this newsletter. Which is why I’ll just summarize it this way: WOW!
  • l decided to leave my job at XING after working with a bunch of incredibly talented people after 2,5 years. It wasn’t an easy decision but…
  • …it led me to join ORBIT! So far, I can’t believe how much we’ve been able to learn and achieve as a team in such a short period of time. I can’t wait for what we’re gonna pull off in the future!
  • On the same note, I not only gained awesome people in a professional sense, but also found incredibly like-minded people in Sven, Johann and Jan on a personal level to have fun with – Thanks for having me, guys!
  • Related to that, I actually found myself in the longest period of not working since I basically started my internship at eprofessional in 2010 – And instead spending an incredible amount of quality time with the little one and my better half.
  • I actually found quite a nice format and rhythm for this newsletter and which also is seemingly rewarded with an increasing number of subscribers and engagement. Considering that I’m sending a regular-ish newsletter since 2 years or so, it’s nice to see this is developing into something sustainable.
  • We decided to leave our trusted central neighborhood in Hamburg and moved a bit more to the north of this lovely city. While space and accessibility were our main triggers, having more nature around us and offering Jannis a more playful environment to grow up in were nice ‘side effects’.
  • With the help of Tim, I’ve been able to pick-up a regular schedule for Productish. Pretty happy with our format and the topics we’ve discussed so far.
  • I managed to publish my by far most successful blog post on Product Discovery. Which also boosted my motivation for more creative writing around product management a lot.
  • I decided to get back into public speaking about product-related topics and submitted a proposal for the ‘Working Products‘ in Hamburg – Maybe you wanna join me? Let’s see where this can get from there…
  • I had my first actual cycling vacation with Robert in the very north of Germany. We had a lot of fun, despite unsteady weather conditions. I really hope to repeat that in warmer conditions and with Friedrich by our side over the course of 2017.

See you in 2017. Let’s make it a good one!

What’s your Product’s primary Business Job?

Often times when I discuss feature prioritization with partners and stakeholders, I pull up a certain example for demonstrating how different primary jobs of a product can be served. As a modern Product Thinker, you should be familiar with the basic premise of ‘jobs‘ a product gets hired for.
Personally, I’m also a big believer that we not only have to take care of user jobs but need to consider business jobs an important guideline for product development as well.

So, in order to emphasize how products can be differently set up in order to accomplish different business jobs, let’s compare Facebook, Instagram and Snapchat and with their app start experience.
All companies share the same business model by monetizing user or business generated content through advertising but still sport different behaviors to channel users through their product.

Facebook greets you with their massively engineered news feed in order to make you consume content and later-on interact with it by liking, commenting or sharing it. After all, Facebook makes money every time you see and click on an ad within your feed. Creating new content is also directly accessible from the direct app start section but is not designed to be the primary objective here. My assumption is that Facebook simply managed to get enough content from partners and publishers in the feed, that they don’t need to be pushy towards their users about posting more status updates.

Snapchat on the other hand throws you directly into the camera screen in order to produce content. Snaps don’t need to be polished or meaningful (filters take care of that. not.). It’s all about producing massive amount of pictures and videos which then get directly shared with all of your friends or only specific ones – or both at the same time.
The interesting thing is though, that Snapchats advertising mechanic is (at the moment) exactly like Facebook’s. Think of the stories which you can see in the ‘Discovery’ section being similar to news feed items and between viewing them, you get served ads. So it wouldn’t be far fetched for Snapchat to make you go through those Discovery stories as the primary job within the app in order to generate more ad impressions.
But presumably Snapchat currently doesn’t have enough user generated content to make that move, which is why you’re still asked to produce content before you consume some. On the other hand, Snapchat’s retention numbers could be more impressive than everybody can imagine and users make their way into viewing snaps anyway. Which makes them so confident to add another ‘hurdle‘ into their app after being opened before users make the ‘money move’ and start to view ads.

Now, Instagram is a very interesting case here. Until recently, the product was almost exactly structured as Facebook, with the creation part being even ‘harder’ to use. This is because Instagram is way more about highly polished content which almost needs to be produced and not (unlike Snaps) being really captured in the very moment. You then scrolled through your feed of brunch and sunset pictures and got served a neat selection of ads. But suddenly Instagram seemed to had a problem with the supply side of content and user activity – and introduced Instagram stories.
And suddenly, Instagram became way more pushy about making you create content right from your first app start experience. From my perspective, this move will probably pay-off regarding their short-term business KPIs but I trust more in Snapchat to have figured out this produce/consume balance in the mid- to long-term for their product.

I hope this lengthy and somewhat meta assessment helped you to take a different perspective into your product’s feature prioritization. For starters, I suggest to simply answer the question wether your main objective is to let users consume or product stuff and orchestrate your product’s navigation structure accordingly. And of course: Always test those change looking at your key KPIs.

The 2016 Holiday Gift Guide for Product Managers

While you probably are busy collecting gift ideas for your friends and family, I thought to at least help you on the side of what to gift for valued professionals around you. Without further ado, here are some handy and pretty useful gift ideas for product managers:

So, go out there and make a product manager you care about happy! 🎄

This article appeared first in my weekly email list for product managers, ux designers and entrepreneurs.

How to use a User Storyboard Template

Often times, the amount of various jobs your product needs to fulfill for your users can become overwhelming and it gets harder to keep an overview about flows and interactions.
This is the point during which a user storyboard template comes in super handy either before or during your next product discovery.

Grab your free User Storyboard template right now by simply subscribing to my e-mail list:

What is a User Storyboard?

User storyboards are similar to scenarios: They illustrate the interaction required to achieve a goal. But instead of using a list of steps, a storyboard visualises the interaction similar to a comic strip.

A user storyboard provides a powerful tool for creating great user stories, but it is not meant to stand alone as a framework for project management. Thereby, you should always use it in combination with other tools and frameworks like an impact map or user story mapping.

How to use a User Storyboard template?

  1. Print the template either as as large as possible for co-creation on a wall/table or hand-out multiple smaller copies for an ideation-style session to begin with.
  2. Provide all information around your users and their jobs-to-be-done during their journey through your product to the team members.
  3. Have rough idea of your product’s functionality (e.g. through wireframes or click-dummies) in place.
  4. Set a concrete goal for your products which must be fulfilled after the storyboard has been put together.
  5. Walk through the empty spaces of the user storyboard template together with your whole team.
  6. Start with visualizing every user story in the intended image frame and add one or max. 2 lines of copy describing the respective actions your users need to take.
  7. Keep the filled storyboards visible in your discovery/team space for making your product’s user stories visible and transparent to team members and stakeholders.

What you’ll get

  • A perfectly scalable .pdf file which can easily be printed up to a size of A0 (841 x 1189mm)
  • Ongoing access to re-download the file as often as you like
  • My contact e-mail address for further questions around how to use this template
  • Access to all future minor updates on this user storyboard template

Grab your free User Storyboard template right now by simply subscribing to my e-mail list: