Contextual

Category: Product Managers

  • Product Managers: Data-driven experiments are an excuse not to be brave

    Product Managers: Data-driven experiments are an excuse not to be brave

    Being “data-driven” is “virtual signalling for Product Managers” and not the best method for some product decisions and roles.

    This snippet from a longer conversation with Patrick Collins of Zip.co digs into the suprising insight of different traits in PMs.

    Patrick quipped about his experience: “I’ve only been doing this product thing for 10 or 15 years”. 

    So it’s clear he has a wealth of experience and carries a lot of lessons and scars from both web and mobile products.

    Patrick’s advice to aspiring and existing Product Managers is to know which type you are:

    1. Analytical
    2. Intuitive and/or creative.
    3. Technical

    In recent years he’s seen migration from Project Management and Business Analyst roles into Product Management. Also there is often a progression from developers into the PM track. But perhaps these new PMs are more analytical and don’t carry a sense of what a great user experience is like.

    The concern is that:

    “experimentation and being data driven,
    can be a cheap out for being brave”. 

    In other words a Product Manager who has the courage to make big bets based on solid user experience background is invaluable in creating a “generational leap” in product quality.

    Patrick notes that this trait is not based on seniority, its really that many PMs are risk adverse. They get into a process of “polishing the turd”.

    It’s an interesting conundrum, in other posts we’ve noted the time expense of A/B tests to get statistical significance, the challenge of PMs wearing many hats and personality traits.

    “But the idea that we can just test our way out of every problem is dangerous because it can really hold a product back.”

    Like most human skills, its part-art and part science. Patrick says:  “I still haven’t quite cracked the formula for what kinds of PM is able to know when to stop polishing and know when to go for a generational leap.”

    “some being more creative, some being more analytical and some being more technical and knowing who you are”

    ref: https://www.linkedin.com/pulse/types-product-managers-animal-kingdom-gaurav-rajan/

    The standard 3-legged stool for PMs is to balance UX, Tech, Business – you may have seen the Venn Diagram in other posts on this blog.

    But the image above illustrated the best fit for PM’s who are pre-disposed to traits of “Technologist”, “Generalist” and “Business-oriented” – the Focus field is a clue as to the persons strengths and weaknesses and ultimately what would be the right product-component for them to work on.

    Digging deeper into the downside of being too analytical, the obvious A/B problem arises:

    “The experimentation culture, I think is damaging in some ways, because it comes across as this kind of analytical thing that that you can test your way out of anything. But it’s like, well, what the hell are you going to test? And how are you coming up with that?”

    If you want to hear more from Patrick on a broad range of topics and experience, join me for our WFH Fireside chat this coming thursday. If you can’t make it, sign up to the blog and it will be in the upcoming posts.

    A note about the cover cartoon

    I was wondering about what picture to put up the top of the post. Perhaps “fork-in-the-road” to reflect product management career choices. Perhaps an “all-in-bet” pic from a casino etc.

    But I actually found a post on Basecamp’s site under their ShapeUp series that captures part of what Patrick was covering. 

    Basecamp are often controvesial, always counter-trend and very, very authentic. This series says:

    Shapeup is Shape Up is for product development teams who struggle to ship. Full of eye-opening insights, Shape Up will help you break free of “best practices” that aren’t working, think deeper about the right problems, and start shipping meaningful projects.

    and that sounds pretty bloody good to me – I’m adding it to my reading list.

    The image came from:  https://basecamp.com/shapeup/2.1-chapter-07

    Transcript

    Patrick Collins 0:03
    Learning of the different kinds of product managers, some being more creative, some being more analytical and some being more technical and knowing who you are. And therefore what if you know i’d imagine the audience is probably going to be aspiring PMs, some of them anyway. knowing who you are as a PM really will help.

    Patrick Collins 0:27
    And you don’t want to be a creative PM, running the platform services team, or tech or a technical PM running the onboarding project for the app, right?

    David Jones 0:40
    Why was it specifically what did you learn that specifically at Moveweb?

    Patrick Collins 0:44
    I guess I’ve learned over both of these past roles, that those different PMs can actually fail in one role and succeed and I don’t mean outright fail, like crashing and burn. I mean succeed in other ones. And so when I look for PMS, I look carefully at their background. And I look at what skills they have. And that will lean me slightly towards where I think they’re probably going to succeed as PM. Creative requires you to take some bold steps. And I think the experimentation culture, I think is damaging in some ways, because it comes across as this kind of analytical thing that that you can test your way out of anything. But it’s like, What the hell are you going to test and how are you coming up with that? Which part and you know, I think I’m on consumer app in particular, it requires a lot of bravery and a lot of courage to translate what you’re hearing from customers into a point of view, and then go test that and having that having that courage to translate data analytics and and customer interview data into into a point of view: not many PMS have that.

    Patrick Collins 2:03
    And it’s actually not a seniority thing I’ve noticed it’s a, it’s a risk taking trait that some PMs just will never get.

    David Jones 2:12
    So just to, just to play that back to you, if I’m a really good data centric type product manager, there was a Stanford saw talk I saw which was called “gut, data, gut”, which was that you’ve got to start with an intuition first, then you can go and get the data to support it or actually run and experiment for that data, then you actually have a new iteration. Are you saying that an analytic type product manager really just misses that sort of “gut” type thing and testing many different sorts of things?

    Patrick Collins 2:44
    CAN. Yeah, I think the concept of experimentation and being data driven, can be a cheap out for being brave and not taking not making courageous leaps on the product and maybe polishing a turd, so to speak. And so sure, I think there’s a really difficult line to walk between knowing when to polish and knowing when to try to “go for it”, like a generational leap. And it’s still kind of I’ve only been doing this product thing for 10 or 15 years now, I still haven’t quite cracked the formula for what kinds of PM is able to know when to stop polishing and know when to go for a generational leap. That’s that’s a really challenging, challenging problem for most PMs. But the idea that we can just test our way out of every problem is dangerous because it can really hold a product back.

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

  • 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 2: Avoiding Feature Delusion and Biases

    In this part Elliot and I discuss the role of founders as product managers.

    Because the skills of Product Managers are not well understood, it doesn’t exist as a job role in the start of a company. So the founders take on the role – at the same time founders are often great, charismatic sales people – here are two common results:

    1. The founder starts out a meeting with the plan to get feedback about an idea or product. Somewhere they start to flip from questions to statements and start telling the interviewee how awesome this product will be/is. Naturally the interviewee doesn’t want to argue too much and so the founder walks away with a rock-solid validation 🙂

    2. One of the founding teams goes out to a meeting and returns with a new feature never previously discussed or even a major pivot! Of course this may be valid, but a data-point of 1 needs some extra research.

    Here Elliot proposes some ways to get space between your skill to sell (your ability to transmit a Steve-Jobs-Like-Reality-Distortion-Field) and being receptive enough to not get deluded about your product vision.

    In Part 3 we’ll look at unconscious biases that may underlie common Product Market Fit misses. Also how this maps into Product Roadmap prioritization.