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:

A Closer Look At Proto-Personas: What They Are And How They Work

Using a traditional model to define and work with personas carries 2 major problems form my perspective. First, a lot of theoretical-based effort is put into the creation of those stereotypes and they often times lack any kind of real life validation. Second, the initial costly creation process is used as an excuse to not re-evaluate user needs and hide them in a drawer until someone asks for them.
While recently re-reading Jeff Gothelf’s book Lean UX, I stumbled upon a very lean (of course) alternative to tackle those issues: Proto-Personas.

Proto-Personas are basically the most lightweight and real life-oriented version of creating user stereotypes to build your product upon. The approach is dead simple: The committee of experts (mostly consisting of design, product and marketing) roughly defines one type of user they see as their target audience. During that, the team focusses on not more than 3-4 demographic aspects of the user and tries to come up with about 4 concrete problems and 4 concrete improvements (basically pains and gains) they think this type of user currently has with the product they’re trying to improve.

The whole process shouldn’t take longer than one hour. After that, the team hits the road and talks to users of the existing product, focussing on pains and gains. The outcome of those interviews can either be the confirmation of the initial assumptions, a correction in the area of pains & gains or even throwing away the whole persona and developing a new one, based on the user interviews.

What I like so much about this format is the incredibly small upfront effort which makes it way easier to discard initial assumptions and react to what you’ve heard. In addition, the used pains and gains didn’t came out of a study or someone’s gut, but from real users.

In Defense of the Gantt Chart

In a world full of agile methodologies and almost infinitely scaled Scrum frameworks, it sometimes almost feels like a deadly sin to use tools originating from traditional project management techniques. Like the Gantt chart.

But especially after my recent discussion with Tim Adler in the Productish podcast I thought it might be helpful to talk about 3 positive aspects I see in using of a Gantt chart (even in agile projects).

  1. Clarity of dependencies – Linking a JIRA ticket to another one in the backlog of the team you depend on won’t point out dependencies and thereby also risks when assessing your project. Drawing straight (red) lines between two dedicated tasks on a huge piece of paper will.
  2. Visualization of progress – While e.g. burndown charts or progress bars on epics will give you a rough idea on the micro level of development, I personally find the perspective on the big picture more helpful. Emphasizing what’s really left before you can ship and how far you already got as a team can be a huge boost for motivation.
  3. Transparency about scope and releases – Even though I’m a strong advocate for digital documentation, dead trees can sometimes be pretty helpful for keeping you and your stakeholders on the same page about the scope of an upcoming release and bring clarity into an otherwise imaginary feature backlog. Literally.

By only pointing out it’s positive aspects, I’m by no means someone who favors traditional ways of project planning over an agile approach. But sometimes certain ways of assessing a project can be really helpful for your success on bringing a product roadmap on track.

Meaning, a traditional Gantt chart isn’t the one and only way to actually plan the project, but rather a nice tool to tackle certain aspects of stakeholder and expectation management.

What’s your favorite way to assess the complexity, pitfalls and progress of a larger project? Let me know!

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

How to fuck-up a Design Sprint: Day 5

  • “Good morning, you ready to talk to some douchebag users?”
  • “No no, we just keep the order of product variants. They won’t have a bias.”
  • “You go ahead for the first interviews, Jim. I’ll just chill with the girls in the observation room aka kitchen.”
  • “Why should I switch-off my iPhone in the interview room? What if I miss an important Snap?”
  • “Wait, the users didn’t got a briefing about the product idea upfront?”
  • “Here’s the user interview guide – It all fits on this one sticky.”
  • “Yes, we’ll directly dive in the product. We don’t care about their background or usual habits.”
  • “Dear user, would you buy this product?”
  • “Please tell us which features you like to see in here.”
  • “I totally think we have all we need. Iterating on this idea doesn’t seem to be necessary.”
  • “Nah, I’ll just drop my notes on Confluence. No need for a retrospective of the Design Sprint.”
  • “Nailed it.”

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

Productish Episode 29: Development Speed

In this episode of the Productish Podcast we’re discussing how to tackle the feeling of not being fast enough in your software development projects and how to shape the upper management perspective on this matter.

Note: This episode of Productish is in German.

Topics we touched during the episode:

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

How Jobs to be Done shaped Uber’s latest App Update

When companies usually redesign their apps, it’s about adopting a new design style (e.g. like Material design) or as part of a whole refresh of their CI. The biggest features usually get introduced afterwards in various updates.

But when Uber just yesterday unveiled their latest app update, it struck me as how obvious they used two of the most important Jobs to be Done metaphors for reshaping the entire rider experience. Starting from opening the app until they have to chose a type of mobility for their next journey.

So let me walk you through Uber’s state of mind when they rebuilt their rider experience using Jobs to be Done.

Asking ‘Where to’ instead of ‘How’

The most noticeable change happened right when you open the app. Until recently, the first screen you saw was about setting your current location and which Uber you wanted to use for your trip (Uber X, Uber black etc.).

But from now on, Uber puts the one question front and center which users really care about when they use the service: Where do you want to go right now?

Uber Jobs to be Done App Update

This is way more then just a different first impression when using the app or testing the latest growth hack. It’s about Uber wrapping their entire product experience around the crucial Job to be Done their users hire the product for: Bring me to my desired destination as fast as possible. I don’t care how you do it.

Enriching the riding experience to make you stick with Uber

After you’ve been successfully picked up by your driver, the usual routing while sitting in a taxi begins. You close the app, check Twitter and Facebook, text your friends or maybe look for a food delivery service to replace your empty fridge at home.

So, while Uber was already heavily focussed on the offline ride experience (clean cars and nice drivers) in the past in order make you chose it again the next time you want to move around town, they’re now going one step further. The app introduces a feature called Uber Feed to also enrich your online ride experience.

Uber Feed applying Jobs to be Done

While you’re riding, the app’s interface will switch to a set of cards giving you plenty of opportunities to interact with services Uber thinks you might find useful during your trip.
Feeling hungry on your ride home from work? Swipe left on the UberEats (can you see the big picture behind their vertical services?) card to see which restaurants can deliver to your house in sync with your arrival time. En route to a restaurant in the city? A Yelp card lets you side-swipe to browse photos and reviews of popular dishes. Running late?
Relax: Right there in your Uber Feed is a Snapchat card with custom filters, including one that updates your neglected dinner date on your ETA.

What this is about? Well as you may know, Jobs to be Done not only discusses why a certain product is chosen in the first place, but also what makes users switch from one product to another.
As Uber’s core Jobs to be Done competes not only with Lyft or traditional taxi companies, but also with Citi Bikes, BART or simply walking, it needs to increase the switching costs of it’s experience as much as possible to form strong habits.

Jobs to be Done Switching Costs

So the new Uber Feed is not only about temporary entertainment, but to lock you further in the Uber app itself and creating a memorable experience which should convince you to pick Uber over and over again the next time you’re evaluating opportunities to get from A to B.

Jobs to be Done decision making progress

How to fuck-up a Design Sprint: Day 4

  • “Good morning everybody – Who brought pen and paper?”
  • “I really think it’s important to nail the color palette with this prototype.”
  • “I don’t care which tool you want to use as long as I can run the prototype smoothly on my Galaxy S II.”
  • “Jim, do you want to maybe collect the requirements for the checkout screen from the legal department?”
  • “Look, I sketched another idea I had this morning just very quickly for our design sprint. Maybe you can add this to the prototype variants?”
  • “Interview guide? That’s way too bureaucratic, let’s just shoot the questions we have in our head at them.”
  • “We should aim for a clear opinion on which version the users like best.”
  • “I don’t think we should document the interview results. The most important quotes stick in our head anyways.
  • “Just go to a noisy and crowded space with lots of people for the interviews. This way, we can talk to as many people as possible.”
  • “Good job, team. Can’t wait to see you talking to those people at Starbucks for valid feedback!”

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