Working with Shape Up in a Product Collective – Marin Petrov (Products at Camplight)

initially uh you know i tried to do shaping in the team because i kind of have both technical art background i've run business before so even though i i kind of had all the skills necessary it's it was still not enough like i i remember i shaped some features which were like oh but that's actually not possible to implement it in this way because of like the way, I don't know, something on the backend works, which is like deep cold buried somewhere, like, which I have no idea about. So it's not that you, you cannot do it alone and then ask for feedback. I just think it's just way easier to involve the whole team. And as we discussed more pleasant and yeah, I'll just trade out, try this way instead of like trying to, um, to go the solo type of shaping work. Welcome to Shapers and Builders, the show about better ways to deliver great software products. Today I'm speaking with Marin Petrov, who's part of Camplight, a collective of people working together on software projects and products. Within Camplight, Marin and his team are working on Assista, a Trello power-up for better time tracking. This conversation is part of a series about companies that use ShapeUp, a delivery framework originally created at Basecamp. If you've never heard of ShapeUp, check the show notes for a link to the video Shaping in a Nutshell by Ryan Singer, former head of strategy at Basecamp and author of the book ShapeUp, Stop Running in Circles and Shipwork That Matters. In our conversation, Marine explains why ShapeUp felt like such a natural fit for the team working on Assista, and how it gave them great language to activities like shaping. It was fascinating for me to learn about Camp Light's setup as a collective, a way of working together that feels like an indie hack-up but together kind of approach. Enjoy! Hi, Maureen. Thank you so much for being here. Yeah, thanks. It's a pleasure. I'm really excited to talk to you today because you have a bit of a special... situation in the way you work and the way the company that you work at is structured, right? So I would love to actually start there and maybe you can talk us a bit through what you do. I know you are part of Camp Light, which is kind of a collective of people and you have various products and services. And yeah, maybe you can just talk us through the background of that and also your role and how you got into. uh and to camp light and the sister that you work on now yeah sure so camp light is a software company like we are basically making software uh but it might be a little different on two fronts um the one one thing or the main thing really is that we're cooperative which means every member of the company is also a shareholder or an owner of that company So yeah, the first thing is shared ownership, legally even. And the next thing is we also use what we call participatory decision making. Basically, we decide together how the company will go forward or like the governance of the company is also shared between us. So these are the two main things. Some people refer to this shared governance as self-management. I really don't like this term because it's a little bit overloaded and people have different ideas of what it might mean. In general, it means that we are all leaders in our roles and we try to steer. the company together. So yeah, these are the two main differences, I would say. And how many people are there on the team and within the company? Yeah, so Camp Light right now, I think we're 22, I believe, people. We're slowly growing, but we're very careful with that. The company existed for 11 years now. We had a... our 11th birthday celebrated last week and congrats thanks and i joined the company two years ago so i'm one of the new guys there and so we also work on um yeah actually maybe i'll say a little bit about the business model it's kind of like an angel agency work um we do a lot of projects with different clients that basically need their software systems built. And it can be anything from web to mobile to any kind of application, really. And then from a few years ago, we also started thinking about our own products. And we do that in two different ways. Like sometimes we... build ventures together with our partners where we have also ownership on those ventures and we also have a few of our own products which we develop and I'm basically on a team that builds these internal products one of which is called the system it's a time tracking software for Trello and yeah They're basically small, like don't think of something big or complex, but we want to slowly kind of grow into more product based company, I would say. Got it. And then the people that work, you mentioned you have this agency stream of work and then you have the internal products that you try to build. How are people kind of staffed between the two things? Yeah. Most of us work on this agency type of project. And maybe me, actually me and another engineer working on a sister full-time focusing on our product. So majority is still working on the... agency type of work and small team is slowly growing around our products and then people are sometimes helping so for example in a sister we are four people i'm a product person you could say then we have two engineers and a designer we collaborate with and also marketing person so yeah four or five people team It's not big. It's actually quite small compared to what I've been using before. But yeah. And those people, how do they balance their time between project work and agency work and then internal product work? Yeah. So one thing we tried to do and are doing now since I joined, I believe, income comes from these external projects, let's say. And then we are also working on these internal products. And then part of this income stream goes into funding those. So it's in effect like people or people or members of the cooperative are also investors in our own products like we decide which one should get a priority which one we should focus on but we also try to have a dedicated team working on those like we tried before to kind of do it on the side like it never actually works so now with this business model where We have a funding going actively into the products with easier, I believe. And we, you know, we try to actively put people focusing on it. So yeah, having full time focus on, on anything I think is important. So yeah, we try to stay focused on those. Yeah, I hope you don't mind that I drill down on this model, but I find it pretty fascinating for also for a lot of people who are probably kind of fond of the indie lifestyle and way of working. So when you mentioned, you know, you've switched now to mindset where you actually actively think of funding these internal products. How do I have to imagine that? Is it literally in a way that you kind of set up a business plan and have certain goals where you say, until this point, we want to have this product be self-sustained or is it more a loose mindset? How does that work? Yeah, I don't believe in business models too much. It's more of a, you could say, agile type of thing. Like some ideas are born really in a weekend, for example. One project we have right now is called TeamGPT, where people can collaborate on a chat GPT type of interaction with OpenAI. But yeah, this was just born in a week, I believe, and now it's growing. So it's more of a let's try something fast. If it works, then we continue developing it. If not, then we kill it. There are many ideas that need to work, actually. But I think that's just the nature of it. And I think the idea is to just really focus on what works and try things fast, fail fast in a way. And yeah, usually that's what we do. We have an idea. We build something around it. Nowadays, at least, that's easy to do. With modern architecture, you can really spin something really fast. Yeah. Yeah. So we don't really have business plans around those. It's trial and error. in a way. But then once it starts, well, then we kind of think about more from the business side. Like, for example, Assista is now, what is it, two years old project, even three maybe. And it's growing, so we have to constantly think about, okay, how do we spend our money, where, and maybe that's why we also use ShapeUp in that regard because it fits us naturally. Yeah. I don't know if that explains it, but yeah, we tried to be more agile at the beginning, but then kind of be more streamlined later on once. The project itself, so Asista as the product, is it, if you don't mind me asking, is it kind of self-sustained yet? Yeah. Why are you still funding it in a way? We are kind of on the edge, I would say. It's self-sustained. But we also put some money into it because we want to grow it in different ways, actually. But yeah, right now, it's kind of starting to generate more. uh more than we actually put it i would say um so yeah nice that's where you want to be cool and um to kind of wrap up this intro section i guess in a way um i um you yourself you have a bit of an interesting background i think or not not the typical product background right um do you want to talk a minute about that Yeah, actually, that's something I'm still trying to wrap my head around, like how that happened. So I come from 20 years of working in the film and animation industry. My, like, what I was doing there is my role was character technical director, which means if you've seen a movie like Ice Age, for example, maybe one of or few of the characters there were moving because, you know, me and my team allowed them to move. So it's a role which combines a lot of art and technology, which I enjoy a lot. Yeah. And yeah, I've been basically doing that forever, really. I think in 2016, I decided to build my own company, which was a software for the animation industry. And then slowly got into building software and mostly SaaS and web applications and stuff like that. But kind of looking from... different perspective. Like it's still art and technology, but just in a different domain, I would say. Yeah. Yeah. Product work is very similar to what I used to do. It's just the domain is completely different in a way. Interesting. I'd love to maybe circle back to that later in our conversation, but I just found it fascinating the transition and what similarities you might see between the two worlds. And you just kind of answered that. Cool. I actually discovered you and our sister through the blog post that you wrote on how you work. And in it, you mentioned kind of the way you've been inspired by ShapeUp. And as you kind of know, right now, I'm trying to talk to a lot of teams that are using ShapeUp and understand their stories. So I'd love to hear your experience and your... Yeah. Your journey in adopting ShapeUp. How do you get in contact, in touch with it? And how did that evolve for you? Yeah. So I joined Camp Light. When was it? 2020, I believe. So the book was already out at that time. Yeah. I've read it and I think everyone in Camp Light has also read it. Like part of our culture is we're like. very curious and we also like to dig in new stuff so i think when it came up it was uh probably discussed uh inside camp light i wasn't there um but yeah when we kind of formed a team around a sister we like it kind of felt very naturally to to use that like it uh it's a process which you know, combines business, design, engineering, marketing, everything in one's very, like it just fits in our workflow and yeah, in our culture as well. So it wasn't like, oh, let's start using ShapeUp. I think it was more like, yeah, we'll just use it. It's not a, it's just a common sense in a way. um so maybe that's how it started um it's yeah even like the words in the um or the descriptions of like what we're already doing in a way like the word shaping is such a great work to the word to describe like uh this process which uh we do collaboratively to uh design or come up with a solution to a problem. So yeah, all that just fit our team very naturally, and we're using it right now. It's not exactly... Yeah, sorry. Yeah, sorry. I just wanted to ask, were you around at the time where the team was not using ShapeUp yet? And if so, can you contrast? Were the things bugging you before? Yeah, so not really. Like, I wasn't there. But the thing is, I joined specifically so we could focus on our own products. Like, before that, it was like a little bit of an ad hoc thing. Like, OK, we do these things, but not really because we don't have funding for them. So when I joined the team, we kind of transformed the business model to also allow for this full focus on these products. And then it kind of happened. Like, okay, this is how we're going to work. This is what processes we're going to use. Yeah, this is how we'll be shaping. And it just evolved naturally from there. It's still evolving. Yeah. Yeah. So, but it kind of, the fact that you joined to focus full-time on the product then meant that all of a sudden you had to set some kind of process and agree on some way of working in a way, even though it wasn't that strict as you mentioned, right? Yeah, sure. That's kind of like what happened. Got it. And then... You mentioned how it kind of fit naturally with how you felt working made sense. But I think you wanted to touch a bit on also things that maybe you couldn't adapt one-to-one from the book, right? Yeah, yeah. I mean, one thing is, like, we're a very small team. So this, for example, the six-week cycles described are something we... Like if we are a bigger team, I see how very structured timeline around those cycles will work. I think we're more agile in that sense. Like, yeah, sometimes you could say a cycle is, yeah, let's ship these two features. One of them is big, the other is small. And then maybe the next cycle will be a little bit bigger. it's more fluid than that like we don't have a strict kind of tempo around that we still have like every quarter we have retrospections and we also use OKRs I know it's like people will hate me for saying it but we like it and we Yeah, we kind of look at those. We see how the business is going. We're just thinking about the next three, four months of what we should be focusing on. So it gives us some way of dealing with unpredictability in a way. Yeah, another thing, when I read the book, I really liked it. Something that was bugging me was this idea of some people will do shaping work and some people will do other type of work. And I can see how this might work in teams where you have someone that combines engineering, design, and business type of thinking into one. And then maybe, yes, that person can do shaping work. But I don't know. Most teams I've worked at, that's a rare combination to have. So we usually do shaping together as a whole team. So we say, OK, we need to shape this feature. Let's sit down. We use Mirror for that extensively. And we're just brainstorming there on the spot. more programming type of action than actually one person doing it. So that's something we're doing differently probably. Yeah. And I think that's, I mean, I had the chance to talk to Ryan a few weeks ago specifically about kind of changes to shape up over the course of time or maybe misconceptions that he was. Correcting. And one of the things we talked about was this myth of the lonely genius shaper. And what he mentioned in that conversation was specifically around that being kind of an idiosyncrasy of how Basecamp worked, but not a design per se of the system shaper that you had to have one person that's this genius shaper. Exactly. I think it's completely fair to design this and even desire to design this as a collaborative activity. Yeah. I mean, it's also more fun, to be honest. Yeah. Staying alone and just doing this, it's not... Yeah, we also work remotely. So in that effect, we're kind of very similar to maybe Basecamp. started that way and stayed that way. And it can get very lonely if you're working remotely. So, you know, doing these sessions is actually a very nice way to connect with people. Maybe, I don't know if this is going to work, but maybe you can try to talk us through the past few cycles or projects that you've done and kind of... talk us through the the sequence of work when were you shaping how were you overlaying the shaping work with the actual development work yeah and how long were the projects how did they get started and and get finished sure maybe not yeah so just maybe last week we had some few shaping sessions um so we used Trello for our project management and Kanban a lot like we have a focus and an in progress column and then a done column you could say and in general like we have a few others but whatever uh so we move you know cards from left to right uh once we start working on something uh it stays in the in progress uh column and then we move it out of there once we finish um so We, this shaping type of work that we do. Yeah. We just have tasks for them. We call them shape this type of feature. For example, for example, right now we're shaping something called a time boxing feature where, I mean, think of like, if you have used the time tracking software. you probably want to set some deadline or appetite or a kind of a time box, how much time this feature or this task should be worked on. And so we're adding this in your system. And there are a lot of complexities around it. It sounds very simple, but because assist is not the typical time tracking software it's like uh adding a little complexities on the on top of that so yeah we just last week we sat down with actually i i started a mirror like we start a mirror board around the shaping feature and uh we just throw ideas there like what will work we always start with okay what's the problem and what might be a potential solution. We have to be very clear about the problem because that's usually where things can go wrong. And yeah, this is something which, you know, I've talked to many customers and they want it, but how they want it is a little bit different. So what kind of solution to have which fits all of them. So we're thinking about all this. Now I first started the board, so I put some stuff there and then I gave it to the team to just review it offline. Like it wasn't an actual session where we stayed together. So they reviewed it, they gave me some comments, then I improved some of the ideas we had. Then we had a session together, which we started uh improving it even more and then something came out of it so something you could say is a finished shaped uh feature um and and what does that look like like what's the artifact at the end the artifact is like uh exactly what's described in the book like we have a problem solution uh and you know like all the Rabbit holes, you might get into appetite for it. Yeah, some... You also use a breadboard as... Yeah, we use Trello to describe all this in the... Basically, in the cart of the task, we put it as a description and we say, okay, this is the actual thing we're building. That's what comes out of it. Like in this case, there are some mock-ups, like very loose type of hand drawings in a way. Yeah. Yeah. So anyone that has read the book, it's like very, very similar to what is described there, which is very, very low fidelity type of thing, which describes the solution, but not in too much detail. And yeah. that's that's what it comes out of the session and then do you go into building right away like do i have to imagine this as a as a just-in-time process where you you shape something you build it you shape the next thing you build that or is there more of uh we shape a few options and then we pick which one we actually want to pursue now how does that work yeah it's more like that we we shape few things but then we kind of prioritize when to start building them and there are usually some features which are being shaped some which are being worked on so it's like an overlap it's not a we don't have a time for shaping or time for building it's like we do both simultaneously yeah so we started implementing it this week We've set an appetite for one week. So let's see if next week it will be ready. Yeah, I was going to say, what's like a typical size for you? Because you mentioned you are a small team. You are kind of nimble and agile in that way. Yeah. Yeah. We also, one thing which we also do is we don't have a strict work schedule. Like everybody works, like they decide. basically um and we we also use a system to track our time internally of how much time we spend building on the system it's very meta uh it is kind of meta yeah so it we we set one week just because we think that's how much time it will take for everything until we ship it uh No, it might go longer than that if people, let's say, go on vacation, especially if we're a small team, that happens. And then, you know, so it's not a one week of calendar, one week, but like one week of work for us. And yeah, interesting. Because you have these other. Yeah. Because you have these other commitments, right? So if I understand you correctly, the kind of the builder team that works with you, they are also busy on the agency type of work. So they have to split themselves even while a cycle is ongoing in a way. One of our developers is full-time on Assista. So usually they, yeah, in that regard, they're focused just on that. Our other developer is splitting time currently because there is like a big project we're working on outside of Asista. And yeah, I'm sometimes doing also design work and we also collaborate with another designer. So if it's something like I cannot do, maybe they'll do it. But usually most of the design tasks, I pick them up. So yeah. When you say design tasks, is that front end implementation or is that a kind of Figma prototype? I mean, both. Sometimes we can also implement something if it's easy enough, like HTML and CSS and JS, for example. But yeah, it's mostly like Figma design type of work where, okay, that's how the screen should look like. Got it. And yeah, we, even our full-time developer, like she is very knowledgeable about front end stuff. So usually she'll just knock it off directly in, in code probably sometimes it's easier than to design it. Yeah. And then transfer it. Cause you're already familiar with the medium, right? Yeah. Yeah. I hope you're enjoying the conversation. I wanted to take a moment to thank you for listening and to let you know about the Shapers and Builders job board. On shapers.builders, yes, that's the domain, you'll find jobs in software development, design, product companies that work with ShapeUp. Its roles are remote. Teams who use ShapeUp generally run as sustainable. So if you're looking for a job in tech, head over to the Shapers and Builders job board at shapers.builders. the conversation. Was that something you were looking for specifically when hiring that full-time developer to have them be full stack in a way? No, but I see a lot of benefit in that. Even for designers to even be able to code, it's just so much easier than to... design something, then hand it off to someone else to implement it. I just feel the more T-shaped you are in that regard, it's maybe better. We don't try to actively do that, but it naturally maybe happens. And maybe because we're a small team, so you have to wear different hats in that regard. So it's out of necessity in a way also. Yeah, that makes sense. But I find fascinating what you said about the time being not calendar week, but kind of a team effort week. And that can play out over multiple calendar weeks in a way. Yeah. is that um yeah go ahead yeah i mean uh as i said we kind of choose when to work we also have families anything happens uh children are sick at home like i don't think you can like it's also not healthy to say okay this is uh we should be able to ship it in one week like nobody's going to die like for example here you're kid background it's like these are stuff that happen right i mean uh it's uh you cannot really predict it when something will be uh will be ready to be shipped and we're usually good with that like we when we set an appetite of like a few days or a week or a month like we we know that it might we'll be able to ship it until then So we don't go over that. And that's what also ShapeUp is good for. Because you say exactly how much time you will want to invest in it. Because before, in other teams, I've worked with the opposite concept of like, oh here is a nice feature that we want to build and uh let's try to build it in that amount of time but it's either you either go over that time and uh your prediction is wrong or you uh do something and sacrifice quality to be able to ship on time so you know with shape up it's like okay this is how much time we invest and we ship until then No more, no less, kind of. Yeah. Yeah. When we spoke before, kind of, we did touch on that topic, right, about appetite being a good fit in a situation where you are also an owner of the company, whereas I think in a pure employee position, you might not care so much if you carry a project forward and forward and forward, sprint after sprint. Yeah. That's very well. said actually we uh like we are constantly like um are we sure are we sure we wanna invest you and build like actually building this thing like is it so important uh so in that regard we're like even yeah even more careful like how much time we put into uh into the software because yeah you can go overboard with uh with that and If you are looking at it from a business perspective, like trying to make a profitable business, then of course it makes perfect sense that you'll be careful with how much you invest. Yeah, I think that's a good time to kind of go a bit deeper on the how do you decide what you build next and do you feel like this pressure as an owner, this pressure to be profitable? Does that push you to have these rather small bets that you place one after the other? Kind of rather one week long versus tying up the team for four weeks? How do you balance that? How do you think about that? Yeah. So we usually talk with users a lot. So we have a pretty good idea of what they're struggling with. like their pain points, I would say. At Camp Light, we also use Assist extensively for all our work, actually. So we are also users of that. So that's actually a very nice thing to be able to use your own software at work. And that way, we have a pretty good idea. what we're struggling with, what we want to build, how, maybe. So how we prioritize is mostly from, yeah, it's maybe both analytical and kind of art in the sense, like I'm kind of fan of a zen and art of motorcycle riding. And they're, you know, they describe this idea of like, looking at something both from analytical point of view and from artistic point of view and it's it's both like we you cannot analyze it only we you have to also feel like what needs to be done in a way like some people refer to it as a product feel and Yeah, so we're like trying to listen to users. We're trying to listen to ourselves. And we prioritize based on that. We just see what's the most painful, basically, and just focus on this to solve it first. Sometimes we see something that is not very obvious. Like now with AI, it's like... oh there are so many rabbit holes there uh so we're like oh maybe we should just build this uh with some ai features and stuff like that uh but it's also a dangerous path to follow the hype in a way so um so yeah mostly listening is i would say the best skill for for that like listening to your users listening to your gut feeling And that's how we prioritize, I would say. And what was the biggest, in terms of time, biggest thing that you ever kind of shipped for Assista? Oh, man, there is this thing which is still biting us. So last year we were like, okay, it's kind of interesting why. So Assista is a power-up. for Trello. It integrates with Trello. And in Trello, you have this notion of workspaces and team members. And all other power-ups, we're looking at them, and they're basically billing you on the number of members you have in the workspace. But maybe only 20% of those people will use the power up. So you're like paying for your whole workspace, even though maybe just a few people will use it. So we thought that's not fair. We were like, OK, can we make a system to be fairer in that regard? And you choose for which members to pay, right? Because fairness is one of our values. So how can we do that? And that was so hard to do. Like it's, I mean, now we kind of see why nobody's doing it. We did it. Like that's a feature we shipped, which took us way longer than like, once we started shaping it, we were like, wow, that's like actually very deep thing. Like, do we actually want to invest time in this? So we saw it's complex. And that's regardless of that, we're like, well, it's kind of against our values if we don't do it. Like we have to do it. We also think it will be good in the long term. Like if people see that we are fair with them, well, I think it's a, you know, from longer term perspective, it makes more sense. And yeah, it's something that took us quite longer. There wasn't an immediate benefit that people probably saw. I think it's a very long-term thing that people will appreciate. And it's also kind of weird because, in a way, we're losing revenue in that regard by implementing this. in the short term by doing the right thing in a way but yeah i i feel it's the right thing to do also so interesting yeah so do you remember did you set an appetite on that project and did you yeah i remember it was like two months or something it's uh wow it wasn't yeah because we there had to be like a lot of screens we had to design like it's not a It wasn't a straightforward thing. Also, all the management of the users inside Trello, like what messages you give them when they are either using it or not using it, that kind of restrictions, it's kind of a boring work. But yeah, a lot of complexities around that. Yeah, also the hard thing is when you implement with third-party software like that, it's always a battle with once they change their API, you have to support all kinds of crazy stuff happening there. So, yeah. Yeah. So that project is still giving you troubles, kind of. Yeah, I think now we kind of want to actually another thing we're shaping right now is just improving that. Because we shipped it, people were not clear how it works exactly. So it works. It's just we're not clear in the messaging and copies here and there. So we have to improve on that next. So yeah, that's actually another good thing about shape-up is you can actually ship something which Well, it's not that polished. It works. See how it's perceived. And yeah, you can decide to invest a little bit more on top of that later on. Which is interesting because I saw some articles online about how ShapeUp doesn't allow you to kind of judge how something will be. perceived, but I kind of see that's exactly what's happening. Like you're actually shipping something, you see how it's perceived. You can work on top of that later on. Yeah. I observe the same criticism of ShapeUp in that, in a way, I think it gets this label as being a bit of mini waterfalls or a bit more waterfall-y in a way that you do. in the shaping you do kind of upfront planning of how you're going to develop this thing. And I think that gets perceived as being waterfall-like. Yeah, I can see how that can be perceived, but maybe it's just how someone is maybe using it. I actually think it's the opposite. It can be very agile in that sense. You can even ship something very half-baked if you want to. I wouldn't do it because it doesn't feel okay, but you can just ship something that's not ready, ready. How would you call it? And then you can even measure how it's used if you want to and then improve later on top of it. Yeah, I have to agree from personal experience that you know i think shape up just forces you to ship it forces you to make trade-offs to to ship and then you you observe and then you have this stopping function of okay we're going to put this out in the world and then maybe we work on something else for a cycle while we observe how it's kind of used and then we can come back to it whereas um in the in a scrum setting i've seen teams just keep treading water on the same thing because it's never ready enough and you know then you don't stop and and observe and step back and give it time to to be kind of used in the market exactly interesting so is that so the two months is that that was that a one-off for you like are you you're not gonna have any two-month projects in the foreseeable future or no i don't know maybe we will uh Right now, the product is very mature, I would say. I just don't see much like what we can build so much on top of it that will probably take a lot of time. We might focus on another product probably is my bet than actually invest more long term. like building features on top of it because at the end of the day, it's not a, it's a small project. It's the idea for it was like, I mean, it will never be a million dollar product. It's just something that will give us revenue on top of what we're doing anyway. Interesting. So is that rather the strategy is to have like a portfolio of these smaller products? niche products for us i i've seen this works uh maybe at this stage a little better uh like building fast trying something if it works then we stick and try to bring it for like further in the business cycle and uh uh i I don't know. Maybe in the future it will be different. Maybe we'll just focus on one product and that will be it. But I just, for now, I don't see what this it is. Yeah. Do you see any of your colleagues transfer learnings from how you work on the products into how you work on the agency side of the business? Are you using ShapeUp there as well or principles from ShapeUp? I actually don't have a very good overview over the other projects. I prefer to be just focused on what we do internally. I know some people are using it. I just have to maybe find out more about who, where, for what. One of the things is we're very flexible. Also, different projects have different needs. Like sometimes we start new ventures, which require us to be kind of fast and iterate very specifically for that type of project. Then we have some long-term commitments, like four-year contracts with a company where we are building their big software. So we're in that regard, like we are very flexible. We have all kinds of different projects and yeah, usually the team that's responsible for that project is the one responsible for also executing it and thinking how they're, they should be working on it. in that regard you know all teams are very autonomous and like the team actually is the deciding unit of what they should be doing and how interesting yeah got it makes sense i guess you have to also adapt sometimes to what the client to the ways the client wants you to work yeah sometimes we exactly we augment like bigger teams and uh we just have to work the way they do. So yeah, we're kind of forced into that environment in a way. So if I summarize the way that you work, would you say you're still very close to the book, kind of the shaping, betting and building? Yeah, I would say, yeah, except like a few differences we mentioned. Something I've also tried to do is when I read an interesting book, I just pick the parts I like from it. For me, it's very strange to criticize the whole book by criticizing one thing, for example. Like, okay, if you don't like this one thing, pick the 99 other things you like and just use those. So I also don't see how a methodology can be followed exactly or should be followed exactly. Like it's the team is the one that has to fit the glove on top of the hand, not the other way around. So yeah, we're using it that way now. Maybe in the future it might change. We'll see. One thing I'm pretty sure we might change is we'll be more like we will definitely have more structured cycles, for example. I see with bigger team that it's in a way a necessity. It's like if you're a small team, you can compare a small team to a rabbit or a big team with an elephant like it's just different types of physicality like you cannot uh jump so easily if you are bigger so yeah we're just giving it some structure on like how how much time is a is a cycle is probably better but when you're like I don't know, five member team, it's like almost useless in that regard. Is there anything that's bugging you right now about the way you work or would you say we've settled? I mean, we just had an incident like yesterday and we just had a before this call, we were in a retrospection kind of call. to see why it happened, like what to do about it, lessons learned, that kind of thing. I wouldn't say something is bugging me. I would like us to be also more focused in a way, but it's kind of also impossible in the current stage of the company. Even though my desire is to be like, yeah, I have full focus, full, you know, steam on. I just don't see, you know, how this is possible right now. Like we are slowly going that direction, but it's just a slow process. Like we don't have external funding. If we had, we'll be probably, you know, faster. But. Yeah. We also don't want to. So you have to be clear about what kind of business you want to build. In that regard, we're very independent. We don't answer to investors. And yeah, it's just a more calm way, I would say, to work. I got it. But then it also means that you do get pulled away on. agency work that drives the revenue, right? Yes, exactly. Or that drives short-term revenue that you need to stay afloat in a way. Exactly, yeah. Yeah, makes sense. Is there anything, maybe any friction that you experienced where you'd say, if I could go back and if I knew now what I didn't know then? Sorry. Based on what I know now, I would do it differently than we handled it. Yeah. I mean, maybe one thing is it's very small, but like initially, you know, I tried to do shaping in the team because I kind of have both technical or background. I've run business before. even though i i kind of had all the skills necessary it's it was still not enough like i i remember i shaped some features which were like oh but that's actually not possible to implement it in this way because of like the way i don't know something on the back end works which is like deep cold buried somewhere like which i have no idea about so it's not that You cannot do it alone and then ask for feedback. I just think it's just way easier to involve the whole team. And as we discussed, it's more pleasant. And yeah, I'll just trade out, try this way instead of like trying to go the solo type of shaping work. you basically your learning was even though you might feel like you have the competency uh the skills to do it um it's still beneficial to have this be a collaborative exercise i think yeah in the very beginning um you mentioned that you use okrs and you kind of laughed it off a bit how do you see okrs play along with shape up yeah i mean it's just delivery Yeah, I see so many people hate it. And I know why they hate it. Because they've probably used it in some very corporate type of setting where it just wasn't used correctly, I feel. I mean, OKRs are nothing, really. They're just a way for us to say with words what our priorities are and kind of measure them. how far we are in the progress um would you be in a position to make it like really concrete on what are your okay us right now and how are you building towards them yeah sure i mean the we have one because we uh yeah that's that's another thing which i've seen teams do i don't know why like they said too many and it just never works yeah uh The only objective right now is for the project to be sustainable. So that means covering everybody's salaries on the project. And yeah, we are measuring by, you know, measuring revenue, monthly active users, and a few other, you know, SaaS metrics you can think of that will tell us are we closer to that or not. And this has been our, we don't actually change it. We just, I think we've stayed with that OKR for the last few quarters. And yeah, until we go there and make it like fully covering our salaries, which as I said, is like almost there, then we will probably think about something else as a priority. But for now, that's the focus. Like, why should we even think about anything else? Like, that's the main thing our business should be thinking at the beginning. So in the discussions about what to build next, do you reflect on, you know, if we build this, we believe this is going to push us, increase revenue by X or... Yeah, in a way, like everything we build is like also tied to that. Like, is it something that will actually... help us. Now, in the case of that feature I mentioned, which is probably the opposite. The fairness feature. Yes. We still believe like that's something that in the long term will bring us closer to more profit about business. So we don't want to rush it. Like, I mean, it's very easy to actually do stuff that. will make it profitable for the next month and then people will be angry with us. Like I, I just don't think that's a good way to run a business. Like you have to be thinking long-term in that regard. So yeah, every time we're like building something, it's also tied to our, is it going to make our customers happier? Are they going to like, this edition more like it's all about you know making someone's life easier in a way so it comes from that in the spirit of time I think we've we've covered a lot of ground what kind of what are you looking forward to in the future on a sister or getting started on other projects yeah so On Sista, we just want to finish up some important features this quarter, ship them, and also as products as a whole in Camp Light, we're looking into a few other opportunities, like... something is baking I would say which is a little bit bigger than this project so we'll see how that goes like we have to again approach it carefully as we are funding it ourselves and yeah how can we if we are to make it a product like how can it be also sustainable so that's what I'm looking for maybe this year to test this and think about some other products we're building. Cool. If people feel kind of inspired by your story or can relate to it, what's a good way to reach out to you to maybe learn from you directly? So they can reach me personally on Twitter. Probably I'm active there. If they just search my name, they will find me. Also, they can write. I can attest to that. Yeah, that's where we met. And they can also write to either team at camplight.com or marine at camplight.com. Sorry, camplight.net. I'm terrible with domain names. And yeah, they can reach me there if they want to. Cool. Yeah, I'll just add a link to your Twitter profile in the show notes maybe so people can find you there. Sure. And reach out. Cool. Thank you so much for your time. It was really cool to hear your story. I love the collective idea and business model that you all have at Camp Light. Thanks, David. Yeah, it was a pleasure. Thanks for listening. There you have it. I hope you enjoyed the conversation with Marine. If you like this show, please leave us a review or spread the word. And to find jobs at companies that work with Shaper, like Camp Light, remember to check out our job board at shapers.builders. Thank you so much for listening and I hope you have a great day.

#10: Today I am speaking with Marin Petrov who's part of Camplight, a collective of people working together on software projects and products. Within Camplight, Marin and his team are working on Assista, a Trello powerup for better time tracking.

This conversation is part of a series about companies that use Shape Up, a delivery framework originally created at Basecamp. If you've never heard of Shape Up, check the show notes for a link to the video "Shaping in a nutshell" by Ryan Singer, former head of strategy at Basecamp and author of the book "Shape Up - Stop Running in Circles and Ship Work that Matters".

In our conversation, Marin explains why Shape Up felt like such a natural fit for the team working on Assista, and how it gave them great language to activities like Shaping. It was fascinating for me to learn about Camplight's setup as a "collective", a way of working together that feels like an "indie hacker, but together" kind of approach.

Enjoy!

Links:
Marin on Twitter: https://twitter.com/marinwaves
Camplight: https://camplight.net/
Shaping in a nutshell: https://www.youtube.com/watch?v=h_8M23wVjXk
Shapers & Builders job board: https://www.shapers.builders