Ways of Working: Navigating Growth & Change while Scaling

Jeff Chow at UXDX USA. Video: https://www.youtube.com/watch?v=3vDVmk97Clg

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

From InVision to Miro

[00:00:00] Host: Hey everybody. So, quick show of hands: who uses Miro here? All right, love it. That's a good sign. So we're going to be digging into not so much Miro the product, but how the teams are building Miro. But before I jump into Miro, I want to talk a little bit about you, because you have incredible experience. Prior to Miro, you were both the CPO and then the CEO of InVision. Can you talk to us about that experience?

[00:00:30] Jeff: Yeah. And I think a lot of people here have probably gone through the history of InVision, so maybe let's talk about the elephant in the room first. Love the nervous giggles too, by the way. Fantastic. So look, I think probably most of us here have built a lot of our careers using InVision. It's brought a lot of designers to truly have a seat at the table, which is fantastic. And even the process of design thinking, it's been at the forefront of that. So an amazing platform. But it did get disrupted, full stop. It got disrupted by Figma. Ultimately, InVision and Sketch were a combo tool, and then Figma came around the corner, and it's like, what if we mashed that all together, put it on the web, made it really collaborative? And then what are you going to do? Checkmate, right?

[00:01:28] And so, look, we did our best to try to respond. I will say the hot take market is pretty profound, around the hot takes of what we could have done better. So feel free to go and find your favorite Medium post or LinkedIn post. But I joined as CPO to spearhead, well, we had multiple products, and one of the products that was growing really fast was Freehand. Freehand is a visual collaboration tool, very similar to Miro, and it was growing very fast, and even when customers were switching to Figma, they were starting to use Freehand wall-to-wall. So my job as CPO was to say, okay, how do you navigate the change management of all these organizations, our internal organization too, to focus on building this forward? So that was my job. And then over time I took over the reins as CEO from the founder, Clark, an amazing visionary entrepreneur, and we brought it together.

[00:02:30] So how we landed at Miro is that our passion has always been: how do you unlock cross-functional teams? How do cross-functional teams work better together? And we're seeing that that is ground zero of business impact. And so that passion, what we were doing with Freehand, was also a shared passion with Miro. Andrey, the CEO of Miro, and I had a lot of great conversations, and therefore, happily, the team at InVision mostly joined Miro, and we're still doing some amazing things together.

[00:03:01] Host: Awesome. It sounds like a bit of a roller coaster ride over a couple of years.

[00:03:06] Jeff: Yeah, it was an emotional journey.

Why the CPTO role

[00:03:10] Host: Okay, so let's talk about Miro, then. Your title is CPTO, and we're going to get into what that actually means in a second. But I just want to talk first about this: you were the CPO of InVision, became the CEO, as you said you took over the reins, and now you've gone into a CPTO role. So what has led you there? Where is your passion? Do you love the product? Did you like the CEO role? Where do you see yourself? Rory just said you went down a tick. What was that about?

[00:03:42] Jeff: Unintentional. No, no, no. Look, I think ultimately what galvanizes me is building amazing products to make a really massive impact. And what I'm energized about, and it's very meta, is changing ways of working, delivering that impact, activating organizations to deliver and build amazing things. And sometimes a CEO is the leader that's going to do that, and sometimes, in Miro's case, being the CPTO really fills my bucket, and it makes a lot of sense. And again, I would say that Miro probably has the best-in-class leadership team, and there's nothing more fulfilling than having partners in crime working together. So it's been a joy.

[00:04:28] Host: Excellent. And I guess, because when I first saw CPTO I didn't actually understand what it meant, can you explain? Because that will give context to how, as you said, you're enabling the team. What is a CPTO role?

[00:04:42] Jeff: Chief Product and Technology Officer. And every time I say it, I too kind of go up: "I'm Chief Product and Technology Officer." But no, I think, look, there's a couple of things. One is, at the end of the day, engineering, product and design have to work really well together as a trio to deliver great things. And how do you actually build that culture, that foundation, and actually solve things? I think there is a trend in the market where there's starting to be this kind of common construct. Oftentimes you find engineering might have their shadow projects, and then design might have their shadow projects, and product acts like they're Steve Jobs and think they can do anything. And so a lot of my job is to say, no, we are one team, we're pulling things together.

[00:05:44] I will say, especially for designers in the house, it's really offensive that it's not CPD. But that's even worse, or even designers who are under CPOs. And so I think a lot of what I'm trying to do is say, actually, no, it really is three common seats at the table, and you need to do that to make the magic happen.

[00:06:04] Host: Excellent. And I guess one of the challenges, particularly as you go up in your career: you have that background of chief product officer. Was technology a challenge, or is that something that you've always been across? When you took on that remit as well, was that difficult?

[00:06:20] Jeff: Yeah, no. I think I am technical enough to do this, and I was a CTO for one of the companies that I founded. So enough to be dangerous, is the idea. But again, I do think it is about building trust with every discipline's craft, to empathize and understand what challenges they go through, what their isms are. Engineering is usually about tech debt, and always having to deliver impact but never being able to do it to scale, and they're on the hook with the buzzer that keeps them up at night, or they're the first ones to blame when there is an outage or whatnot. Designers know that they have to do things, and they really have to think about their craft and the experience and information architecture, and it's not something that you can just whip up really quickly. So how do they have the safe space? And then product is always on the front line of trying to make impact, and being the ones pulling everything together, and it's very difficult. So having that level of empathy is a very important aspect.

Co-creating strategy and breaking it into solvable chunks

[00:07:23] Host: Awesome. I'm going to jump into a bit of the content now, not so much your background, but more into how you're managing. And if we can flick on to the question slide, because if people want to submit some questions as well, please do, and we'll get to your questions as well. And Rory, how are we sitting? Are we being casual? I don't know, it looks a little too casual. Now I'm thinking about my posture. Your posture is fantastic. Great.

[00:07:54] So, chief product officer: one thing I always think of is you're ultimately accountable for the success of the product. It comes to you, as well as technology. But how do you balance that? Because you have that accountability, but you also want, and it's a big thing that we've talked about throughout this conference, to empower teams, because you want that innovation coming from the bottom up, the groundswell. So how do you personally, at Miro, balance that? Okay, you're accountable, so you want your ideas implemented, but also you don't want to stifle the innovation.

[00:08:26] Jeff: Yeah. Ultimately, this type of construct, sometimes people call it top-down, bottom-up, sometimes people call it other things, I find it just a false narrative. We are one team that's working together to solve problems. My job is to break it down into solvable chunks, and galvanize an organization to solve those problems. And what I do find in a lot of organizations is that people tend to feel like they're a meritocracy, and their organizations are starting to build things, and they're like, "My thing is the most important thing for the organization." I just find that's a failure in leadership to get the overall strategy cascading all the way through the organization.

[00:09:17] And so the way I do it is a lot of rinse and repeat: continuous improvement on the strategy, continuous improvement on the delivery. When I create a product strategy, it is co-created. I'll lay the scaffolding, I'll do the first version, I'll send it out using Miro with a talk track, and I'll share it with people. And ultimately I try to get my leaders activated, I try to get the organization activated. I will tell you that the comment bombs in my Miro boards are insane, but it's great, because people feel like they're part of the solution, and they understand innately what the problems to solve are. And that's a really important aspect that manifests in many different operational ways. When I first joined Miro, that was exactly what I did: here's the product strategy, here's the direction, what do you guys think?

[00:10:12] Host: And can we jump into that? Because it's fantastic, but what I often find is, that's great, but how did it work in practice? Are you just giving platitudes, "Oh, I opened it up, and then everybody agreed with me because I'm the senior leader"? Or did you actually get people taking ownership?

[00:10:29] Jeff: Yeah, no, I think for sure people were taking ownership. And maybe that's a great testament to Miro's culture: boy, was there radical candor. So it was a really good one. But look, I think a lot of our job as leaders is to go out and seek to understand, too. The dynamics of a room are really important. If I'm presenting something in a large room, maybe the most introverted person isn't going to speak up. Even if I'm like, "I really want your feedback, anyone have any questions?", they're not going to speak up. So it's finding those moments. I find asynchronous collaboration is a great one, where you'll get some people to share more viscerally than if it were in a room where it's a little bit more theatrical. So I think there are a lot of techniques. The tool belt is pretty vast in terms of how you get that feedback. But for me it's to truly get the feedback, and I can tell when I'm not getting it. I can tell when it's like, "Okay, leader."

[00:11:32] But ultimately, breaking it down into solvable chunks, activating my product leaders and EPD leaders to then take their problem to solve, workshopping with their teams. It is like fractals. My job is no different than the product leader's job next down, and the next down. Everyone's doing the same motion, which is strategy, solvable chunks, communicating to their team, "How are you solving that?", but not being prescriptive.

Structuring 900 people: streams, teams and trios

[00:11:55] Host: Excellent. I'd like to jump into probably a bit of specifics, because you mentioned that fractal structure. I'd love to get an understanding. You have nearly 900 people across engineering, product and design. How do you structure that? How do you get that amount of people aligned, to make sure that they're going in the right place? Can you explain a bit about how you're structured, and how your teams are structured?

[00:12:19] Jeff: Yeah. Again, probably standard things that we all talk about, but it's people, process and product. People is the org design aspect of it, process is the ways of working, and product is our product strategy. And maybe it should be product, people, process. But ultimately, when we establish the strategy, and understand what the moving parts are and what the solvable chunks are, we do want to look at the organizational structure and make sure that it's aligned. And the way we do it is breaking that down into, classically, we call them streams and teams, but zones and squads, the same concept. And we do have a trio model, to make sure that E, P and D are on those specific areas.

[00:13:07] For us, a lot of what we're trying to solve is not being too prescriptive on the surface ownership. We're not team commenting, where the only job they can do is have a roadmap for comments. We are team asynchronous collaboration, and their remit is to improve asynchronous collaboration. They are there to solve a problem. And so they are doing some innovative things, like talk track, if you use it, and others. It's not just commenting, and it happens because they are solving a problem. And so we are trying to structure it in that way, where they feel like they have their mission that cascades up to the overall strategy.

[00:13:49] Host: And did you have to, because you mentioned Miro's culture at the start, was that something that you actively had to build, that kind of ownership? I love the point that if you called it comments, that's restricting what they can work on. But did you have the opposite problem, where you're going, "Okay, solve these problems," and then people are like, "Well, I don't know what to do there"?

Kickoffs, solutions reviews and setting pace

[00:14:09] Jeff: Yeah. So that then comes back down to this: look, leaders speak in the how. Strong leaders can abstract the how. Leaders speak in the how, and then you get the problem statement out of it. That's probably one of the classic jiu-jitsu moves I think a lot of people are really good at. You accept the fact that your C-suite person is going to come in and paint in the air and be like, "What if we move that button 15 pixels to the left and made it bigger and made it blink? Wouldn't that improve conversion rates?" And you're like, "Yeah, man, that's really awesome, we'll try that." And so getting that ism of the why is really important.

[00:14:48] The way we do it is, we will lay out a problem statement, like asynchronous collaboration. We will talk about some things in the how, just to loosen people up. It's not easy. We will rigorously talk about strategy first and then the problem second. It's a good session. But ultimately, in our ways of working, we try to make sure that teams are empowered to have the right kickoff, the right requirements gathering. They set pace to a solutions review date. So after kickoff, they literally establish a date. And that's really important, so that they're setting pace around when they're going to come back and offer us what they think is the right solution.

[00:15:28] And that's also where you unpack it if the team is like, "Well, we'll come back to you in three months." And then everyone's like, "Wait a minute, three months? What are you doing?" And they're like, "Well, we want to go to the zoo and observe the marsupials, to then understand how people behave." And you're like, "Well, no, it's just a notification bell. Maybe we can go a little bit further." "Well, I want to validate if people use the internet." And I'm like, "Pretty sure that's validated." So those are the types of things that we're deconstructing very quickly, finding those ambiguities.

[00:16:01] A solutions review is when you want them to come with a vision. Again, with common constructs, and I'll mix all my metaphors if you guys want, but the Ferrari: I want to hear what they think the Ferrari is, and then ultimately what the skateboard is to start. And so this is empowering the teams to say, "We think it's that." But there's a moment in time where we converge, talk about it and understand, and that gives them the empowerment of solving the right problems.

Research, speed and concepting

[00:16:29] Host: So can we just dig into that? I love the three months, and there's big pushback, and that's a huge thing that we've talked about in a lot of the talks: the value of upfront research. But there's also a movement towards continuous research. Just always be talking to your customers, and that's validating your ideas. So is there a particular methodology that you follow? Do you do continuous research? How would you describe how the teams do those phases?

[00:16:56] Jeff: Yeah. Ultimately, I think a lot of what we try to do is not be too religious about methodologies, other than it should be very iterative. Speed is our number one nomenclature for understanding this. I think team souls die a little bit when they have a three-month project where you don't do anything but talk about the work. And so what we try to do is really break that down, and be like, okay, how do we get to solvable chunks, solvable chunks? And then ultimately, what are the tools we have at our disposal? We have existing customer insights, we have existing bodies of research work. I see a lot of reinventing the wheel of research, and then the researcher finally raises their hand, and they're like, "We literally did a diary study two months ago, why aren't you using that?" And this happens a little bit more fluidly and organically the faster things behave.

[00:17:51] And so yeah, we do a lot of user research validation. We find speed to concepting is a huge unlock. So back to the skateboard metaphor: oftentimes teams mix up the idea of getting the right solution with digging deep, and then all of a sudden the Figma file is like a flip book of interactions, when it's like, wait, you needed three artboards to put in front of a customer. Why wouldn't you do that? And so we just constantly try to pressure test that.

[00:18:22] And I do think it's a really important aspect of the cross-functional team, and the tensions there. It's not the "I will toss this over to design, and they will decide what to do, and then they will toss it back, and I'll tell them it'll take eight years to build, and I'll toss it over, and then we're going to play ping-pong." It's: how do you get teams to work together? How do you get an engineer to say, "Well, couldn't we do that a little bit faster by doing it this way?" And it's the psychology of the team, to make them not feel like they're stepping on each other's toes, but working together.

[00:18:54] Host: And does being in the CPTO role help break that down?

[00:18:59] Jeff: 100%. I think so, because what I'm trying to do is deliver impact, and get teams to understand operating functions, and break those silos down a little bit further. And then again, for me, it's celebrating the successes, and it doesn't have to be one person. I think there are amazing trios of leaders, design, engineering and product. But it is celebrating those little inertia-busting moments where the teams are trying to figure those out.

Q&A: staying relevant against FigJam

[00:19:30] Host: Brilliant. We'll open it up to some questions from the audience. I have a few more, but the top voted one: how are you working to keep Miro relevant when tools like Figma are integrating features like FigJam that are similar to what you're offering?

[00:19:42] Jeff: Yeah. I think in general, canvas-based ways of how teams are working are a giant opportunity. I think we're in the very, very early innings, and I think there are a lot of ways of doing it. Miro's claim to fame, and what we are passionate about, is we believe we are the home where everyone feels like it was a home built for them. And so we are leaning very hard on the idea, and this is back to what I was talking about, that if cross-functional teams are activated, and they all feel like they have a seat at the table, they behave differently. They start trying to solve harder problems. They start becoming more ambitious. And so a lot of what we're pushing on is not to be the adjacent product or the extended arm of others. It's to really centralize along that line.

[00:20:32] We think there's a lot of democratization coming up. So a lot of our roadmap is built around democratizing some of the specialized tooling, and focusing more on how you push the bounds. I would guess most of you are using Miro for some level of brainstorming and ideation phases. There's a giant push that we hear a lot from our customers: "Man, I tried to hack Miro to do a project plan, and it was a hot mess, and it was really hard. Why can't you do more structured data, while preserving the energy of the teams and having engaged teams? Why do I have to context switch out and go somewhere else?" So how do we create those fluid motions? So look, I think we're playing a different ball game. The same metaphor of the canvas is true. We just think the powerful element of it is fundamentally disrupting a bigger breadth of how people work. And yeah, there will be a couple of announcements coming up in July and October.

[00:21:35] Host: Any sneak announcements?

[00:21:38] Jeff: No.

Q&A: product under technology, and keeping power centers balanced

[00:21:38] Host: Hoping to get a break. Brilliant. "We just folded product under technology for the first time. Any tips or warnings you can share?"

[00:21:52] Jeff: Yeah, wow. Well, I sort of cringe at hearing "product under technology," but I think it's probably a naming thing. It's probably more of a branding thing for your organization than anything else. But it's no different than what I was talking about. I don't think product, design or engineering should be under something that has a specific functional name. Technology, maybe, yes: it's broad enough. So my tips, though, are that it really is about the problems to solve, and the cross-functional teams owning the problem to solve. I think if you're finding yourself saying, "Well, now the power center is the engineer who's making decisions, and they're looking at me like, just write the requirements and let's get on with it," then yeah, there's probably a challenge that needs a little bit of a discussion. But this is back to continuous improvement. There is continuous ways-of-working improvement, where the key is to keep the power centers even and balanced, regardless of how you're structured.

[00:23:05] Host: Right. And I can imagine, particularly if you're empowering lots of teams, you can have that repeated in nearly every team, because if you have product, engineering and design representation, there could be power struggles. So do you have any tangible examples of how you're trying to, as you say, equalize that, and of continuous improvement?

[00:23:24] Jeff: Yeah. I think one of the biggest challenges that everyone wrestles with is: do you deliver impact fast, or do you address tech debt, or do it the right way first? And I think this is back to the continuous improvement philosophy. The contract, though, has to be: when you realize what's working, you have to address it to scale. And I think this is all about trust. In every organization I've joined, and I've tended to join mature organizations that need a little bit of a kick in the pants to get innovative again, there's already this erosion of trust. The engineers are going to be like, "Yeah, I'm just going to say that's a six-month project, because if I don't, then you're..." And then you start doing the why, why, why, and you're like, "Why is moving that button two steps to the right six months? How is that possible?" And they won't say. And then finally you get to the heart of it, which is not about the technical why. It's, "Well, last time I did this scrappily, our DevOps team yelled at us for three weeks straight," and blah blah. And so I think it's really incumbent on leaders to unpack the cultural aspects first, before even dealing with anything else.

[00:24:44] For us, I had a couple of projects early on in the Miro experience where we launched a couple of features, and it was like, "This will take six weeks to build." And I was like, "How is that possible?" And then finally it was like, "Oh." And I was like, "Well, my goal is to get three iterations really fast. So launch it in two weeks, let's see how it's working, launch it in two weeks, and then once it's done, you have my commitment that we will address it and look at the tech and clean it up." So I think that's the journey that everyone goes on. Now we've built the trust that, oh no, we didn't just move on to the next shiny new thing. We actually addressed it.

[00:25:27] Host: And what we talked about earlier in my talk, actually, was the challenges that teams have getting code out the door, whether it's architecture review, security review, change control boards. How do you empower the teams, if you want it every two weeks?

[00:25:39] Jeff: Yeah. We are religious in our ways of working, which is kickoff, solutions review, pre-release review, and then post-launch review, and treating those not as gates, but as iterative processes. Each one is a loop, and they're fast loops, very, very fast loops. The reason that's powerful for some of the ones that you just talked about is that the stakeholders, or the RACI, I'm so sorry, I said RACI, but I did, are involved. The security person is there at the kickoff. So instead of being the gatekeeper at the end, doing the gladiator thumbs up, thumbs down moment, they're there, and the expectation for them is, "Hey, if you're thinking that there's a blind spot here around security or others, you need to speak up." It's not the other way around. And what that's done is it started to unlock velocity, because instead of the last-second "Oh my God, we can't get this out the door because there's a curveball," we just know it up front. We're taking the pain up front, and iterating faster and faster and faster.

Q&A: how designers show value

[00:26:48] Host: Well, I think we're at time, but we'll do one last question, because I'm enjoying myself too much. There's much conversation about how designers show value to the business. What have you seen that's worked?

[00:27:01] Jeff: Yeah. There are two things that I think truly work. One is to never talk process. It's all about the business impact, and how you're going to deliver the business impact, and being creative about it. It's always been amazing when a designer comes with a new idea, solving a problem from the UX standpoint, and articulates those interaction models for business impact. We are doing some amazing things on the canvas that our designers are leading, and the way they're presenting it is not, "Look at this spinner wheel, this is so amazing, how dope is this interaction?" It was more, "Hey, this micro-interaction gets more people more engaged. If they get more engaged, they're more likely to co-create," etc., etc. So I think it's a little bit about the description there.

[00:27:52] The last one I would say is there's huge value in designers having a seat at the table with engineers, collaborating deeply with engineers to find the best solution possible. I think what's endemic in our industry is: you spend three weeks on your artboards, you hand it to the developer, they say it's going to take six weeks, then everyone's like, "Okay, oh well," and then it's just a six-week project. When if the designer sat with the engineer and was like, "Wait, why is that?", the developer might say, "Oh, well, actually, if you move two steps to the left, that's a two-day project." And having that level of collaboration, I think design leadership has to figure out how to break those molds and get closer together.

[00:28:38] Host: Brilliant, that was a great answer. So I just want to thank you very much for sharing. That was really insightful.

[00:28:43] Jeff: Great, thank you.