How to Web Live Episode #9 – Ship Work That Matters

Welcome to How to Web Live! The show you need to watch to find out the latest news and trends from who’s who in the tech industry. Every other Thursday, log in on Crowdcast and get inspired!

This ninth episode titled ”ShipWork That Matters”, that aired on January 14, 2021, we had Ryan Singer (Head of Strategy at Basecamp) in a conversation with Adriana Iordan (VP of Product and Marketing at SeedBlink).

Last year was a bit crazy, and we’re not done (yet!). With teams reorganising, working remotely or in hybrid setups, productivity, team culture, and delivering meaningful results have always been in question.

Ryan Singer, product strategist of Basecamp and author of “Shape Up: Stop Running in Circles and Ship Work that Matters”, is one of the leading voices on the topic of organising teams in order to deliver well-crafted, meaningful products.

The host of this episode is Adriana Iordan, VP of Product and Marketing at SeedBlink, an experienced product and marketing executive.

Ryan and Adriana shared invaluable insights into the process behind the Shape Up method and various implementation scenarios within product teams . Here is a sneak peek into their live discussion:

Watch the full discussion on our YouTube channel here.

Listen to the full discussion on Spotify and on Apple Podcasts too.

3 takeaways from Ryan and Adriana’s live discussion:

►”This pitch describes at the right level of abstraction. So not too concrete, it’s not too specific with hard line drawings and wireframes. But it’s also not too fuzzy and soft, saying, you know there, let’s figure out how to build a calendar. But it’s in the middle. And this pitch then doesn’t immediately go to a team, it actually goes to what we call the betting table. And the betting table is where we talk about placing bets rather than planning. And this is a way for us to communicate our uncertainty and the fact that we’re always taking risks.”, Ryan, on the what the pitch features and how it functions within Shape Up

►”Some of some of the things that were a-ha moments for me were that there is a discovery to work that is as important as delivery. And you need a different skill set, you need different time bandwidth allocated to it. There isn’t a product manager knowing it all, outside of the building, doing requirements, working with developers, and all of that. So it helped me to, you know, validate the fact that we need different types of people and allocation.”, Adriana, on getting on board with Shape Up and providing strategical clarity.

►”The thing is that there are different business models inside of the product world. There’s the business model where you make a product, and you sell the exact same product to all customers with no changes per customer. Yeah, and this is what we could call a ‘fixed output model’. And this is what we do at Basecamp for example. We don’t do anything custom to make a deal to sell the product, we never do that. So we’re like McDonald’s, everybody gets the same hamburger.’, Ryan, on the best business model fit for the adoption of Shape Up.

Watch and Listen to the full episode to get your own takeaways!

Are you more into Reading? The Full Transcript is below!

 

Adriana: Hello everyone and welcome to How to Web Live. I’m Adriana Iordan. I am your host today and I just recently joined a startup called SeedBlink as their VP of Product and Marketing. And prior to this I worked for about 15 years in a company that went through all the phases from a startup to very large development teams, through various acquisitions. I am very happy to introduce you someone that has inspired me throughout his work and these years. And it’s our guest, Ryan Singer, he’s the Head of Strategy at Basecamp. So I’m pretty sure everyone is familiar with Basecamp products, as they are used worldwide by millions of users. And not only that he is the person behind contributing to the design and product strategy of this great product, but he also defined new processes of how to design and deliver and strategize around to work that matters. So with that, he is also an author. And he wrote a book called ‘Shape Up: Stop Running in Circles and Ship Work That Matters’. Welcome Ryan!

Ryan: Hi, Adriana. Thank you!

Adriana: Hello! So let’s start with your book just to set the stage for our discussion. And maybe have some points on what are some of the takeaways? What are the signals for you to know that you’re working on work that matters, you’re shipping work that matters?

Ryan: Yeah, one of the things that actually inspired us to talk about writing another book was that we were hearing from other, you know, friends of ours who were working in other software companies – they were saying that they remembered what it felt like when they were at the beginning of the company. You know, when it was a very small number of people, and they had no real organised process, and everything felt like very exciting and very important. You know, and, and then, something changed at some point and they started to feel like they were always doing work; these were always kind of like small improvements, and, you know, fixing bugs and responding to issues. And that somehow it became difficult to really, like, have a new idea, and just do it, and ship it and move on and then do something else. Right. So actually, I think this thing about work that matters – it’s really about the the feeling from leadership, and the feeling from the founders of the company, that the thing, the things that we’re working on, are they actually like big exciting changes? Or are they just at the edges of all the things that we already did in the past?

Adriana: That totally makes sense! I’ve been there, and just when I read your book, I was actually thinking that it would have saved us a lot of frustrations along the way through the growing pains. So I’m very much curious in our conversation to focus mostly on the strategy side – shaping, and how you how you look at this in Basecamp and in your work. So let’s let’s spend more time on some of the processes, the artefacts, well… what you added in your book around the bets and appetite and so on.

Ryan: Sure. So the basic processes, a lot of it has to do with sort of how do we actually think about spending our time? And so there’s many companies, and we’ve been through these different things ourselves in the past too. You know, if we give ourselves too much time to do a project, like six months or something like that – you know how it is; nobody really takes this deadline seriously until you’re a few weeks away. And, so what can happen is actually you spend a lot of time doing things that are unimportant, and then all of a sudden, everyone becomes aware of the deadline, and then starts rushing very quickly. And the other thing is, it’s difficult to really kind of feel the ending of a deadline that’s so far away. It doesn’t, you can’t really feel it in yourself, you know, but it’s real. And then on the other hand, if we are always kind of chopping work into tiny little slices, like two weeks at a time, we can’t actually get anything meaningfully meaningful done in two weeks. Yeah. And then we’re actually spending more time in meetings and planning sessions, and we are deep in the work. So we ended up finding that six weeks was the right time to actually plan a piece of work to be shipped. So that’s kind of the time unit. The other big piece of it is, how do we actually define the work that we want to do? And at Basecamp, and as I described in the book, we don’t do any hard line drawings. We don’t do any high fidelity mock ups, we don’t do any kind of Photoshop, or Sketch, or Figma drawings that go into a project. The projects begin with a clear idea of the concept. This is what we call ‘shaping the work’. So we have a clear concept. And we have some rough drawings. But these are very, very rough. And we are leaving room for the teams to work out the actual layouts and the actual details of the design in the execution, inside of this six week cycle. But the other thing is that we’re also not giving them a complete open question with, you know, we’re not saying go figure out, go do discovery and go figure out kind of what the real solution is. We don’t actually commit the team’s time for this six weeks, unless we’ve already done our preparation of being sure that we understand the problem, and being sure that there is a feasible solution within the amount of time that we want to spend on this. And so this, we can basically say that in terms of artefacts, you know, to your question, we have what we call a pitch. And the pitch is a kind of presentation of shaped work. So this represents the strategic work, and the early kind of large scale design work that went into coming up with a feasible concept. And this is always designed for a certain period of time, what we call the ‘appetite’ – how much time are we interested and willing to spend on this project? Is it worth an entire six weeks? Or is it something that it should only be a quick fix, that should only take two weeks, or something like that? This pitch describes at the right level of abstraction. So not too concrete, it’s not too specific with hard line drawings and wireframes. But it’s also not too fuzzy and soft, saying, you know there, let’s figure out how to build a calendar. But it’s in the middle. And this pitch then doesn’t immediately go to a team, it actually goes to what we call the betting table. And the betting table is where we talk about placing bets rather than planning. And this is a way for us to communicate our uncertainty and the fact that we’re always taking risks. Right? None of us can see the future. But you know, we’re working in new product developments, none of us know what is going to work and what is going to be easy and what is going to be difficult. And so, what we do is we we take our most attractive possibility that we have shaped in order to, to have the sort of the best odds or the best chance of getting a good outcome, right? And then we’ll place a bet, and say this is the thing that we’re going to do for the next six weeks. And then we give it to the team. And actually there’s no, there’s no manager who is creating tasks. No one is creating tickets for other people. The team actually takes the entire definition of the project, this work that was shaped, and the team figures out what the tasks are. And the team figures out the strategies for actually executing it. And also the team makes decisions on the level of details, like what is in and out of scope, actually. There’s a lot of latitude for the team to make adjustments there as well. And the expectation is that then the team will actually ship this within six weeks, at the end of the six week cycle. And if they don’t ship it, we actually cancel the project and we move on and do something else. Because it means that there was a misunderstanding, and this is what we call the ‘circuit breaker’. So, I don’t know, maybe that’s a quick kind of an overview of the whole process.

Adriana: Yes. I think it touches also some of the struggles I guess that drove this. Recommendations you have, work adjustments you’ve done in the processes. Was it driven by struggles you had in your teams, or you’ve seen those in other teams and try to explain how you do it on Basecamp? Have you been through any of those struggles? Have you seen them?

Ryan: I mean, we definitely have been through a lot of these struggles over the course of the, for me the I don’t know, how is it long, 17 years that I’ve been at Basecamp. When I, when I first was working on version one with Jason and David, it was three of us who were working on the product. And, you know, at that time, you don’t need to have any formal process at all, you just understand each other. Right? And, and actually, for quite a while, as we continue to hire people, there was this natural understanding and this kind of, yeah, you didn’t have to say what you were doing, you could just look at each other and do it. And, and then there came a point where a lot of things started to change. One thing that changed, of course, was that we had more and more people over the years, you know. Now we have about 60 people in the company completed overall. And the product team is around, the core product team has around a dozen people roughly. And But still, there’s a huge difference between three people and 12 or 15 people in terms of the way that you work, right? And so this is one factor that eventually we had to learn how to take the things that we were already doing naturally, and kind of turn them into something that we could describe as a process and kind of follow together with more people. The other thing that also became a challenge was you know, the type of work changed because the product became more mature. And then, for a while we were only building new features. And then we started to just do kind of improvements. And then for me one of the first challenges when I had to start to really think about how do we go about doing product development was in 2009. At that time we had I think maybe three or four different products that we were selling. And we wanted to unite all of them with this single sign on and some shared, you know, user billings, user administration and billing system and everything. And this was for us a very ambitious project. And our way of just kind of doing it naturally didn’t work anymore. And it was the first time that we needed some more structure, you know. So this is when a lot of the techniques from part three of the book about how we manage tasks and think about scopes, and things like that, came out. And then later on, actually it was much later, and maybe 2015 or 16 we were working with a new hire. And we realised that there was something that we had never been able to really put into words about when do we kind of give up on a project and move on? And when do we kind of keep going even though it’s difficult, right? When do we just cancel the project? And when do we continue? And we discovered that there was something about whether we still had unknowns – deep unknowns, unanswered questions in the concept. Or if the remaining unknowns were more just kind of small details, you know. And this actually led to designing the hill chart, because we needed a kind of formal way for the teams to be able to say: ‘Do I still have unknowns that could that could really put the whole project at risk? Or do I basically understand what I’m doing and it’s just a question of work?’

Adriana: Very important takeaways! I mean, what resonated very well with me when I read the book, although later than all the struggles I’ve been through. So you should have written that earlier! Some of some of the things that were a-ha moments for me were that there is a discovery to work that is as important as delivery. And you need a different skill set, you need different time bandwidth allocated to it. There isn’t a product manager knowing it all, outside of the building, doing requirements, working with developers, and all of that. So it helped me to, you know, validate the fact that we need different types of people and allocation. Like have product strategies and product owners, at least in in very large organisations. I mean, it worked better for us like that. What I didn’t do well, and something that I’ve read and was impressed in the book was this, not just doing the pre-work, but having it also time boxed, like six weeks for discovery work and putting constraints around it. So like a fixed budget and all of that. So that changed a lot the types of discussions we were having in the organisation. So I’ll just remind everyone, I wanted to give this quick input. So let’s remind everyone that they can ask questions. We are welcoming any questions. So I’ll just look if there’s any new ones coming coming in. So we have from Alex one question for Ryan: ‘How can teams transition smoothly from however they are working to the six week cycles?’. So I guess we’ll get into how do we, how are we able to implement such methodologies in prevalent agile waterfall type of organisations?

Ryan: Yeah, so I think there are kind of maybe two aspects to this. One aspect is how do we get the people to want it? Right? Or how does it actually, sort of the social aspect of getting the agreement to do it within the organisation? And then the second aspect is, like, sort of mechanically, how do we actually do it? I actually think it’s important to be very honest with oneself about the influence one has in the role that one has. So, for example, if we are the Founder, or the Owner, or the CTO, then you actually we can just do it, we can just decide.

Adriana: Right! It’s just on the leadership to take this responsibility.

Ryan: And, and if we’re not in that role, I actually think it’s better to relax. Because this really requires the leadership to decide that this is important. And that leadership is not going to to be interested in spending time on a big change in the process, unless they feel that there is a meaningful problem that they’re trying to, something they’re really trying to change, right? And from what I’m seeing, the successful adoption always comes from the leadership, when it comes to Shape Up. So this is this is, I think, just important to acknowledge. When it comes to actually sort of how to implement it, I think the best thing to do is to take it in the spirit of an experiment, and say that we as an organisation are going to have to now learn kind of what works for us and how to do things differently. And so let’s try one cycle of six weeks. Right? And then let’s, let’s go through the process of figuring out kind of what does it mean to shape work for that one, six week time box? And who is going to do that shaping? And what will be, who is going to, you know, what does our betting table mean? How will we decide which works to do during that six weeks? And then during the six weeks, let’s give it to a team and see how they can manage? Right? And this is what I’m seeing, is that very often what teams do is they try the first cycle. And they have a mixture of, you know, all feelings, right? And they’re they’re nervous, they’re fearful that it might not work, they’re also kind of excited. And then very often what happens is, the first project doesn’t go perfectly. But they can feel, they can feel how it’s different. Right? They can feel how like ‘Oh, we were working together in a different way!’. Or ‘We were collaborating more!. The build team, for example, the designers and the programmers, often feel that they were working together more than they were in the past, when they were just working off of tickets. Yeah. And the people who are on the shaping side and the strategy side feel that they were able to be.. This is very important. They often say that they were able to be more deliberate. They could say: ‘This is the thing that’s actually important. This is the thing that’s meaningful. Let’s give six weeks to this one thing and forget everything on the backlog. Let’s just do this one thing.’ Right? And even if the project doesn’t go perfectly, that feeling of kind of having more control and more collaboration to get something done is very exciting. And then often the teams make some adjustments, you know? And they do another cycle, and another cycle, with these two week cool downs in between. And then they start to sort of find their own way that works that works for their company.

Adriana: All right. So just on that topic, at least in my world, how we manage to use, let’s say, and implement, not fully to the full extent, especially when we were a large organisation, was to treat the discovery work with such methodologies while the delivery work was still with Scrum. So we had this almost double persona as product managers. When we were going to the teams, we already have done what they were doing prior to that. I don’t know, the go/no go type of sessions, where we presented cases, is it within the appetite? Is it a good bet? And so on. But that’s the product strategists’ world while when we were going the teams, we were still facing project managers and Scrum masters saying ‘Yeah, but we want the detailed requirements, we want the full scope upfront, to give you a fixed, I don’t know, time slot for developing something.’ So it didn’t work fully because you you were still not doing it completely, I say within a predictable manner in terms of deliveries.

Ryan: Yeah, that’s interesting. I mean, there’s a lot of things we can talk about here that are interesting. But one thing that I’ve seen in some, I have seen a couple larger organisations who have started to work this way. And it’s very natural, what you describe about how there are kind of, you know, engineering, there’s sort of an engineering world where they want very clear requirements, and they want to give you estimates, and then there’s a sort of strategic side that knew that they somehow, the engineers, even though actually their process is not working very well, their estimates are always wrong, things always take too long, and the engineers themselves are not very happy working on tickets all day. But at least it sort of works. But from the strategy side, it’s very clear that like this discovery processes, you know, needs to be better. But one thing that I’ve seen is that, for example, there’s a there’s a very large company in the States, a Fortune 50 company, who’s doing Shape Up now with their digital teams. And what they started to do is they started to actually take the lead engineers into the shaping process. Yeah, they would actually bring some of the the most expert engineers out of the out of the ticket world, and the Scrum world, and into the Shaping world to actually sort of build test versions and do some spiking to see is this actually, what is the best solution here? And this began a kind of a spirit of collaboration between the engineering side and the shaping side. And this, I think, it starts to actually dissolve this hard wall between them. Ideally, you know, the world that we are in at Basecamp, and this is, I think, easier for a smaller organisation, but this is the real ideal – is that we are not solving all of the design problems in the Shaping phase. And the people who are really building are also making judgments about what is the best design. And the Shaping is more just giving them the outer walls, right? Of time and concept, and what are the main moving parts of the solution. And so they’re not starting with nothing, but they have some some walls, but inside of that they still have a creative work to do together.

Adriana: I’ll take more questions. So we have a question from Marga asking: ‘Why don’t you do high fidelity mock ups? What is the problem with this approach?’

Ryan: Yeah, that’s a good comment. That’s a very good question. Um, there are a few different reasons. But one reason is that that comes up very often is the person who first creates the.. Let’s say we’re starting a new project next week. And I want to give the team something to start with, yeah? If I create high fidelity mock ups, what’s going to happen is I’m going to draw this mock, this wireframe and then I’m going to give it to the team and I’m going to say: ‘Do something different. Don’t don’t really follow this. But but here it is.’ And this is a contradiction. This is kind of impossible. And we’ve all, I think, been in that situation where you say: ‘Well don’t really make it look like this. But here’s the design.’. And it’s so difficult to to ignore all of those decisions that are in that first mock up. And the other thing is that, so it actually limits the creativity of our designers. So if we give the designers too much detail in the beginning, then nothing is left for them to do. And what we want is like – all of the designers that I work with are much better designers than I am. And I know that they will come up with something better than I would. However, for me as the Shaper, I need to understand why is that button there? And which which buttons need to be there? And why would the sequence be first here, and then here, and then here. And these questions are less about, you know, the colour, and the proportion, and the typography, and stuff like that. I mean, even in a wireframe, you’re still making visual design decisions that this is on the left, and this is on the right, and this is above and this is below. But those decisions don’t need to be made so early. Right? The important decision from a Shaping standpoint is, what is the button and where does it go. And there may be five or six different ways to lay out the screen that are better. So the one piece of this is a designer’s creativity. The other thing that is very important, which is often overlooked, is that design decisions have technical implications. And sometimes what happens is the designer puts a button somewhere on the screen. And they didn’t have a real reason for that. But they just put it there, because it has to go somewhere. And then what happens is it goes to the programmer. And now the programmer has a task that you have to make the button appear there, right? The programmer might be looking at the code, and they might say, you know what, it would be so much easier, I could do this for you today, if we could just put the button on this side instead, because we already have a model that is wired in such a way. And and if I have to put it over here, it’s going to take me three days instead of one day. Right? If the programmer could actually have that conversation with the designer, then the designer might say ‘Oh, it’s actually, that’s also perfectly fine actually. I don’t care, I just had to put it somewhere.’. But there might be another time where the designer says ‘No, it’s actually very important. And it’s here for a reason, and so on..’. But if we if we fix the design too early in a mock up, then this negotiation doesn’t happen between the cost of implementing it and the importance of it from the user experience side. So if in the Shaping process we are very soft with the design, and we don’t give a hard wireframe. It leaves more freedom, both for the creative side, and also actually for the technical side, to come up with a solution that can be built in the most efficient way.

Adriana: Well, one question that I guess a lot of us in the audience have is how do you deal with roadmaps and, I don’t know, urgent customer enhancements? Do you have a separate track for those? Are those bucketed differently? How do you look at this?

Ryan: So here I think it’s important to have an honest conversation about something. Very often when we work on a product, especially now that it’s become very popular to sort of talk about this product role, right? Like we think of ourselves as product designers or product strategy people and we identify as product makers. The thing is that there are different business models inside of the product world. There’s the business model where you make a product, and you sell the exact same product to all customers with no changes per customer. Yeah, and this is what we could call a ‘fixed output model’. And this is what we do at Basecamp for example. We don’t do anything custom to make a deal to sell the product, we never do that. So we’re like McDonald’s, everybody gets the same hamburger. And there are many product teams actually who are in a what you could call a ‘solution shop model’, which is where they are actually doing custom work for each client in order to make the sale. These are actually different business models with different processes. Shape up is made for fixed output products, where you make the same product for everybody. If your sales team is requiring you to build a feature in order to close a deal, you’re not. You’re not actually a product company. You are a servant, you are a consultancy. You are doing consulting work for clients, but you happen to have a common platform. Right? And this is different, this is a different world. And very often, this is actually driven by the way that the company is funded. So if your funding is coming from investors, and you have to pay back the investors, then you need big big deals, big contracts, right? You need big contracts. And you have this investment pressure, you can’t say no when the client says yeah, but we need this feature that you didn’t build yet, right? And so, basically, you will never be able to really adopt the betting aspect of Shape Up. If you are in a VC funded company, who is mainly reacting to what sales people tell you to do, you will always be experiencing a conflict. On the other hand, if you are making the same, always making, thinking of the entire customer base when you make decisions, then this, this betting process that we describe, fits. So in this fixed output case that we’re in, and many other companies are into. But it’s important to distinguish, in the fixed output case, it’s not necessary to have a roadmap. In fact, it’s a liability. Because making a roadmap takes away your freedom. None of us know what is going to happen in the future. And so the way to have the most options, and the most freedom, is to only make a commitment six weeks at a time. And we at Basecamp have many, many ideas, about the longer term future, right. And so for example, I’m working on Basecamp version four right now, which we are going to begin building this year. And it will take at least four or five six weeks cycles to build the whole thing. I have many ideas that I’m shaping for what we might potentially do in one of those cycles. But we don’t have any kind of plan for what will happen in cycle one. And what will happen in cycle two and cycle three. We will only decide one cycle at a time. Right? And so I like to think of it as having a kind of portfolio of options. You know, we have a variety of meaningful things that we can do. But we’re going to make those choices one by one. And we’re not going to make any promises to anybody because that would take away our freedom. If maybe one day, you know, you have the Eureka in the shower in the morning. And it would be best if you could actually just throw away everything that you thought before and do that thing because if it’s the best thing, it’s the best thing, right? But this is, this really does trace back to the business model and the way that we’re funded.

Adriana: Custom solutions versus products that you build for everyone. Could it be a model where you build for everyone but still the clients are not equal in terms of prioritisation? Is that something that you face? I mean, do you have clients that are pushing more some functionalities because of their size or, I don’t know, the contribution to the subscription or any of that? Do you consider as input some clients more than others?

Ryan: Well, so for our business model, all clients are equal in terms of their revenue contribution. So, that said, this has been a major strategic challenge for us over the years actually. To understand, like, what do our customers even want? Because the big problem for us with Basecamp is that we have so many customers who are in different industries, who are using it in different ways. And it is a challenge to sort of decide what to prioritise. However, I think it’s again important to distinguish between.. Well, I don’t actually have good language for this. The way that I think about it is sort of time priority versus space priority. You know, if all customers are paying us the same, and then I don’t have any time pressure from one customer to do something different, right? I can plan according to my own ideas. And then I can just look at a cross section of all the customers. And I can say, based on my understanding of the the research that I’ve done, which types of problems are the things that Basecamp should be solving? Which types of situations should we be more competitive in, you know? And then here, I’m looking across all of the customers, and I’m looking for where the most opportunity is to make the products better, and to fit the market better? So yeah, so I was saying, and maybe I’m repeating myself, but we do not want to be in a situation where our attention is controlled by who gives us the most money. Because, for us, this is the line of business we don’t want to be in. We could be we could be in the consulting business, if we just wanted, you know, to make deals to do work for individual customers. But that’s not the type of work we want to do. We like making products because we get to decide what the product should be based on our understanding of what’s important, you know? And, for me, that’s what makes it fun. So that’s the kind of model I want to be in.

Adriana: Can we go back to the input of ideas? Any detailed competitive research? During the testing, for instance, any North Stars or such concepts that are usually in the discovery work? Articles and books?

Ryan: Yeah. So strategically, we have two main inputs. In terms of.. So I like to frame it in terms of the the demand side versus the supply side. So the demand side is: what are people actually struggling with? So very often, you know, someone will say: will you please add a calendar, or, you know, to Basecamp? And this is actually they’re just speaking from the supply side, they’re telling us sort of what they would do if they were the designer, right? This doesn’t tell us kind of why we should do this, and what situation they’re in. So the thing that we really want to understand is.. So first of all, we don’t want to know, what do they want, because they’ll just tell us a solution. And this doesn’t help, right? But we also don’t even want to know why do they want it? Because very often if they tell us why they want something, it’ll just be some rash persuasion for why they should have the calendar. And actually the my favourite question is: ‘When do you want a calendar?’ So if I asked when it puts them into a real moment in the past, what was going on what was happening when you didn’t have a calendar and because you didn’t have a calendar, then you had a problem. Right. And then let’s understand the problem that arose because of that. And so, this, in general, we can call this a struggle. So for us at Basecamp, new product development always starts actually with our own struggles. And this is just how we are as a company. But I think a lot of startups actually begin this way. You see something with your own eyes, you understand yourself as a problem. And you think ‘Oh, I think I could do something about that.’. And then you create a product, right? And so Basecamp was, was created out of our own, you know, scratching our own itch, or whatever you say. And the same, of course, for the our new email service, Hey, and we prefer to always work like that. But then there are, of course, times, especially as the product becomes mature, when you cannot just continue to solve your own problems, because, first of all, many of our problems went away. Yeah, like we solved them with the first version. And then you have a question of why are all of these customers still buying it? And it seems maybe that they use it differently, and what do they want? So then we have to use different methods. And here, the method that I have learned that works best for me, it’s a kind of interrogation interview, that’s based on criminal interrogation methods that I learned from Bob Moesta. And basically, what we do is we, we take the fact that they purchased the product, or they cancelled the product and bought something else. So so this is the crime? Yeah? And because they committed the crime, we know that something actually happened and it’s not just some wishes, and hopes and speculation or something like that, right? It’s not like a focus group, where it’s just opinions, it’s real action. And then what we do is actually interview customers who bought or who bought something else about the chain of events that led up to the crime. So, you know, what, what was going wrong? When did you first have the idea that something should be different? How did you look around for an alternative? How did you decide that you wanted this and not that, you know, this kind of a thing. And, based on this, we discover, actually, the struggles that were pushing people towards something like Basecamp. And we also discover the struggles that push them toward other products, and why they use competitors. And here, we actually learn, also that some of the things that seem to be competitors are not, and some of the things that don’t look like their competitors are. And this is actually a big, interesting subject. But the best resource I can recommend for this is..  very broadly, there’s a book called ‘Competing Against Luck’, by Clayton Christensen, that gives a very big picture of this way of thinking. And then tactically, Bob Moesta, his most recent book is called ‘Demand-Side Sales 101’. And even though the book is kind of written for someone who’s trying to do sales, it’s the exact same techniques and processes for doing a good discovery for product development. And it’s exactly the interview that I’ve been using there.

Adriana: So let’s take some questions. More questions from the audience. We have Bogdan Paun asking you: ‘Have you seen this, or any similar process, working outside of Basecamp? Any tips for quickly exploring and deciding on such a process?’

Ryan: Yeah, we have many, many companies now that we hear from. I’ve been getting emails. Every week I get a few emails from some other company that’s that is now trying Shape Up and asking questions, or telling us that they’re happy with the results, and things like that. Actually it’s quite interesting. We’re really seeing a lot of companies using it. The other thing that we’re seeing is that some companies are adopting it all the way in the sense of they’re doing six weeks cycles, and they are shaping and writing pitches, and they have a betting table and so on. And other, there’s I think probably a probably a factor of maybe 10x more companies are using the language from the book, even though their process hasn’t changed. So they’re starting to have discussions about bets, and uncertainty, and unknowns, and shape and stuff like that, you know. So I think that also the language is working its way in. Discovered tasks versus imagined tasks, and things like that. So yeah, there’s a big influence there. In terms of like, what would I recommend, honestly, my preference is just to wait until you cannot allow yourself to continue working the way you were working before. Really! If what you’re doing is fine, then then that’s fine. But if you reach a point where you say ‘Come on, like, these projects are never finished on time. And all these people are working off of tickets, and it’s not the right work. And people aren’t, the team is, you know, not energised enough. And we’re not shipping the things that we should be shipping.’ Right? If it comes to that, I think then then you reach a point where you just simply have to do something different.

Adriana: On that, as you clashed earlier as well, I think this is mostly if you have the support of the leadership in the company, in the startup. It’s, I guess, easier when the founder is part of the story and they are bought into, then when you have only one leader in the organisation, the others are looking for other types of methodologies. We need to adapt what everyone is using. And on that, I’ll go to Loredana Sabau. She’s asking: ‘How do you handle, manage, conflict management within this framework? So conflict management. It’s broad, but..

Ryan: Yeah, yeah. Well, one thing that’s basically different from this framework is that you have a different type of collaboration at different phases. So in some companies you have.. So, for today, for example, I think we actually often see too much, and this may be unpopular, but I think we see too much collaboration and committee type behaviour, at the strategic level, in many companies today. Where you have the whole team gets into a room, and then they debate about what they should do next. Yeah, I think this is actually like, it’s better to actually have a smaller more senior group, who is setting the strategic direction. Then, on the other hand, we often have too little collaboration on the boundary between the the design and implementation. So for example, if you have someone who defines the work, and then that work gets turned into tickets, and then the tickets get handed down to, you know, they have to get hi fi mockups, and then those get handed to a developer, then you have too little collaboration. So this is where so to answer it, I would broadly say that we have what happens in the Shaping phase, in the Betting phase, and in the Building phase. So in the Shaping phase, this is not much really a question of conflict, it’s more a question of the trying to understand where’s the meaningful thing to focus on, right? For me, I have a mixture of my own – I’m doing very challenging work to try and understand what is important by talking to customers and doing research. And at the same time, if I think something is important, but the leadership Jason and David don’t think it’s important, it doesn’t matter how strong my argument is, because they’re the bosses, right? And they also have to have to care. And so I take their interests as an input to filter my work, because I know that they need to be interested in it for it to happen. So then when we come to the Betting table, there’s going to be a kind of push and pull between what Jason wants, what David wants. And then maybe if someone like me is there, I’m going to be advocating for certain things, but I’m not actually the decision maker. I’m the inputs to their decision. Right? And they describe a strategy that they call disagree and commit. And the idea is like, we don’t have to agree, but one of us has the power to decide, and a decision is going to be made. Right? So this is, I think it comes from actually having an honest understanding of the power structure. Right? Of who actually is, who’s actually in the position to make the decision. Then when the work actually goes, then we make the bet. And the work goes to a team for six weeks. The team is, our teams and the teams described in Shape Up, very often we have a designer and two programmers. And actually that’s it. There’s no other management involved. And this team is completely working together to make decisions, right? Within the boundaries of what was shaped. And, and there, there can be differences of view, there can be conflicts about you know, how to go about it. But honestly, when you have three people, and you have a shared, you have a common deadline, and you have a common background about what you’re trying to do, I think a lot of the conflicts that you see in larger committees disappear. Because you have simply so much reality around you. Informing you, or pressuring you to make decisions that the reality is not so difficult to agree upon.

Adriana: Is there a conflict from the support teams or the commercial side of Basecamp? Coming out and saying: ‘The scope is too small. It was cut too much within the six weeks timeframe. It doesn’t solve the next client need.’. Has that been a challenge?

Ryan: Yeah, that’s a good question. That question, in my understanding, belongs to the Shaping phase. Because when we bet on the work, what we’re betting on is, is the combination of feasibility, value and cost. And so that’s really a question to the Betting table. We definitely have a lot of cases where the people in support have a very different idea about what is priority compared to the people who are at the betting table. And this is a completely understandable just function of their position in the company. Because the thing is that the support is exposed to the tails of the distribution. They’re only going to see the thing that happens 2 or 3% of the time, but on a customer base of, you know, 1000s or more, right? And so their perception of what is a problem is of course, accurate from where they are, but it doesn’t necessarily map to market position. And what I see my responsibility, as, as someone who is thinking strategically, is to is to understand what is most important in terms of the market. And because we’re not money driven, and we’re not investor driven, our market, our definition of market success is always based on fit. Do we have a problem that is meaningful that customers are struggling with? And do we have a solution that we’re excited about that solves that problem? And how can we always try and improve that relationship as much as possible? Right? And so I really want to understand what is the thing that hurts the most, that is kind of the worst thing about Basecamp for the most people? And then, how do we turn that into a feasible project? Now, if we repeatedly, you know, ship things that don’t work, then we have to look at that and solve that. Right? But then we have to, I think, in this in this sort of review of our performance, ask, was it a shaping problem? Was it a betting problem? Or was it a performance problem? And was it a design build problem? Right? Where was the judgement made? That resulted in this in this lack of fit? And that can be very different, depending on the type of issue that comes up?

Adriana: And do you get to measure that? I mean..

Ryan: This is interesting. It’s very interesting. Okay, so basically NO.

Adriana: That’s a lot of non pressure!

Ryan: Well, I can tell you that, whether it’s my own neuroses or not, I do feel a lot of pressure all the time to to do it correctly. However, I actually think that it’s very difficult. It’s extremely difficult to find some number that you could measure that tells you if you’re doing well or not. With Basecamp, is it good if people have more notifications? Or is it good if they have less notifications? This is.. neither one is a signal to us actually, of what is better, right? And if we really wanted to measure, this is a deep, deep challenge. And we actually can do it to some degree, there’s certain things about the ratio of things that are read versus things that are dismissed, or something that could be an indication of value. But it is, it is very easy to come up with naive metrics that are wrong. And it’s very difficult to come up with a metric that actually tells you, if what you’re doing is valuable. It’s very, very difficult. And so the other thing is that what we are sure about, the one metric that we know is true, is cost. We know that if we spend six weeks on something, we spend six weeks. If we spend 18 weeks on it, we spend 18 weeks, and we know what that means in terms of dollars in time. So actually, the thing that we are very sensitive to is the amount of time that we spend. And as long as we feel like the time that we spent was worth it. And that we made our best effort according to our abilities of our strategic understanding, our technical abilities, our ways of cooperating with each other. Then we take the cost as an as a known downside, and we take the improvement as an unknown upside. Right? And as long as we can survive the cost, and still be in business tomorrow, everything’s fine. And so it’s really very often people are very focused on validation. Right? They want to how do I know that what we did was the right thing. So really, we’re focused on survival. I want to know that we’re still going to be in business later this year. And I want to make sure that I don’t destroy the value that is keeping us alive, and the fit that’s keeping us alive. Other than that, anything that we do might be a failure. It really might. And we can only just do our best.

Adriana: All right, another quick question! I think it could be the last one. From Bogdan, as more of a curiosity: ‘Basecamp is a huge inspiration for a lot of people in the software world. Can you name a few partners, or similar companies, or people, that you think we should be following?’

Ryan: Well, for me, the most direct would be to mention Bob Moesta, who has been on How to Web before. Because he’s the one that I’ve, he’s been my main mentor for the parts of the strategy that I just didn’t have answer to, right? So how to really think about what customers want? How to translate that into into projects? How to actually do customer research in a way that gives me causality and true understanding instead of just a lot of opinions and things like that. This honestly has been probably the biggest source for my work, has been the most directly applicable thing I actually use in real work all the time now. And I mentioned those two, those two references. And you can also look him up. He’s also doing workshops, and talks online these days. If you follow him on Twitter, I think you’ll see those. So that would be I think my main recommendation in terms of learning more about these kinds of things from another aspect.

Adriana: All right. Very good recommendation. So I think we have time for one more, at least. The questions are coming in.. So, the one I would pick is from Lucian: ‘What are the top three things to make self organised teams a reality within startup environments?’

Ryan: So the most important thing is that there has to be a, what we call, like a time or an actual time wall, a real deadline, where if the work doesn’t get done by that deadline, it’s that it’s, it’s it’s over, there’s no second chance. This is the number one thing, a real deadline. And you can find it in the book, we call it a circuit breaker. But really what it means is, we’re not going to extend the project. Yeah. And this means that there’s actual stakes, actually there is a reason to collaborate, there is a reason to solve the problems. This is what motivates collaboration. And then the second thing is, we have to give them also the ability and the freedom to actually succeed under that pressure. And that is where they need to be able to have a variable scope, I think. So fixed time, truly fixed time, and variable scope. Room to adjust, to change the requirements based on what they have understood by actually looking at the real code and understanding what’s actually possible. By getting their hands dirty in the real work. You know, this is this combination i think, these are the basics.

Adriana: Okay, Ryan, thank you for your time today. I hope this leaves everyone feeling inspired to at minimum check your book, if they didn’t already. It’s online, it’s available. Maybe they should also check your website – feltpresence.com. I hope this was a helpful resource. Thank you for joining today How to Web Live.

Ryan: Yeah, thanks very much! Also, feel welcome to email me: [email protected], if people have questions.

Adriana: Thank you!

Ryan: Alright, thanks!

8