How great ideas happen and how they get built | Ryan Singer (Basecamp, Shape Up, Felt Presence)

the field has gotten more competitive, the timelines are shorter because there aren't these giant piles of money being thrown around to everybody too, right? So in a way, the software industry is becoming a little bit more like other mature industries. We actually need to be more rigorous about what we spend time on. We can't just design a whole feature and then throw it away because it didn't work and then try to design it again and then throw it away because it didn't work, you know? or having designers create really complicated Figma files and then you give it to the engineers and the engineers are like, no, we can't actually build that. And you're basically throwing all that work and time away. It's not viable anymore. Hi, and welcome to the June podcast. I'm your host, Enzo, co-founder at June. In this show, I'm talking to the most inspiring product and growth leaders out there who will share their tips on how to launch and grow your SaaS. No fuss, no BS. I hope you enjoy the show. Hi Ryan and welcome to the June podcast. I'm really excited to have you here to chat about product design strategy and a lot more. Great to be here. A little bit about you for those that don't know you yet. You define yourself as someone who builds product and advanced processes for design and development. You were the head of strategy at Basecamp for 17 years and now you're the founder of Felt Presence which is, let me know if I'm mistaken, but an agency where you teach design. processes and building products, correct? It's kind of a mix. Like I'm doing a little bit of consulting in cases where it kind of pushes the boundaries of what I've already figured out in ShapeUp. And that's kind of where the framework grows and gets extended. And then also my wife Katia and I together made this course, Shaping in Real Life, where we are teaching people how to actually go beyond what's in the book and adapt the principles of ShapeUp so that they can actually work in a wider variety of teams. Yes. Okay. So you got me here. So you also wrote this book called Shape Up and it's only a four years old book. I noticed the period. It's only been written in 2019, correct? Yeah. That's right. Wow. It's quite quickly, right? Yes, quite quickly. I'm surprised that it continues to spread also. Yeah. I'm not surprised to be honest. I think it's a great book. Last thing maybe about you, you're working with small teams to invent the next generation of creative tools. for the early stage of engineering and design project. You are also one of the person I know that speaks the best or the most highly about his mentors. And I check on your LinkedIn and there are three people you mentioned, Jason Fried from Basecamp, DHH from Basecamp 2, and Bob Moistar. And the first question I wanted to ask you is, could you summarize what you think is the you know these people brought you and maybe the role that mentors have more broadly in your life and it's not something very common to talk about mentors you know so i'm very curious to hear what they represent for you oh i mean i think it's it's essential to to learn from people who know better you know and especially people who have real experience and to i've always tried to do that i mean i remember when i was a teenager trying to just first get started making stuff on the internet, you know? I had like the friend who knew Unix stuff better than I did, you know? And the best way to learn is just to sit together and try to like kind of channel him, you know? And get everything directly like that. So I've had different phases, you know, where there were different things that I was struggling to learn. I've noticed that... For example, there are a lot of musicians out there. If someone who is a fellow musician comes up to them and is really interested in how they play something or how they have a certain technique that they're really interested in sharing, you know? And it's this kind of atmosphere of like, we're both interested in the same thing and we both think it's fun to help each other get better. And I've always been really attracted to that kind of a world. you know there are places like academia where it's a little bit more like everyone is trying to get a stand taller than the others so that they can get status and stuff like that you know but in the realm of like of musicians of kind of builders and doers there's this kind of this more community feeling of like oh we're interested in the same things let's see what we can learn together you know And I always kind of tried to approach learning that way, like becoming friends with people and then just getting excited about stuff together. And in the case of when I first started working with Jason, I mean, he has this amazing kind of directness of vision. He's kind of the opposite of me in a lot of ways in the way that he doesn't overthink things. he sees something and he has this kind of clarity of common sense that like, oh, this is valuable, this is useful, we should build this, or this other thing is a waste of time. So his ability to kind of cut through and focus on what is important, like in a design problem, I learned a ton from him on that. And then, of course, David, with the way that he built Rails and his way of thinking about frameworks was, I mean, Even before the framework thing, I mean, like, I wasn't really a capable programmer before I started interacting with David. I had tried to learn programming as a kid and stuff and never really managed, but thanks to Rails and the kind of thinking that was behind the way that Rails was put together, I was finally able to kind of break through and learn to program. So, I mean, those were, I mean, very, very big, big, big, big influences. And then, of course, when it came to questions of strategy and trying to understand, like, what customers are actually trying to do and kind of cutting through the noise when there's just a ton of feedback coming from all directions. All that stuff I learned from Bob Mesta about jobs to be done and really looking at things from the demand side instead of the supply side, that was also just super eye-opening. And we continue to work together and I continue to learn from him still. A lot of questions I have for you right now. I think the first one I wanted to ask is, do you feel the directness of uh working with jason has also been a helpful way to market base camp back in the days was it going beyond just product building in a way or was it uh did you did you learn more from the you know the product product craft side of things in a way um base camp was one of those things where the the product it was the so-called product-led marketing because there was a really big kind of viral effect where It simply did things better than all the alternatives and people would invite other people onto their accounts and it spread organically like that. So there was this aspect of it simply grew because it was really good at what it was doing. It was a really good fit for the problems that people had. But at the same time, it's tricky because, I mean, Jason is a natural marketer, you know? I mean, the way that he grabs hold of an idea and then writes a headline and makes a really sharp kind of pointed article about a specific point of view. I mean, I think the Signal vs. Noise blog was a giant launching pad for Basscamp. And if it hadn't been for his writing and for that blog and also... David quickly joined and became also a big force in terms of putting opinions out there and getting a lot of attention and taking a stance on things. I mean, it's very difficult to separate these things. This is what I realized, I think, last year when Basecamp introduced, I don't know if they were testing or if they introduced for good a seat-based pricing. And I could find on the Signal vs. Noise an article that said we will never charge on the seat. You know, at first there was a bit of a debate on Twitter, but I think what I realized is that it doesn't really matter. You know, back then, I think the folks at Basecamp really believed hardly that they shouldn't be a seed based pricing. And now they really believe they should be one. From what I'm seeing, they actually managed to break the trade off. They did a third way, which is it's per seat, but it caps out at a certain dollar amount, which is quite low compared to other competitors. So there's a certain dollar amount that no customer pays more than that dollar amount, no matter how many seats. So this was how they were able to... And I haven't seen this from the inside. This happened after I left. But I think this is a big part of the story is that they broke the trade-off by doing it in a different way. I think David might have a piece on that. If you check David's blog, you'll see an article about that. That was not so long ago. I'll do that. I'll make sure also to point in the description of the episode. Talking about David and you talk about RHEL, what is so specific about... the Wells, you know, mentality that, you know, that you learn from. You mentioned that a couple of seconds ago. Oh, there's a lot of things there. I mean, one piece of it is Rails was always about the one programmer who enabling one programmer to do everything. Of course, that's a technical choice. And there are other There are reasons why that might not be a fit, and actually it's very interesting to see all the swings that have happened in the industry in terms of frameworks and stuff over the last ten years. But it wasn't just about the technical aspect. I mean, this idea of optimizing for one programmer to do everything was kind of a philosophical thing of, like, when you can do it all as one person, it allows you to stay in that... kind of structural condition that we find ourselves in in the very beginning of a company, you know? Like when we are just one person, two people, three people, you need to be able to do it all yourself in order to work in this very organic, kind of spontaneous, process-free way that is so much, it's part of what's fun about doing side projects, right? is that you don't have to hand it over in steps to lots of different people in order to get anything done. This very integrative, like fast moving, let's like plug it all together and see what happens kind of style of working, it's really optimized for that style. And that's a really exciting way to work. I think we're also starting to see that there's a turn back towards that with things like Remix now, you know? And there's a little bit of a... I think everyone got such a headache from the single page applications that now there's a turn back toward that style, so that's nice, you know? But there was also more than that. I mean, Rails also, and everything that David was doing with the code leadership, was embodying the principles of people like Kent Beck and Martin Fowler, and David was always kind of preaching the Smalltalk Best Practice Patterns book. So there was a lot of... kind of deeper programming practice that was kind of there as an example. So it was an opportunity, you know, working in Rails and being so close to David was for me and also an opportunity to learn programming style and to learn about how to think clearly about factoring and, you know, how things are, like, where things belong in the code and how to make things clear and how to structure things. I mean, there was a... I don't even know where to begin to sort of describe all the stuff that I learned from that experience. That was a really big thing. That's a pretty fascinating one. I never thought about Rails this way, but that's actually exactly the way I've experienced it. So the first time I was at Intercom, they are big believers of Rails, you know. Of course, at June, we use Rails now, and it's exactly for the reasons you mentioned. Like, we're just moving very fast. It seems to enable also the front-end and the back-end part of things at the same time. So you don't need to have a front-end engineer and a back-end engineer. People really own the problems, which is pretty much what many product startups want to do. What else inspires you these days? Because Basecamp is behind, you're doing your own venture now, you're still close to the folks there and many, many other very smart and brilliant people. What is a deep source of inspiration for you today? You know, I'm always digging in different places according to where I feel like I need to learn more and where I think there's an opportunity to do something new. For example, when I started to get really heavily into the demand side interviews and doing jobs to be done stuff, that was a time in my career when I felt kind of lost. Like I didn't understand what to do next strategically. So then I started to try and learn all this stuff. I first started with Clayton Christensen and then I got really into Bob's work and you know that was kind of a period there. One thing that I'm seeing right now is there's all of these companies who are trying to adopt ShapeUp. I mean surprisingly really a lot. And what I'm noticing is that the level of sophistication that you get from Scrum, it's just not good enough to actually deal with all the problems of building software projects. Like the idea that everything can just become a ticket and then you just do the tickets and then you're going to be done with the project. It's an oversimplification, you know? And the reason that I'm seeing people come to ShapeUp is because they're understanding that there's these different types of work. Like the shaping work is different than the implementing. And the implementing isn't just checking off tasks. It's actually identifying unknowns and working in scopes. There's all these different aspects to it. figuring out like when are we done framing and when can we start shaping and when we kick off like how is the work that we define for implementation at a different level than the work that we came up with in the shaping phase like there's it it's it's it's actually a bit more sophisticated i would actually say that uh and i think what's been missing for a long time is this understanding that building software is real it's real work And when you look at how car companies work, if you look at how companies that manufacture physical hard goods work, you see that there's a level of rigor that has to be there because there are these giant investments in physical stuff. You know, you don't have this mentality like, well, it's all just virtual. We can change it all again tomorrow, you know. And in the early days, There was this feeling like, you know, we don't need that sophistication because in the early days of the software industry, it's like we just need to like race forward because there's it's it's so wide open. There's so many basic things that don't exist. You know, when I think 15 years ago, what it was like working in a software team, it was just like wide open green field all around you, you know? So this idea that you were going to like really slow down, it didn't make sense. What we're seeing today is everything is more competitive than it was before, right? There is a lot of software in a lot of niches already. It's not like you can be the first one to make a project management tool today, right? And then the other thing is that it's gotten more expensive to develop software because you have the phone version, you've got the desktop version, you have the Android, you have all these different things. The stack has gotten more complicated. Even if you're working in Rails, there's still things like Hotwire where you're trying to deliver the level of UX that people experience now. So the cost has gone up and the field has gotten more competitive and the timelines are shorter because there aren't these giant piles of money being thrown around to everybody too, right? So I think... That in a way, the software industry is becoming a little bit more like other mature industries in the way that we think, okay, we actually need to be more rigorous about what we spend time on. We can't just design a whole feature and then throw it away because it didn't work and then try to design it again and then throw it away because it didn't work, you know? or having designers create really complicated Figma files and then you give it to the engineers and the engineers are like, no, we can't actually build that. And you're basically throwing all that work and time away. It's not viable anymore. So there's more demand in the industry for rigor and more structure and a more thoughtful way to go about the work. And so on the one side, like that's... been really fun for me because there's a lot of demand for shape up and I've got a lot of people coming asking for help figuring out how to use the stuff that's already in the book and the stuff that we're already teaching in the course but the place where I'm most interested is of course you know like how to go further with this you know so I've actually been I've done a new round of studying some old old stuff from the 80s and 90s about how you know, some old stuff from the auto industry, some old stuff from Japan, and it's not the standard lean stuff, but actually more about how we actually get clearer about what are the requirements that have to get set early on versus what are the things that we can allow the creative latitude to figure out later. How do we actually judge if this is a project that we're going to invest in or not, you know, and all of that is feeding into a bit more understanding about how to help teams, right? get more rigorous in the process. But yeah, this is all kind of bleeding edge. So that's kind of where my head is right now, like how to help us get to a more mature place. And of course, as part of that too, I'm also building some software to support all this. But people will need to get caught up, I think, more on the learning side before they'll be able to understand what's in the software. Yeah, I dig into video games. recently and how they start with tutorials and it's a very good place also to look into. If you take the first video game studios in the 90s, it's very fascinating how they were teaching players to use the game. And also it was the same, like then it was a CD that you would put on the shelf and if it wasn't good, there was no patch, there was no new version. So it's definitely a good place to look at if you see. It's a very different perspective on quality, right? That we have to ship something that works. We actually have to ship something that works and we're not just going to kind of let all of the bugs appear to us. And, you know, it's a different mindset. I think where it's interesting is that it's not functional. I think the car is functional, right? If it's working, most likely people are going to keep it, right? But game is differently. Like people don't have problems. Like it's entertainment, right? So this is also an area I'm digging into a lot. So The things that we think are functional are often very emotional and very experiential as well. Because if a car was purely functional, we could all just be driving a Toyota Camry. And for sure, there are people buying Audis, there's people buying BMWs and Porsche, and it's for reasons, right? And there's, so like, for example, there's this, I was looking into some techniques, there's a book called Product Design and Development, and it's... covering a like physical manufacturing so for example the shaping of a nail gun yeah and alternate concepts for the implementation of a nail gun and the technology choices for like i mean it's it's it's super interesting and uh if you look at cars for example the the doors and windows of a car are part of an entry system and there's functional requirements that the door has to be able to open and close and lock and unlock and so on but there's all kinds of other things like the sound the door makes when you close it, how much force it takes to open and close it. These are all the experience things, and these are the kind of things that make, you know, the same things that make Apple Apple compared to, you know, like iOS versus Android. You see that it's a lot of experience things that are kind of hard to articulate, but if you were to embed with those teams, you would see that they have a very clear You could almost say that they have like experience metrics where they understand very well why this scroll behavior is better than that scroll behavior and why this rubber band behavior is too fast or too slow relative to what it should be. And you see that in a lot of these real kind of manufacturing firms that they actually end up creating metrics for, you know, what is the right amount of force that I have to apply when I pull on the door handle. You know, and those are the kind of things I think that we thought that we didn't need to know as software people, right? And it was true that we didn't need to know those things. But now I think that there's more competition and that the bar is getting higher and higher. We will find more and more situations where just winging it kind of isn't working as well as it was before. So I think there's a lot to learn here. Pretty fascinating. Yes, for sure. I love the weight of the door. I think it shows a lot about the quality of the car. I'm pretty sure it's faked, you know, but it does feel like it's related to the quality of the car. And I recently saw the clay cars. Have you seen the clay cars, which is the last type of a car? So the last thing they do, the last thing they do still today before releasing a car is creating a real size clay version of it. And so... Basically, they can really find student police, the car shape. And so you can really get a sense in real life of how this car is going to look like. And this costs like hundreds of thousands of euros or dollars. It doesn't matter. They need to do that. So every kind of manufacturer still does that. That's so interesting. This is another area I've been digging into a lot, which is prototyping. You know, what are the different ways that we can prototype the experience and build that into the process of how we're actually developing product? so that we're not just doing the Figma file first and then building that and thinking that it's just a two-step process, you know, but that actually we give ourselves more opportunities to fine-tune along the way. This is something that I first was really inspired by Christopher Alexander's work, and I still, I mean, I'm still going back again and again to that work and getting inspired by it. You know, like Christopher Alexander, when working on an architecture project, before doing the hardline drawings of the actual building, site, like where the walls and the foundation are going to be, they would go onto the site and place physical markers where all the walls would be and then sit in the room to see if the size of the room felt right and walk between the rooms, like a little bit like children playing make-believe, you know, where they've got these stakes sticking in the ground to represent where the walls are going to be, and they would move those around according to what felt right. And then they would make the hard line drawing based on the actual measurements of what they did on the site and take that to go get the permits and then proceed into construction. So there's so many opportunities to rethink the sequence of actions and what we build and what we test at which stage of the product development process. Can you touch a few words on the prototyping, where it fits into ShapeUp or the, you know, the methodologies and what do you think? is very important to get right. The number one thing which I mentioned already that we see in the industry is Figma files getting thrown over to engineers. Once we realize that this doesn't work, what do we do instead? So this is this brings us right into prototyping. So for example, what does it look like to have a running piece of software where some essential flows are wired together, but they look terrible? So what's the software equivalent? of a house which is standing and the walls are there and there's some wiring sticking out of the of the walls but there's no electric there's no fixtures yet there's no drywall there's no actual lamps or or there's no faucets plugged into the water pipes you know it when you when you're in a when you're in an architectural process you get you get the walls standing and you get the pipes and wires in place And then you can choose between all the different possibilities of interior design and fixtures and tiles and stuff like that, you know? So part of this is figuring out what does it look like in a software project to make some architectural decisions and actually go build some stuff and make progress on the project before, you know, instead of committing to the color, this exact shade of green and this exact font size, you know, in the very, very beginning of the project. Yeah, I heard you talk about this analogy with the housing a couple of weeks ago. I was lucky enough to bump into you and it was quite eye-opening. I keep thinking about it now when we design things. Yeah, so one thing I've done, for example, is I built a little CSS library that I use, which is all the fonts are this like Comic Sans. Actually, it's Markerfelt, which is a little bit better than Comic Sans, but it's a font that nobody would think is a real design. and all the boundaries of the boxes are a little bit wavy and messy looking. They're kind of like a little bit like Excalibur, you know, these kind of wavy lines. And you apply these, a couple CSS classes, to the things that are in the interface, and all of a sudden, it frees you from having to make any visual design decisions. You can just think about the raw components and whether the right things are on the page or not. And then anybody who looks at that sees that it's not a bad design. It's like a lack of design. The design just isn't there yet. Just like when you walk into a construction site and you see the wood wall standing up there, you don't think, well, that's the wrong paint color. You know that the walls aren't there yet, but that it's an earlier stage in the process, you know? So if we kind of look at this as, for example, just a rough sequence, we might see breadboarding. which is like sticky notes on a whiteboard where we're talking about the flow from step to step and where the affordances take us and how we move through an interface. Then we could see a rough working prototype with this kind of stub styling where everything clearly looks raw and unfinished, but it allows you to make sure that the things are connected and that you can perform the actions you need to perform. And then you can do a kind of a high fidelity pass. of fine styling and detailing. That's like an example of kind of three different tools happening in different sequence. And that's a very different sequence than you see in Teams today. And it doesn't mean also that we have to tie our hands behind our back at a certain moment. We might be in the shaping phase before we even start building a project, working on a whiteboard and think, you know what, in order to be sure that this is a good idea, we need to see this in higher fidelity. And we can go do a spike and see what that one screen might look like in greater detail if we need to do that in order to feel confident or resolve an issue or get buy-in from somebody. But then once we've done that, it doesn't mean that we have to do the entire product at that level of fidelity. We can kind of take that and then step backward and then choose the level of prototyping or the level of kind of form that is appropriate to the stage that we're really in. That's very interesting. Yeah, so it almost sounds like it's a prototyping or it's some wireframes. but developed already. Yes, exactly. That's, yeah, that's actually, the people I've worked with on projects where I've experimented with this, that's exactly what they've said. They said it's like a, it's like a working wireframe, you know? And it's funny because, you know, there's most of the unexpected complexity and cost in a software project is in the edge cases that you couldn't foresee in the, you know, all the things that it actually has to do that you didn't understand. It's not about choosing the right color blue, you know? That's not where the... It matters to choose the right color in the end. It's an important part of the experience, but it's not the thing that makes the project take two times or three times as long as you thought it was going to take, right? So when you work at this kind of rough, yeah, developed wireframe, like you said, when you work at that level, it allows you to bump into all of those flow issues and experience issues and edge case issues. Way earlier so that you're actually using the time you have more effectively pretty fascinating I would love to connect that to a message you posted yesterday on Twitter Where you're basically talking about you said I'm starting to think product management would be overtaken by product engineering and so one thing which is behind that is the relationship between the technical people and the non-technical people when building something whether it's a digital products or building And I think what you just touched on is actually related because if the engineer is the one able to push a prototype and to start to answer a lot of the questions that may raise in the team, then things will happen very differently. What do you think is happening here? Is it the consequence of more engineers in the companies? Is it the consequence of product managers not doing what they wanted to do? they should have achieved, you know? I think it's a little bit of a pendulum swinging and we got into a situation where it's just where we're at at this moment in time where in a lot of companies today, I would even say the majority, the engineers are considered to be the last step. You know, we're going to create the strategy and we're going to figure out what we have to do and we're going to prioritize and we're going to do a bunch of discovery and then we're going to go tell the engineers what to build and they're going to build it and then we're done. And what really needs to happen is, and you hear this all the time, it's a kind of a cliche that, you know, we should involve engineers more and the technical people and the product people should work together. Or you hear that, you know, product management is somehow this combination of tech and design and business you hear all those things but it's just not true in real life in in in the majority when you look at the in aggregate what is happening out there today most product managers today are unskilled people in terms of building things and of course there might be other skills there might be business knowledge there might be people skills there Honestly, the majority are actually just doing delivery management or project management, you know, making sure that they chase after everybody to get everything done in time. But what we're seeing is that as things tighten, as people start to look at profit and cost again, instead of just growth at all costs, all of a sudden it matters if the thing that we say we're going to build is actually buildable in the amount of time that we thought, you know. And the only way that we are going to identify things that are buildable earlier upstream is if the people who are involved in forming projects and coming up with what we're going to do are technical. So I think this idea that we can have a lot of non-technical people all kind of working on what we're going to do and then throwing it to the engineers is... Again, a little bit of a cliche, but it is what they call zero interest phenomenon. It was this like there was so much money around and everyone was just hiring a million people and no one was really worried about what are they actually doing? And when you look at like, what are they actually doing? Well, the builders, there's a very clear case for why the builders are there because stuff has to get built. But when you look at the product folks, if they're not, if they don't actually understand how to, how things are built and they are not. really making trade-offs in terms of we're gonna this is in scope and this is not in scope because implementation wise this is expensive and this is cheap and so on then what we're seeing is just tons and tons of rework and waste and work moving forward and then getting thrown backward again and then moving forward and getting thrown backward again we're seeing so much waste today as a result of this so it's just a commentary about where we are you know the way toward getting more done with the people we have is to have a larger percentage of our people being technical in the product development process. And actually, this is why my co-founder and I used to work for Intercom. And back there, product people are almost exclusively focused on the discovery part, on talking to customers and writing problems. And then they don't really do the delivery part. Of course, they involve the help on the scope, but they don't really do anything there. And I think this is what some companies have decided to do because of the consequence of what you said, right? Yeah, well, it's also easy to do when there's a ton of money around, you know? Let's have a million people doing research all the time. What you see is that in a lot of companies today who have built out their discovery teams and research teams and stuff like that, that a lot of that research is actually piling up into just piles and piles and piles of documents and hours of interviews and personas and journey maps and all this stuff. but it's not actually translating into what gets built. The engineers look at all that stuff and they're like, I don't know what that means, I don't know what to do with that. And it's not getting turned into, most of it isn't getting turned into projects. What I see in really effective teams is that there's a few people, a small number of people for the whole product business who are completely focused on trying to understand the customer and understand where the opportunity is. Somebody has to be doing that. For sure, somebody has to be doing that. But we don't need to have one person with every single build team whose job is supposedly doing discovery and customer research continuously. That's just not real. You know, we can't consume, if we were coming up with new insights from customers every day, we couldn't possibly turn that into a project and build it at the same rate, right? We just can't consume that much so-called insight. So... I think what really what we need to see, what we're seeing also is that the potency of the insight is not very strong in a lot of these teams. And we need to get to a place where we have fewer people doing customer research, but more effectively. And then working more closely with technical people to turn that into viable projects. Yeah, I'm with you on this one. It feels to me that these are different cycles, length cycles, you know, like research for me is like very long cycles versus teams, product teams, which are working more on shorter cycles. But yeah, it's always been a mystery for me how the best companies in the world manage discovery, because I've always seen discovery more as an ad hoc topic, or maybe even a way for the top management to make sure there was not a bigger opportunity in the market that they would miss, you know? Yeah, it's just, I mean, how the discovery happens and... how the research happens and so on. This is just a question of the structure. The thing is that what happens in a lot of teams today is the product folks will do a bunch of research and then they'll write a document that describes an outcome. We want to build this feature and it's going to be fast, easy, and it's going to do all these different things. But then when you give that to, then they give that to engineers to build thinking it describes what to do and they slice it up into tickets and it's this never-ending scope. You know, and that's because the person who said this is the outcome we're trying to reach, it's a mismatch. Describing an outcome is not the same thing as saying this is something that we can actually build and ship in X number of weeks. There's a there's a shaping step that's missing in between there from framing the outcome to saying these are the moving parts that we can put together with the technology that we have at our disposal in order to actually ship a working product. So that that shaping step is missing in that chipping phase There is something which is I love to get your eyes on which is the ideas How do great ideas emerge? From the shaping phase are how the great ideas happen. Is it? The consequence of rigorness and just right people right process or is it? Coming from somewhere else, maybe a you know a leader that has a strong vision or Yeah, where is this coming? Like just a brainstorming exercise at the right timing? Where are great ideas coming from? Like I know at Basecamp you had such unique ideas and unique take on building things. Well, we didn't always. I mean, there's phases. There were times when there were 10 good ideas and there was no time to get them all done. And there were other times when there were no good ideas and nobody knew what to do. And the reason that I started learning about how to do customer interviews and demand-side research and when I first got connected with Bob Mesta was because I felt lost. I felt completely in the dark. We had a product with a lot of customers. When I looked at the customers, they were so different from each other. They were in totally different industries. And I just didn't understand what to propose in order to somehow make the product better. and i feared that whatever i might do would also make it worse you know so uh so that was a time when when i i i really had to say okay i need to learn i i i'm not equipped to answer this and i need to build some tools and skills for myself in order to better understand what to actually go do next you know and there's of course times when things coming up from there's a million ideas coming from customer support you know There's a million things coming, maybe there's a lot of small things that people internal to the company want to see fixed, you know. But all these circumstances are also dependent on the stage that the company is in. It's very different when you have product market fit and you have a stable base of cash coming in from customers and then it's a little bit more like how do we optimize, kind of how do we take this to the next step. as opposed to when we're not product market fit yet and then the clock is ticking. I mean, that's a very different circumstance as well, right? It's also harder to say no to big paying customers post product market fit. Like if they represent, if a customer represents 1% of your revenue, it's very, very hard to not build what they want. The language that I've been using with teams lately to clarify this is that there's the work of framing and then there's the work of shaping. And framing is about identifying the opportunity, defining the problem, and making the case to spend time on this thing instead of other things. And then if we frame something like, this is worth building and here's why, then shaping is about making the technical trade-offs to understand what to actually go build. And when it comes to this framing work, I mean, there's different aspects to it, but when we're talking about building the case, there's at least two key pieces to it. And one is, can I tell the story of the struggle just on an N of 1 basis? So can I tell the story about what is happening to people and why that's bad and how that impacts us, right? Or if it's not a struggle but it's somehow an opportunity for us, can I tell the end of one story of how this is going to make one person pay us more who didn't pay us that before? The end of one is really important because that's where we establish the cause and effect. That's where we're actually able to understand if we do this, this is what's going to happen as an outcome. Then the second thing is to size that, to scale it, to say, okay, how many of those end of one stories actually exist, right? So, for example, if we encounter a specific situation, which is a really bad experience in the app, and we think that that might accumulate and lead to churn, we can look, okay, and say, what are the circumstances that have to be present in somebody's account in order for that thing to happen to them? And then can we instrument that so that we can actually understand how many people this is likely to happen to, how rare this is, or can we tie it to something in what we know about the data in order to quantify that. And that's where we can bring the two together, where we have a cause and effect story of why this is bad or why this is an opportunity, but then we also have the instrumentation or whatever it is that we can pull together to make the case to say, this is also happening to a lot of people, right? And... you know when we look at every kind of bad experience point or bug or things that customers are complaining about there's always a million things but if we weigh the struggles against each other and then try and figure out how many people we can impact with that change then we can start to really uh make some progress in that framing work i love how grounded you are like starting really from a single customers and then two then three and then making the case and in data we often say the average is the enemy so if you start from the data often you will struggle to find anything. Exactly, exactly. And, you know, because it's so easy to say, oh, we're going to we're going to rebuild the notification system. And here's why we should rebuild the notification system. But like, tell me, how does that who is that? Tell me the story of like how that makes things better for one person, you know, and then and then we at least know what we're talking about. Then we can define a crispier. kind of problem and outcome. And you also have your narrative for the go-to-market. It's almost like you already know how you're going to talk about that feature or improvements. Yeah, you know, you hear this thing about this idea of writing the press release first or things like that. And I think that's actually just another way of expressing the same point. You know, in order to make the marketing pitch, you have to understand the problem and the outcome and kind of think it through from the perspective of a potential customer. So it's just an... maybe a proxy for that or just another way to flip your head into that end of one mindset we about to reach the end of the podcast i wanted to ask you one last question um about ai and llm and all these you know companies adopting these new technologies we had a chat i think three weeks ago with hit and sha about whether ai was more a new features for existing product or if it was more going to change fundamentally the core of new products. And his take was that at the moment, it's mostly additions. It's mostly a layer on top of existing product. It's mostly AI features. Do you see that the same way? Do you see that differently? What's your framework to think about this new AI revolution at the moment? I think it's very exciting. If you look at what Apple just announced at WWDC, you see a very nice example of what it looks like to actually bake this in to the things that we're already using. So Apple didn't release a co-pilot like everybody else did, and nothing against co-pilots. I think what Office is doing, or what Microsoft is doing generally with the co-pilot across all the Office tooling and stuff is really cool and interesting. But I love how Apple... fixed auto-correct. They took something that everybody struggles with all the time and then you notice that, you know, their way of marketing, of course, they don't like to use the same language as everyone else. So they didn't call it AI, they didn't call it ML, they didn't call it LLM, they called it a transformer-based improvement, right? But we know what it means and it means that they're using this kind of LLM style thing and As far as I can see from the WWDC presentation, we should expect autocorrect to be substantially better because it's taking more context into account than it was before. And like that, that is a meaningful improvement, you know? There's, I think, a lot of things, a lot more examples that you can see when you look at what Apple's doing, where they're baking them in, they're baking the technology in. to fix the basic experience issues that we've been living with for a long time so that's really exciting um i think the llm of course it's natural to first think of it as this kind of self-contained feature that lives alongside everything else one thing that i'm really curious about is to what extent uh it becomes uh an a different interface mode you know uh and that's where hard facts and hard answers to mathematical things and facts about the world and ChatGPT is just the means to ask the questions and get the answers back from Wolfram language. So I think that is a really, really kind of promising example. You also see this with Palantir just showed this at AIP Con where they integrated the kind of a chat LLM kind of a thing into their ontology and into their data tooling. and you see that the answers aren't coming from, it's not, you know, like it's not this poetry that's coming from the LLM. The LLM is just a means to communicate with all the other tooling that actually gives you real answers to things. So I'm sure we'll be seeing a lot more of that. Fascinating. This was also the conversation with Scott Belsky last week. He has this great essay called The Interface Layer, where he talks about how interfaces are critical if you want to win the customers and kind of his thesis in 2014 was that any services behind the interface will be commoditized so he was thinking about the uber you know or the google maps and all these companies but it turned out that with chat gpt and open ai things were shaped in a very different way that he expected just because now the underlying services were actually, you know, disrupted themselves. And it'll be interesting to see where it goes. We're very early in this whole thing, you know, so but I really think that the autocorrect is a beautiful way, is a beautiful example of this, of thinking of it as a technology input when we're shaping a solution to a normal software problem. You know, it's just that now we have another tool which can allow us to do things that wasn't possible before. And it doesn't mean It's all about chatting or generating this like mid-journey type stuff, which is also amazing. But I think we're going to see it more as something that goes down into the toolkit that informs what's possible in all kinds of different software experiences. Thank you so much, Ryan. We're at the end of the podcast. Yeah, thanks for having me. Really enjoyed chatting. Likewise. I'll make sure to add all the references you mentioned in the description. And to continue the discussion, where can people find you? So I'm on Twitter at RJS. And my website is feltpresence.com and you can find links and pointers to shape up and shaping in real life. The new course, all of that is there on feltpresence.com. Great. Will do. Thanks, Ryan. Have a good one. Thank you for listening to the June podcast. If you enjoyed this episode, please leave us a five-star rating and subscribe. This episode is powered by June. For a better way to do product analytics, visit june.so.

I sat down with Ryan Singer, the Head of Strategy at Basecamp for 17 years, and author of Shape Up, one of the holy grails for product builders. 



A builder at heart, Ryan is obsessed with creating better processes for design and development and offered his insights into collaborative work styles, deep programming practices and adapting to industry challenges. 


Ryan also touched on effective prototyping, gaining insights from other industries, rethinking the development process, navigating discovery cycles, shaping great ideas, and leveraging storytelling in product development. 


⭐️ What you'll learn in this episode


* How the software industry is maturing…
* … and what that means for the way we work
* Prototyping and the shaping phase of product development 
* How AI integration will impact products 
* and more!




🔗 Where to find Ryan Singer


* Twitter: https://twitter.com/rjs 
* Linkedin: https://www.linkedin.com/in/feltpresence/ 
* Felt Presence: https://feltpresence.com/ 
* Shape Up: https://basecamp.com/shapeup 


📊 Where to find June
* Twitter: https://twitter.com/JuneDotSo
* Linkedin: https://www.linkedin.com/company/juneso
* Website: https://www.june.so/


👉 The June Podcast is powered by june.so 
Discover a new way to do product analytics at june.so