Category: Product Manager

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

  • WFH: Will Design Sprints fail with remote teams?

    WFH: Will Design Sprints fail with remote teams?

    Product Teams are probably one of the least disrupted jobs that are affected by a work-from-home world. But Design Sprints are predicated that you clear your calendar and get everyone in a big room to grind on the creation of something new and substantial or solve a sticky problem.

    This is not just small things about button placement but parts of your solution that has multiple stakeholders and plenty of perspectives.

    I spent an hour with Tim Paciolla who is Lead Designer on Atlassian ServiceDesk to cover the approach and tools to keep Product Teams moving in this important practice.

    For the uninitiated, Design Sprints emerged from Google Ventures and largely have been kick-started by a book by Jake Knapp. You can refer an earlier post and fireside I did with Elliot Ng from Google.


    sprint-book-jake-knapp

    Focus, Challenges & Personalities

    Can you still run Design Sprints in a Work-from-home world?

    Tim claims that absolutely you can still run Design Sprints, but it’s critical the Facilitator needs to have their role confirmed, stakeholder support and ways to keep people focussed.

    1. Make sure roles and responsibilities are understood.
    2. Use ice-breakers and show vulnerability early to demonstrate the fears and errors are OK.
    3. Manage extroverts to leave enough oxygen in the room.
    4. Keep the allotted time discipline in place (we’ll cover compromises in another post)
    5. Make sure you have tools that support remote.
    6. Manage the heads-down time to make sure people stay focussed.

    There is a couple of golden points here:

    Firstly: the facilitator has to work harder. This person is not necessarily a designer or a Product Manager – she could be the executive stakeholders delegate or someone who leads a particular function, for example Customer Success or Billing.

    Second: there are real-risks that during the “heads-down” time that people will lose focus. Its a myth that you are all working together for the 4 or 5 days – there are large periods where the team is working on their particular aspect (sketching, user story, mocks etc) – this is the time where someone may get pulled into a customer support issue, a team problem, some admin or just distraction. 

    This is amplified on the WFH situation – someone may take lunch and stream some Netflix and never return!

    Atlassian’s Playbook

    Atlassian is noted for its supportive cultural initiatives – it’s referenced in various business books for its leadership. One day, I will share an example which is deeply personal but exemplary of what an amazing company it has been from its very early days.

    In the interview Tim lists several tools they use during team formation, project starts and Design Sprints.

    The Playbook is a collection of methods to help teams work together. It has been compiled with heart and open-sourced with generosity for anyone to use.

    Atlassian-Playbook-examples

    Tools for Online

    Surprisingly the solution for remote teams in a Design Sprint is a mix of low-fi and the latest internet tools.

    1. Tim eschews slavish use of online tools when a sketch on paper will do just fine.
    2. Holding the sketch up the camera on a zoom session is good enough to get the point across.
    3. Did someone mention Zoom? Absolutely.
    4. Photo syncing with Dropbox, Google Drive
    5. Shared Whiteboarding tools like Miro and Mural.
    6. The Contextual team are experimenting with Discord to allow free voice chatter to flow during the day. 

    The challenge remains for Facilitators to keep the energy and focus on the team high and not drift off. It appears that no tools other than solid communication can solve that.

    In summary: its truly difficult to keep people focussed on a task but its the Facilitator’s job to use tools and techniques to keep Design Sprints on track.

    Here is few snippets of the session and I’ll upload the full hour as soon as we can process the video.

    Transcript

    David Jones 0:05
    What about now so so here we are, as long as the Wi Fi holds up, we’ll be able to actually all work from home. And, you know, this this kind of like historic thing about design sprints? Is this this kind of like, huddle together and get things done. So is it gonna work? Is it gonna be a complete debacle? You know, am I am I saying that I’m actually here on the design sprint, when really I’m over here, actually, sort of, you know, working on something else or dealing with a customer support request or, or whatever, you know, that they’ve kind of that kind of like in the room accountability you have from like social close social contact is being taken away from us. So can you see it working on no?

    Tim Paciolla 0:46
    Yeah, I mean, yeah, absolutely. I can see it working. I mean, there are there are additional challenges that you have to as again as a facilitator, right as the person that’s sort of leading the team through the week. There are different Things that you’re going to have to pay attention to, right? If I were in a room together as a facilitator, I can very easily say, okay, laptops down phones away, right? Like, I don’t want to see a phone, I don’t want to see a laptop open. And that makes it a little bit more people can still check out. Right, but that makes it a little bit more difficult to check out. Online. I absolutely think I mean, there are companies very successful companies Trello, which is in Atlassian products, you know, they’re almost an entirely remote company. You know, there are others on this, you know, envision I believe is entirely remote automatic is entirely remote. Right. So there are companies out there that are entirely remote, you know, that follows similar processes. So, is it a change absolutely won’t be difficult, of course. But yeah, I think it can absolutely work.

    David Jones 1:46
    And so, if I sort of like just sort of like, go sideways from accountability to personalities, so let’s, let’s say I’m a, you know, I’m a real hardcore coder, and that’s what I do and I tend to look at everything Through the, through the lens of things, and I’ve been asked to join this particular design sprint. And, you know, it’s like, well, for any engineer, it’s like being called into meetings. It’s like a particular form of torture. And so the question is, okay, I’ve got this five day meeting. Am I the right person to be in that group? Tell us a little bit about what personalities you’ve seen? A golden, which, which aren’t so good.

    Tim Paciolla 2:23
    Yeah, I mean, you framed it as an engineer, but really, you know, you can almost use any discipline that question right? Like, I mean, I’ve seen designers that don’t want to be participate in design sprints, right? Like they don’t want to go into a room for five days. They’d rather just sort of sit at their, their, you know, their computer and their monitor and, and work away. The people the personalities that I think are important are people that are somewhat comfortable with being uncomfortable, right? A design sprint can be uncomfortable arrives.

    David Jones 2:52
    Okay?

    Tim Paciolla 2:53
    You know, at times being a bit uncomfortable, you know, or being comfortable with making something hard decisions, hard prioritization decisions, you know, sort of forcing yourself at different stages to sort of pick a direction and sort of stick with it. Right? So if, if you have people that like to, you know, keep all their options open right and have a hard time sort of making a decision. I think that’s a little bit of a challenge. I’ve seen introverts do extremely well in design sprints, right? Again, that’s more about how the design sprint is set up. One of the first things that we do a lot in our workshops or sprints or whenever we’re getting people together are things like icebreakers, right, just to people don’t get people to share a bit of their, of who they are with the rest of the group be a little bit vulnerable. We have an exercise we call hopes and fears exercise, which is meant to sort of expose both what you what you are excited about to get out of the sprint but also what you’re afraid of. Right. Again, that just shows a little bit of the difference. vulnerability and getting people to understand like, you know, concerns that people have. So there’s there’s definitely techniques you can do to get people to sort of, to open up and be involved.

    David Jones 4:11
    Yeah. But so we might just pause there and just sort of like do a shout out for the Atlassian playbook. If people aren’t aware of the Atlassian playbook, it’s basically on the site. There’s a bunch of sort of like human interaction type things and tools that are used for different kinds of things. Things like retrospectives, things like project team formation, like the balancing of a team and talents and stuff like that. But what’s what’s the sort of thing that you use quite commonly.

    Tim Paciolla 4:41
    There’s a couple of things that I think we use, especially as we’re forming new teams, we have a play called the roles and responsibilities play, which is just a really good conversation so that you get people on the same page, you know, earlier I talked about like, in that triad model, knowing who the decision maker is at different points of the Sort of the lifecycle, that roles and responsibilities play really helps draw that out. You know, we also have a play, we call the the DC, which is sort of a decision making framework, which also helps, right, it really does a nice job of articulating who the driver of the decision is, but who the approver The decision is, who are contributors and who are just informed. That’s what the DA ci stands for. Right. And again, it’s it’s all about being clear around expectations of people’s roles and the input that we’re looking for. Hmm,

    David Jones 5:33
    okay. Yeah, so all of those things there in the Atlassian, playbook.

    Tim Paciolla 5:37
    Correct. They’re all up on atlassian.com. And if you look for playbook, they’ll all be there.

    David Jones 5:42
    Okay. All right. Cool. All right. And so then just kind of like around personalities again. Are you saying that roles and responsibilities kind of like help moderate the extroverts?

    Tim Paciolla 5:54
    Yeah, so absolutely. I mean, we don’t typically do like a roles and responsibilities in a sprint. We He would do that more just like at the beginning of a team formation or when new members joined. But one of the things that we do do in Sprint’s is we sort of set the expectations of the room. Again, this is the role of the facilitator, right, like one of the keys, one of the phrases I hear a lot at Atlassian is the phrase, you know, leaving air in the room for others to speak, right? Like, if you think about the person that just speaks and speaks and speaks and speaks like, it’s just a good sort of gentle reminder for that person to kind of take a step back, let others speak, but others, you know, and that’s also modeled by the facilitator as well, like you can do you can make sure that you’re specifically calling people not to put them on the spot, but making sure that everyone’s voice you know, has had a chance to be heard. I think it’s, it’s, it’s really less about the tool and more about the facilitator. Right. I think the the biggest thing that we have to think about is is the structure of the day, right? You know, you know, one of the big things around the screen is sort of the alone time right like everyone thinks it’s it’s actually a you know that you’re you’re collaborating for eight hours a day but a large part of a lot of Sprint’s are just, you know, sort of heads downtime and people sort of thinking and working on their own. So how do you how do you keep not really keep track of but how do you monitor if you will, that time and make sure that that time is being well spent? Right. I think that might be one of the bigger challenges when you think about how a sprint is typically run.

    David Jones 7:36
    Right? Okay. Have you have you used a tool called Miro?

    Tim Paciolla 7:41
    I think it used to be called “real time board” at one time.

    Unknown Speaker 7:45
    It’s now called Miro. Oh, and we use Mural as well. Yeah. Yeah. So yeah,

    David Jones 7:50
    I just found Miro really interesting from a sort of like mind mapping type thing. They have many different use cases. I thought that was good. How would people in a remote world how would People present results of sketches back when they just basically sketch it and throw it on the screen. You know, what are the what have you seen being used? Now,

    Tim Paciolla 8:08
    we take a lot of pictures, you hold a lot of things up to you know, you just hold things up to the camera, you know, things like that. There’s certainly ways around that, you know, with the way certain photo apps can sync now it actually, you know, so I’m on an Android phone, I’ve sort of bought into the Google ecosystem. So as soon as I you know, draw something, I can take a picture of it, it pretty much syncs to my, my cloud based service fairly quickly. And then I can just throw that into a mural board or amuro board or something like that. So again, it adds a little bit of complexity to the process, but but not something that that I think is, you know, it doesn’t make it so difficult that we can’t still, you know, run those types of sessions.

    David Jones 9:02
    Sorry, just what about tools like, like figma? Or an envision? What What about those tools to sort of at least go sort of halfway there in terms of if I press here, and that takes me to this screen or something like that.

    Tim Paciolla 9:15
    So again, I don’t know, maybe this is the second or maybe third spicy thing potentially. I actually I actually don’t even want. So we use figma at Atlassian. Now, we used to use sketch we have libraries, pretty extensive libraries built around our design system, where it’s actually super easy for people to to start throwing together screens based off of the design system, right and the components, because everything’s just sort of at your fingertips in figma or in sketch. I actually don’t even want to do that right because I think then you start to worry too much about like the the pixels nature of it right or the component itself and you’re not really staying at that right level around the idea and the concept and the director That we’re headed. The conversation immediately changes as soon as you put something, you know, like a high fidelity screen in front of somebody, right? The like, there’s Yeah, there’s now the tension between like, are we talking about the idea? We’re talking about the execution? And you want to keep that conversation at the idea?

    David Jones 10:20
    Yep, got it. Yeah. So that’s, that’s why Balsamiq was so fashionable. You know what it was a decade ago, I guess. am I showing my age?

    Unknown Speaker 10:30
    No, I’ve used Balsamiq so it’s all good. I think we’re right there. I think the funny thing is, is that like, we actually do things for even when we do screens, we’ll use like Comic Sans, right? Or we’ll use you know, something that that, you know, makes sure that people understand this is not final. Right. It also brings a little levity because as soon as somebody sees a screen with Comic Sans in it, they’re like, what’s that? But, ya know, it’s, it’s definitely important to make sure that you’re keeping that conversation at the right level. What the right time? Right? There’s there’s a time and place to have those conversations about the final execution. But a design sprint is not, it’s not the place in my mind.

    David Jones 11:07
    So first questions from Philippe share, err, please ask him about digital tools to conduct a design sprint online. So I think we’ve kind of covered that. Is there anything else you wanted to say about tools?

    Tim Paciolla 11:22
    I mean, it depends on how like, if you are definitely getting into a situation or a period where everyone is sort of working remote, there are better ways to facilitate the sort of sketching things. You can have cameras that you can buy that it basically, you know, points down onto your desktop and will live stream what you’re drawing, right. So there are things there are models like that, that you can go to if you want to get sort of more involved, but the ones that we’ve talked about mural, Miro. They’re all sorts of good solutions around having a collaboration space that you know, you can sort of the the digital stickies, the digital whiteboards, zoom, obviously, you know would would be a or something like zoom Skype, whatever would be a requirement. You know, it’s interesting, I think most of the digital whiteboards also have voting and that type of stuff. So I’m just trying to think through all the like the hands on processes from a sprint. So I think most of the tools are probably fairly well suited for it.

    David Jones 12:29
    Yeah, one of the one of the things we’ve been doing is, this is this is our team is we’ve been using Discord, which is the gaming communications thing for where you can basically all talk at the same time and hear each other. So we’re doing using that more to try and basically have a much more connected sense in the work from home situation. So you know, I think sometimes we’re even talking more than we ever did when we’re at work sitting around a table Yeah, so that’s that’s just an interesting, interesting sort of test for us. You know, it’s still a little bit quiet but it does allow us to just kind of shoot the shit for for a while on different things or, you know, talk about what you had for lunch or anything like that.

  • Covid-19 and Contextual

    You’ve already been flooded with many company statements about the current pandemic conditions – so we’ll keep this simple.

    First and foremost, we wish everyone, their teams and their families the best possible outcome. We are quickly learning that no precaution is too conservative – so take care!

    During this crisis our commitment to you is to help you onboard and guide users without gouging your pockets – we remain significantly more affordable than others.

    Yes we are prudent with our expenditure – we all must be:

    1. we are not burning big cash to market (shout about) ourselves.
    2. we won’t irresponsibly grow our team without sustainable revenues from customers.

    3. we see plenty of opportunities to improve our product features and quality.

    Sorry – no fancy promotions – just a solid team with a solid product – here to help you and your users.

  • “Recipes” and “Jobs to be done” (JTBD)

    In another snippet from the interview with Matt from Bonjoro we discuss why “Jobs to be done” (JTBD) is so important to them.

    Bonjoro have a large inbound funnel of different triallers types – because their platform is horizontally applicable. However, they are optimizing for SaaS customers in Sales and Customer Service use-cases – they are high value and  high conversion probability. He discusses the conundrum here.

    It seems brutal but if Bonjoro try to craft onboarding for all users they will lose their valuable SaaS customers by diluting the flow.

    JTBD works, Personas don’t

    Conversely Bonjoro don’t find “personas” as terribly useful. A persona is great in marketing because you can speak to their needs – higher up the funnel.

    When it comes to Onboarding and Activation however, the user’s goals or “Jobs to be done” need to be displayed and aligned with the product goals.

    The perfect example of this is Bonjoro have a playbook of “recipes” for customers – this is effectively a cookbook of “Jobs to be done” for different customers. Just like Monday, these recipes are then baked into the product – they allow a user to get a Job Done quickly because they already learned about it in the marketing. “Show me, don’t tell me”.

    bonjoro-cares-for-customers
    Bonjoro is about customer care – at scale

    Product-led or Brand-led?

    I quizzed Matt on Product-led and his response was surprisingly insightful – for him its more about “Brand”.

    “Brand-led” is more his focus rather than Product-led because Bonjoro’s strong Design and UX DNA means they do “Product-led” things by default.

    I was shocked to hear him assert that the Bonjoro brand is of equivalent value to the actual functionality of the product.  Matt says that “Brand” is more important than startups realize.

    His view seems to be working, they hold a leadership positon in the “Personalization at scale” space? Their NPS is a fabulous 71.

    They are well respected, this is a very Product-led outcome but also their Brand is very, very fun, caring and recognizable.

    Stop “growth-hacking”

    Another cracker quote from the conversation was Matt’s plea to Stop “growth hacking”.

    He thinks most people arn’t skilled enough to do it, so ultimately get distracted by it.

    Bonjoro instead have a clear mission of personalizing and caring for customer. Matt says: “This has been lost, and it always used to be a way to compete and it’s got harder to compete “

    Take a listen to this and other posts with Matt, its informative and enjoyable.

    Conversation Transcript

    Matthew from Bonjoro 0:02
    longer form content. And so like, kind of white papers, but ones that you can take and “implant”.

    Matthew from Bonjoro 0:09
    So we’ve done this whole piece on our “Video files playbook” where we say: “use video, if you’re e-commerce or fashion, do this”, you know, “if you’re if you’re this, do this”. Yeah.

    Matthew from Bonjoro 0:20
    That has worked extremely well for us. And this goes back to a bit of the part around educating the market as well as trying to sell to it. Education has really worked well for us, and it has to be how we play out…..It’s still early days.

    David Jones 0:36
    Does that does that really worked because it’s a recipe based approach for those different sectors? Did you give them recipes?

    Matthew from Bonjoro 0:43
    Yeah, recipes are awesome.

    David Jones 0:45
    And the recipes are reflected in the product as well, too.

    Matthew from Bonjoro 0:48
    Yeah, exactly. Yeah.

    David Jones 0:54
    Has “Jobs to be done” been a recurring thing for you. It’s something that we refer to all the time internally. So, you know, is that a mainstay of how you view things?

    Matthew from Bonjoro 1:07
    Yeah, I think one of the hardest things is trying to get the whole team across (JTBD), the deep understanding of what “jobs to be done” is. It’s obviously way, way easier. It’s a way easier to categorize customers, by channel by industry by job title.

    David Jones 1:21
    Persona. The HubSpot kind of way: “this is, this is Mary, she’s 28. She’s a grad, she’s got a mortgage”. And, she wants to she wants to get somebody over the line because her KPIs are based around signups or “conversion to pay”. Do you still use that already? Or do you focus more on the job rather than the persona?

    Matthew from Bonjoro 1:47
    So the answer is we have to focus on “jobs to be done”, because the persona doesn’t work for us. So I think again, given the broad range where we operate, you know, and SaaS are one of our best customer bases but it’s still 20% of 100%. We have kind of like a lot of users who are not in that area. So but interestingly, you see more and more SMEs, poaching things from the SaaS mindset.

    Matthew from Bonjoro 2:17
    You see more e-commerce approach things from a SaaS mindset. So the mindset is more important than the company and the industry and potentially their business model. Everyone’s got leads coming in, are they approaching and going, what how many do we convert? What’s the lifetime value? What’s ARPU? What’s the CAC? This attitude is what works for us. So “what are the jobs that fulfill those points”?

    Matthew from Bonjoro 2:39
    Personas, we struggle with, and, you know, I just don’t do them anymore.

    David Jones 2:48
    Right, so you really are pinning it to the JTBD.

    David Jones 2:53
    What about product-led? In the last couple of posts I’ve talked about product-led type stuff. Have you glommed on to that particular bandwagon or do you see it as too high-level or common sense? What’s your thoughts?

    Matthew from Bonjoro 3:09
    Yeah, so I’d say it’s probably more common sense. Again: design first product first. It’s bit how we think anyway.

    Matthew from Bonjoro 3:22
    However, I think we’re building two things here. We’re building a product and we’re building a brand. And if you were to take the dollar value of those two things, I would say they’re probably about equal.

    David Jones 3:37
    right.

    Matthew from Bonjoro 3:39
    What I mean is given the stage of the company, our brand has a very good position in the marketplace and where we operate is very well known. We have like NPS rating is I think is 72. We’re really well respected and we’re building more of a name for ourselves as one of the leaders in this area of “personalization at scale”. And that gives you a lot of power to start to educate and to be a front runner.

    Matthew from Bonjoro 4:07
    It’s really important and I think brand…..we are quite “brand-led” and the fact that you’re doing a good thing here, we’re like, “Look, spend more time with customers”. It’s a good thing.

    Matthew from Bonjoro 4:20
    “Stop trying growth hack”, this kind of stuff works. It’s really nice positioning as well: people are kind of bouncing back to this (personalization), but more so it’s quite good timing. I think your product-led for sure. I think “brand” is a lot more important than maybe a lot of startups think what brand is.

    David Jones 4:36
    Thats funny, which was “stop trying to growth-hack”. And it goes back to that statement earlier that you had about: “automate processes, not people or not customers”, and that seemed to be tied into this kind of Northstar of making customer relationships personal but not getting bogged down in the weeds or crippling your scale. When you do that.

    Matthew from Bonjoro 4:59
    This is probably where a lot of people get crippled by the “growth hack” thing. Where everyone’s trying to hack their way and do these things. And a lot of people (to be honest) don’t have the experience to kind of do them or pull them off or what works for one company will not work for you.

    Matthew from Bonjoro 5:15
    So I think this idea of also having the recipes…the stuff you use in your business, the “plug and play” and they work.

    Matthew from Bonjoro 5:22
    You look back was always like “build a marketing list”, you know, and it wasn’t that hard to do. And so if you can find out what these pieces are, people can essentially step in, “plug and play”. And when you when you rely on the team, the culture of relationships, nothing greater than that way. Like everyone could do that. Well, every (company/team) culture around that base can do that. You know, you will still get stars, you know. “Everyone can do Twitter, not everyone’s good on Twitter” and “not everyone should be allowed to Twitter”.

    Matthew from Bonjoro 5:51
    I think we’ll see a same thing here – even if everyone started using this (personalisation at scale), you still have people who “stand above” and they “stand above” because the team, relationship show that “they do care”.

    Matthew from Bonjoro 6:00
    So how do you give them easy ways to show that online?

    Matthew from Bonjoro 6:04
    This has been lost, and it always used to be a way to compete and it’s got harder to compete – face to face. So how do you bring that back and how do you tell you when do and how you again, make it simple, I think I think that’s kind of the key.

  • Remote working Product Teams

    Remote working Product Teams

    I’m sitting in an airport departure lounge to head home – SaaStr 2020 was cancelled on strong recommendation of Santa Clara county. Others in SF have also been cancelled. There is a guy a few rows behind me coughing and sneezing – not into his sleeve, not covering his mouth.

    Apparently oblivious to Covid-19 and oblivious that others are doing their best to minimize risk to themselves and other. He likely to be on my flight – oh….the…joy. 

    Meanwhile “Zoom” Video Communications Inc (“ZM”) is up 33.44% last 30 days and Slack Technologies Inc (“WORK”) is up 22.68%.

    Clearly investors comprehend that technologies that help reduce travel, reduce the potential for infection are a great bet on the future.

    Its now the norm that Product teams to be more distributed instead of centralized. Some companies like Gitlab are born remote.

    With COVID-19, many companies are implementing work-from-home as a preventative measure and also self-quarantine.

    “GitLab is the world’s largest all-remote company with team members located in more than 65 countries around the world.”

    Even large product companies like Atlassian have embraced remote work as a priority. “We think that by doing remote we can tap into a whole new workforce that our competitors aren’t tapping into,” Atlassian Co-CEO Scott Farquhar.

    Great remote tools are emerging such as whiteboard tools Miro and teams going beyond Slack to use the voice “hoot-and-holler” of Twitch.

    But the big deal is changing the culture. Engineers are notoriously introverted and I’ve spent 15+ years trying to get engineers to talk to each other even when they sit a few feet apart!

    I asked Bonjoro’s CEO Matt Barnett about his team structure and how they handle the remote culture. 

    The no-surprise summary: “Communication is everything”. But here are a few specific tips.

    Key Point 1: Drop a 2 minute zoom call to somebody to resolve an issue that might otherwise take hours or days. Why?

    1. Timezones mean that chat/text messages and emails are unresolved for hours or days.
    2. People misinterpret the tone of chat or emails.
    3. If you must use text, then don’t use capitals (SHOUTing) and choose the best emoji for the purpose.
    4. The huge benefit comes with conflict management.

    Key Point 2: Bring the team together once a year. The team has to “break-bread” and spend time together in the same physical space.

    Conversation Transcript

    Bonjoro Team Locations

    David Jones 0:01
    What size is the team at the moment?

    Matthew from Bonjoro 0:03
    So we’re 15 we’re in Sydney. So Australia, Manila, South Africa, London, Colorado and Poland.

    David Jones 0:13
    So you got you got time zones and language covered.

    Matthew from Bonjoro 0:17
    That’s our team. I’m trying to look at if it’s a blessing or a curse. (laughs)

    Remote Team Lessons

    David Jones 0:22
    is there anything any lessons you’ve had in terms of working remotely? or working across time zones?

    Matthew from Bonjoro 0:29
    Communication is everything. 100% and by “communication” I did not mean paragraphs on Slack. Yeah. I think this is a hard one. Like the best thing we’ve learned is is culturally shift to a stage where you can drop a two minute zoom, call somebody to ask one quick question, two minutes, and then you’re back to work as if you were in the office, rather than going into slack debates that go on for hours

    Remote team conflict resolution

    Matthew from Bonjoro 0:55
    Obviously harder in different time zones when people are asleep. But I think the number one thing it resolves, if you can get to a good stage of it is conflict management. When you have conflict, which will definitely have, don’t get sucked into a rabbit hole, because if people are asleep you are awake it like it compound things. This will be read for the worst rather than the best way when they are written

    David Jones 1:17
    Slack chat and email just tend to sort of amplify the paranoia side if you don’t pick the right emoji 🙂

    Matthew from Bonjoro 1:26
    (laughs)

    1. Get the right emoji
    2. Don’t use CAPITALS.
    3. If build a remote team, bring them together at least once a year.

    If can’t can’t do it all at once, to bring out half a team one time and then take the other half to them maybe another time. Because your team has to break bread together. And when you can do that, again, when it gets back to communication and conflict and daily work. You’ll be better placed you’ll know each other better. You respect each other more and you’ll be able to solve those problems a bit easier.

    David Jones 1:56
    Yeah. Good stuff. Thank you, sir. Really appreciate it.