Do Product Managers need a Portfolio?

It’s almost funny how much focus the specifics of certain 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 other hand it’s ‘perfect’ for judging the capabilities of a person based on pixels.

The situation is then often times, 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 be an important part of a Product Managers 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 then the actual medium you’ll use to showcase your work (since there’s no Behance for Product Managers yet) is the actual content to put in.
As a Product Manager, your success is often times measured by the numbers/impact your product has generated. It’s a bit unfair to say, but while designers can hide themselves behind pretty 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 definitely 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 did a very bad 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 constant representation of yourself or for a specific 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 can be found in this neat article by Sachin Rekhi.

If you’re be interested in developing a template for Product Manager portfolios, simply 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 most 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 push back I often hear about the MVP approach of a new product is the assumption that basically 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.

In order to condense the actual 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 visualisation of what the difference between a shitty version of an overall product vision and qualitative sufficient iterations of key 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 exactly the story of Product Hunt).

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

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…

The best Alignment Tools for Product Managers

Generating and keeping Alignment across all levels of an organization – from C level until the single engineer – is from my perspective one of the most important (and often times most challenging) for a Product Manager.
And while often times suggested simple change of habits like ‘talk more to each other’ or ‘keep a confluence page about what has been agreed’ are right, they don’t necessarily provide the right level of confidence to a Product Manager to strive at his mission.

That’s why I picked 4 alignment tools for Product Managers for you to grab for your next product strategy session or product discovery kick-off. Going too much into detail about how they’re used would blow the frame of this format:


Luckily, I have been around at XING when this framework was developed. It is a mix of the influence from Stephen Bungay and Christian Becker and has been evolving through internal forces since then. Check out the full guide right here (original link is currently broken), watch my fellow Product Tank Hamburg Co-Organizer Marc speak about it attend the upcoming workshop around Auftragsklärung facilitated by Christian Becker in April at MTP Engage in Hamburg.

Intermission by Intercom

A simple but effective one pager developed from the guys at Intercom. They managed to integrate all the stuff I like the most around product development (right now): problems first, defining specific measures of success, job stories and a clear product scope.
Would love to see some writing on the actual usage from the product teams (and stakeholders) at Intercom in the future…

The Product Tree

The best thing about this format is it’s strong visual aspect. It’s maybe not as sophisticated as the other frameworks above, but it’s focus on feature prioritization is its biggest strength at the same time. It ruthlessly forces everybody at stake to develop a shared understand about what to actually build next.
In addition, its format is perfect for keeping the aligned vision constantly visible in the team space.

‘Working Backwards’ by Amazon

While there’s no official material on this framework, it’s widely confirmed and well-known in the product manager community. It’s the result of Jeff Bezos’ approach to cut subjectivity and fluff of product development. The result is a document which shouldn’t exceed a page and a half in lenght which needs to be provided to meeting participants before e.g. a kick-off meeting for tackling a new product.
Never used it in ‘production’ but will definitely do in the near future.

Which format, framework or result of common sende are you using right now to create and follow-through on alignment within your organization?

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.