Contextual

Category: Product Manager

  • Comprehensive cross-platform support

    Comprehensive cross-platform support

    Cordova, Phonegap, Ionic, ReactNative, Mobile Web, Desktop Web are now available to add to our Native IOS and Android platform. This gives us terrific coverage of more than 90% of Apps in the Play and Appstore.

    Its difficult to predict winners in development platforms and here is 3 examples:

    •  Ionic [not an environment but a framework for mobile elements in a HTML/JS development environment – typically Cordova or Phonegap
    • ReactNative
    • Flutter
    • Xamarin [now owned by Microsoft]

    Ionic had huge popularity from 2015-2017 and is still popular but is under a lot of pressure from ReactNative and Flutter. Ionic was a huge improvement screen elements that made a much better user experience but performance on-screen is an ongoing challenge. ReactNative solved the performance and native component problems.

    ReactNative got a huge amount of traction in the startup community because it was invented inside Facebook. It then hit a few roadbumps with their licensing [because it was invented inside Facebook – LOL], fixed it and enjoys good performance and native screen appearance. We find a lot of agencies like it because of the HTML/JS implementation – its main challenge has been some big changes over time – a lot of their sample apps are based on earlier versions so things get confusing at times.

    Flutter – Contextual currently does not support and its probably going to have similar teething problems to ReactNative. Introduced by Google in 2017 it has great UI performance because it uses reactive programming method and UI elements are widgets which creates an abstraction from the native elements. We’d expect startups to pick this up but because it uses a new language “Dart” it will be slower to be picked up by agencies and enterprise. The benefits are immediate cross-platform support for iOS, Android and Google Fuchsia [Google’s upcoming OS]. It does NOT support HTML/WebApps.

    We are pretty excited about Flutter but will wait for commercial demand.

    Xamarin breaks my heart regularly, we have supported it in the past on Android and could support it again – we’ve currently withdrawn support. We just don’t get support from Microsoft. There is huge potential for Xamarin in the enterprise given the amount of C# developers already building enterprise apps but its not translating to momentum.

    With the re-tooling in the enterprise from Windows desktops to Surface or ruggedized Androids, Xamarin should be perfectly placed  – it just seems that mobile developers want to build their own careers on the better supported development environments. We can support Xamarin again if there is a strong commercial driver.

    Contextual is far and away the leader in tips, popups, tours, feedback, surveys and other engagement layer items across all platforms – we had a unified vision that end users will jump from web, to App, to mobile Web and App developers want one platform to target, engage and track – other solutions like Walkme and Pendo have made acquisitions of companies to add these features but only Contextual has a unified vision and cloud solution.

  • Onboarding and 10 perilous Off-ramps

    Conversion and Activation

    Acquisition is not the problem. Just ask the insiders at Clash of Clans, Slack or Fortnite!

    If you have cracked Activation [or conversion], Retention and Revenue then your marketers crank up acquisition spend – much easier said than done, but at that stage the financial equation says that if you ramp spend then you get more revenue.

    Only a few companies get to this point – when being smarter for the clicks than competitors ads means more traffic, more conversion, more revenue. The marketers continue to get budget as they’ve found what Eric Ries calls the “engine of growth”.

    Cracking Activation

    All eyes are on the Product Manager, Designer and Engineering to drive down Day0 abandonment. There is limited time to Activate the user before their attention deficit leads them to another problem, another game, another solution.If the user hits problems in the first session, then they are unlikely to come back – these are Top-of-Funnel bugs  and they can kill your business. This should be a science, there are many blog and Medium posts on Best Practice BUT….we’ve seen many enterprise, B2B and consumer Apps make the same repeatable mistakes. So here is a checklist of gotchas your team should sanity check that you’ve removed from your early users experience.These Top-of-Funnel bugs are “off-ramps”.
    attract-retain-convert

    What are the off-ramps?

    Off-ramps are the places where users leave your App. Literally the analogy is that your App is a freeway with lots of users and some, typically 70+% on Day 0 depart before getting to the destination you built the freeway for!

    Solving for this is not the topic of this article, but you begin by tracking all usage to discover where the users churn and experiment to fix areas.

    Here are the broad classes and specific examples of off-ramps:

    Basic Functionality

    The App crashes or is broken

    This should be a no-brainer, good QA, beta test groups, exception handling, load testing are all the entry level things you should be doing prior to release.

    Loading takes too long/Server performance

    More subtle, make sure that the App has been designed to be “quick as a bunny” in the first “job-to-be-done” [See our other posts discussing JTBD]. The user will tolerate a splash screen, but let them get access to data and results quickly. Often when an App launches and there is a initial spike of load – your backend developers should make sure the servers are provisioned for the spike, NOT the pre-launch traffic. Also ensure the JSON data the App is pulling is minimal so that data flying over cell networks is not slowing the user experience.

    Does not work off-line or in poor network conditions

    Web Apps rarely work off-line, but mobile Apps are expected to operate sanely when there is zero or one bar on the phone.

    Wrong App

    Was your marketing driving users you never wanted? Does your App ‘look-and-feel’ appear different to whats in the Appstore. Are you using different names and terms?

     

    Gates and Barriers

    It’s often said that Products die of “self-inflicted shotgun wounds”. Here are several ways for Product Teams to shoot themselves in the foot.

    Carousels

    Picture this. The user hears about an App from a friend/colleague – they get curious, download the App ready to solve a need, yes the user has a “job-to-be-done”. Excited, they open the App for the first time and they are confronted by a 5 screen swipeable carousel telling them exactly what their colleague had already told them. They quickly swipe through and dismiss this full-screen barrier and get on with the job. OK, so no harm done? Why optimise an App for the lowest common denominator, why not optionally offer struggling user the carousel instead?

    Demanding registration before an “aha” moment

    This has to be my pet-hate. Why are Product Teams, so in a rush to capture a user? So they can spam them with email later? A better solution is to let the user get a great experience first and THEN they will gladly go to next base with you.

    User meets in-App payment requirements too soon.

    Just because Apple does this doesn’t mean you should. They are a trillion dollar company, so people know what they are buying. You still have to prove your value – convince them first of how valuable you are, then place the payment gate at a point where you are on the cusp of taking it away.

    Creepy Moments

    I didn’t know what to call this but if you’ve seen the Netflix series “Dirty John”, then this is the moment where the user feels “something is off”.

    Private Data Requests

    Why the hell do they need my birthdate? I don’t even trust this App yet. Progressive Onboarding means you can allow the user to complete their profile on their terms and their time. They will surrender that data in exchange for value you deliver.

    Prompts for Push, Location, Address Book, Filesystem

    Same as above, don’t ask for what you don’t need untill you are delivering value. There is some pretty good tools and patterns available to explain to the user “why”.

    Poor Single Player Mode

    Users generally want to feel they’ve joined a community and they are in safe company.

    No first-time user data

    Sometimes a new user some example data or a walk-through to get started.

    Failed Invites to teams or friends.

    In the pirate metrics of AARRR, this is the “Referral” step and critical to driving viral growth and reducing acquisition costs. If it breaks you are losing a significant competitive advantage.

    If invites are being sent via email, check your invites don’t got to spam folders. If you are suing social, make sure all authentication bugs/fails are handled elegantly.

  • When should a startup get dedicated product management?

    When should a startup get dedicated product management?

    Steen Anderssen sat down with me for a fireside in front of around 200 Product Management folks. I asked the question: “When should a startup get dedicated Product Management?”

    This short video provides some surprising insight into how Atlassian thinks and how the founders remain in contact with product vision regardless of how large the company has grown.

  • 7 Product Management Anti-patterns

    7 Product Management Anti-patterns

    Here is a recent Medium guest post I did for the Product Management insider. 

    The 7 Product Management anti-patterns are not the complete-forever-last-word, but worthy of note when you are roadmap planning — the list originally was a tweet I made distilled from the series I’m writing here on cognitive biases in roadmap planning — the tweet was flippant and fun but got was retweeted more than I expected — so this post drills in deeper on the list points. Enjoy and comment on Medium, I’d love to get your take on what should be on the list. 

  • Getting Product Market Fit – Part 3: Cognitive Bias in Roadmap Prioritization

    If you are a Product Manager, understanding the bugs in you and your colleague’s brains may hinder your roadmap. A common bug is bias.

    In an earlier post in this series, we hinted at biases in product decisions – these are manifold and critical to understand because any one may be a game-changer for product-market fit. So in later posts we’ll share some ideas/tools on Prioritization but this post covers the brain mechanics that bias our decisions.

    We’ve all heard about “confirmation bias” but here is the wikipedia entry on hundreds of cognitive biases. A popular example from many eastern and western cultures is “full moon makes people crazy” – this may be statement of fact or it might be confirmation bias. In fact biases are part of our daily life and culture itself is an in-group bias based on conditioning and genetic capabilities (dogs hear better than humans).

    But check out this diagram below, you can’t hope to know all biases operating on you and your team but you want to have operational discipline to not let them run your roadmap. i


    Cognitive Bias Codex from 2016
    Source: Cognitive bias cheat sheet

     

    The categories of:

    • What should we remember
    • Too much information
    • Not enough meaning
    • Need to act fast

    are good ways to break down the large volume of biases. The outer ring gives example of how the brain optimizes and as a result is buggy and subject to exploit or irrational behaviour.

    I recently attended a “bias in the workplace” (“Inclusive Leadership”) workshop and its intriguing to note that biases are brain shortcuts – simply put the brain is designed to conserve energy and sugar which are all necessary for primal survival.

    How Bias affects roadmap

    So the following examples are common, you may recognize you’ve experienced a few yourself.

    Cognitive bias: 

    • The CEO or Founder thinks Feature X is important
    • A favorite customer pressures to you directly about a bug or feature
    • Features trump bugs

     

    Sunk-Cost bias:

    • “One more feature and we will have product-market fit”
    • the best ideas are my ideas
    • “don’t validate with your mother”, “data sample of one”
    • “the team has put their heart and soul into this”

    There are lots of different biases and left to our buggy brains and lack of formalized tools we will make roadmap decisions that may sound well justified but often biased.

    An Antidote to Bias: RICE

    Some Product Managers advocate this method to reduce bias in roadmap planning. The mnemonic stands for:

    Reach – number of people/events per time period (e.g customers per quarter)

    Impact – (e.g For each customer who sees it, this will have a huge impact. The impact score is 3)

    Confidence – (e.g The reach and impact may be lower than estimated, and the effort may be higher. This project gets a 50% confidence score.)

    Effort –  a number of “person-months”  (This will take about a week of planning, 1-2 weeks of design, and 2-4 weeks of engineering time. I’ll give it an effort score of 2 person-months.)

    I’ll dig a little deeper in the next post about this in practice. We’ll also look at JTBD again. Even a brief nod to OKRs is a relevent element of a Product Manager’s armory.

     

    The previous posts in this series are:

    Part 1: Founder Market Fit 

    Part 2: Avoiding Feature Delusion