Tack On, or Rebuild?

Hi, folks. Welcome to today's podcast. For those of you, I haven't given it a name, because for those of you who have been trying to keep up with the way that we've rebranded stuff, this used to be called Engineering Evolved with me, Tom Barber. Uh, it's now called Concept to Cloud because me and Amelia were sitting, talking about how we should name things, and she was like, "Why don't you just name the newsletter and the podcast Concept to Cloud? " So welcome to the Concept to Cloud podcast, cleverly named, I know, uh, where we discuss everything to do with both product design, UX from Amelia's perspective, all that type of thing, and then also product engineering, how we go about building these systems out, and just like, you know, try and educate the world as to some product thinking, product ideation, and also just things that we've seen or things that we've done over the years that maybe weren't the best.

So thank you very much for tuning in. Uh, once again, this is the Concept to Cloud podcast for anybody who isn't keeping score. Um, okay. So we're gonna get going. Um, and we're gonna have a, a bit of a conversation here about some of the stuff in the newsletter.

So if you haven't subscribed to the newsletter, go ahead and subscribe. There's, uh, thoughts and ideas and opinions in there. That'll be coming out every couple of weeks. Um, and so we're gonna kick it off with part of my, uh, story or article inside of the newsletter, which is the things that you can't see. Um, and in the newsletter I was discussing about the fact that f- for those of you who don't know me, I used to run, or still do run, the Seikou analysis platform, OLAP analysis platform, now called the Semantic Layer because apparently everything needs to be semantic- [laughs]...

in the AI era. Um, but obviously there's still a lot of installs out there in the world where people have installed this thing and continue to use it. Because I went off to NASA and went and did a whole bunch of NASA stuff, and people continue to use these, like use this tool. Just because you stop, you know, developing things doesn't mean that people stop using it. Uh, but what happened recently on a vacation that wasn't really a vacation was that, uh, I tried to find out how good Claude was at restarting- [laughs]...

uh, old projects and like could you, could you even still build the thing? That then snowballed into rebuilding Seikou and taking it forward. Um, but in terms of installs, so we've seen, uh, 97 new installs since we rebuilt the thing, which is pretty cool because, you know, it's, it's, it's grown once again from not very much to, you know, nearly 100 installs. This was a week ago, so it may also have changed. It's probably gone through 100.

Um, you know, people who have downloaded it, evaluated it, and are just interested in installing, um, Seikou inside their environment. I still get some metrics though back from, back from back in the day, and still get pings back from about 180, um, old Seikou installs, um, which is, um, sizable. And of course, you know, two-thirds of the people who I can currently see are working on an old one could do with upgrading. But this of course is a bit of an issue across industry as a whole because trying to figure out how to patch vulnerabilities, upgrade people in an environment where things are on-prem as opposed to SaaS is, is something that's quite tricky, something that's quite hard because, you know, you just don't see, you don't see those people, and engaging them and going, "Hello," um, is obviously, is obviously quite tricky. Um, you know, we've got, uh, your kinetic recorder as well.

That sort of falls into the same bucket of downloadable software, and so reaching out to those people from a product perspective is something that's quite hard. I mean, yeah, that one's difficult because if you're building from zero to one, and you know me as a product person, now with the age of AI, I can build things on my own, but putting in the engineering that like needs to happen, um, to track bugs and, um, make sure that like feedback forms go to the right places so that I can address things quickly, like it is very difficult, right? And, yeah. Where, you know, when it comes to product, um, installs and what have you, like, you know, we're sort of duty-bound as people building products that get installed on-prem to put some sort of ping in there. Mm-hmm.

Because you need to understand if people are using, to your point, if people are using features. Mm. Is it worth developing that feature further? Do... What people want back from it?

Now, some of that you can get obviously from questionnaires or asking on social media, talking to customers, that type of thing. But at the same time, you know, so much, especially in the open source world, so much of what we deal with are people who you will never see. You will never interact with them. You have no idea who they are. And so putting in something like Sentry, even just from a telemetry perspective, or if it's web-based, just a like a Google Analytics cookie or something that allows for that to come back to you- Mm-hmm...

just to tell you that you've got an install somewhere or, you know. And it's not about tracking down IPs or figuring out who the people are. It's more, as product people, the desire for us to be able to understand who's using the product and how so that we can improve it- Yeah... over time. It's anonymized product research, right?

Like that is what it is. It's understanding who's using what, what's breaking, right? And then you wanna get into the inside of a product. So you wanna get past, you know, the things that, you know, are buggy or the things that we didn't execute properly, or in building a lot of zero to one in multiple platforms at a time. You know, you can build out the happy path and the critical paths, and you can start to see where people are gonna flow outside of that, the other things they may wanna use, the ancillary features that are there.

Um, but to- To allow us to really see what a user needs, those things have to work. And so, um, it's all anonymized obviously, right? I don't know who's doing what. Um, but it gives me that feedback to know, um, you know, if I open this gate or if I fix this thing, users are gonna flow through it. Um, so it's just product research in terms of developing a better product for the user themselves, right?

Um, a lot of the time, like you, you can say like, "Well, I have a need for this, and I work in a certain industry, and I know this tool is gonna be useful to me," but you have no idea how massively that's gonna go. You don't know how it's gonna scale. You don't know how it meets people in different industries, environments, situations, um, different levels of, you know, computers. Like we're in product, but we all have, you know, fancy Macs and things like that. We have things that are not necessarily accessible to the rest of the public that we're building the tools for.

So all of that becomes very important in terms of, um, really opening your perspective, uh, into the products that you're building. 'Cause if you are, if you are building something that you want to be helpful in a certain situation or you want a lot of people to adopt, um, you know, you've gotta, you've gotta make it malleable, and, and that takes a lot of time. It's easy to build the initial concept. It's a lot harder, um, to make it widely accessible, um, in all the different ways. So yeah, very useful.

I always think it's, um, understanding. Like we can chuck features out there, but really understanding like are people going in and experiment- experimenting or just testing with the feature and then just- Mm-hmm... abandoning it, or are people using it to a point where, oh, actually we should invest more time or like work with our customers and say, "Look, you know, we built this feature for you. " Mm-hmm. People are using it.

Why don't we go out and get some feedbacks and do some market research on that feature so that we can improve it further, add more value, customer retention, all that type of stuff. Um, you know, because that type of insight is crucial to defining your product roadmap, especially when you've got something that's mass market or like freely downloadable. But you really have to be able to listen, um, which is obviously what I focus on in our newsletter this week. Which takes us on to, um, your section in the newsletter, one of your sections in the newsletter, which is the bias in what we hear, you know, especially as someone who works in, you know, product road mapping and research. Yeah.

Well, this is, this is a big thing. So I, you know, we talk about product and we say like, "Okay, we need to do the product cycle, and we need to get user feedback, and it's an iterative process. " Yes. All true, right? And then we say, how do we make this user feedback easy?

Well, we're gonna provide them forums. They can give us bugs. They can give us feedback. They can give us features, right? And, and that's all really great.

It is really great, but all of those things are still framed within the product itself, right? And a person's experience exists outside of that product. If they're going to, um, a banking app or something, um, you know, they're checking their balance, but why are they checking their balance, right? Th- and this is just an example. They may wanna transfer money from one bank to another or, or move things around or split things up, but that banking app only does a couple of things.

And so we say, "Hey, we've made it really easy for you to check your balance," you know, but we haven't, we haven't actually listened to what their whole workflow is, what they're actually trying to accomplish. So the bias of listening to feedback that we stage, th- those feedback forms are important, but they're staged. We're asking for feature improvements within, um, the platform, and sometimes, you know, y- customer feedback will come through. We're asking for any bugs, which is again, constrained to the platform, and then we're asking for, you know, any other frustrations or, or what have you. Um, and that might be in the use of the platform.

That could be in the UI design. That could be in the UX design. That could be still, um, users coming in and talking about their frustrations using the predefined offering of the platform or product, right? And so, um, that isn't to say that all customers will speak like that. Like, some will say like, "Hey, I need this to do this," or, "It would be really cool if you integrated, you know, my la- like Citibank with Plaid technology.

" I don't know, I have no idea. Um, but you don't often get the customer that's gonna say that. You get the frustrations. You get the things when something didn't work the way they intended, when they were far down the funnel and had tried a bunch of times and got so fed up that they actually decided to fill out the feedback form and let you know, like what wasn't working right. You don't get what they were actually trying to achieve.

So there's a huge bias in product development where we basically limit the vocabulary and the perspective of our feedback to our product, and this is where listening comes in because this is what, uh, you know, this is where UX research goes back and product research becomes so important. You need to sit down with your users, like one-on-one, and actually understand what they're doing. You need to understand what the workflow is in their life around the product that you've created. Um, and I think that scares people a lot because sometimes that's do we add on more features? It's do we rebuild something entirely?

Um, but it shouldn't. Technology is always evolving, and you know, somebody might have a new tool that they now want integrated with this tool. So it's, so it's not something that's, that's scary. Um, it's something that should be encouraged because it keeps the product up to date. Um, you know, for product people, I think that's s- you know, experienced product people, I think that's pretty obvious.

I think in this age of AI, though, people are making platforms, and they're like, "Well, my UI came out and it's so nice," and they're understanding this, but product thinking has kind of settled to the bottom a bit, and now it's starting to come back up. You know, AI's been popular for what? A year or two years, like really picking up velocity, and people are starting to see the shortcomings of, of the product thinking. So it's, um, all that to say the listening outside of the scope of the product that you've made is actually very important. Um, yeah.

Well, I think, um, like we notice it- Regular enough. Like when it comes to AI-driven product development, right? Mm-hmm. You can... A bit like when you're on LinkedIn, and you can spot the AI-driven comments and posts and what have you from a mile off, to a degree you can see the AI-driven product development as well.

Yeah. Because so much of it in terms of, like, not necessarily the, the way that the applications operate or function, but by the way that they look, they feel, the sort of flow that you get out of them. Yeah. You can sort of tell what's been AI, AI-designed. B- yes, because oftentimes that comes from somebody giving it a prompt, and they get a really good set of screens, and they get a really good set of first levels of screens, but as soon as you start getting into the depth of a platform, whereas on an old website you could have gone, you know, pages deep into something, maybe you need to, maybe you don't.

As soon as you get, you know, one or two levels deep, it's talk to the chatbot or, um, email us for support. Like the, the depth and the care is not there even if the site looks really nice on first view, but that makes a huge difference in the customer experience. Because if somebody's, was engaged enough to come to your website to go through to find that information, you've kind of lost the plot now. Um, and yes, you can see a ton on LinkedIn with, like, AI comments, but AI websites and AI, like, platforms that are using AI, I'm not knocking all of it. Some of it's great.

Like we use AI a ton. Um, but it's about not... AI, [laughs] it's kind of like walking a dog. Your dog shouldn't be leading you [laughs] when you walk. You have to lead the AI.

Like you need to direct it. You can't just, like, s- let AI, like, go and make everything and be like, "Okay, that's good. " That's what I get for walking dogs this past weekend. It's fine. But you, you know, you, you have to tell it what to do.

You have to tell it how... You, you direct how you want it to execute. Um- So, like, this is a lot of, like, the stuff that we end up, like, just collaborating with people on, is like, you know, someone comes to us with a thing that they've built. Yes. Um, and if you go to our website, you will find a product audit service that we offer.

[laughs] So if you want some of this, uh, this, uh, thought leadership and ideas, go and, uh, like, stick a, a date in a diary, and we will go through this. But, like, a lot of what we see is, like, a great first pass because Claude or Codex or what have you- Mm-hmm... will tell you that everything has been done and it's amazing. Yep. But then that may be, to your point earlier in terms of, uh, vernacular, that may be the happy path.

But then when stuff goes wrong, it's not really been thought of, or edge cases or anything other than this is how the user gets to my site. And so AI also, like application. So like, you know, Claude or your favorite tool has got, you know, I don't know, three quarters of the work done in a reasonably generic way because, of course, AI learns from other sites. So, you know, whatever happens to be popular at the time seems to be a compounding thing. Um, but at the same time, you get to a point where it'll tell you that everything's done and your product is shippable.

And of course, it may be shippable, but you may also have a whole bunch of blind spots in there that you've not really- Yeah... considered because your, you know, as a, as a developer, AI has given us the ability, us engineers as opposed to product people, the ability to be able to knock these things up really quickly and efficiently and effectively on mass, which is why obviously so much code is being developed at the moment. But at the same time, without the real contrarian thinking that you get when you've been working in the product field for as long. And, and in terms of, like, blind spots, it can be things like something went wrong, I can't see this button, or, you know, when I click this, this screen pops up, and then some of this is just, like, UI checks and the, it's buggy and stuff like that. Um, if that becomes a consistent theme though in your UI, it will just lead to a frustrating experience.

If you're doing something that's already somewhat, uh, intensive or, like, data heavy, um, that just becomes... That's just like adding fuel to the fire of frustration. Um, but the other thing is, is sometimes AI develops things that work really well from a programmatic perspective, but they don't take the user into account. You know, they don't think of all the different users that are going to be using something. Like, um, you know, maybe a programmer is using a tool, but maybe also, you know, a marketing person is using the tool or a data analyst who doesn't have the same depth of knowledge, and it doesn't provide, um, frictionless ways for people on the same team to communicate or see the same information in a way that they can digest, right?

So from a product perspective, you don't just think, "Here's what I want this to do. H- go ahead, AI, and do it, and make it possible. " It may only make it possible through one lens that is largely, um, colored by the person who is giving the prompt and not by the recipients or whose, or the people who sit at the other end of that product. You'll end up with, um, you end up with software that I think doesn't meet higher criteria situations, the needs of higher criteria situations. Um, and at that point it needs guardrails.

At that point it needs to be packaged of where you can use the AI. Okay, you can use it at this level. [phone ringing] Oh. There we go. Do we need...

Do I need- No, it's off. Sorry, it needs to be packaged. No, you could... I was just gonna say that you have to put guardrails around AI, so you can put the workflows where they can fit and, and not just say, like, "Here's an AI. Come interact with our chatbot," or, "Here, AI will do it, and we're gonna put an AI engine over everything.

" Like it, it has to be you'll engage through this gateway, past all your security checks, past all your data structure, and AI can process the things that are here in this space, and then we can output it, you know- To whatever the next phase is, but it's just using AI not as some magical wand that can fix everything, but instead something that is just a machine that does some form of processing that you can trust, and then output it. Um, I think that's- Excellent... the consensus. All right. That's the end of the first part.

Now, a word from our sponsor. [upbeat music] Why hire when you can partner? Concept Cloud's leading engineers build your startup's prototype without the overhead. Launch faster. Conceptcloud.

com. Okay, we're back, and we're gonna talk about whether we should be tacking onto a product or rebuilding, and the thought process that sort of goes through, like, some of that. You talked about it a bit in the newsletter. I wrote a bit about it in terms of, you know, um, [lip smack] features that need to be added on, or do you just start again at some point? You know, do you just call it a day and start again, or start something adjacent?

Um, you know, a lot of the time, especially from an engineering perspective, we try and end up using feature flags to be able to switch things on and off. Um, and if you've not used feature fag- flags, they are great, um, in a lot of cases, because you can switch functionality on and off, both from a, like, "Do we even want to release this thing? We have released it, but we don't want people to see it. We would only like a certain, you know, proportion of our population to see it," or that type of stuff. Um, and you can obviously trigger these things.

But it does become a management thing as well- Mm-hmm... because things like navigation menus and all that type of stuff need to be able to react for, for those things to exist. And also, if you're just turning elements of a screen off, you need to make sure that the rest of it still behaves to a user who can't see that functionality, like, appropriately. And so sometimes you get so far down those weeds that you're like, "Well, actually, I should just start again. " Um, you know, especially in open source world, where it's great just to, like, add new things, and as we keep talking about AI, I mean, obviously it's quick and easy to add new features and functionality to a lot of stuff.

Um, but that doesn't work from a, from a customer perspective. Obviously, if you've got a commercial product or something, and you need to, like, be able to expand this stuff, you need to figure out whether or not you are in a position where you want to be able to add a feature or rebuild. Um, so I think all that's true. When you have feature flags, and it's like, "Okay, I want to turn this feature on, I want to turn this feature off," I think that's kind of, um, a simpler case for it, right? Because it's, "Maybe this is too hard to digest.

Maybe this is good for this customer. " You know, and maybe you get into, like, we have feature flags because we have role-based stuff, um, role-based, uh, systems. Um, but the one thing I think about is a lot of the time, uh, with data research and dashboards, right? If you have, uh, created a feature as a product designer, and, um, that feature serves a particular... From a dashboard perspective, it serves a particular group, and it gives them a collection of insights, um, those insights might be useful to them.

Um, but maybe you need to design the insights to go across multiple personas or something like this. Maybe you need to adjust it, and in that case, a feature flag doesn't really work, right? In that case, you actually need to go back. You need to build your dashboard. Um, so we did something like this, where we chose one persona group y- in our, in our research before.

So we chose a persona group, um, largely based on the resourcing, um, and what we maybe should have done was base it on some of their, uh, interests, right? And it w- it was... The difference was important because of the privacy of the data, what they could access. Like, there was, there was relevance to, to, to dividing the groups in that way. But what may have actually served the product, and what have actually, what actually may have served the community better, would've been to align some of the dashboard's data output, um, around a different thread, right?

A different common thread that these people had, and maybe that meant rearranging some of the personas to say, "Well, this is the common thread on this vertical, and this is the common thread on this vertical, but this is the common thread between all of them," right? Um, and so in that case, it's... You can add on more features, um, to supplement, or you can rebuild. Rebuilding doesn't always mean you scrap the whole thing [laughs] and everything you've done. Yeah.

Right? But it does mean you take a few steps back. It does mean you very likely look at your data and know that it's already there, it's already well-structured, and you just need to create something else on top of it. You just need to output that data in a different way. Maybe you need to j- do data visualizations in a different way, and your rebuilding is essentially going through the product and doing a sweep of pretty much every touchpoint and stage in that product, um, to rebuild it.

Now, when you talk about feature flags, like, that can come into play too, because you might rebuild [laughs] this whole thing, but you don't want to dump something brand new on a user or on your customer base that they don't recognize, right? 'Cause they don't know that you might be reorganizing that thread. They don't know how their product will change. Um, and so slow introductions, feature flags, then become really important to shepherd that customer into something that is hopefully better for them, but also doesn't pull the rug out from them either, um, so they're not left with something completely unfamiliar. Um, so you've...

What I've just described is both rebuilding and tacking on post rebuild, but, um, I think there, it, there comes a point where tacking on features, if it's leading to, like, diminishing returns, and you're, and, and you're just not getting the adoption you want, you're not getting the conversion you want, like, something's kind of missing, even though you have great technology, and you're doing something really powerful, and you have, you know, amazing, well-structured, clean data underneath your platform, but people can't really see the value out of that, then you probably need to go back and look at how you can rebuild the customer experience to be something that is more useful to them. Um, and understand that the word rebuild is not as scary as it seems. Um, I think a lot of times leadership will hear the word rebuild and, and- The natural wonder is, well, why didn't we build it right the first time? [chuckles] Right? And it's, and it's a fair question, but it is a question that people will ask.

It's like, "Well, why did we get it wrong the first time? " It... And that is largely because as you start to see how people use things, they start to run into the limitations of it, and then y- it, it's just iterative insight, right? It's, it's always part of the process, and if you look at, you know, product industry as a whole, really for any product that has been made, it is constantly iterative. Um, so it sounds scary, but usually it's a good way of keeping a business kind of up to date and relevant actually.

So, yeah. I mean, one of the other things, I know we keep harping on about AI, but one of the other things that we see as well, and, um, one of my notes here says, "Keep it boring," which is one of the mantras that I try and come up with, um, in terms of like, you know, not just adding on features for features' sake. Um, but in terms of, um, some of the customers and people we've been speaking to recently, when I talk to engineers, they think about the speed that you can develop at, and that becomes a downstream thing. So, like writing the code is no longer the bottleneck. People would argue that, um, CI testing- Mm-hmm...

sign off downstream of engineering is now a bottleneck, which to a degree it is. But actually, I think they're sort of missing the point as well from a product perspective, which is getting a roadmap together that now survives like, you know, a few weeks of contact with a bunch of agentic engineers is pretty hard because of the sheer amount that they can churn through. You know, like what used to be a quarterly roadmap would now last a week and a half. There's no... You know, we've built AI, and we've built all these machines that can do things quickly.

Humans are still moving at the same pace, [chuckles] you know? Like our, our, our ability to digest information, um, our ability to digest information hasn't changed. The, just the speed of information that comes across our eyes is what changes, right? Um, and so that has pros and cons, and it's probably a whole other conversation to have. But, um, it is a huge bottleneck.

Coming up with a roadmap, coming up with a roadmap and pushing out features still at a faster rate is not always a great thing, right? Th- And that's not to say not to come up with the features at a quick rate. Um, it's to push it out and overload your user with all the new features, right? It's still bloat. Um, we talk a little bit about brand strategy and, you know, sometimes brand strategy is advice like, "Do the same thing over and over and over again.

" But if you're like, "Oh, look here. Oh, look here. Oh, look here. Look at all the stuff we can do," that becomes confusing for a customer. They don't know what they're getting.

They don't, you know, they don't have a stable, um, business to go back to. Um, and maybe it is great, right? Maybe the, maybe the core business is there, and, and all the extra features are experimental, and it's fantastic, and that's something that that customer base likes to do. But for most products, I think that would overwhelm the user. For most data heavy regulated products, I think that level of feature bloat can actually end up coming off as an untrustworthy signal over than a trustworthy one.

Um, and I don't know what that's like from an engineering perspective. Yes, developers can push out things very, very quickly, but I'm curious like how you make sure everybody's pushing out things of the same caliber and structure. I don't know what that looks like. Yeah, this is true. I mean, it has changed a lot, um, in terms of the way that developers develop- Mm-hmm...

because, like, you know, there's still an expectation that developers understand what's going on in the code. Um, but you're also then trusting the developer to actually spend some time, you know, looking at the code and understanding what's going on. Because at the end of the day, if you have a vulnerability, a security issue, or just something that plain doesn't work- Mm-hmm... you want a developer to be able to understand why without just trusting that the AI bot's gonna fix it if you go and ask it. Mm-hmm.

Um, you know, and certainly from a security perspective, uh, there's been a bunch of studies done recently where, you know, a vulnerability has been exposed. Uh, an AI, an LLM has been asked to fix it, has done, but it hasn't necessarily patched the whole issue, or it has created bugs and security vulnerabilities on top of, you know, the one that it just fixed. And so, you know, you still need the engineering talent to sit there and deal with this type of stuff, um, to make sure that, you know, they can get the stuff out the door. But as we found out recently, um, like, um, like releasing Claude code to a developer core can ruffle feathers because at the same time you're asking them to start like reviewing a lot of pull requests and understanding what the LLM is doing rather than sitting there and writing code, which I get from a, from a, as a, as a grumble. If you're a developer and you're happily writing, you know, your React code, and then suddenly one day you're like, "Okay, now you've just got to look at these pull requests," I can understand why that would be annoying.

But at the same time, um, you know, you have to be able to, you have to be able to, um, understand the engineer's gripes and grumbles and, you know, possible discontent whilst also trading that off against the fact that you can just ask an LLM that costs next to nothing compared to a developer's salary- Mm-hmm... to do the thing. And so, um, you know, product development has changed a lot, both in terms of like the timelines and stuff it's achievable and the s- the things that you might put in it. So of course, you know, we look at MVPs a bunch, and like what you used to m- what... Yeah.

What you may have used to ship as an MVP in terms of like the amount of functionality and stuff that went in it, your MVPs can be vastly more complex than they were- 12, 18, 24 months ago, which means, of course, from a product delivery perspective, you then need to put more thought and effort into it. And so the constraint from an MVP or from a, like, testing the market perspective is no longer, like, how many features and functionality can I build because a team of three or four people can create a fully functioning platform of some sort. Um, but it's like what needs to go in there from a product perspective that allows us to understand whether there is the market for that product in the first place, and how a user is gonna react to stuff. Form, right? And this is about trust signals, and it's about the signals that people get that may or may not be true, right?

They can look at a platform that looks polished, that looks complete, and then, you know, time is gonna tell you if they're actually using it or not, right? Like, you still need to go... This is, like, I don't want to say the danger of AI to say that it's just AI. It's the danger of any technology that moves forward quickly, right? That, that moves, tries to move past this principle to s- that forgets that humans still interact at the pace that humans interact at.

Which is to say that they still need to know if the core offering whatev- of whatever they're doing is actually picking up traction, um, in their customer base. And there's a certain skill in knowing how to distill what is the essence of a product, right? And being able to stay, uh, true to that through line. Um, yeah, no, I mean, I, I think, I think- I was g- I was gonna say, go fever is a real thing. Yeah.

Especially with AI. It's like, go, go, go. Yeah. We must move 100 miles an hour, and that's, you know, what, what we see a lot of. Anyway, we will move on in a second.

I have so much feeling on that. She has so much feeling on that. That sounds like another episode in its en- in its entirety. The same minds that worked on the last Mars rover now work on yours. Concept to Cloud builds startup MVPs that perform.

Concepttocloud. com. Okay. Welcome back. Part three, the final episode, part this episode, this gargantuan installment of the, uh, Concept to Cloud podcast.

Thank you very much for joining us once again. Uh, we're gonna talk about the way the internet did it, which is, uh, if you read the newsletter, um, part of, uh, Amelia's article in there. So- All righty... here's where- So talking about rebuilding and why rebuilding is scary, and from a product perspective, how to do a proper, uh, rebuild, right? And so this, to do a rebuild, you need to take into account that if you have a service that your customer depends on, you can't just change the interface and the usability of that service.

Nobody has time to sit there and study and read your docs and to know exactly how you've changed things, what you've done. It needs to be pretty seamless. And so the example that comes to mind for me, uh, is thinking about the way the internet's changed over the last 30 years, right? We started from dial-up all the way now to, like, gigabit, and at what point did civilization shut down and say, "Oh, well, we're not gonna have internet for, like, two months, you know, until, well, we, well, we go up to the next phase"? Like, it never happened.

And it... and that's an, an amazing feat of infrastructure, right? Like, it's, you know, we sit here and we talk about digital products, but that is a physical product of infrastructure that, you know, technology, governments, um, all over the world have made possible without any visible intensive disruption. That's incredible. Like, I think that's, I find that to be incredible, and I find it strange that in this era where we push out software so quickly because we know people will digest things, it will, they will use things, like, you know, a user will just chew through all different types of software, um, we don't ensure that same experience, right?

And I think a lot of the times that contributes to why a product sunsets sooner than maybe it should've. Because we didn't think about what the user need next, what the user needs next, and how we, um, move that product forward to meet them in a way that doesn't break their experience, right? Like, a lot of the times we'll use products that just we don't use it anymore. We don't have a use for this. There's another technology that exists, and, and that is also, you know, I can make an argument against myself and say that's kind of the nature of technology.

Another one will pop up somewhere and people will just lean to that. But depending on, uh, the product itself, I think there are a lot of products that just say, "Well, this is it. This is our one trick. This is what we do," and then they're done, you know? And so a rebuild is something that has to be done very thoughtfully, right?

I think it's, it's, it's about, yes, it's about user research. It's about listening to your customers. It's about, um, looking outside of the scope of your product to understand what they're doing. It's also understanding that your product side and your engineering side [laughs] need to talk to each other and really understand each other because very likely you've already got the capacity there to do the rebuild. It's just how you funnel it out.

Um, and I think that can just give a lot of longevity to products that exist. I think that's a fair point. And then also in the newsletter, I was talking about, um, you know, especially for on-prem stuff- Mm-hmm... every, uh, feature request or feature discussion that you have with a customer is really an upgrade discussion. Because of course, you know, if they ask for something and you've got to ship a new version, new version of Sequr, the renew on-prem, new version of Kinetic Recorder, but it's also not just them.

As a product organization, you have to think about is everybody else in that ecosystem. Like, one customer rings up, you know, I don't know, Samsung rang up and they're like, "Oh, we'd like this, like, new dashboard feature, please. " Like, "Okay, not a problem. " But in reality you say, "Okay, not a problem," but how does that impact from a product perspective everybody else that, you know, is consuming your product? Someone's using Kinetic and they're like, "Well, actually I'd quite like to have my face in the corner of the screen whilst it, like, whilst I'm recording a demo.

" Like, you know, how does that get built is, you know, a serious consideration so that it doesn't impact other people who do not want to see their head in the corner of a window. You know- Mm-hmm... there's, it, the, all that type of stuff has to be taken into consideration and, you know, it, that, that type of stuff is A far bigger conversation than quite often I think we give it credit for in terms of im- like, you know, trickle-down impact to other customers. Yeah, absolutely. Right?

So I think it's, it's easy to say like, "Hey, let's build this feature," right? And when you're saying, "Okay, let's build a feature for a Mac," or, "Let's build a feature for an iPhone," these systems already have a ton of constraints. But when you're building a product that's just saying, "Here's a product and you can use it on whatever system you have," whether it's on-prem, whether it's your personal devices, whatever it may be, right? Um, there's a limit to what we can do, obviously, to how compatible we can make something. But, um, a lot of time and care needs to go into making sure that if we say, "Okay, you know, Samsung, we can make this product for you," you don't want to create an imbalance in the experience of your customers either.

It's, it's, "Okay, how do we take this thing that one person wants, and then how do we make it available to other enterprises," right? Or, "How do we set this at a level that other enterpr- people at this tier can also use it," right? Or, you know, kinetic recorder we talked about, y- you know, the video in the, in the small side of the scr- in the corner of the screen. It's a tiny thing. It's a common request.

It's, it's not a big deal. But as a small shop building this, it's like, "Okay, well, how do we do this in a way that works with... Now we have all this data from Zentry on all the different types of users that we have and all the different types of systems that are coming in. How do we do this and take the time to make it so that it works on every system, it deploys properly? " Um, this is of interest to me because, you know, you as an engineer have more familiarity with it.

Me as a zero to one builder, I have no familiarity with it, right? And it's a conversation that we have regularly, which is a lot of me just being like, "Oh my gosh, how do I do this? " Right? But a, a lot of that is, is learning how to execute and implement the UX principles that we sit there and talk about from a product perspective. And it's like, okay, actually, what does it take to, to make this happen for someone?

Um, and what it takes is a lot of time. What it takes is a lot of time. Um, and, and, you know, and AI can direct you, it can guide you, and you can learn along the way, and we're still in the early phases of that. Um, and AI is great for a product person because it can just go and say, "Okay, do all of this stuff," you know? And he will, he or she will do it, or it will do it to [laughs] Uh, there's a poll.

What gender do you associate your AI with? Anyway, um, but to, but to what caliber, to what quality- Mm-hmm... to what, um, level of completion. It's, it's a tricky thing, and it takes a lot of time. That's cool.

Um, yeah, no, that's, uh, again, that's another conversation for another day as well. Um, you know, a lot of these things we can continue, wax lyrical on for, I think, for, for a long period of time. Um, okay, so to round this, uh, episode out, uh, the bill arrives late, which is part of what I was writing in, uh, my article in the newsletter. Um, you know, because we talk about upgrades, we talk about on-prem a fair amount- Mm-hmm... in this, in this episode.

Um, you know, and just because you patch something in a version doesn't mean that the other person is then going to deploy it. You know, if you've got 1,000 customers, 1,000, 1,000 installs of Seiku, for example- Mm-hmm... and you fix a critical vulnerability- Mm-hmm... doesn't necessarily mean that tomorrow 1,000 installs are suddenly gonna magically get updated. Which of course, if you're running a SaaS platform, you upgrade it all for them, everything becomes transparent, and no one ever sees a thing.

Um, but of course, what that then means is that for those who have either skipped upgrades or, you know, come at it four years late because suddenly their CISO's kicking off because they've got a security vulnerability and everyone's now suddenly worried about AI, you know, hacking into all these systems, and people start to take it a bit more seriously, um, that becomes something that you have to be able to manage as a product as well. Is like, you know, if you've got a user who's on version three of something, and you're, you're up to version seven of something... Um, actually, uh, to, to name drop, I saw Chris Mattmann, he sent me a, um, a screenshot yesterday where he'd upgraded Lucene from version six, which I think was back when I was working at JPL, so sort of 10 years back, back at the start of JPL, so like 10 years ago, and he upgraded to version 10 today, yesterday. And I, I think judging by the, uh, swear words I got in the message, it took him a while. Um, you know, because this is...

But this is something, you know, from an open source perspective, you have to be able to, be able to deal with these things. How do you go from version six to version 10? What needs to get changed? And so you need to be able to support your customers through that process. It doesn't necessarily mean that everything has to be automated, but they do need to be supported on how to get from one version of something to the next.

And again, it's not an engineering task per se, but it's still a product task, and something that people have to, like, take into consideration is how do you deal with installs, upgrades, you know, and when things go wrong especially. Right. Well, I think there's a couple of things there, right? When you, when you wanna make that upgrade, you've done the engineering work, but now as a company, as a small company, as a mid-sized company, whatever it may be, how do you now change your capacity from engineering to support, right? Because you're gonna need to figure out...

You're basically c- just gonna need to be there to be like, "Okay, this person's having a problem. " You know, if you have a Slack channel, people are just gonna come in, and they're gonna start flooding you with all the bugs, all the issues, all the, all the stuff that they're struggling with. Um, hopefully nothing that they've lost in, in the transfer. Um, but if it's on-prem, if you don't have the access to be like, "Here, we're gonna automatically update your software," you know, every couple of weeks, months, whatever. It's about earning trust and knowing that people have the security to say, "Well, I have a business that I run that is, um, careful enough, secure, that That is contained enough that I need to run it on-prem.

And so you need to be able to know, people need to be able to know that you're gonna carry them forward safely, that they're not gonna lose any functionality, that they're not gonna have an interrupt in their service, right? That they're not going to have any blips in their business for whatever you're, uh, doing. So that tr- all those things, um, become incredibly important just for the trust signal of your, of your customers, right? Um, Seku, you said you s- you're speaking to what? Like 180 people.

But the first Seku came out how many years ago? 2016. So 10- Eight. 2016, 10. Yeah.

I can't add. 10 years ago. I think it was 10 years ago. It may have been longer. It was definitely, and it was a pento analysis tool before then.

Was then. So it's, um, it's been around for a while. Yeah, but this is the thing, and so, like, you know, uh, uh, going full circle, going back to where we started about, like, being able to understand where your users are, who your us- users are, or why we put telemetry pingbacks in stuff is, like, because you can't support the customers that you can't reach. Mm-hmm. If you have no idea who they are, and I'm talking about free users, not paid customers, 'cause generally if they pay, you probably know where they live.

Um, but you know, I, I consider in the open source world, anyone that downloads the software and use it effectively a customer. I value their feedback. I want to be able to support them- Mm-hmm... in their journey in using whatever piece of software I happen to be releasing. But if you cannot reach them, you cannot help them.

And so that becomes critical in, you know, in, in what we try and do when it comes to the outreach, and also from a product perspective and talking about features and all that type of stuff is, you know, you can, uh, never answer a need that you've never heard. Because if you don't know that person exists in the first place, how can you ever help them? And I think, you know, taking all that into account and sort of bringing this discussion all the way back to the start again, is stuff as product people you have to pay an awful lot of attention to. Because, you know, you need that type of, of backwards and forwards between your users being free or paid, and your product roadmap, and the product people who define the roadmap so that they can better tailor that roadmap for everyone's use cases. Yeah.

Absolutely. Um, and, and just to kind of finish that point, you know, if it, it was 10 years ago, like people have gone through so many different avenues of technology, and you have no idea where they're implementing Seku, how they're implementing it, right? Um, but they're still going back to the repo. They're still using it. Um, and you know, there are ways for people to reach out and give feedback and such.

But, um, building as much as you can so you can hear from them, um, is critical because those people have been loyal to that platform and, and you wanna be able to service those customers, right? And you wanna understand why, with all the different things out there, why they choose to go back specifically to that platform, to something that is that dated, right? We've reached the end. I think we've reached the end. Yeah.

Um, so [laughs] uh, thank you very much for taking the time to join us. I hope you found some of this, uh, discussion and insight useful. Uh, thank you to Amelia for joining me. She'll be back in a couple of weeks for another discussion, which I bet she cannot wait. Um, thank you very much again for taking the time.

This has been the Concepts of Cloud podcast. My name is Tom. If you need to, uh, if you need any help and assistance in anything that we've discussed today, product related, engineering related, or whatever, you'll find the links and everything in the description. Um, and make sure that you like and subscribe, share this podcast with all your friends. We need the listeners.

Thank you very much for tune- tuning in once again. We'll see you soon. Bye for now.