Contextual

Category: Product Manager

  • Customer-driven product management with Productboard

    Customer-driven product management with Productboard

    In this session we explore the Productboard platform. Readers of this blog know that a Contextual we are extremely passionate about:

    1. JTBD (Jobs to be done) and how the best teams link Strategy and OKRs to feature prioritisation.
    2. How teams use methods like RICE (to score) or Opportunity Solution Trees (for ideation)
    3. How this practically allows a Product Team to triage/groom the backlog and…
    4. Execute on the most impactful and meaningful tasks in a sprint.

    productboard

    Drilling into Productboard, I was interested to learn their approach to Roadmaps, Feedback and linking these thinks with Strategic elements such as OKRs.

    I wanted to see how it works in the platform and how this works for Product Teams and also flywheels out to others in the organization for linking actions with strategy.

    On the video is Sophie Lalonde and Alon Bartur are both from the Productboard  Product Team! This is getting very meta ????

    https://vimeo.com/476995521

    What I learned along the way about Productboard is a good lesson for other products.

    1. They have a clear vision to be meaningful to product managers “out of the box”. Their north-star appears to be the Product Manager’s Dashboard.
    2. They can penetrate deeper into an organization by being useful to surrounding teams. (Customer Success, Engineering, Leadership).
    3. Smart onboarding that:
      1. allows their own Customer Success to understand what challenge a trialler is looking to solve.
      2. Allows the best templates to be shown (that “out of the box”experience).
      3. Easy and fast invites to colleagues to kick-start collaboration and increase likelihood of activation inside that trialler’s company.

    Productboard is an impressive platform and the video is worth a look. In coming weeks I’ll extract a few short nuggets that were excellent learnings.

     

  • 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.

  • 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/

  • 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

  • Opportunity Solution Trees for Product Teams

    Airwallex is a newly-minted unicorn based in Australia operating at the intersection of FX and business expense management.

    This snippet is a preview of an upcoming fireside in a few weeks with Richard Jeremiah who is Product Director for the SME Platform.

    Airwallex Logo - Black (1)

    Airwallex are an interesting play in that they potentially compete with Brex, Transferwise and Stripe. No lack of ambition here ???????? and its bound to be a great discussion – particularly because Richard also held senior Product roles at Seek and Joro.

    Richard will be talking about learnings from using Teresa Tores’ Continuous Discovery Method and how that wires together with OKRs (Objectives and Key Results), JTBD (Jobs to be Done) and Opportunity Solution Trees.

    I wasn’t familiar with Teresa’s work, so I found this post which covers real-life examples of a company getting started with Opportunity Solution Trees – I look forward to digging more into this with Richard.

    The key takeway for me in this preview is that this approach stops a Product Team from focussing too narrowly on ONE solution to the challenge (and racing off and implementing), but gives you a breadth-first perspective of potential solution candidates. The last quote captures the value of Opportunity Solution Trees (etc) as a discipline for Product Teams – its a ripper!

    “Shift from being a feature factory to a problem solving product team”

    Sign up for the blog on the right if you want to get notified about this session.