Category: Roadmap

  • Top 10 reasons to NOT code your flows

    Top 10 reasons to NOT code your flows

    You probably don’t miss Letterman much but in the spirit of Dave, here is a not-too funny countdown on the build-versus-buy decision Product teams need to make about adding an engagement layer (specifically tips, tours, flows, hotspots etc) to your App.

    As a recap, the Contextual mission is decoupling “App design” from “App Engagement experiments“.

    So, we think that Developers own the cadence of the “App design” layer. Conversely Product Teams need to iterate fast on Experiments for feature adoption, onboarding, feedback etc.

    10. Bugs and technical debt – Build once and fix many times – you can get open source tips and popup libraries for your flows but once you cobble it together you “own” the fixes and changes that start as small tweaks and end as big jobs.

    9. No roadmap disruption – your backlog has hundreds of feature requests to be triaged and added to sprints. Do you really want to add Engagement experiments to your tech roadmap? Therefore, your experiments may or may-not work but you delayed features to try it out.

    8. If it works you will keep using it – A corollary of the prior 2 points: if your Engagement activity is working then you will double-down and use it more. So then you double-down roadmap disruption.

    7. Manual targeting – you start out with a flow for everyone but soon you realise you want to treat different personas with a unique experience. Your engineers now start saying a whole engine needs to be implemented to do right-place-right-time. Thats a lot of code.

    6. Real-time Audience Segmentation and Pesonalization – engagement needs to happen in sub-seconds, if you are relying on hooking data out of analytics packages or CSV uploads, you’ve already lost the engagement opportunity.

    5. Analytics that make sense – your team has invested in Mixpanel or Amplitude that are terrific platforms, but to instrument these tools around every subtle engagement on your flows, tips, tours, flows,  tooltips is a data science job. So that is a “Hammer to crack a Walnut”.  4. Analytics you can see – contextual reports are important to Product Teams, you don’t want to have to dig around in Jira, the CRM and paste it all into a spreadsheet. If you are running engagement, you want to quickly see daily or weekly with zero effort how each experiment is performing, make micro or macro changes and measure again. 3. Delayed experiment iteration – Product Managers and Growth Teams need to iterate fast. Getting ensnared in the roadmap cadence is death to growth. 2. Outsource confusion – so….you’ve sent this non-core coding offshore? But mixed interpretation, timezone problems get some real mixed results. You know what I’m talking about 🙂 1. Discincented engineers will go and get a better job – tips, tours, flows are valuable to Product Managers but sooooo not a challenge to your engineering talent. “What font do you want again?”. Nuff said. 

  • Canva: Product Management Process and Stack

    Canva: Product Management Process and Stack

    Canva is one of the fastest growing companies around and now has 500 staff. I recently interviewed Robert Kawalsky who’s startup Zeetings, was acquired by Canva in April 2018. Robert soon took the lead for both Zeetings and Canva Presentations groups which represents a huge opportunity in Enterprise, SME and also Education.

    Our the interview (a fireside at Fishburners) covered a lot of topics – I’ve selected 5 minutes where I asked what he’s learned about Product Management processes, tools, stack inside Canva.

    https://vimeo.com/pointzi/review/335333108/b45df2b0de

    From Chaos to Clarity

    A few times in the talk, Robert referred to Canva’s method of wrangling ideas into features, he called this “Chaos to Clarity” – its a great description of the a product feature’s journey. The “Chaos to Clarity” process is:

    1. Initial Visual Lo-Fi designs – at Canva they are very visual about the way something would appear to a user. This is done in Canva. Sketches, Wireframes, Mockups.
    2. Pitch Deck for that Product/Feature – also done in Canva.

    3. Press Release for that Product/Feature – typically done in Google Docs.
    4. Strategy Document – a long form description that outlines the problem, user stories, dependencies with other products

    5. Design Document – this is the handoff from Product Team to Design/Engineering
    6. Prototype – this is typically used for putting on usertesting.com so they can verify user understanding and response.
    7. Technical Design Doc – where engineering consider the implementation requirements.

    Canva’s Product Management stack is: Canva (surprise!), Google Docs, Usertesting.com, Jira, Trello, Mode and Amplitude for analytics.

    Ideas are the lifeblood of startups and agility can easily degrade into chaos. Too much order and you have stultifying bureaucracy – the Canva process strikes a good balance of balance.

    The Full Fireside

    For those interested in Roberts’ broader journey and a success story of an acquisition of a small startup into a powerhouse unicorn, here is the full video. (its missing a few minutes from the start). 

    Are you looking to get more users to love your mobile and web apps?  Click on the buttons below to get your 14 day free trial or contact us for a demo! 


    Get Started


    Get a Demo


    Contact Us

  • Feature Prioritization and roadmapping

    Feature Prioritization and roadmapping

    Previous posts have discussed roadmap prioritization, delusions/biases and methods like RICE to reduce bias when deciding what features to add to your Product.

    With that in mind, I was browsing a Y-Combinator interview with Brian Donohue, the President of Instapaper, acquired by Pinterest. I thought it was worth sharing.

    Brian provided a simplified prioritization technique WITH 2 super-important axes that Product Managers commonly forget because they are “in the weeds”.

    Brian would build a table with the following:

    1. Did users request it
    2. Does it give us a competitive advantage
    3. Can we build it into the business model

    The first is a no-brainer** if you have a good user-base and repeated asks***.

    Second and Third are harder for the Product Manager because often the backlog is so large and detailed its easily to forget to challenge your decisions with a more commercial hat on.

    So Brian’s method offers a very pragmatic top-down approach to getting a feature on the roadmap. One way we are trying to do this at Contextual is to map from quarterly OKRs to sprint planning.

    Typically we go from:

    1. Trello Board
    2. Challenge against quarterly team and company OKRs
    3. Sprint Plan
    4. Implementation

    Its a work-in-progress and still subject to bias but you might like to try adding Brian’s dimensions to your method.

    BTW: my good friend Scott Middleton CEO of Jirio/Strategos and Founder of Terem created an Epic List of Every Product Prioritization Frameworks

    ** if you are not Steve Jobs.

    *** we’re also experimenting as an “ideas-driven organization” as inspired by the book titled The Idea-Driven Organization: Unlocking the Power in Bottom-Up Ideas by Robinson & Schroeder.

    Here is interview with Brian.

  • 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