Blog

  • Developer retention – the cost of app complexity

    Developer retention – the cost of app complexity

    App complexity grows over time – but developer retention is usually a few short years. Product Managers need to reduce App complexity to the core features and outsource non-core functions to other products.

    In a recent post, we discussed the return on investment of using platforms like Contextual for onboarding, announcements and guidance vs hard-coding.

    Whilst hard-coding might be a quick win to create some simple tips, the complexity increases rapidly when you realize the cost of:

    • analytics to confirm effectiveness
    • targeting to get the right audience and trigger at the right time
    • small (or large) changes to the text or images that result in the need for an update.

    Most importantly there is the:

    a) reduced speed of learning (iterating for increased adoption or engagement)

    b) the distraction of hijacking your Developers away from working on product features

    The Cost of Technical Debt

    When a developer says “goodbye” – you need new or existing developers to cover the code “surface area” of their contribution. Developer retention is a major underestimated consideration for a Product Manager.

    When a PM opts to hard-code something non-core in their application, the team is making a commitment to maintaining, enhancing that in the future. Also it’s often the case that old features break when something new changes.

    This is one form of technical debt.

    Here is what happens: Your genius developer has a lot of intellectual clout and can solve things quickly with their prowess. However, they are so talented that weekly they receive calls from recruiters and eventually they decide that it’s time to make a move.

    Because they were fast, sometime the coding methods may have used shortcuts or intimate knowledge of the system that the incoming developer needs to learn. New developers often need 3-6months ramp to be able to understand how things are done.

    Don’t code what isn’t core

    When using a guidance platform like Contextual, the integration is a few lines of code and then you’ve freed you’re developers to work on key core app features.

    Automating onboarding, announcements and guidance is systemised at the no-code level and therefore insulates against staff churn.

  • How one Bank App uses Feature Announcements

    Contextual was designed for Apps to make onboarding, education and Feature Discovery simple and code-less. Most commonly the use of Tips and Tours to nudge a user into action is a great user engagement approach.

    But what happens when you are rolling out a major feature?

    • Perhaps tips of a popup are a good introduction but not impactful enough.
    • A Home Screen carousel is just too interrupting to the user flow and has low conversion rate.

    Try a Feature Carousel

    St George Bank is a major bank and they made a significant investment across their ATM machine network to support “Cardless Cash”. If you’ve not heard of Cardless Cash its a major improvement to getting money easily for your wallet – the benefits are:

    1. Card Security – you don’t need to pull your card out and put it in the machine, where you might forget it. Risk of “skimming” is also eliminated.
    2. PIN Security – you don’t need to expose your PIN where someone may spy it.
    3. Fast – its pretty quick to get the cash out, just a few keystrokes at the terminal.
    4. Money for others – A parent can send the access code to a child who can then get cash for an emergency.

    The challenge is that whilst a huge rollout investment is made, getting customers to use this feature hits the human fear, uncertainty, doubt and plain laziness.

    So the Product Management team at St George obviously wanted to give the new capability the best chance of uptake and embedded a Feature Carousel into the App. So if a user explores this section of the App for the first time, they get a richer walk-through that is eye-popping and more persuasive than just a tip. Here is the introduction.

     

    There is a couple of interesting things to observe:

    1. They decided to reduce the number of swipes by putting 2 steps on each page. I don’t know if this helps with memory retention of activation – but its an interesting experiment. With Contextual, you could run an A/B split to see what gets better conversion.
    2. Short Sharp Action-oriented text. Notice how there is no waffle and Verbs like “Get”, “Find”, “Withdraw” get task focussed.
    3. The explanation is contextual and the user can immediately perform the task.
  • Hardcode or Buy – the return on investment question

    Hardcode or Buy – the return on investment question

    What elements are best to hardcode and what should be “bought”?

    Product teams always have a backlog of features, fixes, customer requests and re-rewrite/re-factor advocates.

    At the same time, customer churn, engagement, monetization are the primary product goals that map to company OKRs. 

    We used to hardcode emails, now that would be crazy

    Retention-driven growth needs multiple inApp and out-of-band initiatives. One out-of-band example is customer emails (drips, newsletters, transactional).

    Back in the 2000s product teams used to get the developers to hardcode their HTML emails. Over time it was realised that this was a huge waste of developer time and stopping them making a better product!

    So the craziness stopped and now we have a massive industry of products like Mailchimp, CampaignMonitor, Autopilot, Sendgrid etc etc that full-fill the need far better than any in-house initiative.

    Today very few companies would make the “build” decision and prefer to use a SaaS platform product that makes email creation and sending easy – its a no brainer!

    Should Apps hardcode inApp engagement?

    Moving any task from backlog to sprint should be sanity checked against the one question:

    “Is this our core business?”

    For most products, if your product needs:

    • Guides,
    • FAQs,
    • Tooltips,
    • Announcements,
    • Feedback,
    • Videos

    Then, the answer is NO.

    For some companies, for example gaming, every user moment needs to be hardcoded and controlled. The financial stakes for conversion are measured in milliseconds and their ad-spend is huge so they need to capitalize. With tens or hundreds of developers and many millions invested – this is a core competency for the Apps survival.

    For most companies, however, the core competency is the functionality of the product and ease of use. As we discussed elsewhere, this is why we discuss a:

    1. Feature layer (App Design layer)
    2. Engagement layer

    The Contextual Engagement Layer

    The Feature Layer – changes with the speed of sprints. It is owned by the developers and should change slowly.

    The Engagement Layer – should iterate rapidly. This is where Product Managers and growth teams can iterate and learn what creates retention and feature usage uplift.

    The launch (to customer) cadence for each would look like this.

    The Business Case for not hardcoding

    Once you start with engagement layer activities you are super-sprinting and measuring much faster than your feature sprints can. You may eventually hardcode something that has been successful using Contextual – giving you more fine-grained control, but you didn’t spend person-months building something that nobody cared about.

    This table shows our recommendations when establishing a business case:

    1. Stop wasting developer time.
    2. Speed up your learning iterations
    3. Target and measure users at different phases of the journey – don’t spam everybody with popups and announcements!
    Hardcoded Contextual Platform
    With Hardcoding, every single tiny change requires App (web) & Appstore (mobile) releases With Contextual, changes are instant or scheduled to users ????‍♀️
    With Hardcoding, you need to stop developing features ???? With Contextual, you don’t bother developers
    ???? – keep making your product better!
    With Hardcoding, you’d have to code user targeting (yep, more code) ???? With Contextual, audience targeting is point-and-click and real-time ????
    With Hardcoding, no analytics ????‍♂️ With Contextual, guide interaction analytics are built-in ????

    In a business case, numbers speak louder than words – so contact us if you’d like to make use of our spreadsheet and add your unique numbers and resources.
    The spreadsheet isn’t too pretty but its enough to make a data-driven business case.

    For your:

    a) developers. Some developers have a “not-invented-here” view that is disconnected from commercial reality. Especially with outsourced or offshore contractors, they may have a tendency to want to “build everything” even if the work is demeaning to their talents and time.

    b) management – they carry the burden of costs.

    You can also point them to this video – in 7 minutes it summarises the points discussed here and may be quick enough for them to review to have an informed conversation.

    So, if you need help with your build vs buy decision – either a discussion or quantitative model, hit us up in an email or the chat widget.

    You can also fill out a request on the Contact Us page.

    To understand what functions the platform provides, check out some of the video examples.


    Banner image credit: https://corporatefinanceinstitute.com/

  • Don’t build shiny objects

    Don’t build shiny objects

    Shiny objects are the features you release that arn’t supported by evidence the customer needs them.

    Airwallex’s Richard Jeremiah gives his perspective on how Product Teams should triage the firehose of ideas, feedback and opinions that all compete for precious sprint resources.

    In this short video, Contextual’s David Jones asks Airwallex’s Richard Jeremiah how they reduce down all features into the things that get built.

    He cautions that all product teams have a tendency to  “Veer off the path” :

    • moving away from (measurable customer) “outcomes” to “output”.
    • Teams often shy away from uncertainty to just making and releasing the new shiny objects.

    Outcomes vs Output

    For Airwallex and “Outcome” is focussed on customer value – this generally relates to an Objective or a Key Result in an OKR.

    In contrast, an “Output” is just the result of keeping busy. This is often features that are built in isolation from customer needs. In other words, output is that new shiny objects are something the team saw in a designer’s blog post or a competitive product.

    The challenge, Richard says is that “Outcome” is always way less certain than “Output” – an output is a known quantity, its just a matter of applying the resources and getting it released.

    An Outcome requires much more validation and rigour to verify:

    • Are we building the right things?
    • Are shipping valuable things for customers

    “Solving core customer problems is one of the great challenges of Product Development.” and “Get inside the head of the customer.”

    Triaging competing requests

    At the top of the product teams work funnel is a massive amount of options:

    1. Bugs to be fixed
    2. Technical debt to be re-factored. Scale and stability issues.
    3. Customer feedback captured in Zendesk etc
    4. Sales people claiming its imperative to implement ABC feature for XYZ prospect
    5. Team opinions
    6. New shiny objects and technologies
    7. validated feedback from customers
    8. results of experiments, hacks
    9. biased opinions from the product manager.
    10. and that old favourite….the fly-by CEO visit about something that’s been bugging them.

    There is a lot to be triaged and having something like RICE is fine, but it’s rudderless.

    Similar to what Zip‘s Patrick Collins advised the sprint needs to be filled with jobs that match to the customer and company imperatives.

    Specifically, Richard says: Strategy—>OKRs—>Measures that reflect toward an Objective or Key Result/Outcome.

    This top-down approach leads to using tools like Teresa Torres’ “opportunity solution trees” to ideate a range of possible technical and non-technical solutions.

    From there a weighting or “sizing” (Richard’s term) for each initiative is used as another filter for what makes the sprint.

    Summary

    The summary is that new shiny objects will always be tabled as solutions to product problems or opportunities. 

    Its correct – the shiny objects may be a terrific solution! But you MUST run them:

    a) through the lens of the customer’s needs

    b) the organisational priorities and OKRs.

    Banner Image credit

    Transcript

    00:03 – some of the lessons that i’ve

    00:04 – learned over my career but it’s very

    00:06 – very easy for

    00:07 – teams to veer off the path away from

    00:10 – outcomes towards output

    00:11 – it’s very easy to veer off the path of

    00:14 – experimentation uncertainty and trying

    00:16 – to nail down something that is certain

    00:18 – which is

    00:18 – in many cases look at this shiny thing

    00:21 – that i’ve built

    00:22 – and so trying to embed that into your

    00:25 – day-to-day

    00:26 – um check-in with the team i think so

    00:29 – anyway you’ve got these squads

    00:31 – how do you actually make sure you’re

    00:32 – building something that people actually

    00:34 – want

    00:35 – so yeah i mean that’s a that’s a big

    00:38 – question

    00:39 – um and it’s it’s really challenging i

    00:42 – think i think this is

    00:44 – you know making sure you’re shipping

    00:45 – value to customers is the

    00:47 – it’s one of the defining aspects of

    00:49 – whether you’re not gonna be successful

    00:50 – as a business

    00:51 – um i mean that’s that’s like are you

    00:54 – well suited as a business to do

    00:55 – to do that and all those stuff there’s

    00:56 – lots of other questions but one of them

    00:58 – is generally

    00:59 – are you solving a core customer problem

    01:01 – is

    01:02 – one of the great challenges of product

    01:04 – product development look our focus is

    01:07 – and my focus has been for a long time um

    01:10 – i i spoke previously it’s all about

    01:12 – focusing on the outcome

    01:14 – and not focusing on output that’s the

    01:16 – that’s the key

    01:17 – um it’s very natural as human beings

    01:20 – that we want to focus on

    01:22 – the output and not the outcome and one

    01:24 – of the reasons for that is output is

    01:25 – certain if you

    01:26 – if you apply effort you’ll get you’ll

    01:28 – have something to show

    01:29 – for it in terms of that you know it

    01:32 – could be

    01:33 – whether it’s a new page that you’ve

    01:34 – created whether it’s an experience

    01:36 – enhancement thing you’ve done whether

    01:37 – it’s a new feature

    01:38 – that’s available on your on your

    01:40 – platform you’ll have something to show

    01:41 – whether that thing matters or not that’s

    01:43 – the question right and so the

    01:44 – outcome is always way less certain and

    01:47 – we have a natural information as people

    01:49 – to want to you know shy away from that

    01:51 – uncertainty towards something that’s

    01:52 – certain

    01:54 – you have to be relentless in that focus

    01:56 – on the outcome

    01:57 – and that outcome could be whether it’s a

    01:59 – commercial outcome that you’re trying to

    02:01 – achieve by a meeting a need or a

    02:03 – customer need itself

    02:05 – you know that’s where your focus has got

    02:06 – to be so for me

    02:08 – trying to ensure that you’re shipping

    02:09 – value it’s all about

    02:11 – focusing on the outcome um and

    02:15 – and then you know if the outcome is

    02:17 – customer related

    02:19 – ah yeah so you sort of threw that in at

    02:21 – the end but it sounds like the most

    02:22 – important thing

    02:23 – so you you know what goes in the top of

    02:25 – the funnel

    02:26 – is a whole bunch of things you’ve got

    02:28 – opinions you’ve got sales people walking

    02:30 – back saying

    02:31 – you know they’ll come on board if you

    02:32 – actually develop this feature

    02:34 – uh you know you you know that sales

    02:36 – people are always dragging in between

    02:38 – you know bits of roadkill they say that

    02:40 – this is definitely the one that’s going

    02:41 – to

    02:42 – break the you know it’s really going to

    02:44 – the company will break out

    02:45 – you’ve got opinions around particular

    02:46 – things and then you’ve got disciplines

    02:48 – and customer

    02:49 – so how how are you feeling the top of

    02:51 – the funnel and then how are you triaging

    02:53 – that to get to this

    02:55 – output that’s actually used by a

    02:57 – customer

    02:58 – used by a customer yeah sure or even

    03:01 – valued

    03:02 – valued by a yeah yeah so

    03:05 – we um the general the general approach

    03:07 – and i

    03:08 – alluded to this before with you know we

    03:10 – have a strategy we have a set of okrs

    03:13 – that that then outlines um you know

    03:16 – here’s some some measures we’re going to

    03:18 – try and deliver over the course of the

    03:19 – quarter

    03:20 – and those measures reflect progress

    03:22 – towards an outcome or an objective

    03:24 – right what we take from there is trying

    03:26 – to understand

    03:27 – what are the various opportunities there

    03:29 – are to better serve the customer in a

    03:31 – way

    03:32 – that’s going to drive that particular

    03:33 – key result and

    03:35 – getting an understanding of that is all

    03:38 – about trying to get

    03:39 – under or inside the head of the customer

    03:42 – and there’s a lot of ways to do that

    03:45 – and you know you have to you want to use

    03:47 – all the tools you’ve got your disposal

    03:49 – sales people they are one of the tools

    03:51 – yes they have

    03:52 – they’ll have a lot to say that

    03:54 – oftentimes will be focused towards

    03:56 – a feature and a solution and they’ll

    03:57 – tell you about the solution

    03:59 – i mean one of the things is to try and

    04:01 – step back from that and say well hang on

    04:02 – what’s this solution actually trying to

    04:04 – achieve

    04:04 – and refer back from that some of it is

    04:06 – talking to those sales people all those

    04:07 – customers support people

    04:08 – and just taking on the journey to say

    04:10 – hey when you talk to your customers

    04:12 – next time they come up with a solution

    04:14 – can you ask why they want to do that and

    04:16 – actually try and work with your customer

    04:17 – support team to drive better customer

    04:19 – insights on the

    04:21 – the why for the customer as opposed to

    04:23 – what they want because

    04:24 – you know if you ask a customer what do

    04:25 – you want they’ll ask for you know

    04:27 – classic saying i want a faster horse not

    04:29 – i want a

    04:30 – motor vehicle so it’s about trying to

    04:33 – use

    04:34 – as many of the avenues that you’ve got

    04:37 – to get customer insight and that can be

    04:39 – you know talking to customers watching

    04:41 – customers engaging with customer support

    04:43 – team as i’ve said you can

    04:45 – um and in fact you can do that yourself

    04:47 – you know one of the things i used to do

    04:49 – a little bit of secret to get onto our

    04:50 – zendesk and start seeing what customers

    04:52 – are saying and trying to understand

    04:54 – what’s going on for them uh and again

    04:57 – you know

    04:57 – use your sales people they have a lot of

    04:59 – insight they’re coming to customers all

    05:01 – the time

    05:02 – but what you need to do is you need to

    05:03 – bring that back to try to understand the

    05:05 – customer’s motivations trying to

    05:06 – understand their needs

    05:17 – okay so that’s a discipline to actually

    05:19 – just basically look at it through the

    05:20 – lens and i guess what are using customer

    05:22 – interviews for that or

    05:24 – yeah so there’s a mix i mean the way

    05:27 – the way you know uh structured it and

    05:30 – the way we’re structuring it and while

    05:31 – it’s the framework we’re using is jobs

    05:33 – to be done

    05:34 – um we at seek

    05:37 – out a thing called a mental model which

    05:39 – is a more detailed deep dive than jobs

    05:41 – to be done into very

    05:42 – difficult tasks and that that is

    05:44 – essentially that mental model is

    05:45 – essentially a shared understanding of

    05:47 – the customer

    05:48 – and what is put against that mental

    05:50 – model the evidence that used to

    05:51 – construct that at

    05:52 – customer interviews uh customer support

    05:55 – insights

    05:56 – um you know experiment data behavioral

    05:59 – data on the platform like

    06:00 – basically any data point you can get

    06:02 – about the customer is used to help build

    06:03 – out that shared understanding of how the

    06:05 – customer

    06:06 – thinks facts their motivations what

    06:07 – they’re trying to achieve et cetera et

    06:09 – cetera

    06:09 – so is a mental model an intersection of

    06:12 – you know demographics slash personas

    06:14 – and job to be done is that is it so yeah

    06:18 – i mean you could segment the mental

    06:19 – model

    06:20 – based on the different personas um but

    06:22 – really it’s just a more detailed view

    06:25 – of jobs to be done you’re getting down

    06:27 – to very discreet tasks as opposed to a

    06:29 – job you know a job is

    06:30 – a manifestation of multiple tasks it’s

    06:31 – like subtasks and sub-sub-tasks it’s

    06:33 – really really granular

    06:35 – and it just essentially represents a

    06:37 – shared understanding of the customer how

    06:40 – we

    06:40 – understand the customer’s motivations

    06:43 – and what they’re trying to achieve

    06:44 – through

    06:45 – in this particular you know task

  • Trigger guides at the user’s right time

    Trigger guides at the user’s right time

    It’s hard to miss Netflix’s latest blockbuster docu-drama “The Social Dilemma” (I’m a big fan of Tristan Harris).  The social network’s AI is characterised as the perfect “feed”ing of content to the user at the “right-time” to get the result the social network wants. 

    Aside from the moral and social issues, most Apps would dream of achieving timing of Guides, features or content to a user that deepens engagement and understanding of the product.

    Where is benefits the user first, then it becomes a win-win for user and product. The product is stickier with the customer and informs them (hopefully) about benefits to that user.

    The Problem: vendor based triggers

    Lets take a small example from the password manager “Lastpass”. 

    We all know the situation – you head into an App that you use because you have a job to be done (JTBD). For a fleeting moment you see your page and know what you need to do next.

    Wrong.

    Instead, the App’s product manager has decided to tell you about something completely different, the example modal below takes over the full screen.

    If you are like me, you definitely want to know about “Welcome to Families!” but not-right-now-I’ve-got-a-Job-ToBe-Done!

    Of course, most users will click dismiss and may never be able to find the way to start the guide again later.

    lastpass onboarding guide

    Now….the Lastpass Product Manager has done some things right and some things wrong here:

    PROS
    1. I upgraded to “Families” plan previously, so now they think is a good time to show me a tour.
    2. The modal has a clear purpose and call to action (RED is the LastPass colour, so while red normally would be a warning, its “on-brand”).
    3. The modal allows the user a way to dismiss.
    4. Allow an option for a “MAYBE LATER”
     
    CONS
    1. I upgraded to “Families” plan previously, so now they think is a good time to show me a tour. BUT, its too intrusive and ignores my JTBD.
    2. The problem is that like me, many users will just click this away and its a crap-shoot whether the user clicks the “X” or the “MAYBE LATER”.
    3. Many users will NEVER see this prompt again – that is bad for the adoption of the “Families” feature.

     

    Here are some other approaches you can use instead or in-concert with the above approach.

    Better Alternates

    FAQ widgets

    Depending on a user’s journey and and the page the user is on, then a contextual sidebar widget can be shown. Lastpass could just update the widget for a user.

    Here is an example we use in our dashboard. It’s contextual but not interrupting the user’s JTBD. By clicking an FAQ item, the user can re-run the guide when it suits them.


    Hotspots and Launchers

    As discussed in our post on Continuous Onboarding here a 3 different types of hints to a user.

    1. For general reminders and help, you can use a tooltip. This is the little ❓in the bottom left.
    2. On the right side we have a glowing dot, or beacon. This is super useful as a shout-out that needs attention.
    3. The cute gift icon is from Slack’s UI. Using an icon that  and acounter 

    Click to see the animation

    Timing

    Both FAQs and Hotspots can be timed to appear when at the right time of the user’s journey. You have control based on:

    • what features the user needs
    • what goals they’ve completed
    • demographically where they fit
    • what language is best for that user.

    In summary, prompting users for guidance is not really best-practice, its just the most-common-practice.

    The Guide (or walkthrough) design pattern is great but as Product Managers and Product Designers, we must always consider the user’s current JTBD and keep out of the way until they need us.

    We may not have the dystopic controls that the social networks have to “tell a user what they need” but solutions like Contextual have a growing set of capabilities to guide the users at the best time for them.

     

    Source for the banner image: thequint.com