Contextual

Category: Product Managers

  • Podcast: Steen Andersson – Head of Product at Atlassian

    Podcast: Steen Andersson – Head of Product at Atlassian

    Steen is Head of Product Management at Atlassian.

    He was Google Drive’s Group Product Manager, VP Product at Nitro after they acquired his startup Sensedoc.

    Before that he was co-founder of 5th Finger which actually got acquired (not once but) twice! by both Microsoft and Merkle.

    In this podcast we are talking how Atlassian grows Product Management talent and other goodies from Steen’s startups and roles. 

    Don’t miss where he shares Atlassian’s Four Pillars of Great Product Managers.

    Some of the topics covered:

    • What are the qualities of a great product manager at Atlassian?
    • Can you grow these skills or are they already growing on trees?
    • Do PMs spend X% of their time with customers or triaging requests?
    • What ratio of PMs to devs in a group?  (Is there also a scrum master?)
    • If we contrast with Nitro (being a smaller company) – is the role/skill different?
    • How Atlassian use JTBD or “Top Tasks”
    • Whats the hardest part of deciding what come next?
    • Do you have a story about Feature/Roadmap Bias

    A particularly AWESOME element is that he shares their “four key pillars of being a great Product Manager”.
    Check it out on Soundcloud.
    The Contextual Product Manager · Steen Andersson – Head of Product at Atlassian

    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

    Part 1 Transcript

    David Jones: [00:00:01] Hello, Hello!

    [00:00:01] Steen Anderson is with me today and he’s the head of product management Atlassian. He was also at Google Drive as group product manager and he was V.P. of product at Nitro which was a smaller company but an interesting company. And that was after his startup called since Doc was acquired so we’re going to cover that a little bit too. Before that he was also a co-founder at fifth finger which actually got acquired not once but twice. Believe it or not by both Microsoft and Merkel and today what we’re going to do is talk about all things product management. How are you Steen?

    Steen Andersson: [00:00:34] Good. Great to be here.

    David: [00:00:35] Yeah. Thanks for coming. Appreciate it. So this is a warmup for another fireside. We’re going to do so that’s gonna be fun.

    Steen: [00:00:41] Yep.

    David: [00:00:42] I don’t know whether we want to have a fireside in Australia during summer. It’s a little bit warmer for that.

    Steen: [00:00:48] Like a beach a little beach barbecue maybe.

    David: [00:00:50] Yeah I was wondering whether we should wear the sort of like the San Francisco Christmas bed jumper or whether we should wear a white shirts. I’m not sure what’s the right thing.

    Steen: [00:00:59] Yeah. We’ll make it fun.

    David: [00:01:02] OK, so let’s kick off, just where you’re at at the moment. So what are the qualities of a great product manager at Atlassian?

    Steen: [00:01:08] I mean that question is a great one it’s a it’s one of those age old mysteries that everyone ask. You meet a new Product Manager in a back alley way and you ask him that question. Look, we’ve done a bunch of work just recently actually last year. Is it a review the way we think about PM hiring and also appear PM promotions, ah, ladder and how we think about identifying talent and success and and recognizing that and what we did. And we actually spoke to a number patterns across the company, we’ve got 120 now. A good number there. And across the senior leaders we got together and so shared with some senior folks from Microsoft folks like myself that have a variety experience of start ups as well as Google. And then my boss job Joff, is from LinkedIn and there’s a bunch of different good good sets of experience. And we actually looked at what is the sort of the common overlap of answers to that question. And we came up with these four key pillars of PM excellence or how you going to call it. They broke it into these 4 categories. So ONE is: “leads and inspires”. So a great PM needs to be able to lead a team inspire a team that’s the first thing and a lot of depth behind that we can talk about if you like. Second thing is being a “master of the PM craft”. So thinking about like all the tools in your kit bag to help you understand how to think about roadmaps and prioritization to like you know think of creative ways to drive a team through particular challenging process to come out the other side; How to ship with velocity; all these techniques to just you know operate and be a great PM. The 3rd one is “delivering outcomes” and delivering outcomes comes back a lot to things like metrics, understanding what are the key levers we have to play with and how to appropriately use those to drive business outcomes like driving MAU or driving revenue or innovating in a way that’s really differentiating that sort of thing. And the last one is “being a great communicator” and the meaning of Great Communicator is really key. I think you make great PMs you’ll tend to find a common pattern that they really grab you with the way they talk about the problems they’re working on and just how they think about their space and all things in the world and so being an awesome communicator but written, verbal and presenting are critical. So thats how we think about what makes a great PM and it’s exciting to have some of that clarity and alignment in the organization now to sort of allow everyone to work on those things and help grow their teams and hire a great to have common lens right.

    David: [00:03:48] So number (1) and number (4) are really skills that can belong to a range of different jobs not just product managers; the metrics in (3) such as driving MAUs and things like that well that really is an outcome. So that sounds like number (2) is the one that’s kind of like industry specific is this the sort of thing that you have to find people that are already, you know in the industry or already doing product management or you know can you grow these skills or do you have to pick them off a tree?

    Steen: [00:04:17] You look at it you can totally grow all these skills. I think like anything in life there is certainly people who naturally have the predisposition to either find it easy to learn these skills more than other people or maybe they’re really passionate about them slaves at one time and energy into it. So all “grow-able” . I think the PM craft side, the master of the PM craft is, certainly yes, it’s more domain specific. I think the challenge for us is, as you go up the PM ladder to different higher levels of seniority it does become more difficult to find people who have depth of experience in that area. But I think as you go “up”, the “sliders” is on each of these four pillars change as you go more say some ways like leadership and inspiring. More important, more seasoned, more senior you go. But they’re all all important at each level. In terms of how we think about I can talk a bit about how we think about finding and hiring and so what we look at getting teams from. If that’s helpful.

    David: [00:05:15] Yeah go for it because I guess what I’m hearing is that if you’ve got somebody that’s coming in as a line PM then they could be theoretically a developer who wants to actually move into another thing as long as you feel as though they’ve got the potential to have leadership and communication skills.

    Steen: [00:05:31] That’s exactly right. I think again this these pillars help us qualify that person or sort of quantify that person and they have that that sort of product “gene” potentially and the passion and they can communicate their ideas and that sort of thing and they are a clear thinker. The biggest challenge for us is hiring PMs, for sure it’s challenging. I think in our business unit last year because we have fairly technical products we do have this natural tendency to want to hire people who also have an unstated 5th leg which is some sort of technical knowledge.

    David: [00:06:03] Yeah. Yeah. It’s really different to some sort of consumer product where there’s where there’s a lot of touchy feely stuff or things that many people can kind of just relate to as a user “in a sense”.

    Steen: [00:06:17] Yeah exactly. I think if you go outside of high tech and the word Product Management can relate to things like you know the marketing programs for a cereal packet like there’s a very different broad spectrum of the title. But in the bounds of high tech and suddenly it’s certainly challenging. And so we have a few programs we do things we do. We look at for the sort of more entry level PMs. We run an APM program – associate product manager program. It’s somewhat based off the sort of great leadership done by Google and then Facebook and LinkedIn and now a number of other sort of leading tech companies in the US globally. That’s basically a acceleration program for first time coming out of university. It’s a two year program; they do two one year rotations through different teams of the company. And that’s designed to give them a breadth of experience exposure to domains, different teams, different folks to learn from and accelerate their growth strategy, so after 2 years they can become PM and being highly productive. The long term goal there is to bring those people in at the entry level and grow them to be long term leaders of Atlassian. We might find they go and leave the company for a while and then come back at some point the future, we don’t want people to expect to come here and be here for like 20 years. That’d be great but that’s not realistic nowadays. Yeah. This idea of like helping see the industry, have people coming and going, but creating these long term PM leaders that have affinity with our business and our values is certainly part of the focus. So to that is the entry point. We have intakes in Bay Area and in Sydney and also New York we’re starting up next year. So that’s sort of that’s the APM channel. We then have to straight hiring we do pay PM level up to sort of all that through. Now hiring entry level PMs is not too hard in most places. We look at if they have got foundations of those four pillars to have a basic level and that means studied engineering computer science necessarily but they need to know enough of ground you know what is a programming language like they’ve dabbled with code and with computers enough they can understand the basics and found that the fundamentals. That’s often enough, but, if someone’s got like no technical companies competency whatsoever or interest in it. We find that it’s like we’d rather hire someone who has that versus not. It’s just doesn’t it just you know not it’s much harder to be successful. So that’s one thing for us at least.

    [00:08:36] And then as we look to the senior levels, the senior levels are hard for us because we’re looking at folks who’ve got experience. And some markets like Australia or even parts of the US like in regional parts of the US you may have or Europe you might not have the development path. It’s a bit like trying to hire a top grade cricketer in the US or a top level gridiron player in Australia, your just not gonna find it because there isn’t that sort of nurturing from young level right the way through to develop that talent so well that’s way too easy. You know you grow it ourselves or bring it in from another country or region.

  • “Slow” is a dangerous place for products

    “Slow” is a dangerous place for products

    This paragraph caught my eye:

    “Slow is a dangerous place for a product company to be. Slow product teams tend to be outcompeted by fast ones. We complain about how Figma and Slack don’t feel native, but why are most of us using Figma and Slack? We’re using them because they outbuilt and outcompeted their native competitors. There are so many things that could improve in these products, but they’re the best tools yet built for their purposes.”

    For product teams, releasing and syncing the features across your IOS, Android and Web platforms is a mammoth task. You release a new feature and then nobody uses it. You release on one platform and users complain its not on the other platforms!

    With Contextual we allow you to not only announce new features but also test different engagements or interest in a feature PRIOR to building.


    Lets say you’ve received some feedback from your customer success team, or using interview products like https://greatquestion.co/ or https://dovetailapp.com/

    You want to drill in and get a sense if other users would value this. With Contextual you could:

    a) ask for feedback with a question – a simple popup message targeted at a specific audience segment lets them single click answer to “take their temperature”

    b) Do a mock announcement for a feature:

    1. Users who click thru on the announcement can be measured.
    2. After clicking thru, you may ask the users for their level of interest.
    3. Promise to get back to them when its released.

    This time-tested launch-hack from that lean startups have been doing for a decade. It may appear a but scammy or disingenuous but inApp you already know the user and if they arn’t interested, they will just click away. No harm done but valuable data to be gained.

    This animated GIF shows how to do this with Contextual in a few minutes.


    The starting quote comes from an excellent post by Allen Pike, (the owner of Steamclock Software) on when/why product teams should prefer to use Native or Hybrid app development. The main point being – the more code platforms you support, the:

    • greater cost to your team to implement
    • greater cost of co-ordination
    • inability to iterate and test fast

    These are absolutely the problems Contextual helps try to solve – both because we provide libraries for ReactNative, Cordova, Ionic, Capacitor and of course Native IOS, Android and Web!

  • 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

  • How OKRs work (and don’t work) for Product Teams

    How OKRs work (and don’t work) for Product Teams

    In a recent discussion with Patrick Collins from Zip Money, he revealed they replaced roadmapping with OKRs. At Contextual we’ve had several false starts with OKRs – so this deep-dive video is with OKR expert Sten Pittet of Tability.

    Sten asserts that one of the main things people get wrong is making objectives to quantitative and making results a proxy for projects.

    He said that Patrick nailed it by saying its OK to abandon a project during the 90-day period if it seems it will fail the Key Results you are seeking.

    The diagram below explains the hygiene that Sten recommends. By adding the “Projects” ring, it reduces the usual confusion about key results. (He acknowledges he stole this and enhanced from Simon Sinek’s Begin with Why).

    Specifically here the fixed-ness of Objectives and friction in changing Key Results. These are the stable business-centric goals that should NOT be schizophrenically changing after the last customer meeting or if the CEO has some genius new strategic lightbulb moment.

    Sten does a great job framing these 3 levels, starting with these statements:

    Related to impact you have on your customers.

    and

    Teams can double-down on projects that work

    Objectives

    The way you phrase the top-level objective has the potential to kill or inspire teams to launch projects to meet that objective – afterall people/teams naturally obsess over such a concise directive.

    Bad example: “integrate with Stripe” – only related to dev team – can’t help Sales/Marketing get on with their work. The Key Result is also very binary: “Ship or Not Ship”.

    Better Objective: Get Paid Customers. This empowers each team to flush out their own Projects:

    Product: find a way to charge them (that might still be Stripe but it is in concert with other possibilities and team Projects)

    Sales: what markets can I tackle?

    Marketing: what initiatives will drive growth?

    Support: how can we reduce churn or convert trial to paid?

    Moving down to Key Results –  these “really focuses the attention of people on what is important”. A sensible selection is not the binary Stripe result but Revenue. Suddenly things are quantitative and not binary – its more trackable.

    In the bad example: The Product team say “we really need to ship that integration”.

    In the good example:  Marketing can get great progress by surveying customers on purchase intent.  The big contrast here is that waiting 2 months for the Stripe integration won’t move the needle if there is NO purchase intent.

    So the Stripe integration is downgraded to a Project. If that project looks like it will fail or run over the 90 period – the better OKR helps teams ask: “how can we charge people today?”, “can we do it manually” etc.

    Bad OKRs can derail a company. Good OKRs align teams in achieving one big thing for the business.

    The evolution of teams getting used to using OKRs and becoming more “outcome driven” looks like the picture below.

    Projects then should change a lot, they are just “bets” on getting a better Key Result. He was impressed with Patrick’s comments:

    Teams are autonomous and they can double-down on what’s working – if a specific project doesn’t lead us to a better Key Result, then we just kill it.

    Sten thought this was a sign of a top team.

  • Scaling Product Teams

    Scaling Product Teams

    This video interview (below) is a section of a longer fireside with Patrick Collins, CPO of public company Zip (ASX:Z1P). There is 25 people in Product and 150 people in Engineering, so we dig into the way Zip is structuring given their explosive growth revolutionising how we think about payments.

    Zip organizes teams in triads of: Product Manager, Engineering Lead and Designer. They then have 12 “durable teams” that worked on fixed part of the product. So there is no rotation of teams according to a project, they are wedded to the part of the product they “own”.

    No BA’s or Project Managers

    The video starts with a discussion around the triad and what happens when PMs ask for extra team members such as Product Marketers, Business Analysts or Project Managers.

    Patrick’s contention is:  “I just haven’t seen any problems that the triad can’t solve.”

    He has a spicy response to requests for these extra roles: “I just think you’re doing your job”.

    Because hiring PMs is challenging given the high demand and lack of experience outside Silicon Valley – Patrick is bullish that these roles CAN become great PMs, but old habits/tools like Gantt charts have no value in the product-driven Zip culture.

    Scaling is splitting

    Patrick sees that durable teams – led by triads – is a scaleable structure that works from startup from public company.

    He reminded us that startups typically begin with: a hacker, a hustler and a designer. In other words the triad is often the basis of great startups because all the essential jobs can be done with these founders.

    The great challenge for startups is to control the propensity to split your focus by adding “New Features”: Patrick says: “if there’s not a strong overlap with the customers that you’re meeting on a daily basis and the problems that they face” then 

    No Roadmaps

    I was under the illusion that a public company – with all their investor expectations and oversight would need to have a predictable and accountable course of execution. I was wrong!

    “Why would I force my PMs to tell me what they’re going to do in six months when they’re they’re going to learn something tomorrow that might dramatically change their outlook on what they should do.”

    Instead, the company works from a very startup based ethos that 90 day OKRs map well from company strategy to sprint level execution and feature delivery.

    OKRs

    For the uninitiated, OKRs stand for Objectives and Key Results, you can read more here, here and here.

    “when I joined, the company was very focused on what initiative they were going to deliver, what feature they were going to deliver without kind of just answering those more fundamental Objective questions.”

    So the insight here is that Product Teams can always busy, but they need to have their efforts directed in harmony with the companies goals. The other insight that supports the “No Roadmap” principle is:

    • a Product Team can run an experiment
    • if that experiment is underperforming in achieving an OKR, then it can be abandoned.
    • another experiment can then be run with the intention meeting the OKR.

    This makes huge sense as a sanity check on any sprint scheduling process. Its not important to be busy – its important to get jobs done related to OKRs.

    Product Council

    The diagram above (sorry, no social distancing!) shows the ZIP approach to quarterly planning for the 12 durable Product Teams. Using the aforementioned OKRs, Product Teams present to a “Product Council” features from their backlog. The goal is to “lock-in” the sprints and features for 90 days that map directly to OKRs, Product Strategy and ultimately Company Strategy.

    Its an intelligent structure with feedback loops from Strategy to steering (Product Council) to prioritisation (Product Triad) to execution (Product teams of engineers, designers, QA etc).

    Below is the 10min snippet that delves into these topics – Patrick is crystal clear with nuggets that all teams can benefit from hearing.

    (sorry about some of the sync problems – WFH is really pushing neighbourhood network limits at times!)

    Transcript

    David Jones 25:09
    this probably speaks to a challenge too which is that a lot of people who might have been businessanalysts or project managers now see that the Holy Grail could be a Product role because product is now, you know, what, a decade ago, a product manager with somebody figured out the wording on the back of the Cornflakes packet. “Here’s where you call for consumer care”. Now, the product role is really a central part of the success with a customer and a real pivotal thing. So, a lot of people are running into that, but it sounds like what you’re saying is they’re bringing some baggage from their previous roles. Whereas really, they need to strip back and actually say, “What does the product really look like?” Is that what your are saying?

    Patrick Collins 25:53
    yeah, I’ve definitely noticed that with some of my team members at Zip, I think when I explained what a great product team looks like. I am fortunate, and the reason I joined Zip is that is already is a pretty strong product culture and it’s been set up pretty well. And I don’t feel like I’m trying to change something from a from a different kind of culture. But I definitely do notice, like, for instance, I’ve noticed that some PMS, talk to me often about why they need a BA on the team, or why they need an analyst dedicated or why they need a Product Marketer dedicated to them. And I resist, and we do end up in some pretty heated debates on it. But, I guess simplistically, I would say, I talked about that “product triad concept” of of an engineering lead, and a product manager and a designer. And I just haven’t seen any problems with that triad can’t solve. And so the idea that you would need to get dedicated folks from different roles to do that. To me I tend to use fairly harsh words like “I just think you’re doing your job”

    Patrick Collins 27:06
    Between those three people if you can’t figure that out, if you need an analyst to kind of understand the requirements of your platform I don’t know what you’re doing as a PM and tech-lead so and so yeah, I’ve had some I’ve had to kind of I think challenge some of that thinking for sure. That doesn’t mean that a strong BA can’t transition into a good PM role or a good project manager can’t transition into into being strong PM as well. Is there some baggage there?…..Potentially because I think in a modern product concept, product team approach that the shuffling of duties around between the team lead and the product manager is a little unconventional to the way you might see a traditional project team work.

    David Jones 28:01
    I think you said 25 people in product, 150 or so in engineering? So that’s one:seven-ish, I guess. Is that right? And anyway? Yeah. And then durable teams. So given that the product team has probably got a bunch of sort of like a management layer in there, does that mean you’ve got like 15 durable teams operating at the same time?

    Patrick Collins 28:28
    Yeah, it’s about right now about 12 durable teams. And in my product team is designers and UX. So there was some double up in the counting there. I think maybe give or take 15 dedicated Pac Managers. We’re all different of all different seniority levels and all different capabilities and skill sets as well. All product managers are not created equal.

    David Jones 28:52
    Well, as Monty Python used to say, That’s “bloody luxury”. You know, how do you how do you translate that back to like a smaller, smaller startup that’s perhaps got some product market fit. And this still sort of being dragged in many different directions. How would you give in your Fifth Finger experience? How would you think about durability and stuff like that; “tribes” or whatever. When you really when you really are wearing 40 different hats, you know,

    Patrick Collins 29:22
    I think it scales perfectly well, I think the idea of having…..when you think about a startup, normally you’ve got a hacker, a hustler and a designer, right? So, that’s not unconventional way to start a startup and sometimes the designer will be a freelancer or sometimes it’s (the founders are) a hacker and they’ve kind of got to go recruit someone to do this, the sales side. I think that is a very common organizing unit for a smaller business and it does scale really well. They just kind of keep splitting the problem down and scaling that up into a bigger company.

    David Jones 30:02
    It’s the surface area. So what happens is a start up, you’re supposed to have a smaller surface area, you’re kind of working on that nugget that really matters. And then you start to bolt on different things. So again, it comes back to focus. It’s like, if you’re gonna build this other project it’s gonna divide and conquer you. Right? Yeah. Okay. It’s always dangerous to work – So from a product perspective, particularly as a small team, considering new features, or considering new product lines is like one of the most dangerous things you can do.

    Patrick Collins 30:38
    It’s a challenge for sure. If it’s not if there’s not a strong overlap with either the customers that you’re meeting on a daily basis and the problems that they face. It’s a real danger to introduce a new problem into an existing team.

    David Jones 30:52
    Yeah. Okay, good. All right. So you’ve got you’ve got your teams. We had a chat on Sunday. And I said, What are your roadmaps look like? And you had a response…..

    Patrick Collins 31:06
    I said, “we don’t have roadmaps”, and you were shocked. Right?

    David Jones 31:11
    I was delighted. Go, yeah. Give us give us the good oil here.

    Patrick Collins 31:22
    I guess it goes back to that startup, like, if you were if you were four people in a room in a startup, and you were running really hot of a problem, would you build a roadmap for what you were doing? Wouldn’t right? You’d want to know really clearly what objectives you’re trying to resolve, what objectives you’re trying to accomplish and what problem you’re trying to solve. You’d be laser focused on trying to solve them. And you’d organize around that and the only time you might make a roadmap as if a VC asks you “what’s the plan ahead” and so you might go cobble one together on an ad hoc basis and do it. And so I see a scaled product organization no different. Why? Why would I force my PMs to tell me what they’re going to do in six months when they’re they’re going to learn something tomorrow that might dramatically change their outlook on what they should do. So, it’s an anathema to the idea that a product – so I guess my organizing principles, we just went through, we do quarterly product planning cycle, all 12 of those product teams presented yesterday to a group that I’ve organized called our Product Council and we predominantly focused around their objectives and key results (OKRs). So we had a lot of time debating what what this team should be trying to solve. I’m really proud to have gotten to that point over the course of a couple quarters because when I joined, the company was very focused on what initiative they were going to deliver, what feature they were going to deliver without kind of just answering those more fundamental Objective questions. And so, by focusing on OKRs (Objectives and Key Results), we’ve kind of forced the team to really understand what they want to get done by the end of June. And we forced the executives in the Product Council to align around that as well. And there was listed set of initiatives that they’d gone and done sizing to understand how they might deliver that there was a lot of research that had gone into it from a customer perspective as well about why that was good problem to solve. And each of those teams know that if they go to deliver a feature and they’re working on that feature, and as they test it with customers, they might only be halfway through design and development and testing the customers and realize it’s just not going to get them there. It’s not going to get them to their OKR. Then they have free autonomy to abandon that feature and move to the next most promising feature. And so it’s through that lens of crafting and curating a backlog of things that they’re going to work on and testing all the time to try to hit these objectives. That means that a roadmap feels fairly pointless. That doesn’t mean that I don’t have people in the company asking for it. And there have been some people asked for a roadmap and there certainly are features that our partners and customers need deadlines for to be able to integrate to. There are times where deadlines are critically important. But yeah, OKRs and backlogs is our primary organizing mechanism rather than roadmap.

    Patrick Collins 35:22
    And it is guided by a company strategy as well. So both the company strategy, there’s a product strategy. So there is other high level objectives and inputs that we’re considering. That helps guide the initiatives and the objectives that they’re trying to accomplish. I mentioned earlier that our mission is to become an everyday payments provider. That is an overarching “north-star” for us that does provide a pretty strong filter for the things that we consider to be valuable and important.