Contextual

Blog

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

  • Tutorial: Recreating Pastebin’s simple tip

    We sometimes get questions for more content about using the product and some quick start tutorials.

    This simple example shows how you can combine an images and text content into a simple tip. Its based on a simple, no nonsense example from one of the web’s busiest sites: Pastebin and its got a clear Call-to-Action presented in a playful way.

    The tutorial is interesting because it shows what Contextual can and can’t do with a few elements.

    Naturally we could have created an exact copy using our HTML templates, but the goal here was speed and simplicity rather than technique.

    I realized afterwards, I could have the tutorial use the basic blank tip template and built up from there – so that might have been even faster!

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

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