Why Scrum Isn't Always The Best Method, Lessons Learned at Facebook w/Nimrod Priell

Show Notes

Omer: In this episode, I sat with Nimrod Priell who is the founder and CEO of Cord.com to talk about the challenges and the inherent pros and cons of agile and scrum methodologies. At, Cord dot com Nimrod works with the team in six weeks sprtins and quite different methods as described in shape up.

Nimrod worked previously many years ago with Onovo that was acquired by Facebook and led product teams at Facebook following the acquisition.He's been angel-investing and advising startups across the globe and recently been focusing on his work, with cord.com. 

Later in the episode, we talk about clever ways to go to market with different products, products for developers and SaaS. 

This is the only episode where we used tape recorder. So quality is not top-notch but the content is definitely worth it.


Omer: You work by scrum, you have sprints you usually, those are go over to weeks. You have the right, like the show of discovery and planning that I know that you guys do things quite differently.

Right. Because I think at some point you said maybe you did things for six weeks, so Yeah. What, why did you choose to do something else? What do you think is like the root cause of, of not adopting scrum and maybe take me from here. 

Nimrod Priell: So this is interesting. This is an area where I had you know, I've very kind of solid opinions. They're very different from what I see usually in the market. And we have to train people coming in to think differently unless they came from a very specific set of companies. So I come from Facebook, I that's where I really trained to be a PM. Over five and a half years there, I worked with tens of teams because I was in a centralized sort of role where I worked with a lot of different teams and very few if any, actually worked at scrum at, in Facebook and this goes back to a few other teams that I know. And so when I started chord, I sort of built on the experiences that I had that were very, very good and very different to scrum.

And by now I have a philosophy around it, but then somebody pointed out. That's what we do at chord is actually very similar organically without knowing in advance to a different method called shape up. And then I read the shape up book and it's it's excellent. And we adopted some of its ideas. I think the key problem with scrum for me is that it's based on two weeks sprints and it posits a question that is at the heart of what was wrong with waterfall in the first place, which is asking engineers, how long would it take? And scrum asks it in a different way. It asks you to sort of set sizes. I don't know, t-shirt sizes points, cards, there's all kinds of little games, but in the end of the day, there's a moment that almost feels like negotiation between the engineers and the project managers it has to do with how long does a piece of work take.

 I came from engineering, anyone who came from engineering knows that. Virtually impossible to assess in software, how long something will take the best engineers in the world. There's this guy called that his blog is called rants on repose. Very, very well-known engineered does this thing for 30 years. He said, you know, early on in my career, my assessment of how long. Would take me was about three times off. So I would assess things that took, you know, between a third and usually, you know, three times longer, they took three times longer than I, than I estimated. And now that I'm so experienced in so senior I'm about two times off. Right? So it, it just, doesn't, it's a fundamental fact of software engineering and that's, that means that when software engineers are asked how long something will take, they send bag and they think of this just as any other estimation or engineering problem where estimation the quality of estimation, the accuracy matters a lot.

So it's hard for them takes time. And it just creates this energy in the room every two weeks. That is almost confrontational. And instead, what we do is we say: look, we're building this, this thing, right? This, like, I dunno, this product is an analogy to like, I don't know, cathedral or whatever. Right. We're building this amazing thing. We should just look at it every period of time, say six weeks and not ask ourselves "how long does something take", but ask ourselves "what needs work here the most?", what area here is under developed? Where should we invest our time? And then just say, all right, let's start investing there.

Let's sequence the work let's prioritize. Let's understand what we could be doing. There is a shared project, but without asking how much we'll get done in these six weeks, without trying to pin down a a sort of commitment to a certain set of deliveries, just saying arrive, you know, what? Sign up flow needs work or we want to build something here and let's sequence it. And then, because it's six weeks, there's enough time for engineers to do some research, play around with it, try and start building something after a few, a few weeks within that realm, they get more confidence and they can tell you more confidently, you know, I can see from here, this is what shape up calls, health charts.

We don't use these health charts. But we take a lot of the sort of underlying concepts from it. We can see from here, what, what work is remaining. We already flashed the thing out. We built a lot of the hard bits. We now just have to like finish a few very, very clear bits and having worked in this area for the past couple of weeks, we know what, what are we going to deliver.

And so I think another take on this is that scrum is a great way. It has the right motivations in place, but it's not the optimal solution to solve these motivations. It's optimizing for the sort of average engineer. And what I found is that really good engineers hate scrum. . They hate being every two weeks in this sort of negotiation position, the pace is too fast. It doesn't let them do longer term projects. It sort of over prioritize short-term wins and the, and it really is good for sort of the more junior or starting engineers that need to break down stuff to really, really tiny. And being guided. And then what you really want in a project management system is the one that optimizes for the happiness of senior engineers and dragging all of the juniors up to that level, rather than something that makes all the senior engineers sort of grumbly and optimizes for the junior ones. That that's how I see it. 

Omer: If we take a bird's eye view on the process you start with, this is like a KPI right, the start from like business KPI, and then look at, okay, what are the pain points we have that correspond with that KPI and you get, it seems like in the, in the beginning of those first, like six weeks or, or the entire six weeks, you get a heat map of what's happening with the feature or the module in the product. Right? Like, so off there's a six weeks usually you go deeper, but based, based on your experience, is it like so or you move to the next thing you say, we, we took care of whatever we understand, and then we move on? 

Nimrod Priell: We usually move to something else to let the changes sort of you know, See what the effect of the changes were. Right? So you sort of, you landed it's live with clients, with users. That's the important things that scrum got right. And I think a very important in any system is that you deliver something that's user facing by the end of these six, six weeks. So you can sort of let it rest, see what it does, tend to another area.

There's always enough stuff that needs tending to. and then during these six weeks where you were sort of working on another area, there's data that you've accumulated there's discovery from these changes, and you can go back and say, you know, why do we got some of this wrong? And we want to do another iteration there, or, you know, it's fine.

And we can really move on. So we go back and forth. The second thing to say is, you know, we. We basically, we do the process. You said, we decide where do we want to work in? And we do try and have deliveries during these six weeks. We do try and land, you know, as we start planning it, if we see an opportunity but this is the really sort of agile way.

We, we talk to each other, the engineers are immersed in this project for six weeks. They understand the why. A lot of opportunities and we try and sequence them in a way that there's some quick deliveries early on, maybe even in the first week or two, it's not regimented into a cycle 

If there's opportunity, it's if it happens to be, you know, as part of the. Early discovery for them of this new modular concept or ideas within whatever we're trying to optimize. If they discover something that's very quickly, don't wait with it. Right. They just launch it. And then by the end of the six weeks, we can look back and say, right, well, we did a couple of things. Some of them were early on, quick wins at the start. Some of them took, you know, the whole six weeks to mature. 

A lot of times we would do what shape up "scope cutting"- you had a lot of ideas on the table, but to get something shipped by week six, you came in at the week four and you said, you know, you know, and we're gonna, like, we're gonna really, really simplify and clean, cut this out, like drop a lot of edge cases and deliver something that is a bit more raw.

And maybe we deliver the more raw thing just to a subset of users, whereas a test or whatever, or we just use it in a sales demo. to check it you out it out, We see all kinds of ways, even if it's not ready for "product" product to learn from it. And then move on. 

Over the time over the, the, the sort of you know, years of running this and the company we layered on top of a bunch of things that just keep everyone in this six week rhythm, which is a very nice sort of it's enough time to go deep into something.

But there's, you know, eight of these in a year, there's two per quarter. It sort of works with a quarter schedule very nicely. When we layered on top of few things, for example, we need time to plan the next six weeks, usually as PMs and designers, to bring something to the table, to look at the data. And we do it, of course, over the, the, we call it these blocks.

We do it of course, over the block, but also we. Half a week, the end of every six weeks. So the sixth of every six weeks is actually called intermission week. And it's where engineers can work on whatever they think is important. And it's still, you know, it's not like go build a game in your free time.

We want, we, we encourage this to be impactful, but it can be tech debt. It can be an internal tool. It can be something that basically the PM did not say is right. And then we also have two people at every single week that are doing what we call front lining and front lining means these people are responsible, both, both for on-call.

If there's, you know, production fires or, you know, something urgent. And the, the rest of their time, they devote to fixing small bugs, just going through the sort of bug list and the triage. And what this means is that there's always two people working on all areas of the code base, even things that they didn't develop and, you know, just making it better, just improving quality.

And that means that when we plan out the six weeks, we don't need to take care of and prioritize and, and, and think at the level of these tiny little bit. And, you know, assign them points and assign people to that because there's constantly someone doing that kind of like general sweeping and Polish and whatever. It's two people. So they teach each other. It's a random set of people. So it makes everyone sort of, we rotate.

Omer: It's not just like, someone junior. 

Nimrod Priell: No, no, no. It's just a random rota of two people at a time. To people is really important to here because as a single engineer, you can get stuck and not even know how to move, but with two people, two minds, you unblock each other very, very quickly.

You teach each other the best methods you make the whole team socialize with each other. You make everyone sort of feel responsible for the whole code base, because if you're, you know, if, if you have a lower sort of quality bar and you release shit with bugs, then ill, you know, it'll bite. You like the frontliners will constantly go and have to fix the your stuff and you will be effected when were front lining and usually sort of makes people because they care about their team and so on, makes them care for the sort of level of quality. So these things we layered on top, we found to be very, very useful. 

Omer: How do you rally the team around actual value rather than shipping features shipping code? Because you know, I've seen in, especially with startups, it's just harder to organize generally that sometimes as an engineer or in a squad, you're just thinking of a feature and then you get into the rabbit hole of edgecases (yeah) because this is sort of like sometimes the engineering mind. Right. And you ended up spending twice the time you would want shipping something that might not be the most impactful. And I figure, and I guess you might be doing work on, on that side that you really need all the organization who have this impact- based mindset.

Yeah. So, yeah. But what do you do other than the. This method, what do you do to get everyone on board and thinking this way? 

Nimrod Priell: Yeah, I think that's, it's it's a different topic though. I, I do think it also is something that's easier to do when you have six week blocks and two week blocks because the six week block sort of schedule lets you invest time instead of every two weeks sizing up, you know, items, which, you know, always takes like an hour. Even if you plan it as a, as a 15 minute scrum planning it lets you really sort of prep for and invest in telling a bigger story about what's going to happen in the next six weeks. Bigger story about what are we investing in and really build a picture of the why.

So when we plan out a six week block, maybe it's a new feature, maybe it's an area or a KPI that we want to improve and brainstorm and how to improve, but it always comes out as a sort of a, you know, like a, like a big moment for the team. It's the block planning. We have a social celebration around it.

Every six weeks we can go out. you know, have drinks or dinner or whatever. And we, the, the product team, the designers sit down and explain, you know, what we found was the big area of the cathedral that we want to invest in, in the next six weeks. It's easier to rally people around that then sort of every two weeks change the course or change, the focus, or like, you know, do a big talk and then end up the point that you can do in two weeks, which really is, you know, not a lot. 

And so I think that helps it, the schedule, but then what we do is, is very much sort of your classic sort of product management workbook. We spend a whole lot of time on the problem space and really talking about the problem. It could start with a KP or the KPI could be like a, sort of a lens to that problem.

Like, you know, activation's not high enough. People are not enough aware of our prodcut they're not using, you know, this and that feature of has strategic sort of value for us, or here's what we heard from, you know, all the clients in the past. And we go and we show clips of these are interviews, which today are on zoom and are very easy to record and just summarize for people and so on

And then we, we really talk about, okay, well, what do they, you know, what do they feel as they go through it? What do they need? How will it help them with. Do we want to invest in it, et cetera, et cetera, and just stay for as long as you can in the problem space. Because what I found is people's nature is to go to the solution space, but the more you actually force everyone to be in the problem space, it suddenly becomes clear to engineers.

This is a trainable quality, that there's a core journey here and that the edge cases that they care about, and it's great that they care about them. That's the mark of an expert engineer, but the edge cases are just not common. And what we would be better off with is first learning by delivering something in the core journey, learning whether it matches and then investing in all the edge cases.

And just trying to like block them off for now. No, you can't add a second task manager into your configuration. Now you can't do this kind of then just like really cutting out all of the rare branches and finding a way to deliver the main experience and seeing how much value it has. 

Omer: Cool. So. Moving from right from here from, from value first approach with, with engineering to perhaps the, the clients or the user side with Cord you've been not really maybe having any huge pivot, but I think the value prop stayed around the same concept, but the manifestation change. Right? 

So you started without an API and now we have got a couple of API s. So what were like major milestones along the way? And like how, how did you tune the valley and the pitch and basically found PMF. 

Nimrod Priell: Yeah. So this, this was you know, Cord's story maybe for everyone who doesn't know Cord Cord which is cord.com, by the way, there's a few companies called cord, but we're cord.com. It's a way to turn every SaaS product into multiplayer. Basically we take the experience, you know, and love from Figma or a Notion or Google docs. And we give it an every SaaS product that you use.. 

And we have two constituents, two main constituents. One is SaaS vendors that want to give this experience to their users because it will make their SaaS product and their vertical more you know, successful. It's a great value prop, users love collaborating on the product when they can. And it helps seat expansion and we retention and sales and so on. So a SaaS vendor like Typeform, which we partnered with, gives all of its users collaboration with cord on the surveys that they create inside Typeform. 

And the other constituent is the end user because, you know, the end user has to have great collaboration to prefer it over the ways in which they communicate today, which are slack and email and so on.

And slack and email are great communication products. They just have one fundamental unsolveable problem, which is they're not in context. So I can go to do, you know, a a type form that I created or a BI dashboard or whatever it is. And they'd have no idea that anyone was there. What did they think about, you know, what'd they talk about?

Were there any problems we tried to solve whatever it's all buried in some channel and some DMS in slack in the past, and have no way to sort of sum it up these countries. So this is the reason people leave Google doc comments in line. They, they never you know, have a Google doc and discuss it in like slack because whoever will come there will not have the context.

It's much better to communicate in context when you can. And so basically we saw from the very first day, the big strategy was that there's these two constituents. And now the question was, how do you plot the right path between them. 

On the one hand there's advantages to working directly with the end users of these products, because amm a sales cycle that involves, you know, adding an API to a a product is very, very long.

And by the time you get to end users and you actually, you know, learn from how they use it and whether they benefit from it. And how did they want to experienced communication collaboration. You could spend a lot of months just on going through whatever the SaaS vendor wants you to go through. Like, I dunno, security requirements or whatever.

And so we released this first as a Chrome extension mainly so that we could iterate faster and the Chrome extension has this nice sort of side effect, which is it's available across all of the SaaS so you can really see how teams start to use it when they can have the same mode of collaboration, the unified inbox, across everything from, you know, Google analytics, their cloud products, their marketing tool stack their, you know, whatever.

And when we did this, we are organically got to users who are working in tech, who happened to work in other's companies and they said, "oh my God, this is amazing. I wanted for my you know, I want for all of my users, I want for all my clients, do you embed the, you let us embed this". And when they reached out that just made the SaaS vendors sale, much, much easier.

They could see it's working for them and they want it in this format. And so that's how we sort of started landing our first deals with SaaS vendors. So, you know, this was always a part of the strategy for us. 

it's a beautiful, almost like a bottom up a go to market approach where you start from the users and then you climb up to the vendors.

The thing is, is engineering quite sophisticated, quite different from what usually is being done. And I guess then the, those SaaS vendors they reached out and said, we want you to incorporate you. So that that's the reason you started with the API or was it yeah, the different 

That's exactly that. I mean, again, we knew in advance, this is the move that we want to do. And we knew that there's an opportunity there. I spoke about the advantages of starting with the end user, which are mainly agility and finding PMF, which are just invaluable. And, you know, if you can have them it's the best thing and you need to use it. Superpower. Many companies cannot have them because if you are a B2B by definition sells to enterprises, I dunno, you're doing finances for public companies.

It's a very specific kind of finance work. And if you do that, you, you know, we can't get to end users really quickly. You have to start as they want working with public companies. Right. But if you do have the ability to work with end users, it's just much faster to iterate working with end users. And you don't need a lot.

You need a handful, you can get them from, you know, friends and family. You can recruit them from your networks. You can find other ways and communities to penetrate and recruit them. And so this is, this was an advantage we wanting to use, but at the same time, once you start working with SaaS vendor, you get access to all of their users because you're embedded in their product and all of their users get exposed to it.

So we always, you know, we say, look, we're learning from, we have a user base that's bigger than each and every one of our clients, because once we, you know, once we have more than one client, that's it like we're learning from the shared sort of base user base of all of these SaaS vendors. That's just amazing distribution, right?

So if you measure yourself by your learning on the end user and improving the product, you want these distribution channels. So the API distribution channel is just amazing.

Omer: Interesting. So when you said the learning from this shared user base, and this just reminds me of a thing. Last week or so you had this tweet that went viral with this like exact hockey stick of the, I think there weren't even like X and Y a labels. It's just like, when people see a hockey stick in the, in the startup ecosystem immediately, it triggers something in their brain. But it seems like, I guess it was coming from one of those collaborations. And you get the. This huge user base, all of a sudden you started looking for a partner and it's like, how do you sort of like tackle what's your angle for looking at in the tons of data that you just get? Just like in almost like in one day. Yeah. This huge pool. It can go so many ways. 

Nimrod Priell: Yeah. So I think, look, our north star KPI was always the number of active organizations were active organizations is a group of people having conversations on you know, inside their SaaS tools and it needs to be a group of people can be some, it cannot be someone sort of leaving comments for themselves or sort of playing with and saying, go, I'm just trying to get out.

And it's not about the number of messages they have because that changes by workflow changes by person's verbosity, whatever that's not right now, what we optimize for we just want to see retained actively (con) you know, actively conversing organizations. And so that was always the north side KPI, but now you go on a very, very classic sort of, and Teresa Torres, has these opportunity trees, which are an amazing articulation of this. And we at Facebook called them KPI trees, where you just go from that question, you ask yourself "all right, well, what leads to an active org?" 

First of all, at the minimum they have to you know, retain, they have to constantly use it. They have to invite other people. They have to try it out. They have to be aware of it.

So we have all these sub metrics that lead to each other and lead to the top level KPI. And you now try and look at the data across these metrics and identify where's the highest leverage point. Where do you have the most gap. And you usually you'd find that with data, but that doesn't mean you'd find the solution with data.

Then you have to lean very heavily into something that's harder for us to do, which is collect qualitative data and go, and with the hypotheses that you formed with data, maybe my hypothesis is invite flow isn't working well enough or people aren't aware of the power of some feature. That's a "Aha moment" or whatever, and you need to then go and, and get and spend time in the problem space.

Find the hypothesis for why is that is what's interrupting them. And the best way to do is just talk to users. So you go and you find that users that didn't fall, you know off that point in the funnel and the users that did, and you interview samples of people from both groups and you talk to them and you'll find all kinds of things, right.

And then you go and you try and maybe measure some of these things or try and release experiments and and trying to optimize for them. 


Omer: That's it for this time. Thank you Nimrod for joining us and you all are welcome to get in touch via Twitter. Either with Nimrod or with us, we would love your feedback. Have a great one. 

Share on :

Contact Us

Thanks for your message. You'll hear from us soon!
Oops! Something went wrong while submitting the form.