Latest / Fractional Frequency / Scaling Brand: From Founder-Led Product to Mature Velocity
Transcript
- Billie Tienda: Hey Jenna. Hi, Erin. How are you? Good. How are you? I am fantastic. Excited to have this conversation today. Me too. I am very excited because in this episode of Fractional Frequency, we speak with Jeremy Blaze, a London-based product designer, multi-venture founder, and head of the product design agency Never Before Seen. Jeremy will discuss the current insane pace of software development. Where the bottleneck has shifted to product. The conversation will focus on how to build product velocity and scaling momentum without accumulating long-term debt, how quality will become the differentiator as more swap is getting shipped. We will also delve into the transition from founder-led product to a mature product function and a practical approach to integrating AI responsibly. Jeremy, welcome to the podcast. Thank you very much for having me. Yes. So why don't we begin with you telling us about your journey on becoming a multiventure founder and pro and the product designer leading never before seen? Yeah, I think you ⁓ you covered the basics pretty well there. I got into product and design through what is a pretty standard path, which is I was sort of I built websites when I was younger for people and that sort of eventually transitioned into Products work. I got a holiday job at a at an agency that was doing web design and product stuff and quickly sort of found an interest in the in the product side of things ⁓ through that. So really just got into it through like an interest in design and wanting to make cool stuff, which is a pretty standard technologist story. And then since then I worked in inside of a few startups ⁓ and sort of freelanced all the way through it sort of just I just wanted to work on a big variety of things. So I always took whatever jobs came came along, whether they were consumer or business or whatever else, just to sort of stay interested. And yeah, that led me to I enrolled in a computer science degree very briefly, left I'd sort of always always known how to how code, at least somewhat, never been particularly good, but just enough to be able to build build my own ideas. And slowly just built up a little portfolio of Bad projects and things, which some of which grew, many of which failed. Awesome. And I I think it's really important that people understand that there is going to be failures, right? It's just not this linear road to success always. And so it's helpful to have, you know, those failures that you experience because then you learn from it. So you noted that the pace of software development is now insane, creating an extreme acceleration where the bottleneck is now the product. What Does this pace mean for founders and operators of product companies? This is all incredibly new. So I don't wanna sound as though I have a definitive answer on a lot of this because everyone is still navigating this, have ideas like everybody else about it. What seems to be happening is product engineering and design, right? So that the three main disciplines that went into like building or executing the product, those are kind of flattening into one discipline in many senses. Engineers are spending a lot more time doing work on the design side or the product side. Product people are shipping code. Now, designers are shipping code. It's where there used to be these sort of three silos, they're getting a little bit homogenized, which I think is a really good thing. Because like good product ⁓ good product managers or designers always involved engineers in the design process and vice versa. So I think having seeing that flatten is entirely a positive shift. I think. The challenge is that none of our processes have kept up. None of us know how to do this because we're kind of all just working across everything. And that's the different ways that people are trying to navigate that. Some people are just trying to ship way more because they can. The ⁓ the engineer, the cost of or time to build has plummeted to nothing. So now product and design, as soon as they have the the PRD, like the requirements document ready, send it into the AI. And a few hours later you've got you it's built, then you can ship it if you want to. Well, you should, that's a whole other thing, which I'm sure we'll get to. The way people are doing it is rather than trying to ship a larger quantity of stuff, they will sort of they'll continue with a similar approach to how it is now, except they'll make each individual on the team broader reach. So a product manager might ship a feature end to end. So they might do the design, the product, and actually ship it. And same thing with an engineer. So the sort of the idea is like it's the it's the feature CEO. So they get a whole la fairly large portion of the product. And they're responsible for doing that end to end. That's another way we're s we're seeing people navigate this. And I'm sure there are lots that I'm missing as well. But it's sort of just interesting seeing how we deal with this like massive change to the process where the engineering, the time to ship has plummeted to nothing. It almost seems like you have to be able to do all three in order to I don't know if it's being successful, but be able to be in this phase of or this pace like you said, right? Like you said it was, you know, it used to be siloed, but now it seems to be it's like you're it's an all-in-one, right? There was always a lot of overlap between those three, right? Any any great designer always knew a f a fair ⁓ probably probably could code to some degree. Any good product manager understood some technology tech architecture principles, even if they couldn't like write code themselves. That goes with with ⁓ sort of across all of those disciplines. I think you're right though that it is it is homogenizing quite a bit. And but also the barriers to upskilling in those other disciplines is much easier. And if an engineer wants to upskill in productive design capability, that's much easier for them to do. And obviously it's much easier for designer to upskill in engineering. Yeah. And that makes sense. So How do teams build product momentum and scale product velocity without leading long term design? I think if you can ship anything, you've got you've all of a sudden got a new question, right? Where we can there there's a dangerous pathway here where we we're talking I can't remember if this is before we hit record or not, but there are lots of there are lots of failures in every in in every product person's past, right? ⁓ that there's not all of your ideas are great. And the problem is we can now ship all of our ideas, which is in one sense amazing. That's That's really exciting. But also we not all of our shouldn't be shipping all of our ideas. Right. So a lot we now need to sort of I hesitate to say this, but we almost need to intentionally slow ourselves down a little bit now to avoid shipping rubbish and make sure the stuff that we ship is actually going to drive some sort of value and not sort of turn the product into this weird hodgepodge of of various things. I think to Continue having a unified product rather than just sort of having it give s sort of spit up these different directions and be hard to define, which is again something we're starting to see. Thought come to mind and like more of a kind of a how-to. So you have worked across a number of different environments and you mentioned it's important to slow down so that you're not just shipping everything to mind top the second it comes. What what have you seen work well in terms of teams like asking themselves questions or or pausing to evaluate how do you choose in the moment what is high quality versus what really shouldn't be shipped? Yeah, how to define quality. That's definitely a challenge. ⁓ the something I think that is really important is with very few exceptions, it's I think it's important that a product is very easy to define. You should be able to say what what this thing does or what value it's meant to provide in a sentence. And it should be very obvious what what it does. There are lots of products that we can think of where that's become really might be another. Facebook would be another. They they don't sort of solve one thing, they have a million different things. That's a strategy, but it's a unique one which most of us aren't trying to do. I think it's important for most small and mid stage startups or a product to be really easy to put in a sort of d to to define. And the danger with shipping every every idea that we we come up with is that gets that product definition gets really, really murky. So that's one test is like a you know a SaaS tool for or managing go to market teams or something. Does the feature that we're talking about here, or the the widget padding, does that support that's that's a really important test. Another one is just ensuring that you've had some you've given it some you've you've sat with it a little bit. You might you might ship it to a small number of you to a prototype and send it to some to some advisors or s a f a small group of users that you're you're close with and sort of try and get some feedback and see whether this is being solved in the right way. It's really easy to jump at solutions. We all love doing that, right? We'll we'll find a problem and we'll immediately come up with a solution to it. Is it the right solution? You can't really know that until you've tested it a little bit and spoken to some people and tried to tried to sort of pull it apart and pressure tested it a bit. And once you've done that, you'll often find that your first the first solution you came up with was maybe not quite as hot as you thought it was. I think it's important to not skip past that, which again is a danger of this sort of accelerated pace. And about the like the litany of features. I was on my phone yesterday and was served suggestion about downloading I and my knee jerk reaction was like I'm exhausted. You it on one hand, I'm sort of you know compelled to check it out, right? ⁓ and on the other hand, it's like one more Facebook add-on feature and understand and incorporate into my life. So that makes makes a ton of sense. Thank you. It's like as soon as you learn one feature, they have another one. And then you're like nah self. It's just it's it's constant speed. Yeah, and and and that that's an interesting additional bottleneck further down the road, right, which a a lot of people are talking about now, which is what is an appropriate pace to be f shipping features that users can keep up with, right? ⁓ there's i if if Facebook is mobile major update every day, which theoretically they could do, like they they have the capability to, everyone's just gonna get overwhelmed by that. Packaging becomes even more important. Yeah. Yeah, I think about even just like our iPhones, right? And how much they constantly update. And then you have the cars, right? And it's just they also need to ensure that they're setting out some sort of training mechanism or manual on how to, you know, what is right to ensure that it's being adopted if that's the goal. So I I guess what is, you know, what is the hardest part about navigating the transition from a founder led product to a mature product. in terms of the cadence, decision making and hiring. I think it goes back to everything that we've just said in that the A good product cycle will add something to the product that meaningfully creates additional value. But we need to make sure that the thing that we add is supporting the thesis, the product, is supporting the users that we're we're serving. The transition from founder to more ⁓ broader product function or founder led product led product is the challenge with that is conviction into what the product should originally do. you get a lot of that adherence to the core thesis. A lot of that ends up coming for free. You you don't the the founder doesn't necessarily have to think about it because normally very clear vision for where they're wanting to take that. As you other people start to articulate their own visions for where the product should go, you do have the risk of in different directions. Now, this is something that we all know how to navigate. There's we've got to communicate the vision to to the team so that everyone shared to work towards. And when led in in a in a careful manner, that's that helps sort of make sure that the product does continue to go in that direction. Product managers, that was kind of that's that's one of the core roles of a product manager, right? Is is to make sure that it g continues going in that direction. That does raise something about, you know, as product management is decentralized across engineering and designers, then you know, we just gotta be little bit maintain that. Again, we are shipping that. spiky, murky ⁓ yeah, yeah. We've Jeremy, we've talked a couple of times or sort of brushed on the impact that AI is having i in the space for all product companies, for ⁓ product development, software development. I'm sort of curious to spend a little bit of time on that with you. So what is maybe start by telling us about Your approach to incorporating AI and product development, including maybe maybe how you think about RISPAR, you think is is okay. Well this I think the using AI to build the product is that that's actually an easy one. I think ⁓ you know vibe coding as we're calling it and now as some people are calling it agentic engineering, is a challenge in that we we have The the fear at the start when we when we were all starting to vibe code was, ⁓ we're shipping all this code and none of us know what's happening under under the hood. No one know no one actually understands or has reviewed the code. Now that might be an issue at some ends of the spectrum of vibe coding. Most like any mature product company is having engineers review it. ⁓ we can even get agents to review our code. I actually think that's much less of a an area of concern than people people think it will be. I think what will happen is we are all shipping way more. Anything that we were shipping always had huge software companies still every few a massive attack or or some snafu with their with their product, it happens. We're never going to diminish the road. I think AI is actually around them a means of making it more dangerous. I think if the product handles ⁓ complex or ⁓ complex matters. So if it's dealing if it's moving money around, for instance, we need to be really careful. And that just comes down still to responsible engineering, segregating services appropriately and good security practices, and keeping your engineers involved in the in the design of the the of the system. But that's the engineering, the process side. The user side, I think, is in many ways much more interesting and much harder to answer AI there, because the challenge there is years ago when we we weren't shipped with AI in them. There were y the scope for misuse of our products was very small. And when I say misuse, I I don't necessarily mean that we didn't predict, right? People mostly we had a very we would the product would guide people in a specific way and they would use it mostly within how we expected them to. Now, as we ship these really fl actually know how people are going to use right because they They're infinite in ⁓ in their potential application cases. So I think that's really interesting. The challenges we're seeing with ⁓ with interface design now is you know, we we all jump we're all using the the chatbot a lot now as a as an input method. And I think the chatbot is a really good input method, to be honest. ⁓ that's the potential designers like to hate on the on the chatbot. I actually think it's really good. But it is a bit of a black box problem, right? One of the key things in UNB able to try sort of progressively demonstrate new areas of the product to a user as they got to know the the system better be harder now. Because when we just give them a chat window, y you might see some cheesy suggestions underneath for how to get started. But a lot of the time it's a pick your own adventure paradigm, which doesn't easily help people sort of level up. So there's something to be really intentional about a shortcoming of of this new method ⁓ or this new input pattern. But I think that's another area where the process or the the patterns that we have haven't really kept up with where the technology has gone. It's we're seeing lots of people answer this in really interesting ways. But balancing that should the product be opinionated question with the how do we let people do whatever they want with this product piece. is really difficult. And I think it has Yeah. Yeah. That's interesting. And I'm sure that's a a large part of your conversations on a daily basis with your clients and trying to a really I'll I'll g I'll give you a ⁓ it's just come to my useable example of that. Like from the SaaS world is every SAS app is is adding this at the moment, which like the the first AI feature of SAP ad is AI reports or something like that. Or maybe it might be AI search. But if if there was an an analytics module in our in your SAS app, you you're probably gonna start seeing AI get added in there at some point. And all it will do is build out the queries to cr generate the report. And the question immediately comes, okay, if we're doing that, do we still provide the stock standard reports or do we just let people build their own? And the answer to that is probably, yeah, we should provide some building blocks so that they can get started and allow them to customize. But again, it's just really simplistic example of We could go completely the pick your own adventure route. We could go completely the really opinion it. Yeah. Yeah. That makes that makes sense. I you know, I think increasingly like people need things to react to and and where I've interacted with products where that's not the case, ⁓ you know, it can be kind of hard to figure it out to to try to get there. We talked last time, Jeremy, we were talking a little bit about what AI is good at. And you mentioned that you feel like there's a little bit more strength, at least today, in the softs than on topics or tasks that are more rigid. But that if people don't love to have that conversation, but you think it's an important one to have. So tell us a little bit about your perspective there and and why more creative teams should be. AI is obviously fantastic at fantastic at writing code systems. an illustration. There is not necessarily a correct answer to any illustration brief. There are probably there are many correct answers to that illustration brief. To the brief of Zap, there's a much more g ⁓ answer, right? And I think the we need to make sure that we're getting getting used to using AI for those areas where there's not necessarily a clear single they're not deterministic. It's not it's not a simple calculator that we've done. I think this is what we touched on last time. Is It's also really difficult to measure success when you start applying AI on the softer side. It's really easy. Yes, the AI built a perfect to-do list app, right? That's really easy to define. But if if you ⁓ depending on where you apply it, this can be a little bit more scary than ⁓ in other places. But say you're building an AI product that is provides, let's say, companionship or something like that. If you're providing some sort of personal AI. How we determine what is actually for the user? That's really subjective. It's very hard to define. And we technologists aren't necessarily very good at defining that because it's gotta be defined in a in a social or an individual or a behavioral method. It's not it's not gonna be you're not gonna find a define success in a deterministic way. And I think that's sort of the paradox we have here, where we're trying to apply in these soft directions, which is grace. It's really difficult to see is it actually doing the thing that we want it to do. It's really easy to yeah, it's giving us results that look good to us, but that's a vibe. It's really difficult. Yeah. Yeah. It makes a lot of sense. I I think that you know it's probably a conversation that'll percolate for a while while we wrap our arms around how work is based in in the coming year and beyond. Some Jeremy, and just talk a little bit about leadership. You have been involved in a number of different ventures and startup environments ⁓ in a leadership capacity. As you think about just various lessons you've learned during your career or over your career, what is maybe, you know, kind of the top one or two pieces of advice that you would have for an early founder in that realm. And I've not much experienced startups, more been across the more creative or business application. I think something that that's really important is striking a balance between the mindset of just ship it, like you know, race race to ship something as soon as possible, versus the alternative mindset, which a lot of creatives gravitate towards, which is only ship it when you're happy with it. What once you're proud of it right. Those are very there are there are examples. Figma is a great one, but we probably all know it took like three or four years to ship a product. Their investors were freaking out. And that's an example of one end of that spectrum. And then right now we're seeing everybody launch an app in in a weekend, other end of the spectrum. I think neither is correct. The the the answer is is always somewhere in the middle there. It's gonna be different based on the product. But I think making sure that you ⁓ you strike that is really important. And I think that's answered at the start by defining what do I what do I want this product to do. And the moment you think that it actually fulfills that value in a meaningful way, think you I think that's that's the moment they use it. Yeah, I I can totally appreciate that we were evaluating some candidates ⁓ for a position at Strativist actually in the engineering space in the last couple of of weeks into two finalists and had that dilemma. There was one that you had a technical exercise that was good, maybe not great, done really fast. And then the second one was great, but took more time, the the merits of of each. And ⁓ and it's you know, sometimes an answer that's not not totally clear, but I, you know, I think to your point you even said in the conversation, Jenna, it'd be nice to have a combination of two. You know, somebody who's interesting ⁓ and also a great product. And so I think that's for P product world. I think, you know, there's there's another thing that sort of sort of as as we're talking here, and that is, you know, thinking about the various environments that you've been a part of. So you've seen Lots of startup companies taking products to market or attempting to take products to market. And one thing that we've talked about in the past actually is that you know this idea of like timing to market being, you know, maybe the most important differentiator for new companies, Guriz, for your on that, what do you think, or what have you seen rather, makes a really successful new company? Is it timing to market or is it something else? My view on this is starting to in is starting to shift a little bit with with what's happening at the moment. And my answer there would actually be that I think one of the things that people make a mistake of, myself included, is not spent on brand. ⁓ That was fine five years ago. Now the challenge is that everyone, every person with a technical ability can ship a ship as in a few days. And it will look exactly like that. And it's really important now that we actually spend time to are making it making sure that we're differentiated from that cohort, but also so that because I think brand is going to more and more become a point of difference. Technical most is becoming like now as in a like a technical competitive advantage. I have a who was showing me this ⁓ about a week ago. They were their ca the calendar app that they were using was frustrating them. They wanted they wanted one they set Claude code to run throughout two days and it clones the whole calendar app and they added the feature. So they feed the entire application and just added the new features for themselves, and they now they now have a working version. Which just goes to show, like for a few hundred dollars of Claude ⁓ of Claude tokens, you can now clone an entire But the technical ⁓ like overhead to shipping this stuff is so low now. The differentiation has to be somewhere else. Is it is it network effect? Is it brand? I think it's gonna vary across across price. But I don't think it's technology anymore unless you're at some really pointy end of research or s like scientific Is he selling that calendar feature? Because the calendar drives me nuts. So I'm in the market for a new calendar that ideally can combine all the calendars that I have just after this. Well, to build your calendar app and and ⁓ Jerry, I think that's that is like so, so interesting. It has me thinking a lot about ⁓ a lot about just the brands of companies that we work with and in our own brand, I think that can takeaway and and think critically about. We have a couple of just kind of practical takeaway questions that will ⁓ fire at you to to wrap our conversation. And so the first is is kind of ⁓ digging into the the product. Space again. So what is one question that listeners should ask themselves this week about their product quality standards? I have the answer for this, which is I I've I I've always wished I had a better way of explaining this than I I do. But this is especially a pr ⁓ a thing with with SaaS products, is that I think that we think about SaaS products in a very two dimensional way a lot of the time, right? Which is that we divide divide them up based on what the nav bar ⁓ shows on the left, what the what the ⁓ what the app's menu shows, and then we think about them as discrete things like that. I think what's important is three dimensional product thinking out turn. But I think it's really important to sort of ta take stock of your product and think and try and zoom out and see where should these different independent components be are there ways of centralizing any of these in a bet in a better way? Are there object abstra abstractions that we could use to To divide up not the different facts or objects or components of the product. I don't know if that makes sense, but the idea is trying to see like what like the layer across all the different distinct things that our product does. Is that is that like is that layer clean? Is that pathway that that traverses all of the all of the different offerings? Is that clear? Yeah. Yeah, I think there's there's a red thread that I've heard about simplicity in just the way that people are interacting with products. And ⁓ it's a good reminder. I think probably people, you know, know this, but are easily distracted by the bells and whistles and various hypering to the tape. Thank you for that. Okay. Last ⁓ last question, Jeremy, as a as a leader and practical leadership tip there for for somebody who is in any leadership capacity at a startup or or fast growing company. I'm actually gonna borrow what you were mentioning before about your hiring conundrum where you had one person who shipped something very quickly and it was and it was fine, but and then someone else who shipped it a lot more slowly, but it was really good. I personally think you should you should try and lean into the person who can ship who can prove that they can ship the really good thing, even if they can ship can only ship it slowly, because I think it's i to make that person more efficient. I think the I think me into into my suggestion here, which would be try and measure the input, not the output in a lot of these cases. In any creative discipline, it's it's really difficult to predict how long something we all we all, I assume Esther and and have have lived this trying to write a proposal on a creative project where we're not sure exactly how long it's gonna take because until you do the project you're not gonna really know what's involved in it. That's kind of the nature of this a lot of the time. Until we've done it, we don't know how long it's gonna take. And that's That's that's some in some ways going to be true. That trying to get them to ship something as soon as possible or come up with a solution as soon as possible is always going to lead to a sad part result, in my opinion. What's important is to say, okay, we have this problem, we have this amount of time in which we need to solve it. Let's try and use that time to the best of our ability. Rather than saying just try and get that time down to us as quickly as you you possibly can and say, right, I can afford to spend eight hours or six weeks on this problem, six weeks. And we'll map out how we're gonna do it over that scale. I think measuring the input rather than the output is really important. And you can apply that individually or across a business. I like the way you think about that. ⁓ and speed is not always not always the answer. In in our industry we we have a sort of a triangle that we often refer back to speed, quality, cost. And everybody wants all three. ⁓ you can't have all three. You can usually pick two. And so you can have a conversation about that. But Jeremy, thank you for spending time with us. It's been great to pick your brain and ⁓ you know, maybe borrow some of your best practice, ⁓ both for us and and for our listener base. Really appreciate you ⁓ sharing openly about your approach. And so if if listeners want to ⁓ learn more about you or engage with your firm, where can they do that? Yeah, they can ⁓ they can Google Jeremy Blaze or Never Before Seen, ⁓ which is the name of my studio, and they'll be able to find us that way.